Re: Palettes and libraries.. (was Re: Interface localization ?)

[Gregory John Casamento]

Nicola,

I think that would be cool. :) 

The one thing that's missing from the one's in Renaissance at this point is the 
ability to encode and decode themselves using the (normal or keyed) archiver.  
I suppose that can be done without any issues.

If you don't mind, I would like to extend the existing classes in Renaissance 
to do this.    This way, there would be a Renaissance palette that could be 
used from Gorm or IB and you could use Renaissance with it's own XML format..   
If I do it correctly, it will be possible to use Renaissance from within IB as 
well.

There's some other thoughts, since we're on the subject, that I would like to 
discuss:

Gorm's method of reading and writing model files was redesigned completely when 
I implemented nib files.   It has a set of Wrapper reader and writer classes 
for each different format (gorm, nib, gmodel) and Gorm's internal data 
structures are not coupled to any given file format.    It is possible to write 
a set of wrapper classes for Renaissance as well and include them in the 
palette (soon... via a plugin), this would allow Gorm to read and write 
Renaissance files.  The only issue is that, unlike Nib and Gorm files, (and 
similar to gmodels) Renaissance files lack certain meta-data about GUI that is 
necessary when editing.   

Loading a model file into an editor (such as Gorm or IB) is a slightly 
different thing than loading it into a live application.   When loading it into 
a live app, all you need to know is the class you want to instantiate and it's 
properties and little else about it.   In the editor (where all of the classes 
might not be present/linked in) you need to have a set of files that describes 
these classes to the editor.  Both nib and gorm wrappers contain a number of 
files... a file for the
objects, a file that lists the classes that are in the file etc and any custom 
classes as well as what outlets and actions are defined on them.  

I'm wondering if you might be willing to extend the Renaissance format to be a 
wrapper that includes this information.  Once that's done, it would be possible 
for Gorm to read and write Renaissance files.   This might run contrary to the 
goal of having gsmarkup files writable by humans, since they would have to 
maintain the wrapper structure.   Alternatively... Gorm could generate the 
metadata file in the same directory.

Later, GJC
--
Gregory Casamento -- OLC, Inc 
# GNUstep Chief Maintainer

----- Original Message ----
From: Nicola Pero <nicola.pero@meta-innovation.com>
To: Gregory John Casamento <greg_casamento@yahoo.com>
Cc: Vetter Chris <chris.vetter@gmail.com>; Truls Becken 
<truls.becken@gmail.com>; GNUstep Discuss <discuss-gnustep@gnu.org>
Sent: Sunday, November 25, 2007 4:50:04 PM
Subject: RE: Palettes and libraries.. (was Re: Interface localization ?)



> Just to make a few things clear.  It's not a matter of "merging"
 anything from 
> Renaissance into Gorm for dynamic support of resizing or translation.
   All that's 
> necessary is to create a palette with GSHbox and GSVbox (which are
 part of GNUstep gui) 
> and the appropriate editors and inspectors. 

Just a comment - Renaissance has more powerful/advanced boxes than the
 ones included 
in gnustep-gui.  The Renaissance ones are easier and friendlier to use
 - so you
want to base any palette on the Renaissance ones! ;-)

Thanks