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

[Gregory John Casamento]

Nicola,

> I'm a bit confused by your email - there are different ideas entangled. ;-)

I crammed a lot into that email. :)

> 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 
> :-)

In Renaissance, from what I understand, the widgets leave some of their 
placement properties blank/unspecified to tell the autolayout manager that they 
can be resized.  If a value is specified, then it will be respected, if not 
then it is open to interpretation by the autolayout manager.  Please correct me 
on this, if I'm mistaken.

This approach is perfectly fine and can be modeled in Gorm.  There is a 
callback which IB/Gorm makes to the palette's main class that is used to 
determine if any additional inspectors should be added to the list.   If the 
method is defined, it can check the conditions of the object being edited and 
act accorrdingly and can add inspectors which will allow Gorm to be told to 
blank out certain attributes when saving.  This is the method used when you get 
extra options in the inspector pulldown when you edit a text field that has an 
NSFormatter instance associated with it.  

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

I agree..  I believe that these already have the encoding logic built into 
them.  This was my original course anyway.  

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

That's why I asked first.  It's your framework and I didn't want to make any 
changes to it that you wouldn't approve of.

Thanks, 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>; GNUstep Discuss 
<discuss-gnustep@gnu.org>
Sent: Monday, November 26, 2007 7:17:37 AM
Subject: Re: Palettes and libraries.. (was Re: Interface localization ?)

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.pero@meta-innovation.com
Cc: Vetter Chris <chris.vetter@gmail.com>, Truls Becken 
<truls.becken@gmail.com>, GNUstep Discuss <discuss-gnustep@gnu.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.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









_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep