Re: [OT] Best way to isolate a GUI?

["Randy Brukardt" <randy@rrsoftware.com>]

Warren W. Gay VE3WWG wrote in message <3E52A1BF.1020809@cogeco.ca>...
>Randy Brukardt wrote:

>> The big problem with the variant interface is that everything has to
be
>> defined in one place.
>
>Why is that a problem? XEvent does this too. So?


Keep reading...

>> That's usually not practical. The notification
>> data includes various data types specific to each of the types of
>> controls.
>
>OK, I can see that you might have some package interdependency
>issues, depending on the data _types_ being used. I do believe
>however, that careful planning can avoid these problems.


Not practical, unless you plan to eliminate most type checking (that is,
most of the advantages of Ada).

>> If we had to put all of that in the spec. of the Claw root
>> package, we'd more than double its size (and its already 5000 lines).
>
>So? What problem? Longer compile times? Is that what we're worried
>about? It may be a consideration, but not necessarily a
>deciding factor.


Readability, of course. And excess coupling. (It's the coupling that
causes other things to be dragged in).

>> If we had used a variant solution, there
>> would be no possibility of that, as every possible control would have
to
>> be reflected in that variant.
>
>This is patently false.
>
>I don't believe that just because a variant record is used that this
>eliminates the possibility of a cleanup.  The reason is this: you only
>carry _EVENT_ data in this variant record -- not widget internal data.
>This event data can be used to communicate with many widget callbacks.
>
>Perhaps you misunderstand what I am suggesting here -- I am not
>suggesting widgets in a variant record. Oh, no! Only _event_ data.


I'm only talking about "event" data. Let's look at some of the
notification event data.

For a tree view control, the standard notification includes the
following components:
     Old_Item_Handle, New_Item_Handle, Old_Item_State, New_Item_State,
Old_Item_DWord,
     New_Item_DWord, Action, and Point.
The notification gets sent when the selection changes, when an item is
expanded (or contracted), when an item is deleted, when an item is
dragged, and more.

In order to make this into a possible variant, we'd have to pull all of
the handle and state declarations into the root Claw package. (States
are usually private types in Claw along with a set of constants and
operations -- no direct bit operations). That would be a lot of excess
coupling. Moreover, we'd need to do that for every type of control that
has its own distinct state; there are around ten of them currently.

We'd also have to expose (unsafely) much more of the low level guts of
Claw. For instance, we use the 'user-defined dword' to hold an access to
the Ada version of the item. In our interface, we simply declare this to
be:
        Old_Item : Claw.Tree_View.Any_Item_Access_Type;
But, if we moved that to the root Claw as you suggest, we wouldn't be
able to use the access type (not without moving the bulk of the
Tree_View package into the root Claw -- surely you can't be suggesting
that!). So, we'd have to open this up to some sort of user conversions,
both more error-prone and more likely to be abused.

Of course lumping all of that into the Claw root package makes all of
those things harder to find, as it is no longer declared with its
related code. Root packages should be as small as possible, not full of
unrelated garbage.

Anyway, my position is very simple: minimizing coupling is good. And
having to put stuff in a variant in a root package that doesn't
logically belong there is unnecessary (bad coupling).

>> Since we used a tagged type, we don't have
>> to drag in Tree Views unless the user actually withs Claw.Tree_View.
>> (That was happening for another reason, and the internal
restructuring
>> eliminated that.) That cut the average size of Claw programs by 500K.
>
>Look at the way XEvents is defined. It does not define a member for
each
>widget. It defines a view for each _event_ type. The members correspond
to
>needs of the _event_ _communication_.  Nothing you have said has
invalidated
>this approach.

I think you have a completely different idea of what an event is than I
do. You're thinking at the level of X11, which is a low-level graphics
environment. It has very simple events like "mouse moved" and "key
pressed".

While those are clearly events, there are also events specific to a
particular control (or widget, if you prefer), like "Button pressed".
And most importantly for this discussion, there are events that are
meaningful for many controls, like "item selected". The data that gets
sent with a "item selected" event is specific to the control that sent
it, but the event is common to all controls.

>> But that's a pretty limited GUI (and calling X11 a GUI is a stretch).
>
>Um, MOTIF, which is used UNIX-wide, is entirely built upon X11.
>Not to mention that Gtk also builds upon X11 in the environments
>that require it. The X intrinsics build upon X11 to provide the
>widget foundation and callbacks, that other widget sets in X use
>(like MOTIF/LessTif).  All of these layers use callbacks and
>event data. If this aint a serious GUI, then tell me why
>the LessTif team has taken several years to duplicate MOTIF 2? ;-)
>It is, and continues to be.

MOTIF is a GUI. X11 is not; it's more of a toolkit for building GUIs.
Windows is built on top of GDI, but I don't think anyone would call GDI
a GUI.

In any case, my point is that there are a lot more kinds of events in
the full-blown GUI than there are in X11 itself. (I should point out
that its been years since I've had any reason to look at X11, so I'm
working from old memories of X.)

>But my point has always been in this
>thread is that there has been no good reason given that event data
>cannot be provided in a callback parameter as a variant record.


For simple events, I prefer to simply provide the data as parameters to
the action routine (the event handler that you override in an OOP GUI
like Claw). And, if the events are sufficiently different, I'll provide
different routines for them. For example, I certainly see no reason to
share the handler for a keypress and a mouse click. That usually
eliminates the need for complex data structures of any sort.

            Randy.