I'm a bit confused by your email - there are different ideas
entangled. 
It would be interesting to see what the Gorm
"auto-sizing box" palette approach
would end up producing; I have my doubts about it (don't
think the results will
be that useful), but it seems like a simple enough project
that might easily be
attempted and might produce something usable or at least
teach us something 
The 'Renaissance GUI builder' is a much more complex matter
- as you well know
from previous discussions/threads/flamewars, I don't agree
with your approach - I
just think it will destroy the Renaissance philosophy thus
failing to produce
anything different from the standard Gorm/NIB encoder, which
is fine, but it's not
what Renaissance is about (why even bothering then ? Just
use XML Gorms/NIBs)!
In that light, it may be better to try the Gorm palette
approach with the
gnustep-gui boxes, which are more traditional and would fit
a bit better
in the Gorm philosophy - and would simplify psychologically
the problem by
removing all the other Renaissance "differences"
from the project - if you
concentrate on just one new bit (the auto-sizing boxes) you
may get something
more useful out of it.
Thanks
PS: I do of course encourage you to do any
experiments/attempts you want with
Gorm + dynamic sizing stuff or even Gorm + Renaissance, but
I started up
Renaissance as a completely separate framework to make sure
it would be easier
to preserve its philosophy - ie would you mind not making
changes to the
Renaissance framework itself to have it fit with Gorm's one
? You can still
use categories or external add-ons of some sort. Or (my
recommendation, as
explained above) start with the simpler gnustep-gui boxes
and see how it goes.
-----Original Message-----
From: Gregory John Casamento <greg_casamento yahoo.com>
Sent: Monday, November 26, 2007 3:13am
To: nicola.perometa-innovation.com
Cc: Vetter Chris <chris.vettergmail.com>, Truls Becken
<truls.beckengmail.com>, GNUstep Discuss
<discuss-gnustepgnu.org>
Subject: Re: Palettes and libraries.. (was Re: Interface
localization ?)
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.perometa-innovation.com>
To: Gregory John Casamento <greg_casamentoyahoo.com>
Cc: Vetter Chris <chris.vettergmail.com>; Truls Becken
<truls.beckengmail.com>; GNUstep Discuss
<discuss-gnustepgnu.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
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
|
