Re: =?iso-8859-1?Q?Re: Proposition for a Gorm feature Was: Gorm too complex ??=

[Nicola Pero]

> Basically I'd like the best of both worlds, an archive which can be used 
> to produce 'perfect' code identical to the wysiwyg editing, or 
> autosized/styled code as you prefer.  I really don't believe that the 
> two are incompatible (or even that difficult to manage).  I suspect that 
> by far the larger problem would be implementing themes in the AppKit itsself.

I'm not completely sure what the advantage of this integrated archive
would be ...

WYSIWYG is inherently non-portable to other platforms.  You might well
encode using encodeWithCoder:, initWithCoder: - it wouldn't work well if
you port it to MacOSX anyway.  Those methods are done already.  If you use
a property list format, while it's readable, it's not really editable,
since you have tons of WYSIWYG details and inter-object references and you
can't really edit all those rectangles, coordinates, fonts, colors, flags,
references between objects without using a gui builder.  The only
advantage is that it is an open format, so that even if all sources of
gnustep-gui get lost in the mists of times, you can still probably guess
how to write a decoder.

autosizing/styled is easily ported to other platforms.  Because it's
encoding the logic of how the gui is built, and not all the tiny details,
it can really be edited by hand.  You can't edit gmodels, because of the
overwhelming amount of details information, and the total absence of
details about the logic.  It would be really nice if you could edit by
hand (without Gorm) the files of this new format.  Just consider that you
could build your gui using Gorm ... if you port your application (built
using Gorm) to MacOSX, where you don't have Gorm, it's an absolute
definite advantage if you can still add, say, a new button, by editing the
gui file by hand ... this is simply impossible with gmodels, where the
complexity of the objects and details makes it horribly difficult and
boresome to actually modify them by adding or removing or changing the
relationships of objects.  To allow you to read it, understand it, and
change it, the new format should provide very little information about gui
objects (for an 'OK' button, probably only name, text, and autosizing
information).

I also don't like the confused way in which gmodels save the objects ...
in no order whatsoever ... with arbitrary references everywhere ... and
tons and tons of objects ... that's a format for computers, not for
humans.

I'd like instead the new format to have probably a main object in the
window as the top key/value of the sub-dictionary containign the window
objects - a hbox/vbox likely, and the hbox/vbox to contain an array - the
views in that hbox/vbox (the array is `inline', not referenced as a string
and then actually elsewhere as in gmodels) ... each entry in the array
describes a view ... which might actually be another hbox/vbox which is
described by another array inline.

If enough few details are present, and if they are well organized,
according to logic, you might be able to edit them by hand, and after some
practice even to produce them by hand from scratch.  While of course you
prefer to use Gorm, it's still a great option to have.

It also allows you to write easily computer programs which can generate
parts of the gui ... for example which can read the database definition of
a table from a database, and build the form to allow the user insert the
data in that table ... just plug in a form field for each field in the gui
... you could still edit the resulting file using Gorm, or by hand ... or
cut&paste the produced form into somewhere inside an existing file for an
existing window (try doing that with gmodels, eh ... cut&paste by hand a
part of the gui from one window into another one) or not edit it at all if
it's generated by the same program which is using it.

Hmmmm .... yes - it's not difficult or long ... if only I had the time to
code it, I'd just do it.  If there is enough interest, I might do it.