Re: Some somewhat cooler thoughts...

[Nicola Pero]

> I understand this.   To reiterate:  In my original message you will see that I
> am speaking to the larger issue of incompatibility between GNUstep and MOSX 
> *in
> general* not only on the GUI front.
> 
> For example, if I encode an NSNumber (or any other object) to a file in 
> GNUstep
> and attempt to read it using MOSX I will be unable to do it and vice-versa.  
> THIS is the larger issue that I have been talking about.   You seem to be
> limiting your scope to the GUI front, but I'm not.
> 
> It's my belief that there is a way to solve this, but no one has tried yet. 
> Renaissance makes progress on the GUI front, but not on data compatibility
> (unless your saving to a non-serialized plist or other text file) or the DO
> communication issue.

Ok - sorry then - I misunderstood your email completely - I apologize.

Yes - you are right in this - Renaissance only addresses the GUI part; it
does not solve portability of encoded objects, or
cross-OpenStep-implementation DO - it only solves the GUI part (I now
assume that's what you meant by 'it solves only half of the problem' then)

That might or might not be a problem, it depends on the type of
application.

I was assuming we were talking of GUIs mostly, which is why I thought you
were talking of GUIs still - but yes if your point is about encoded files
and cross-DO, while I think for most applications those shouldn't be a
problem - yes, for some they are a difficult problem.

It's just sort of a separate topic, but yes, relevant. :-)

Thanks for taking the time of explaining your position again - I apologize
for not getting it the first round. :-)


> [...]
>
> I have been investigating ways to accomplish this in .gorm files.    It could
> be done by translating the string which is decoded from the .gorm file when
> it's loaded into the application at run time.

Yes ... but then what happens if the translated string is too long to fit
the original size of the button ?

(I'm not expecting you to reply, it's just for stimulating further
thoughts).
 

> > But those guidelines are at the end of the day, autolayout containers and
> > autolayout constrains: autolayout tools.
> 
> I was under the, perhaps mistaken, impression that Renaissance *forced* the 
> use
> of the box layout.   I thought the whole *point* of Renaissance was to
> autolayout the GUI so that it would look acceptable on all platforms.

Yes - you can turn off autolayout, by just not using boxes, and forcing
sizes and positions of GUI objects - but then of course your GUI might not
look much usable on other platforms/languages (buttons might be the wrong
size or mis-aligned etc) unless you undergo the effort of writing
different .gsmarkup for different platforms/languages.

This is not how I would do it and yes sort of not the 'default' philosophy
in Renaissance, but nothing prevents it from being realistically possible.

I think I need to spend a few days testing/{finishing if
needed}/documenting this way of using Renaissance, as it seems there is
quite a lot of interest in it.


> And what if I don't want my buttons and such to line up along these 
> guidelines?
> What about allowing the user/developer the freedom to do what he/she wants?

As a first step, you can tweak the autolayout flags (this is like
adjusting the positions and relationships of guidelines to be different
from the standard ones, or moving the guidelines around).

By changing autolayout flags and adding/removing/rearranging boxes and
grids, you can probably get nearly any possible position you might need
:-)

Anyway, as a second step, if the first wasn't enough, you can write your
own autolayout object supporting your specific needs (this is like
completely writing different guidelines behaving in different ways).

As a last option, you can turn off any autolayout and hardcode sizes and
positions.  I put this as last because it won't work well when you port
the application: you will need a different .gsmarkup on a different
platform/language.  It's not an option for me usually (due to inherent
laziness when it comes to repetitive tasks and lack of development time) -
it might be an option for a moderately big company, or for a devoted
individual.

 
> A few things to sum up my feelings:
> 
> 1) I never said I didn't like Renaissance.  I simply said that it should not
> displace .gorm and I that I had certain reservations about it.
> 2) I am very willing to help in either a) adding .gsmarkup support to Gorm.app
> (hard) by bundlizing certain features or b) help in writing another UI builder
> perhaps using Gorm as a basis or by making portions of Gorm into
> libraries/frameworks which can be shared between the two applications.

Great.  It seems we are probably going for b) then.  I'd really appreciate
your help and experience with Interface Building when we start this job,
and possibly making portions of Gorm into a library might be a good idea.


> P.S. I must admit to be a little suprised when Renaissance came out especially
> when I was just finishing up with Gorm.app.   I was concerned that the project
> might be shifting directions for some unknown reason. :)

Well - I am very well aware that not all the world is going to necessarily
love Renaissance - and that there might well be reasons to prefer a
traditional Gorm. :-)

I did never want to interfere with the traditional way of building
interfaces - really - I implemented the whole of Renaissance as a separate
framework so that it's portable, but also so that it could be developed
separately without interfering with/harming/messing up the traditional way
of building interfaces.

I don't really want to feel like 'aggressive' wrt traditional interface
building; I'm really not - I'm happy with people going on building
traditional interfaces using a traditional Gorm if they so like, and
myself (and whoever, often or occasionally, so wishes) building
Renaissance interfaces using Renaissance + a modified Gorm.  I'll try
honestly to build good working support for traditional size/position
placement of views (including traditional autoresize flags) in
Renaissance.

I need to stand up and talk loud for Renaissance only because I have the
feeling that unless I do, nobody will realize that we have this new
powerful toy, or take it seriously. :-)

I think any of us involved in GNUstep must be aware that now we have
Renaissance - no matter if you want to use it or not.  I hope, after all
the discussions we had, that now everyone is well aware of its existence.
:-)