Re: Menu (Was: Re: Unimplemented AppKit classes)

[Nicola Pero]

> > The idea of visual editing is great, and Renaissance is going to have
> > that! :-)
> > 
> > It will have its visual editor.  It is meant to have it.  It's incomplete
> > without it.
> > 
> > The visual editor will not use encoding/decoding, but Renaissance to
> > read/write.
> 
> What about custom objects and custom views refering to those objects?
> Or just standalone objects.

<button instanceOf="MyButton" title="Quit" action="terminate:" />

will create a button, but use MyButton as the class of the button instead
of NSButton.  All the attributes available to buttons are available for
you to use, plus you can add any custom embedded outlet you want.

In Renaissance, *ANY* widget and window supports the 'instanceOf'
attribute automatically.  (so, you can do <window
instanceOf="TemplateWindow" ...> or <textView instanceOf="RichTextView"
...> etc)

(you need Renaissance from CVS for support for this, 0.6.0 doesn't have
it).



<instance instanceOf="MyWindowController" />

will create a standalone instance of MyWindowController.  You can use
embedded outlets only with this variant.


If you need your own tag, then you need to extend Renaissance.  It's very
easy to add new tags to Renaissance - you just need to add a class
implementing the tag, and encoding/decoding it.  Very similar than with
traditional encoding/decoding, but you add an entire class rather than a
couple of encode/decode methods - which allows for a lot more flexibility
and a much richer API.

We already have an API for all that - but I want to feel free to change
that API while I write the graphical editor to account for all sort of
things which I didn't think about, so please don't use it too much yet :-)


> > Keyed archiving will not give you portability.
> > 
> 
> Why not if we use some readable (or at leas well documented) format 
> suitable for object archiving (like XML) ? I mean, the thing we need
> here is additional information about the ui.

No - it's much more complicated than this - in many cases we need less
information.  We don't want to encode the window background color unless
the programmer really wants to set a custom background color.

Else, a window encoded under GNUstep would use the GNUstep window
background color, and when decoded under Apple Mac OS X would be decoded
with the window background color which the window had when encoded, and so
use the GNUstep window background color on Apple, which would look
horrible on Apple (the same would happen on GNUstep itself with different
themes).

But we still must give the user/programmer the possibility of forcing a
custom background color for a window (say, yellow) if he really wants so;
it that case, we do need to encode the window background color.

If now you use both key-archive all attributes, and most attributes are
optional except the few the programmers want to set to force them ... well
you are approaching a description of Renaissance XML format :-)

Which, unless you use Renaissance, it's not supported by standard (not
even keyed) archiving.


> Renaissance: Description about position and size relationships between 
> objects.
> Gorm: Archived 'real' objects.

I'm confused by this suggestion.  What do you mean by 'real' objects ?

Why do you want to archive real objects ?  What is the advantage ?

Using the .gorm format automatically destroys any portability, so I'm not
quite sure why you want it.

You can't encode the real objects on one platform, and decode them on
another platform.  You can't, unless your definition of encode/decode is
so vast as to include the whole Renaissance in it, and then you should use
Renaissance and that's it :-)


> I think wee need both. Gorm is lower layer and Renaissance is upper layer.

This description makes no sense to me.

Renaissance is a complete full replacement for the usual encoding/decoding
system, including anything needed to build portable UIs.  A modified Gorm
would be an *upper layer* running over Renaissance and allowing you to
edit windows graphically, and then use Renaissance as the *bottom layer*
to write/read them to disk.


> From my point of fiew, i would suggest to add some additional information 
> to gorm files. That information should be something like it
> is in .gsmarkup files.

.gsmarkup files contain different information than .gorm files, not more
nor less - different.



> What we need is something in between. What about including .gsmarkup file
> describing relationships between objects into .gorm archove/package?
> Then after unarchiving you do the relayout as you do reconnection
> of outlets and actions now. This is possible after adding
> Renaissance features into gorm, of course. First step should be adding
> H/VBoxes into the gorm...
> 
> Keyed archiving came to my mind, because you can add custom additional
> information about archived objects into the archive without affecting
> decoding.

Hmmm.
 
 
> >>> What you really want is a graphical editor for Renaissance files which
> >>> allows visuallayout, but using the Renaissance objecst to do it. Then
> >>> thats the perfect soution I feel for both parties.
> >>> 
> >> Or take it from other point of view ... I want a way of describing 
> >> position and size relationshps between objects in Gorm :)
> > 
> > You want a modified Gorm which uses Renaissance instead of
> > encoding/decoding.
> > 
> 
> Yes, something like that, but I would not drop encoding/decoding (custom
> objects reason).

"custom objects reason" is not clear to me.

Renaissance already supports custom objects in the same way as traditional
encoding/decoding does.  You can just put a custom object in place of a
standard object anywhere inside a window (or a window itself, or a
controller standalone object).

The API for writing new palettes/tags is not finished/stable yet - simply
because I don't want to commit to an API for palettes before I can even
write a palette myself. :-)  But it will be available - it fits perfectly
well in the framework.  Renaissance IS extensible - a lot extensible - you
can add new tags/custom objects.

Actually, I feel that Renaissance is more powerful and flexible than .gorm
in the management of "custom objects", because it's not decoding/encoding
objects of a fixed class.  The class of the decoded objects can be freely
changed at run time.

It can easily swap classes when decoding (see the 'instanceOf' attribute
at the beginning).

Actually, Renaissance can be extended in completely new directions, such
as repetitions or conditionals or complex associations (see Helge's
posts).  While those suggestions remain vague and possibly difficult or
cumbersome to do at the moment, a more mature Renaissance might well
support them.


> Moreover, there should be situations, where you use exact placement
> of objects into the window and do not use auto placement.

Yes - but there is no reason why Renaissance can't do this.

It's so much more trivial than autosizing.

<view width="200" height="200" />
  <button x="2" y="34" width="120" height="12" title="Quit" />
</view>

will give you a button with the given size at the given position in the
enclosing view, skipping autosizing and autoplacing.

If that doesn't work, it's a bug and let me know (I'm not sure I have
spent the 2 minute required to implement the x/y attribute for views), I'm
sure I tried and tested providing width and height (which automatically
disables the autosizing), but I probably never tried it out the x/y stuff
... but this is *trivial* to implement, if you think you might want to use
it, I'll make sure it's all implemented and works out of the box - which
is not at all a problem - nothing can be more trivial I'd say.