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

[Nicola Pero]

> > Hi folks,
> >
> > IMHO it is better to write XML or property lists as layout.
> > the code to load this files should be available as Framework that also 
> > works on MacOS X with Apple runtime.
> >
> 
> See the gmodel code in the Model subdirectory of the gui library.
> Feel free to add gmodel import/export to Gorm.  Shouldn't be too tricky.

I think .gorm is optimal for traditional WYSIWYG gui editing.

.gmodel is a bit unsatisfactory.

I think the ideal cross-platform format which would make most people happy
would have the following properties -

 * be a property list or XML format.  (I prefer property list, which btw
   can be saved as some variant of XML)

 * encode only the minimal 'generic' information about gui objects.  For a
   button, its text and whether it's a on/off button, or a radio button,
   or another type of button.  If it has an image, the image, and if it's
   on the left or right of the button.  Possibly its default state
   (toggled/not toggled).  Optionally the font size (in generical
   terms: small/medium/big).

   Things it shouldn't encode - background color, text color, size,
   position, exact font, border type, border width, etc

 * encode the 'logical' position and inter-relationship of gui objects.
   This is normally done by using boxes - hboxes and vboxes.  We already
   have these boxes - GSVbox, GSHbox, and GSTable - they are missing in
   the openstep specification.  If the library is meant to be able to run
   these files on MacOSX as well, and if the library is LGPL, we can
   bundle the boxes classes with the library for running the thing on
   MacOSX.
   
 * when creating the objects from the file, do the following steps - 

   - lookup all strings in the Localizable.strings file (or another
     .strings file).  That makes sure you can translate the gui by
     simply translating all strings in the file.  (no need to rebuild
     the gui).  Put the translated strings in the objects.
     Create the objects.

   - call sizeToFit: on each object after creation, then put them into
     boxes, size them to fit as well, etc building up the positions
     and sizes dynamically as the objects are read from file.

Such a format would be both portable from/to GNUstep and MacOSX and
OpenStep - I mean portable without *any* change, and look perfectly native
on all platforms.  If we implement themes for gnustep, it would also work
fine with themes.