Re: CORBA based persistence engine

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Wed, Nov 11, 1998 at 10:40:59AM +0100, Kero van Gelder wrote:
> > > 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. 
> 
> And opened files? It's no problem to save the dialog, but the dialog
> was not on its own, it was part of something bigger; do you want to
> save that all?

What I have right now are contexts:

Say, you have a menu. The menu will probably have some objects it is
connected to (which are in the application). Now you define a context
which contains these objects, and say: serialize that menu relative to
that context. The serialization process will now skip all objects
which are in the context, and just serialize your menu objects.

Upon restauration, you must supply a similar context, and now can restore
the menu relative to that context. It will reconnect itself to the objects
in the context.

To make it clear, in that context you would probably at least expect
a window where the menu can draw itself, maybe some Desktop core APIs
which handle shortcuts, and an object (say the core of your word processor)
that defines actions that may be performed (such as new file, or whatever).

BTW: opened files: most applications I have seen have an event loop where
they fall into after performing calculations, disk operations, drawing
etc. Almost everywhere, there are no opened files which remain opened
when you are in the event loop. The IO operations are performed as
direct consequence to user input. So if you make "save yourself" an 
event, it won't have to care about open files.

> 
> [snip dialog editor]
> 
> > > 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".
> 
> Also have a look at my posting
>   http://www.gnome.org/mailing-lists/archives/gnome-gui-list/1998-November/0079.html
> 
> [snip nib]
> 
> [snip toolkit idea]
> 
> > 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).
> 
> By serializing the look'n'feel only. That part is handled by the WM
> and Gnome libraries, which can be adapted from our side to support it.
> The applications just use that library.

Yes, but I want to have some standard way of building components, in
an object oriented way, and serialization and materialization should
be normal for them. Having menu structures in a file is not as nice
as being able to save basically any component.

> Hey, it would be great if to _any_ application I could say ``Save
> yourself'', because I'll continue next week. But may be we'll have to
> wait for a wide-spread OOOS (Object Oriented Operating System) for
> that.

The problem is, that we'll probably never get that one if we can't do
it step by step. Because writing a whole new (free) OS is a project you
won't achieve without an 10 years timeframe. But as you improve existing
concepts of UI building, more and more people will see, that they might
need something like that and will do more and more steps in the right
direction.

What I am proposing is starting to implement the ideal of persistent
objects in a small setup, but still achieving good goals. For instance
not having to port the visual appearance of configuration dialogs or
stuff like that when changing toolkits seems a good goal to me. Having
easy implementable, toolkit independant GUI builders, as well.

Thats what we can achieve without throwing everything away, and having
that will be better than nothing, and perhaps further steps may follow.

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