Talk:Honeycombs: Difference between revisions

From Rosetta Code
Content added Content deleted
(I think it'd be best to let the implementer worry about that.)
(That was the answer I wanted!)
Line 26: Line 26:


By a widget, I meant an on screen component that has its own set of properties and is capable of reacting to events.
By a widget, I meant an on screen component that has its own set of properties and is capable of reacting to events.
<br>

[[User:Markhobley|Markhobley]] 16:37, 26 May 2011 (UTC)
[[User:Markhobley|Markhobley]] 16:37, 26 May 2011 (UTC)

: OK, that's cool. I have just the thing in mind then. (Part of the problem in the general area of GUIs is that there's no standard terminology, leading to this sort of discussion.) –[[User:Dkf|Donal Fellows]] 19:57, 26 May 2011 (UTC)

Revision as of 19:57, 26 May 2011

Just some observations (not criticisms):

  • The hexagonal shape of the widget will be interesting, as GUIs normally use rectangular bounding boxes. A rectangular box used in drawing will require one of three solutions to avoid overdraw:
    • The use of a drawing mask
    • Transparency in the widget's drawn image
    • A tileable rectangular pattern not 1:1 associated with the widgets themselves (i.e. drawn as a background, with transparent widgets on top)
  • The rectangle/hexagonal dissociation will be interesting for pointer hit checks, too; a rectangular widget would need to detect that the pointer check is outside its hexagonal region, and then it would need to be able to have that check passed on to the tiles below it.

--Michael Mol 18:10, 25 May 2011 (UTC)

Question: Must the widgets be represented as distinct objects in the code examples? If so, that would preclude the use of things like the wp:Flyweight pattern, which strikes me as a particularly appropriate tool for this problem. --Michael Mol 18:10, 25 May 2011 (UTC)

Personally, I would imagine that a rectangular background should be permitted. I would also imagine that any implementation of "widget" should be permitted. Finally, I would imagine that the task's slippery use of "honeycomb" (initially it's the collection of widgets and later on it's a single widget) and color (initially all colors are the same and later that becomes a non-specification) should be ignored. --Rdm 20:04, 25 May 2011 (UTC)
Ok, there were some changes made. On the selection of a hexagon, should the previous hexagon's 'selected' appearance/state be cleared? (i.e. should any previously-selected hexagon return to its original color?) --Michael Mol 20:12, 25 May 2011 (UTC)

Mark, you might consider uploading a simple image (a low-filesize PNG would be perfectly appropriate) to illustrate. (An animated GIF to demonstrate behavior wouldn't be bad, if you can swing that) --Michael Mol 20:20, 25 May 2011 (UTC)

It was looking good, but I think the requirement for the message output and the each-hex-only-once made it more complicated than the gains in illustrating the concepts involved. The user will know that X was selected because the hex changed color, and I don't see the illustrative benefit of each-hex-can-change-only-once. --Michael Mol 02:56, 26 May 2011 (UTC)

Maybe we can drop the message, and just keep a record of which hexagons have neen clicked. Depending on how the widgets work for the language, we could either set this as a property of the widget itself, or keep the information in a separate array. We can then use this record to programmatically prevent reacting to already clicked hexagons. I am open to suggestions on the wording here.

That's something that's probably best left unspecified so that it can be left maximally to the discretion of the implementer. What's significant is that the on-screen and interactive behavior is preserved, right? Let the implementer worry about that. --Michael Mol 16:45, 26 May 2011 (UTC)

Markhobley 16:37, 26 May 2011 (UTC)

This reminds me of a gameshow that used to be on UK TV. More on topic, would it be an acceptable solution of the task if there was a single containing widget containing a grid of hexagonal active regions that can be colored/highlighted appropriately? That's much easier to implement… –Donal Fellows 09:44, 26 May 2011 (UTC)

Without a definition of what a "widget" is, which goes deeply into how widgets are implemented, you are asking for a meaningless distinction. And, personally, I do no think we should be asking for that kind of definition -- I think it would be micromanagement and language-specificity of the sort we try to avoid here. --Rdm 11:34, 26 May 2011 (UTC)

By a widget, I meant an on screen component that has its own set of properties and is capable of reacting to events.
Markhobley 16:37, 26 May 2011 (UTC)

OK, that's cool. I have just the thing in mind then. (Part of the problem in the general area of GUIs is that there's no standard terminology, leading to this sort of discussion.) –Donal Fellows 19:57, 26 May 2011 (UTC)