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

[Nicola Pero]

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

No - gmodel currently encodes nearly all information about a gui object -
just nearly the same that you encode in a .gorm, only in property list
format.

Not saying that it wouldn't be easier to start from gmodel than from
scratch - but currently gmodel is saving a lot of WYSIWYG info.  A huge
amount.  Every single subview of every single object, with every single
piece of information saved as separate objects in full details.  All that
would need to be changed.


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

I suppose that when you create a window without a specified background
color/image, the theme default would be used.  If you explicitly set the
window backgroudn, the theme default of course is not used.

The typical problem when porting gmodels from another openstep framework
is that colors are all wrong ... because are the default colors of the
other framework.  Normally you just want the background of the host
framework.

So I think simply .gmodel - if they are to be the format - should not
encode window background colors.

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

Yes - good idea - it's not what happens currently, and yes it should
probably be fixed.

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

Oh yes - I agree with that.  Even if the actual amount of code needed to
write such a framework is not so much.