gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summer of Code 2007


From: Nicolas Roard
Subject: Re: Summer of Code 2007
Date: Fri, 16 Mar 2007 15:25:53 +0000

On 3/16/07, Yen-Ju Chen <address@hidden> wrote:
On 3/16/07, Nicola Pero <address@hidden> wrote:
>
> > 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.
>
> It's kind of an upsetting answer for me, but I'll refrain from submitting it 
as a project then.

  While I agree with Gregory that it would be better to support
Renaissance in Gorm,
  for SoC, which only last a summer and depends on student's interest,
  we should not block the option of Renaissance GUI builder.
  1. Duplicate work will become an issue only when there is a student
who are interested in it.

Yes, definitely. Just add the project for the SoC, if somebody is
interested it's good anyway. Although I understand greg -- what we
would ideally get from the SoC are areas that we need yet where few
are working on it at the moment; SoC or a bounty would be in that case
possibly a good incentive for people to work on these.

In my opinion, these areas for the moment are the windows port
(although Xavier works on it now) which is really needed, the Cairo
backend (same here, fred is working on it too, but I'm sure he
wouldn't mind help), the printing backend, and in general reducing the
gap between gnustep and osx... (in addition to adding/improving
classes, bindings looks to me like a very cool project for instance).

  2. Even there is a student who is interested in it, Nicola can keep
the GUI builder modular
      in case in the future, GNUstep want to support Renaissance in Gorm.
  So if this Renaissance GUI builder can be more or less in the
similar structure of Gorm,
  or even use the same interface for bundle, to me, it should be an
option for students.

Well... having looked at Gorm's code and architecture, I'm not sure
why we would need a completely different GUI builder. Gorm is very
flexible! for me we could easily:
- add a gorm palette dealing with the autoresizing widgets (GS*box)
- load/import Renaissance files

Actually I'm thinking that a nice addition to Gorm could be, instead
of a "new application" menu item, have a panel coming up asking you
what kind of "gorm file" you are interested in. In that case you could
choose a "Renaissance" project, where you'd have the resize stuff all
ready for you, for example. Or we could have even more complex
projects (like a steptalk-based project where you'd do all your
development *in* gorm; or we could imagine a project showing you a
palette of stacks and things like that,  eg to have something very
close to Hypercard, etc.). Remember: Gorm is not a mere GUI builder,
it truly is an object relationship modeller ;-)
That probably would benefit on a more customizable/flexible palette browser.

--
Nicolas Roard
"La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est
quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry




reply via email to

[Prev in Thread] Current Thread [Next in Thread]