Re: ANNOUNCE: GNUstep Renaissance is out!

[Nicola Pero]

> > There's a lot more difference between .gorm and .gsmarkup (as I imagine
> > it) than an "output format". "Borrowing" code is a good idea, but I
> > think trying to squeeze both models into one app would cause nothing but
> > problems.
> 
> From looking at gsmarkup, it seems as though most of the same concepts apply. 

I am mildly agreeing with Alexander here.

I will need more extensive study of the details to be able to give a final
opinion, or to enter into details, but when I think at .gsmarkup, I think
to something quite different than .nib.  So much different that it's just
natural that the code to edit them will be different.

When thinking at .gsmarkups, I think to a description of the 'logic' of
how a window should be generated at run time, rather than to just an
encoded dump of a window object on a specific platform.

Most details which are normally encoded in a .nib are omitted in a
.gsmarkup.  For example, size and position.  They are omitted ... except
if the programmer wants to actually force them, in which case they are, of
course, not to be omitted.

The decision whether an attribute is to be omitted or not, for example if
the background color of the window has to be saved into the file or not,
is at the programmer's choice.  By default it's not saved (the platform
default one is used when decoding), but the programmer should be able to
choose that for a specific window, he/she wants the background color to be
saved (for example, if he's implementing a stick-it application where he
wants to display yellow windows).

The information whether the background color has to be saved or not is not
stored in the NSWindow itself.  NSWindow has no instance variable to store
this information.  The information must be stored somewhere else.  But
then, adding a traditional -encodeWithGSMarkupCoder: method to NSWindow is
not enough to implement writing the window to the .gsmarkup file - or
anyway it doesn't work with the traditional logic.  The method would need
to actually look up in external tables to know if each piece of
information has to be stored or not.

If we store this information about each possible window/view attribute in
a separate table, to know if we need to store it in the .gsmarkup file or
not, then it makes much sense to actually store the attribute itself in
that table, and only if required.

And then encoding is simply done by working on the table - the actual
window instance can be ignored.  If the table is organized in an object
orientated way, it makes then sense to have a new object attached to each
window (and to each relevant view in the window).  This object will store
the information about the attributes of the window (/view) which have been
manually set by the programmer.  It's those objects (and not the actual
windows and views) which we then encode/decode to disk.

Anyway, this is sort of the design which might compose a .gsmarkup editor:
a web of 'logic' objects, which are the ones actually encoded and decoded
to disk, and each 'logic' object able to generate (and interactively
modify) a 'platform' object (a specific window, view etc instance for that
platform).

I need to try all this out before discussing further - it might be that
this is not the best way to do it.

What I want to stress is that there are reasons to think that it might
require different concepts, and we must be free to express those concepts
freely to get to an optimal design.

By the way, .gsmarkup do use heavily autoresizing and autolayout based on
some new boxes and autolayout concepts, rather than traditional
autoresizing masks, so the view editors and everything would need to be
completely different, and support completely different attributes (which
are stored in the enclosing boxes, but which need to be available
separately for encoding - again they can't be stored in NSView, they have
to be stored in the 'logic objects').

In general, the way I think about .gsmarkup files is much different from
the way I think about .nib files.  So it's just natural that code editing
them will be much different.

I fear that trying to force all these new ideas into the old .gorm editing
framework would not allow us to express and expand those ideas freely, and
might waste a lot of our time in trying to force together different
things.  That, and it might also compromise and weaken the design of the
new framework.



> When Gorm creates an archive it archives both the object instances and the
> connectors.  Some of the gsmarkup examples look as though they contain the 
> same information (see calculator.gsmarkup).

Yes - there are similarities ... a lot of them!  All the best of .nibs has
been stolen and put into .gsmarkups. :-)


> I believe that the information being stored in both a .gorm and a .gsmarkup
> file are similar enough to allow Gorm to be adapted to work with both.  It 
> may not be trivial, but it is doable.  As an example, currently Gorm can 
> load BOTH .gorm and .gmodel files.  The only reason it can't save gmodel 
> files is because they are *deprecated*.

I won't question the fact that they are similar enough that it might be
possible to adapt Gorm to work on both.  I need to think more about it to
come to a final conclusion.  And I'm definitely favourable to sharing
efforts.

But I want to stress that the whole purpose of Renaissance is to
experiment and implement new ideas which can not be supported in the
traditional .nib frameworks.

If all it was about was just a new XML .nib format, it would have been a
pretty useless project, and I would not have started it in the first
place.

In view of this, I want strongly a .gsmarkup specific editor, with
.gsmarkup editing specific code, as I don't think we'd be able to design
and implement the editor properly and according to the new ideas if we're
trying to force it inside a different architecture and mentality.

But once all this is safeguarded, I'm very happy to share code with Gorm.