Re: Nuke libgmodel?

[Nicola Pero]

Hi Jonathan, 

 gmodel is already quite an independent library - and we have actively
pursued making the gui independent from libgmodel - for example by writing
the save panel, the font panel and the color panel in code.  This makes
sure the gui works - panels included - even if work on the gmodel
libraries is not finished and/or we can't produce satisfactory gmodels.

Perhaps, the best design would be a modular design in which:

 * you have a standard way of loading nibs - by using the GNUstep 
   archiving/dearchiving facilities;

 * for any alternative nib format - such as gmodel - you have a bundle 
   containing code able to open and save such files;

 * when the library needs to open a `nib', it looks at the extension
   or at something else, and opens it with the corresponding bundle.

Then, gmodel code would become a loadable bundle.

This is because I have long wondered if it wouldn't be worth to implement
a new format - sort of a quick very very simple scripting language - which
would assume everything is packed using hboxes/vboxes - and which could be
edited quickly by hand to produce standard GUI windows.


>     This leads me to suggest removing libgmodel from gnustep-gui. 

I agree but I suggest postponing this after we have a working Gorm.


> Thus, a gmodel would be a transfer format for Gorm to load for tweaking, 
> before saving as a .gorm file.

I agree - that's the target we are after.