discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Menu (Was: Re: Unimplemented AppKit classes)


From: Nicola Pero
Subject: Re: Menu (Was: Re: Unimplemented AppKit classes)
Date: Thu, 23 Jan 2003 13:48:10 +0000 (GMT)

> As far as i have read from renaissance docs, it is not just about plain 
> coding/encoding of objects and their attributes...Personaly i find it a 
> bit complicated.

It's not about plain coding/encoding of objects - which is because that
approach had failed to provide us with a portable framework (see our
.gmodel attempt).

I never liked proprietary binary formats (and binary encoding/decoding
objects into files) - maybe for this feeling of depression which I used to
get when browsing old, big NeXTStep archives full of software with full
source code, knowing that all that software was using the same API as
GNUstep and yet I could not run any of that software on GNUstep because of
the binary, proprietary, totally platform-dependent format they used to
store their windows, when they were just dumping the instance variables of
their NeXTStep window objects (and all objects and internals contained in
the windows) into binary files.  I couldn't even figure roughly what the
windows contained (to rewrite them manually in code), because the nextstep
nib files were simply unreadable sequences of numbers for me.

No matter what, I want an open, easily readable, public format to store my
windows, and a portable reader/writer which uses only the public API.

.gmodels looked like the solution to all that - and I worked a lot on
.gmodels in the past - I believed in them at some point :-).  But as a
plain matter of fact, they couldn't be made to work satisfactorily, and by
trying hard to fix them I learnt in the hard way that they - I think -
can't be fixed/made to work satisfactorily.  I got many lessons back from
that failed attempt, which I've used to build a new better framework,
which supports open window descriptions, and real portability -
Renaissance.

I think I've finally won my battle for open, portable, readable formats:
Renaissance provides open, portable UIs which look good on every OpenStep
platform on which it runs (GNUstep and Apple OS X at the moment).  I had
to drop the traditional approach to encoding/decoding of objects to get
this.  I am not surprised I had to.  The traditional approach was never
meant to provide portability across different OpenStep implementations
(nor to support a lot of other features, like run time translation of
windows, which Renaissance supports).

A Renaissance XML file describes 'what you want this window to look like'
rather than just dumping/restoring the window attributes of an existing
window as created by the local library, as they are, into/from a file.

I find it's very very easy to use in practice.  Just look at the examples.  
I think you could use it even without reading the documentation :-)

The internals might be complex - or maybe the documentation is too
detailed :-), but writing a .gsmarkup file in practice is very easy.  You
just put <button title="Quit" action="terminate:" /> if you want a quit
button.  I can't imagine something simpler to use.

I somewhat think that thinking in terms of encoding/decoding will make it
harder for you to use Renaissance.  Just forget about it.  Renaissance can
read an XML file and create the objects you describe in the file, setting
the attributes you specify in the file.  Forget about encoding/decoding,
it's not that.  :-)

Maybe I should write a second tutorial about creating windows, and putting
stuff into windows, and explaining how to use the boxes (which are
terribly easy to use, just yes it's not explained anywhere how to use
them) :-)

I agree that with a graphical builder for it, it will be *much* easier to
use.  A graphical builder is definitely planned.  Renaissance is
incomplete without a graphical builder.  I will write it. :-)

Renaissance is meant to please both the 'I can do everything from my
editor' crowd, and the 'I love to create windows by dragging&dropping
objects into them' crowd.  It has been designed to please both of them.  
It's only a temporary situation that it is without a graphical builder.

Once we've got a graphical builder for it, you can just forget all your
problems about how the encoding/decoding is done - the graphical builder
will work more or less in the same was as Gorm currently does (just you
need to use boxes when building as well, but that will work in the same
way - you drop them in the window, then drop things into them ...).  You
won't even know the difference, except that your .gsmarkup file will run
under Apple Mac OS X or under any other language (Chinese or whatever) as
well without any change, and except Renaissance graphical builder will
itself run under Apple Mac OS X as well! :-)





reply via email to

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