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 <[EMAIL PROTECTED]> To: Fred Kiefer <[EMAIL PROTECTED]> Cc: Developer GNUstep <gnustep-dev@gnu.org>; Adam Fedor <[EMAIL PROTECTED]> 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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
