Re: CORBA based persistence engine

["Andrew S. Townley" <atownley informix com>]

A little disclaimer at the beginning:  I think this is a cool idea  
and it would be great to see something similar come about for gnome  
and/or KDE.  I also have not yet actually written an application  
using gtk+ or gtk--, but I have read a lot of posts, parts of the  
gtk+ tutorial and looked at several of the examples.  I have,  
however, worked quite a bit with C++, Objective C and Java.

If none of this doesn't make sense now, it will as you read the  
response.:)  I was just trying to set the stage a little before  
people got the wrong impression.

Begin forwarded message:

> From: Stefan Westerfeld <stefan@space.twc.de>
> Date: Tue, 10 Nov 1998 14:10:40 +0100
>

[snip]

> The thing starts becoming interesting, when you start to save  
collections
> of objects. Imagine you have a whole dialog, with checkboxes, buttons, 
> a tabbed notebook and some pixmaps. You simply tell the dialog "save 
> yourself to that file", and later you are able to restore the dialog, 
> including all connections between the objects, all texts and pixmaps. 
>

[snip]

> More about dialogs & the GUI
> ============================
> For dialogs, the interesting component is a dialog editor.
> Without it, the thing would be boring: you write a program that sets up 
> the layout, connects the object, and sets all properties. You throw the 
> dialog - once created - to a file. Later, the program which needs
> the dialog restores it.
>
> But with a dialog editor, things look different. You click your dialog 
> together. Then, you save it to a file. Your application now restores 
> the dialog from the file every time it needs it.
>
> When another user would like to change the look of your dialog, he can 
> do that even without modifying your source, or recompiling. He  
just loads
> the dialog into an dialog editor (not even necessarily the same), and 
> changes everything he likes to change. He saves, and voila, the  
new dialog
> is used by your application.
>
> The thing starts becoming nice (but a little tricky), when not only the 
> dialogs of your application are managed that way, but - when its really 
> good - every control of your application. The user is now able to add 
> new menu items, change the look of your application, in certain limits 
> even the "workflow".
>

The above points are pretty much exactly how the Apple/NeXT  
Interface Builder program works.  You are actually creating and  
manipulating instances of the GUI objects and your application  
objects.  Connections you make, controls you use, instances you  
create--all of these are archived into parts of the NIB (NeXT  
Interface Builder) file.  At run-time, the objects are read from the  
file and displayed on the screen.  There are some extra method calls  
to support doing things when the nib is loaded, e.g. awakeFromNib  
which are called by the framework when the object is restored to  
allow run-time initialization.

In practice, you can do everything you describe.  In fact, this  
mechanism is how Apple handles internationalization:  there is a  
separate nib file for each language along with all of the appropriate  
strings and localized images.  Also, you can modify the GUI without  
changing the source, as you mentioned and as long as you're careful,  
you can substantially alter the way the application looks.

Whatever the actual implementation, I think that this approach is  
one of the better ones I have used.  I certainly think that it is  
easier and more flexible than Microsoft's approach which was pretty  
much followed by everyone on the Windows platform.  However, Apple's  
YellowBox for Windows proves that you can work around these  
limitations because YB/Windows works nearly identically to the  
development environment under MacOS X Server or the OPENSTEP  
environment from NeXT.

One of the things which you need to support such an idea, however is  
a GUI builder of some complexity.  Part of what makes Apple's  
Interface Builder work so well is that the languages it supports  
(Objective C and Java) both support run-time binding and determining  
if objects conform to certain signatures or method calls when they  
are loaded by the GUI builder.  Both ObjC and Java support this  
pretty well, but a language like C or C++ doesn't do quite such a  
good job in this respect.  The only way to make it work would be a  
whole lot of extra layers on top of C or by extending the RTTI  
mechanism in C++ to provide something similar to Objective C or Java.  
 Not that this couldn't be done, but I don't think that doing it is  
a good way to go.

Given that we don't create these extra layers, it means that the GUI  
builder has to be more complicated and, therefore, less flexibile.   
Another problem from the C++ side of things in gnome comes from  
gtk--'s use of templates.  Because templates are evaluated at  
compile-time, there is *NO* way to effectively have both templates  
and run-time object creation across all parameterized types without  
destroying everything you gain by using templates.  What this means  
from a gtk-- perspective is that you can't exactly have a single base  
class which encapsulates the GUI objects effectively.  Before anyone  
gets upset, I'm not saying that the way gtk-- works is bad; it just  
doesn't easily support the same interaction mechanisms that would be  
needed to make a GUI builder which could deal with controls/objects  
it didn't know about when it was built.

The other issue, of course, is that the majority of gtk/gnome apps  
available at the moment are written in C.

> Toolkit issues
> ==============
>

[snip]

>
> You just save your dialog (applicationg gui), which is currently using 
> toolkit A, and restore it using toolkit B. Voila, instant port, without 
> changing a single line of code ;)
>

[snip]

This is a very appealing concept, but I don't know how it could be  
done to support the different language bindings of each toolkit (e.g.  
how to you unserialize into a C application?  Could be done, but the  
code would probably be kinda tricky).

ast