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:37 PM, Nicola Pero wrote:

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

It uses get and set methods to set logical attributes rather than dealing
with ivars directly though.   The degree of detail encoded depends on the
archiving/unarchiving methods used.

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

Well, I don't agree about coding less ...IMO there is no problem having 
all
that info there.  You could just have an option to only use what you want
on decoding ... so you could get the best of both worlds - potentially
detailed control for the best possible look, and automated layout where
appearance is not so critical but you want a quick implementation for a
particular style or language.

And you could introduce the support for the automatic layout gradually
as you implement different decoding behaviors for the various classes,
while having stuff continue to work at all times!

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

I think I'd have a two level approach ...
1. an option on loading a model to decode everything in full wysywig 
detail
or to discard detail and autosize/style instead.
2. an option on encoding any object to force an override so that the 
decoding
choice is hardwired for that object.

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

Again, I think that's wrong ... I think that they should not *de*code the
background colors.  Unless you want them to of course.

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.