Addressing Gui Elements

Issues to consider for addressing/referencing GUI elements:

How are long paths addressed?
How can relative path addressing be implimented?
How do we keep pre-selected widget/object ID's/names unique?
In what scope range do we keep pre-selected widget/object ID's/names unique within?
When does unique name verification happen?
If a given name is unique within a higher level (document, panel, window, etc.), how do we select which level to make it unique relative to? (Is the level hard-wired into the tool-kit, or selectable?)
Do we sometimes want explicit names and sometimes want auto-numbering or internal numbering for different widgets and/or circumstances? (Perhaps with potential overlap such as a numerical address for every object, but optional additional reference names, such as "myStatusBarWidget".)

Addressing GUI elements is not as simple as it might seem at first. In the old days you could have a 3-level path-based-approach such as:

  windowX.widgetY.value = 7;

And all was well.

However, to allow more flexibility and complex GUI's, a GUI tool-kit should be allowed to nest widgets. For example, within a window there may be a left panel and a right panel to group widgets (perhaps with a slider/sizer in between each). But within these there may also be sub-panels for finer grouping.

Another example consider this nesting:

Application MDI window
- Window for data entry
  - Panel for data-grid area (may include buttons, links, etc.)
    - Data Grid
      - Column X
        
        Row Y
        
        Cell (container)
        
        Checkbox widget
        
        Widget attribute

Obviously we don't want to reference such a long path for most references. Widget ID's are often used in DOM, but being relative to a "document" can present problems for shuffling stuff around. An individual ID or name has to be relative to something to assist with name-space management.

We don't want to import two sub-panels with the same widget markup into a "document" and have ID conflicts. Pre-selected ID's will have this problem. In such cases we would want to use path-based addressing, but not necessarily from the application root.

If we hard-wire it from the application root, then it's harder to move around. It's roughly comparable to using an absolute URL on a web page versus a relative URL. Relative URL's make shuffling stuff around easier. However, most GUI systems don't allow relative widget addressing. Perhaps a GUI kit could learn a thing or two from URL addressing.

--top

Do you mean using pointer centric Employee ID's! An employee ID is a number, like a windows API handle, that points to or references the widget. Useless for humans, since numbered widgets don't mean anything to humans - only english descriptions mean something to us. By the way, it sounds like you are inventing an Object Oriented GUI which uses tables as configuration, LOL.

I'm not sure how you are classifying something OO versus TOP. Anyhow, one approach is that every widget would get some kind of internal ID number, but there would also be optional named ID's. Perhaps call one widgetID and the other widgetName. The widgetName would be what we'd use in a program for explicit references.

You've said before you don't like pointer hopping or narrow tables since they are "pointer centric". Isn't a widget ID like a pointer - just like in the windows API where you have a handle, which is a number, but it is also a pointer. It appears you do like "pointer centric" and you think something which points to something is "relative".

  var
    p: pointer to Button;
  {
    long.widgetname.path.Button.color := green
    // set up pointer to Button
    p := long.widgetname.path.Button;
    p.color := red;
    p.color := orange;
    // above is same as longform below:
    long.widgetname.path.Button.color := orange;
  }

The pointer (p) is a shortform for the button so that you don't have to type out the long path. People use pointers for shortform in C and C++ all the time.

I don't see any "hopping" here.

The above is using pointers, so what is pointer "hopping" then? And why do you think narrow tables are pointer hopping in addition to being pointer centric?

Please clarify reference to "narrow tables".

In my opinion, the GUI should be specified via some kind of XML-like markup (such as GuiMarkupProposal). However, it may also have a TOP equivalent, a JavaScript (client-side) equivalent, a C equivalent, etc. I see the GUI engine as best being managed by a lighter-duty database of some kind and most communication to the GUI engine is via the markup language or through SQL as best fits the situation. (SQL because it's a familiar query language, not because it's the best query language). It would no longer be tied to a specific app language, such as JavaScript, Java, TCL, etc. And an SQL query interface would make debugging much easier than manually traversing a DOM tree or the like.

Whether the RDBMS representation would best use "narrow tables" or the like depends on the what kind of GUI specification design is settled on. The current crop of RDBMS engines kind of limits our flexibility compared to say DynamicRelational, but we can perhaps find ways to work around it. If we use the existing "static" RDBMS, then I have somewhere on this wiki proposed a general "GUI-Object" table for traits that almost all GUI elements have in common or could have in common if we change their "type", which should be permissible. Then an AttributeTable would be used for widget-specific attributes.

I would at least suggest that the "reference implementation" be in a RDBMS, but some may want to build a lighter footprint version in C or the like, and use RAM address pointers instead of "object record ID's". One is going to give up some some X-ray-ability by doing such in exchange for being hardware-friendly. It's best to go backward from a reference framework that is developer-friendly to a hardware-friendly one than the other way around. We want our tools shaped around being human-friendly (developer-friendly), not being machine-friendly first. Hardware or optimization maturity usually catches up.

See TableOrientedGuiDiscussion for name-space management suggestions.

Discussion