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

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

Warren W. Gay VE3WWG wrote in message <3E51A55A.3000101@cogeco.ca>...
>Randy Brukardt wrote:
>> Warren W. Gay VE3WWG wrote in message <3E5121BD.4010200@cogeco.ca>...
>>
>>>For input and output callback arguments, I use a discriminated
record,
>>>which then allows Ada95 checks on record members according to the
event
>>>type (ie. the record variation). This is something I wish GtkAda
would
>>>use.
>>
>> That doesn't work well if you have callbacks which are evolving (as
most
>> real-world GUIs are). Adding a new variant to a record can break
>> existing code (think aggregates, think name conflicts), and will
require
>> recompiling everything in sight.
>
>I don't find this a particularly good argument. I want the code to
break
>if I change the callback requirements, even if just for one event.
>Any structure changes are all localized to the variant
>record, so it is very easy to locate conflicts (or simply let the
compiler
>do it for you). Of course not all variant record violations can be
>detected at runtime (some can however).
>
>As far as "recompiling everything in sight", I feel this is not a good
>reason to avoid it. If a recompile is necessary (which GNAT _can_
determine),
>then let it compile away. This is an automatic process.
>
>Reluctance to recompile suggests that your goals are not in sync
>with the end user's--  ;-)


Most end users that I'm familar with don't want to have to rewrite all
of their programs because we've provided an updated version of the
interface with a few new features. That requires the interface to change
as little as possible. Even adding a parameter can cause problems with
extensions of a type. Adding visible components (which breaks all
aggregates) is simply not acceptable.

>The end goal, IMHO, is to produce a library that provides the best
interface
>to the user; not to be convenient to the library developer ;-)


There is nothing "convenient to the library developer" about either of
these "solutions". The best solution is to not have the problem in the
first place. Thus, we use dedicated action routines (callbacks) whenever
possible. The only place that we use any sort of variable data is in the
lower-level Notification interface, and that's because Microsoft gives
us no choice.

Note that the notification interface in Windows is defined as a set of
overlayed records, using which ever one is appropriate for the current
message. There is no "variant" and certainly no discriminant. And each
new thing Microsoft adds creates a bunch more of these.

The big problem with the variant interface is that everything has to be
defined in one place. That's usually not practical. The notification
data includes various data types specific to each of the types of
controls. 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).

We recently completed a project eliminating as much unused stuff from
user programs as possible. 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. 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.

>The X11 software (a real world GUI, BTW) uses a finite number of
members
>in the XEvent union (albiet in C, and certainly inferior to any Ada95
>variant record).  This model has been well proven and works well. The
>bonus is, that if you insist on a very general structure, this too can
>be accomodated in a variant record with a system.address or some such
>kludge. But at least that kludge is optional, and perhaps temporary as
>your GUI evolves to perfection.


If you're mapping an existing union, you're way ahead of the game. But
that's a pretty limited GUI (and calling X11 a GUI is a stretch).
Windows doesn't work this way, and I doubt that many of the higher level
GUIs built on top of X11 do, either.

                 Randy.