Re: Summer of Code 2007

[Gregory John Casamento]

Nicola,

> No, let's not start a new flamewar here, ;-)

No one is doing that.   I'm not trying to start one by replying, but I just 
wanted to have a purely technical discussion on this topic.

> I did have in mind writing a Renaissance GUI Builder because I'd like to
> see a "native" Renaissance GUI Builder where the Renaissance philosophy
> is implemented natively.  I do believe that that will require new user
> interface/design ideas.  Ie, I want auto-layout concepts directly built
> pervasively everywhere into the basic interface.  I feel adding Renaissance
> to Gorm (which has a completely different philosophy) will end up in a 
> patched system that might somehow work but be ugly and meaningless.

This is not a true statement.  The IBEditors implementations (GormObjectEditor, 
GormViewEditor and subclasses) control the behavior of each element in the gui 
while it is being edited.   Gorm and IB are not strictly "fixed position" 
editors.     It is not impossible (nor against the paradigm of IB or Gorm, as 
you suggest) to create an IBEditors implementation that takes Renaissance 
behaviors into account and even allowed them to dynamically resize the way they 
should in Gorm.

Gorm and IB are open ended gui editors and do not lock you into one given 
paradigm.   That being said, the existing editors and inspectors in Gorm and IB 
do not currently have this functionality, but only because it's never been 
implemented, not because it's not possible.   

When I refactored Gorm to handle nib files, I made it so that the internal data 
structures were simplified.   How Gorm internally stores the gui elements is 
not necessarily tied to a given format.  The nib and gorm and gmodel writer 
classes all take those data structures and transform them into what is needed 
for output.   The same could be done for .gsmarkup.   The only information 
currently missing in .gsmarkup files is metadata concerning custom classes 
(i.e. which instances are subclasses of other known classes) and classes added 
during editing (an equivalent to data.classes in a .gorm package or classes.nib 
in a .nib).  The saving or non-saving of default values also could be built 
into the
editors or even into the writer class which writes the .gsmarkup file out.

> Nobody needs to worry anyway as I don't have time to write a Renaissance GUI
> Builder myself ... unless I stop working on gnustep-make of course. ;-)

I'm not worried, actually, I wouldn't mind seeing something like this happen.   
What I want to avoid is needless duplication.

If a "native" solution is what you insist on, then I would encourage you to 
take a look at what can be reused from Gorm, since it is a huge amount of work. 
  This would be useful since it could result in the creation of a general GUI 
builder toolkit of some kind arising out of Gorm's code.

But... for the sake of the Google SoC, it's probably best if we concentrate on 
those areas in which we are sorely in need of help.   Currently, a Renaissance 
GUI builder would be interesting, but not essential.
 
Later, GJC
--
Gregory Casamento


----- Original Message ----
From: Nicola Pero <address@hidden>
To: Fred Kiefer <address@hidden>
Cc: Developer GNUstep <address@hidden>; Adam Fedor <address@hidden>
Sent: Thursday, March 15, 2007 1:56:47 PM
Subject: Re: Summer of Code 2007


>> Can we add 'Writing a Renaissance GUI Builder' to the list of tasks ?  I 
>> volunteer mentoring a student doing that.  It's a pretty tough job though, 
>> so 
>> only determined people! ;-)
>
> No, lets not write a new GUI Builder here, 
>

No, let's not start a new flamewar here, ;-)

Your idea could be good and I respect it, feel free to volunteer for it
(or for mentoring it) but it's not what I had in mind. :-)

I did have in mind writing a Renaissance GUI Builder because I'd like to
see a "native" Renaissance GUI Builder where the Renaissance philosophy
is implemented natively.  I do believe that that will require new user
interface/design ideas.  Ie, I want auto-layout concepts directly built
pervasively everywhere into the basic interface.  I feel adding Renaissance
to Gorm (which has a completely different philosophy) will end up in a 
patched system that might somehow work but be ugly and meaningless.

I have nothing against a Gorm pluging for Renaissance though.  You can mentor 
a Gorm plugin for Renaissance if you want.  I volunteer to mentor "writing
a Renaissance GUI Builder" though. ;-)

I also suggest we stop the discussion here and accept that we have different 
views.  We all thought a lot about this and we came to different conclusions.

Nobody needs to worry anyway as I don't have time to write a Renaissance GUI
Builder myself ... unless I stop working on gnustep-make of course. ;-)

Thanks



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev