gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keyed Archiving and MOSX compatibility...


From: Nicola Pero
Subject: Re: Keyed Archiving and MOSX compatibility...
Date: Thu, 25 Mar 2004 03:22:48 +0000 (GMT)

> > > My intent when I suggested that we implement keyed archiving was to be 
> > > able
> > to
> > > get XML output for .gorm files, whether that was MOSX compatible or not.
> > > 
> > > I beleive it is well worth the effort to try to make GNUstep and MOSX
> > > compatible in this way, but I also believe that we shouldn't massively
> > impact
> > > current functionality to make it happen.
> > > 
> > 
> > I would also like to see this happen. My feeling is that an XML format 
> > is only worthwhile, when it is compatible to MacOSX. The only other 
> > useful attempt would be to to get the Renaissance format working :-)
> 
> 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.

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.

Given this basic fact, I fail to understand how encoding/decoding objects
with all their attributes is a good approach to portable interfaces.

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!

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.

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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]