Re: Keyed Archiving and MOSX compatibility...

[Nicola Pero]

> > > I don't see Renaissance as the answer due to it's tag-based mentality.
> > 
> > I don't see NIB (no matter if binary or XML) as the answer due to its
> > encoding/decoding mentality.
> 
> You seem to have taken this somewhat personally. 
> 
> My comment is aimed at the idea that you need to write a new tag every time 
> you
> add a new class to the framework rather than simply defining how that class
> should encode/decode itself.

I don't think that's a major difference.  Adding an encode/decode method
is writing a small category with a couple of methods.  Adding a tag is
writing a small class with a couple of methods.  These are operations of
similar complexity.


> Fred's proposal was, I believed, to somehow get GUI to encode using the
> gsmarkup format which is innappropriate given the fact that it uses the
> tags.  That's all I meant.

I agree GUI is supposed to have encode/decode operations and you don't
want to use gsmarkup for that because gsmarkup does not do normal
encode/decode. :-)

I don't think gsmarkup should be in gnustep-gui, while encode/decode might
be there, or should be there for historical reasons/compatibility. :-)


> Nothing personal was meant, although I get the impression that the only
> right answer in *your* mind would have been Renaissance.

Ops, Ok, might have misunderstood, sorry.

 
> > The objects are different on different platforms.  They have different
> > colors, different fonts, different sizes, different images, different
> > default alignments and properties.  The default button on GNUstep is 
> > totally different from the default button on Apple Mac OS X.
> 
> All Renaissance does is it comes up with a different way to store it using the
> tags and the getters/setters of each object.  How is this better than what I'm
> proposing?   The answer: it isn't.

Renaissance does not come up with a different way of storing it.

Renaissance keeps a tree representation of the logic/XML in mind, in the
form of a tree of tags, which represents the *logic* of the interface,
including which attributes are relevant and which are not.

You can then ask this tree representation to generate a platform
representation of the window, or you can ask it to generate the XML.  
Generating the XML is currently unused and it's only meant to be driven by
an interface builder application, which is supposed to keep the logic/XML
tree in mind and generate code from there rather than from the platform
objects.

Have you ever actually looked at a Renaissance XML file ?

<?xml version="1.0"?>
<!DOCTYPE gsmarkup>
<gsmarkup>

<objects>

  <window title="Button Test" closable="no" frameAutosaveName="main" >

    <button title="Click this button to quit" action="terminate:" />

  </window>

</objects>

</gsmarkup>

In this file, most "attributes" are omitted, but a few are not.  This is 
not normal encoding, because normal encoding either includes an attribute 
all the times, or it doesn't include it at all.

Renaissance keeps a separate tag represantation which stores that
information too - if an attribute required or not.

 
> > Given this basic fact, I fail to understand how encoding/decoding objects
> > with all their attributes is a good approach to portable interfaces.
> 
> Decoding to a known set of attributes is an acceptable approach.  Renaissance
> does the same only by using the tag as a proxy for the real class and a
> slightly different set of "attributes".

Not at all.  Renaissance has not a fixed set of attributes, most/all
attributes are optional and are included or not depending on the
programmer's wish.

This is an essential point which basically means that Renaissance is *not* 
using encoding/decoding.

 
> > You encode an object in one platform and it's very nice and fits with the
> > environment, then when you decode it on another platform, the object is
> > totally wrong and means nothing in that context.
> > 
> > It's absolutely the wrong approach!  Dumping the objects to disk as they
> > are on a specific platform is exactly what you don't want to do to have
> > portable interfaces!
> 
> Coming up with a compatible way to store archives in general is not wrong.

Yes.  It's just the idea that the archives contain encoded objects which
is wrong, and that you generate the archive by encoding the objects on a
certain platform without understanding that they will be decoded on
another platform.


> If this leads to being able to read the interfaces created by IB since they 
> are
> archives, then so be it.  There's still no reason not to try.

... I agree, I never said not to try.  I encouraged you to try :-)

... I just said what you get won't be as good as what Renaissance does.  
Of course you've got a graphical builder which is good, and Renaissace 
doesn't have one.


> As I said a long time ago...  the real problem is the format of the *archives
> themselves* not JUST the GUI archives, but the archive format across the 
> board.
>  What good is it to develop an application which archives data, but then can't
> read it across the different platforms because the archive format is not
> compatible?   It's useless.  *IF* we can make a compatible XML format using 
> the
> NSKeyedArchiver, then we should pursue this.

I never said we shouldn't.  I said the quest for platform compatibility 
doesn't finish once you can decode your NeXTstep look&feel objects on an 
Aqua machine.  The real troubles start at that point actually. :-)

 
> > So the only solution is to encode the *logic* of the interface in those
> > files.  If you want a button, the file should record that you want a
> > button, not if on the original platform the background is white or striped
> > by default (you should still be able to force a specific background on all
> > platforms if you so wish), then the library will generate whatever type of
> > button looks good by default on that interface.
> 
> And so by doing this some information *is* lost.

The programmer can decide which information is essential and which is not,
which is something a machine can't do.

If you want to keep a fixed background color on all platforms, maybe
because yours is a yellow post-it application and you want all windows to
have a yellow background, you can do it.

If you just want to create a window with a standard background, you don't 
put the background color in the file.



>                                                 You don't really think you
> can get a consistent, acceptable interface on all platforms?  I've yet to see
> any complex guis done using Renaissance beyond a few examples.  Inevitably
> something is going to be different and it's going to require a new interface
> file.

So you don't really believe that it's going to work, do you ?

Well I do think it's going to work, actually that it works now, Finger.app
has a normally complex gui and works very well cross-platform.


 
> > I think the problem that Gorm, Apple, IB, NIB have is their inability to
> > look outside the very strict and religious dogma that the right way to
> > create windows description is by serializing/deserializing the objects.  
> > It's not if you want portable interfaces, and it's not if you want to be
> > able to dynamically modify the interfaces.
> 
> I take it dynamically modify = "modify with a text editor".   If I wanted to 
> do
> this, I would write code... oh wait.. that's what I'm really doing with
> Renaissance anyway, isn't it?  Only I'm doing it in XML, by hand.  

Yes, that's why we need a Renaissance-based Gorm which allows you to edit
Renaissance files including choosing which attributes are to be encoded
and which are not to be encoded and such stuff ... it would work in a
different way than the existing Gorm, but maybe not too different.

 
> > Doing it differently makes the reading/writing process more complex, but
> > gives you the best results.  Encoding/decoding is just not up to the job,
> > because you *don't* want the same objects on different platforms.  You
> > want automatic and intelligent adaptation to the platform.
> 
> If you mean you want a format which doesn't conform to the platform or any
> platform in particular, I'm not sure what the benefit is here.   Just because
> the format is exactly the same as one on a given platform, doesn't make it any
> less portable unless some platform specific things are stored.   
> 
> To my knowledge this isn't the case with GNUstep currently and even if there 
> is
> Apple specific stuff in the .nib archive (from IB) we can skip it since we 
> only
> pull what we need from the keyed archive.

Do you store the background color of windows ?  If yes, you are storing a
platform-specific detail in the file.  If not, you are not giving to the
programmer the possibility of forcing a special background color for
his/her windows.
 

> Anyway, these things are possible outside of Renaissance, as I explained in a
> private email to you.

Everything is possible outside of Renaissance, but then you're reinventing
it.  Keyed encoding + XML is still a different thing though.