Re: CORBA based persistence engine

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Tue, Nov 10, 1998 at 11:34:29AM -0600, Andrew S. Townley wrote:
> [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.
Yes, this is exactly like I want it to work ;)

> 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.

Interationalization could perhaps be done more or less similar like
gettext, because otherwise you have to retranslate everything every
time again.

> [...]
> 
> 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.

Thats why I am using CORBA. There you have your type management, and
I think you can do everything you describe above with CORBA. You don't
need to add anything to any language that is supported by your ORB,
since it will have mechanisms to do type checking, conversion, etc.

For instance, I do not need the RTTI of C++ in any way, since I can
use mico's methods of casting objects, determining the type of an
given attribute, etc.

When there are good enough bindings from one ORB to C (and I suppose
for instance mico has everything you need, like dynamic invocation,
any types, ... even for plain C), you have the same for C, without
adding anything.

> Given that we don't create these extra layers, it means that the GUI  
> builder has to be more complicated and, therefore, less flexibile.   

As described above. One of the main things, is that the GUI Builder
will be really easy to implement, since it won't care about the
language you are using, the attribute saving and restoring, the toolkit
that you are using, etc. ... it will even be possible to reuse things
created in GUI builder A ind GUI builder B, since the file format is
given by the persistence engine.

> 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.

I am not quite sure about this, because I effectively don't know gtk--
at all. But I suppose it would be possible, since you would wrap every
gtk(--) object entierly into CORBA, and forbid more or less most direct
interaction between the (C++) program and gtk--. Instead you would use
CORBA, so that for instance even signals and slots would go over an
CORBA model, and not over the native gtk model.

You may argue, that this is bad, but think of it that way: if you wrote
a component, which is non visual, and want it to interact with either
Qts objects or Gtks objects (depending on the prefernces of the user),
you can't use the native toolkit communication!

> > 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).

Not at all, I suppose. Every C application can use CORBA objects, right?
So every C application can talk to the dialog, which has been unserialized
as if talking to a CORBA object. No problem. Of course, you must write
your applications to do so, but if the GUI builder is good, it will be
really what you want to do anyway (instead of designing your layout in
your source code).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-