God Gui Widget

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 "<widget...>...</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.