Re: UI Object Archive (Was: Re: Menu)

[Nicola Pero]

Stefan, thanks for your comments.

This email is sort of outdated, because by the time I finished it, the
discussion had already gone a lot further.  :-)

I'm sending it anyway, since it contains what might be useful information.

> >> .gorm is not platform independen? If not, why? If it is because 
> >> of lack of .gorm file reader, then i do not see it as a problem of
> >> .gorm file.
> > 
> > Even if you could read it on other platforms then it would not work properly
> > as the objects are different sizes and shapes on screen and thus you
> > dont actually want thhem in the same places on differentplatforms.
> > 
> > What you want is to keep their spacial relationships thesame.
> > 
> 
> Object resizing/fitting is not a problem of object archive, 
> we are speaking about two different things.

No, it's not ... and yes it is. ;-)

NeXTStep had a certain philosophy, which is consistently pervading all the
API and the logic of their frameworks.

The philosophy is that of What-You-See-Is-What-You-Get: you create the
window graphically, then encode the window to a file.  When you decode it,
the window is recreated exactly as you saved it ... perfectly the same, to
the pixel.

That's why they are using encoding/decoding.  Because they want to
encode the window exactly as it is, and decode it, recreating it, exactly
as it is.

If you don't want to recreate the window exactly as it is, because you
want to perform autoresizing, autosizing, you want to adjust colors and
fonts and system images and sizes (and even classes/types of
widgets/objects) for a different platform/theme, you want to be able to
use slightly different APIs on different platforms (to adjust for the
quirks of each), you want to translate strings when you decode and adjust
for the translated strings, then the obvious question raises: why are you
using encoding/decoding at all ?

There are plenty of other ways of parsing files, or of writing files (ways
which can be used by a visual builder too, no reason why not).

Are you sure that you are not just using the wrong tool for your task ?

There is no such thing as the 'absolutely perfect tool for any problem'.  
Each problem has usually a different solution.

Saving windows to disk, then recreating them back exactly as they were has
in encoding/decoding a great, brilliant solution.  You dump and recreate
ordinately your internal data/object structures to disk.

Saving `essential' descriptions of windows to disk, then using them to
generate the best available match of the description on the platform you
are running on, including possibly fixing up most attributes and
rearranging objects and putting any sort of (more or less dirty)
portability trick in the object generating layer, can have a different
solution I think.  Somewhat similar (any writing/reading of files
involving objects is somewhat similar), but different.  Possibly a
modified/customized encoding/decoding (which is sort of what actually
Renaissance uses).

I'm not surprised by that.

Finally, I'm not quite sure why do you care what mechanism Renaissance is
using to write/read its XML files.  Renaissance contains a very very
portable engine which can write/read them on both GNUstep and Apple Mac OS
X (and, if you install libxml2, on older OpenStep systems as well, thanks
to Pete French who wrote a pure libxml2 backend).  What's the difference
to you - the end user - in which way does Renaissance writes/reads its
files ?

This engine will support a graphical/visual editor, if that's your
question.  I will hammer and hammer it until it does, if it tries to
resist being graphically editable :-)


> > Which is what Renaissance does - thats what makes it such a great idea (that
> > and the fact that you dont need some over blown graphical app to write
> > interfaces, you can do it in 'vi')
> > 
> 
> I have nothing against renaissance, but excuse me... the 'advantage' 
> of writing UI without graphical app seems to me like being deaf and
> composing music, or it is like painting and being blind.

Renaissace is meant to have a graphical builder.  It *will* have a
graphical builder - it's utterly incomplete without one.  Just I haven't
written it yet - been busy writing Renaissance itself. :-)

 
> > You can also read an Renaissancefile, unlike a NIB file, where its almost
> > imposssible to get an exhaustive list of everything in one.
> > 
> 
> From all this, it seems to me, that keyed-archiving (see FoundationKit 
> update at Apple's site) using some readable format (XML for example) is
> the best and simple solution. This can also solve custom objects
> problem.

You are free to try - but may I suggest that it will not work as well as
Renaissance dedicated reader/writer engine.  We tried that (or somethign
similar) already, it's called gmodels.  It's a step in the right direction
... but it's not enough, it didn't work well.

Basically, the idea is that I/we don't want to archive windows and then
dearchive them.  What I/we want to do is, edit the description of what/how
the window should be in a nice editable file (manually or via a gui
builder), and then the library should be able to use that description to
create the window on the native platform.  It's a different philosophy.  
A similar task, but we're free to use tools which suit better the
different philosophy (which are only slightly different).

I still don't see why do you care.  Internally, Renaissance might be using
some sort of encoding/decoding (which it is in fact), or not using it.  
That's not the point.  That's not the public API.  The internals could
change any time.  The XML format will remain the same, and the public API
to read/write files too.  The visual builder will need to access the
internal details, but it will hide them from the user.

Btw I don't see what the custom object problem is, Renaissance supports
them.

The only reason why you might care if for the API for implementing new
tags/palettes ... which is not yet well defined/designed - there is not
much point in trying to define this stuff before having written/worked on
the graphical builder.  It remains a quite dedicate task, and as soon as
the API is good and consistent, I don't think it's going to be a
particular problem.  But yes, this is the main point where a few of the
internals will be to be disclosed, and how Renaissance is reading/writing
will impact on how you write palettes.