Re: Renaissance menus on OS X ?

[Nicola Pero]

> >>...as with so any things in the post-NeXT world :-) o.k., that makes sense
> >>now. I think what would be a good thing to have, however, would be a "base"
> >>set of gsmarkup files which do the same as a "new project" in Interface
> >>builder does - i.e. come with all the standard menus attached so you just
> >>add your own at the end. Alterting the example so that the gsmarkup
> >>file was loaded before application main rather than in a delegate might
> >>also be advantageous if you really wnat people to do it at that point, as I
> >>suspect that an awfull lot of code is written by taking an example and
> >>modifying it.
> > 
> > Yes.  Good idea!
> > 
> > I've been thinking about adding a 'template' application.
> 
> Hm, I'm not sure what you mean.

He just means template gsmarkup files for the main menu (containing the
usual Quit, Edit, Copy, etc entries) and the main.m code.  You then copy
them, and start your application from them (I think project center for
example does the same, when you create a new application, you get a
template/default main.c suitable for an application and other similar
basic files).


> Anyway, "standard components" can be easily build using "WO reusable
> components". Those can even have parameters, eg:
> 
>    <var:embed component="DefaultMenu" title="NSApp.name"/>
> 
> Think of it like using a .nib as a view in another .nib.

Hmmm.

Yes - we probably want to have something similar, and all the other stuff
with conditionals, repetitions etc.  Maybe as an extension or as a
preprocessing ?

When the .gsmarkup is read, it would first be preprocessed to process the
var:xxx, generating (internally and invisibly) a plain .gsmarkup which
would be processed in the usual way by the existing code.  This just for
simplicity -- we can merge the two processes together at a later stage
when things are clearer, and the design more definitive.

 
> > I added a new <image> tag for this, and documented it.
> > 
> > Something like
> > 
> > <image name="GNUstep" />
> 
> I would suggest using "<img src=.../>" and adding a NSURL subclass for 
> resources (eg gsresource://mainbundle/GNUstep.gif). The src would need 
> to be relative to the document (gsresource://mainbundle/MyPage.gsmodel) 
> and we could use "img src="GNUstep.gif".
> Easy todo with NSURL.

<image name="MyImage" /> will use [NSImage imageNamed: @"MyImage"] as the
image to display.  That seems the obvious way to start to me: usually when
you write an application you just put MyImage.png in your application main
bundle, and [NSImage imageNamed: @"MyImage"] will found it from there
automatically.

I suppose using a custom URL format to specify where to find resources
might be a quite interesting extension.  I suppose that would allow you to
choose the bundle/framework you want to get the resource from, for example
?

[NSImage imageNamed:], while it's the usual way of getting to an image,
has probably the disadvantage that if the .gsmarkup file is part of a
framework (and not of the main application), then when the .gsmarkup file
is loaded, I don't think the image would be found, as the framework's dirs
are probably not searched.  Unless you register it manually with NSImage
under a certain name of course.

As you say, I suppose we could add a src="..." attribute with a custom
NSURL as something more advanced than name="..." - we can have both
name="..." and src="...".  I like src="..." :-) but probably need to think
a bit about how to design this URL format and have it work.

I probably need to prepare a list of ideas :-) I can't implement
everything immediately, and I want to think and discuss a bit before doing
things (to get them right), but I don't want to loose/forget them in the
process.  I think I'll add an IDEAS file to Renaissance.
 
> > <window class="MyWindow" title="Hello" width="200" height="4000">
> >   <!-- some views here -->
> > </window>
> > 
> > then the system when decoding the <window> tag could plainly simply
> > allocate it of class MyWindow (assuming it exists and it is a subclass of
> > NSWindow) instead of simply NSWindow.
> 
> "class" should be used for CSS ;-) But besides that, yes, IMHO this 
> would be correct (MyWindow class used in a window "mapping" context).

Do you have another suggestion, instead of calling the attribute 'class' ?  
It's very intuitive as a name for the attribute.

I like the idea of CSS, but giving it a serious thought, I'm not sure it's
actually relevant.  Can you imagine a really useful example ?  I'm frankly
not sure I can, and the system is so much simpler without them.