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

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Randy Brukardt wrote:
> Warren W. Gay VE3WWG wrote in message <3E53CCDF.1090509@cogeco.ca>...
> 
>>Randy Brukardt wrote:
>>
>>>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.)
>>
>>I won't disagree with that. In fact, to some degree, I think you've
>>managed to successfully present the tagged record approach as a good
>>callback approach for two reasons that I would consider key:
>>
>>  1. Reduces one central "definition" of the event to a base type (or set)
> 
>>  2. Allows easy extendability of the event object as new widgets
>>     are developed.
> 
> Yes, exactly. These are precisely why we used the tagged approach.

It took a little convincing, but I am sold on this now ;-)

>>>>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.
>>
>>From a "client perspective", I would agree with this. But with my
>>library writer's hat on I don't because that means I have to define
>>different collections of callbacks. Whereas if you define one type
>>of callback interface, say something like:
>>
>>   procedure Callback(W : Widget_Type; Event : Event_Type'Class;
> 
> User_Data_Ref : ...);
> 
>>then you can centralize code to call a callback list, add to and delete
>>from the callback list. All widgets can then be built to use the same
>>resources.
> 
> Remember the ease of writing is WAY down on the list of good things for
> Ada, 

Yes, I agree with this.

> and we certainly followed this approach with Claw. Our goals for
> the interface were (not necessarily in this order):
>    -- Avoid unnecessary overhead in the implementation of the interface;
>    -- Insure that the interface prevents common errors, preferably at compile-time;
>    -- Make the interface easy to use for the client.

I tend to put "overhead" in the lowest category as long as the overhead
is "reasonable"; at least for projects like a UI. I would personally
rate your last two points higher for example, if I were to rate them
(all of them goals that I would agree with).

> Our effort in writing the interface was never an issue. Of course, we
> expect many people to use it, and thus the effort spent in meeting the
> goals will pay off over time.

That's what I prefer to see, for sure : long term goals with long
term payoffs.

>>Ok. You have sold me on tagged types for the event info. However, I
>>still some application for variants within those tagged types ;-)
> 
> Like Marin, I'll never say "never use" something, because that's silly.
> If a variant makes sense in a particular extension, by all means use it.
> But the base item should be a tagged root type of some sort, not a
> massive variant.
> 
> I think we finally agree.
> 
>               Randy.

Yes. In fact, more than this.. 8-O

I liked your idea of taking what I call the "application
context" object and extending it to provide the access to the user data.
By doing this, I was able to eliminate a system.address and a ghastly
generic procedure to convert address to User_Data_Ptr.

The only downside
to this, is that the user must continually "convert" the ACTX_Type to a
User_Data type, to reference members (the ACTX_Type is a controlled limited
type).

     type User_Data is new ACTX_Type with
        record
           Whatever : Boolean;  -- User data member(s)
        end;

     procedure Callback(ACTX : ACTX_Type'Class; ...) is
     begin
        User_Data(ACTX).Whatever := True;
        ...

I suppose if you have many refs to the user data type, you can call
a procedure with the type converted as in:

     Yet_Another_Proc(User_Data(ACTX),...)

where

     procedure Yet_Another_Proc(UD : in out User_Data; ...) is
     begin
        UD.Whatever := ...;

as either an internal or external procedure.

Thanks for the effort of convincing  ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg