Based on a discussion in GuiConfiguration where widgets are defined by selecting from a buffet of choices rather than inheriting. I believe '''hierarchical sub-typing limits options and thinking'''. For example, there's a lot of conceptual overlap between "button" and "hyperlink" and one may want to use features of one for the other in some cases. The term "God" here sort of means the same as a stem-cell: something that can become many other specific things. See GodClass for a comparison. I challenge anybody to identify a "hard" distinction between widget "types" such that widget sub-grouping X will never ever have features of sub-group Y in a practical sense for all conceivable existing or future products and gadgets. Somebody once suggested that a button that doesn't do anything (has no events) was useless. However, I later thought about a game with bunches of buttons where most don't do anything but a few have activities. Such is sort of like Battleship, or Windows Mine-Sweeper in reverse. There could be patterns to titles on the "active" buttons such that one uses clues to narrow down probable hits. Your score is the number of hits per buttons clicked. Some still seem silly, like a table/button hybrid, but perhaps there's a use for such that nobody's thought of yet. --top ''If it is a stem cell that can become many other things, you've just discovered OOP techniques. A widget can have a base behavior but then custom widgets inherit the base and change the widget for custom needs.'' OOP didn't invent defaults. Further, non-trivial hierarchical inheritance has proven difficult in practice (see LimitsOfHierarchies). Branch A may find it needs something from branch Z. You can't just borrow across branches with hierarchies. More sophisticated forms of inheritance needed to overcome these weaknesses start to resemble sets (SetTheory), but in a poorly-done way. Sets are generally what I propose for managing myriad variations-on-a-theme. -t {So you say, but you've never provided a demonstration of it. Where is your description of a general set-algebra for defining variations-on-a-theme? How does your proposal differ from SETL? Etc.} Yes I have, I just forgot where I put the sucker. ''Sets? Aren't you a promoter of bags, not sets? When you link to pages like SetTheory I find this funny, as if in this case science/math is important, but in other cases it's tied to psychology, and not theory.'' I've said many times that sets work for the majority of cases. It's nice to have the OPTION of bags when it's a better fit. PickTheRightToolForTheJob. And let's not drag the "bag fight" into this house also. ------- This is a GUI widget interface meant for illustration at this point. A much fancier one can be designed, such as polygonal borders and border areas. "Compound" widgets will be described later. '''Widget''' * widget_ID * widget_name // optional reference name for programming * Value // text, markup, or field value * Width * Height * Tab_order * Prim_Img // primary background image * Alt_Img // alternate background image (defaults to primary if none supplied) * Click_Img // image displayed while mouse is down (defaults to primary if none supplied) * Roll_Img // image displayed when mouse rolls over (defaults to primary if none supplied) * Border_color // (defaults to transparent) * Border_width // (defaults to 0) * Option_tag_on // Boolean, triggers a down-arrow to indicate options are available * Option_tag_orient // orientation of option tag (compass-style: n,ne,e,w, etc.; default to "e".) * State // std, hidden, hover, down (pressed), selected * Has_Focus // Boolean * List_Ref // name of list (may not necessarily be a text list) * Slide_pct // slide percentage for slide-bars and similar widgets * Slide_drag_img // image of slide knob or handle. Transparency allowed for shadows. (Alpha-channel?) * Some custom widgets will need custom fields. Ideally, DynamicRelational would be available. If not, then an AttributeTable could be used. '''Event Message Structure''' (A message generated by an event) * widget_ID * container_ID * event_type // mouse-down, mouse-move, mouse-drag, text-change, etc. * widget_x // position of widget relative to container * widget_y // * mouse_x * mouse_y * mouse_start_x // initial mouse pointer position if button down (such as dragging) * mouse_start_y * source_widget // widget ID of "start point" widget if dragging or mouse-linking '''Event''' * event_ID * event_name // optional reference name for programming * implementation // code snippet or function/method reference name/ID * '''Event_Register''' * widget_ref * event_ref * priority // double-precision * trigger_type // on-click, on-focus, etc. ------- Sounds like you want a WebGL or SVG canvas. ''Canvas? There may not be a need to make a hard distinction between a widget and a canvas. For example, A panel in one context should be able to be treated like a widget in another, responding to the same events as a widget would (if applicable to that item). In other words, uniformity in treatment. '' -------- If one was implementing a GUI markup language (GuiMarkupProposal), it's still helpful to have "dedicated" tags such as BUTTON or INPUT (box). However, that doesn't preclude the inclusion of a generic GUI widget "..." that can potentially be any of the others, if so configured (via attributes). Specific tags such as BUTTON would simply apply the appropriate defaults for a "typical" button. --------- See also: BigIdea