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

[Richard Frith-Macdonald]

On Monday, February 11, 2002, at 06:05 PM, Nicola Pero wrote:

> > > 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.

Yes.

> 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)

gmodel.

>  * 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).

gmodel.

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

Well ... gmodel would encode some of these too.
I'm not at all sure I agree that it shouldn't.  Ok, so it would make the
archived data a bit smaller, and if you are wanting themes then some of
this sort of stuff would be redundant, but it would be good to keep
it for unthemed stuff.  Indeed, if we had themes we might want to mark
some bits of the UI as un-themable ... like forcing a particular
background color on a window.

>  * 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.

I see no reason why these classes should not be added to Gorm and/or 
gmodel.

>  * 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.

Sopunds good.

>    - 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.

I'd expect unarchiving GSVbox etc to do that for their contents.

> 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.

Basically, I think that while the gmodel stuff is not in great shape 
(which
is why I didn't use it for Gorm), it's getting there, and would take much
less effort to modify to be the sort of thing you want than any other 
option.