Re: Some somewhat cooler thoughts...

[Nicola Pero]

> > If Gorm were modified to save to .gsmarkup files rather than .gorm files
> > then things would behave precisely as they currently do to the best of
> > my knoledge (if I am talking crap,  Nicola can put me straight - its not my
> > library, Im just an entheusiastic and very apperciative developer).
> 
> I was given the impression (by Nicola and Alex M.) that Renaissance uses
> relative positioning by using GSHBox and GSVBox objects.

It does by default, and it's sort of the philosophy of how we expect
people to use it.

But allowing you to turn off autolayout and providing your own absolute
positioning and sizes is trivial.

It's trivial because it's much less work for the library if you have
computed sizes and positions yourself, and the library can just use them
:-)


>                                                       Since Gorm relies on
> the user being able to set the exact position of the widget on the GUI, it
> doesn't seem that the two paradigms will mesh well as the resulting .gsmarkup
> file would need to approximate the position of the widget by nesting boxes to
> achive the desired position.

Hmmm - well - .gsmarkup can contain absolute sizes/positioning.

But if Gorm is used with Renaissance, it should have very good support for
boxes too.  The user would use boxes himself.  You drag a box into the
window, the you drag a button into the box, then a textview into the box,
etc.

By clicking on a menu item, Renaissance would draw red lines (continuous
and dotted) around boxes and box contents, so that they are aware of where
they are and how they are placed.  You can turn this off from the same
menu. (functionality already implemented in Renaissance).

Boxes in a Renaissance-aware Gorm would be very similar to the existing IB
guidelines.  But, contrary to the IB guidelines, they are essential parts
of the interface, and a Renaissance-aware Gorm would save them to disk,
and use them to create the window on another platform, following exactly
the same guidelines you've used on your original one.


> So, while it might be possible to create a GUI builder to make .gsmarkup files
> using portions of Gorm, the paradigms are so different that it would probably
> make a mess of things within Gorm itself.    Don't get me wrong... I don't 
> mind
> trying. :)   But I just dont see it happening. 

Ok - I sort of agree with you here - I'm not sure on this matter either.
:-)

Yes - you are right that the paradigms are different and conditionalizing
most of Gorm code to behave differently if editing .gorm or .gsmarkup
might make Gorm a bit of a mess, and maintenance nightmare.

I'm for obvious reasons a bit hesitant in starting a new, separate editor,
stealing a lot of code from Gorm, but not merging anything back.  I can do
it, and it would be the easiest route for Renaissance - but maybe not the
best one for GNUstep as a whole. :-)

Maybe rearranging the Gorm code we could be able to clearly separate parts
to be used when editing .gorm files and parts to be used when .gsmarkup
files.

If you have any thoughts on this matter, please let me know.


> > So, given this is the case, I dont see what is lost by moving over to using
> > them. Note that I am not talking about adding anything to Gorm to allow it
> > to edit the autolayout facilities of .gsmarkup files, merely that it saves
> > the current "exact position" information in this form.
> 
> Is it the plan to replace .gorm files with .gsmarkup files? / Will the
> Renaissance scheme replace the encoding scheme in gui which is currently used
> to create .gorm files? (I sincerly hope it won't)  
> 
> This should never be considered since Renaissance is *best* used as an
> extension to GNUstep since it can then also be built as an extension to Cocoa
> on MOSX.

Yes - you are perfectly right.  :-)

Renaissance is *best* used as an extension, and its `encoding/decoding' is
far more complex than the standard one.  I don't see any reason to dump
the standard one, which we already have, and works so well.

When I say I want to modify Gorm to support .gsmarkup, I'm absolutely not
implying I want to drop .gorm support.

 
> Creating a seperate GUI builder to create .gsmarkup files is the best way to
> go.

Ahm.  Ok - let's keep this decision on hold for a while still. :-)

 

> ** Renaissance only solves half the problem. **

Renaissance solves the *whole* problem of portability, if that's your
point.

It solves it *now*.  It *does* work on GNUstep and Apple Mac OS X, and I
can write GUIs which work, and look *good*, on both platforms (and you'd
never know when looking at them how they were created or that they are
ported from another platform, they look perfectly 100% native).

I bought an Apple Mac OS X to make sure it did.

This is a fact - Renaissance *does* provide portability *now* and it just
*works*.

Please stop spreading false information by saying otherwise.

 
> You will STILL have the issue that the encoding formats between the two 
> systems is incompatible, which is one part of the problem.

I think calling it `encoding format' is what is confusing you.


> The other part is, even if the encoding format was compatible the way in 
> which things are encoded (the order of encoding for ivars of a given class)
> is going to be different and very difficult to discover.

Renaissance does not encode ivars.  Renaissance creates objects as
described in the XML file by using the public API.  There is nothing to
discover.


> To make GNUstep *TRULY* crossplatform we need to solve this and other 
> problems.

I'm not sure what you mean.  I can compile and run Finger.app on both
platforms from the same source code, and it looks good and native and
works perfectly well on both platforms.

I call that portability.


> Simply making it possible to create GUIs for both platforms is not enough.
> 
> We have an encoding difference between the two systems *in general*.

Either you spend a few hours studying how Renaissance works (because, in
case you didn't notice, it *works*), and then once you've understood that
its 'encoding' is not at all the encoding you're used to, or if you don't
know/understand it, please just stop talking about 'encoding' when talking
about Renaissance.

Think it in this way:

 Renaissance reads the description of a window from an XML file, and
creates it using the public API.

Forget about encoding/decoding please. :-)

Renaissance has been designed to be *portable*.  It's deeply built in its
design.  I've trashed/replaced quite a few basic design principles of
NeXTStep nibs to get portability.

Renaissance is the result of years of work to build a portable UI file
format.  It *works*.  I wouldn't have released it if it didn't work.  I
kept it on my laptop for 8 months, until I was sure it worked.

You don't like it - fine.

But it *works*.

You think autolayout windows are not as pretty as gorm ones - I'm fine
with that - you are free to think what you want.

But Renaissance *works*.

You feel autolayout restrictive - I'm fine with you don't liking it.

But Renaissance *works*.

I'd be just happy with this basic fact being acknowleded - Renaissance
*works*.  You can have any opinion you want, but Renaissance *works*, and
its UIs *are* portable.

Please stop saying that it doesn't work.


> > For me that sums up the pro side of the discussion - and I admit that I dont
> > really understand what the con side iis at all .... unless I am wrong about
> > Renaissance being perfectly capable of ding everything that .gorm files
> > currently do.
> 
> The cons as I see them are:
> 1) .gsmarkup currently cannot express the same information as a .gorm file.

If it did, it wouldn't be portable.


> 2) GUIs created using .gsmarkup on one platform may not look as intended even
> with the "autoformatting" capabilities which Renaissance provides.   

I don't second this.  I think you should (honestly) trying using it before
arguing that it doesn't work.

But even assuming you are right, you can always create a separate
.gsmarkup for each platform/language, so where is the problem ?

Is that your suggested solution, generating a separate .gsmarkup file for
each language/platform ?

But consider Gomoku.app.  A small, hobbyist application written using
GNUstep.  Translated into 5 (I think, maybe more) languages by helpful
occasional contributors.  Imagine we do an Apple Mac OS X port.  It's fun
I do in my spare time - I don't have much time to maintain it.

If you're managing its 'Preferences' window using .gorm/.nib, you need 12
different .gorm/.nib files describing the same window.  You need to create
12 different files for the same window, making sure they contain all the
same things, connectors etc and you need to maintain 12 different versions
of the same window.  Do all changes 12 times, test everything 12 times.  

In my view, this additional development burden is so horrible as to
destroy all the advantages of using a graphical GUI builder.  You could
very reasonably consider just creating the user interface by hand in code
- at least you have a single codebase, make a change 1 time, test it 1
time.  I don't have all that time to spend on maintaining my hobbyist
application - if every window has 12 different versions to maintain and
test, it's just crazy.

Or you could consider using Renaissance - then you can have a single
.gsmarkup.

You can, if you are a hobbyist doing it in your spare time, with not
enough time to develop 12 separate windows.

If you are a big powerful corporation writing a hugely expensive
application, then you have the money and resources to develop 12 separate
windows ... and you can - why not - just create 12 .gsmarkup files, and
hand-tweak all autolayout parameters differently (or even move widgets
around) to get them look at their best on every platform/language.

I feel that .gorm/.nib, by forcing you to create a separate file for each
platform/language, it's forcing even the hobbyist to undergo the huge
overhead of a giant corporation.  Renaissance gives you the choice, either
a single .gsmarkup (which IMO can look great [if not great, at least good]
on all platforms/languages anyway), or multiple .gsmarkup (which
theoretically can be tweaked to look `at their best' on different
platforms).



> 3) The intelligent layout, in this case, will stand in the way of making it
> look good on all platforms since changes on one may adversly effect the look 
> on another.

You are arguing that a single .gsmarkup for multiple platform can't look
good on all platforms ?

Then create a separate .gsmarkup for each platform (/language).  Nobody
forbids you from doing that.

With .gorm/.nib, you *must* create a separate .gorm/.nib for each
platform.  With .gsmarkup you have the choice.  And this choice can be
critically important for small developers or small companies, which can't
afford keeping N (with N big) versions of each window of their
applications.

Btw, just to give a fair bit of background/real experience on this, and
get out of the FUD and vaporware about autolayout necessarily looking
horrible when moved to another platform, as far as I am concerned, my own
programs/experiments look much much prettier on Apple Mac OS X than on
GNUstep - even if I developed (and designed) the UIs under GNUstep using
Renaissance.

The reason IMO is that the appearance is much more influenced by the
'platform theme' and by the 'platform graphical look' rather than by
anything else.

The text is so much prettier on Apple.  The window background is so much
prettier.  The button edge is so much prettier.  The whole result is so
much prettier.

But what has this all to do with the layout ?

In a standard example, I wanted two textfields one over the other,
followed by 5 buttons, and a big textview below all that.  All using
nice/standard spacing between the elements, and keeping the buttons the
same size, and the textfields not too small.

I told Renaissance this is what I wanted, and Renaissance did it.  Had I
used IB to build the interface by hand, I'd have manually dragged the
buttons into the window, then set the image and text, then asked IB to
size them to fit the image/text.  Then I'd have moved the buttons to the
IB guidelines, and used IB help guidelines to align them, used IB
guidelines to put them in a row, then used IB layout facilities to make
them the same size etc.

So where is the difference ?  When building interfaces using IB, you are
*already* using the IB guidelines to help you position/align your widgets;
you are *already* using IB to make buttons the right size; you are
*already* using IB to make all buttons in a row the same size etc.

Without IB guidelines I personally can't get anything to look any good,
because I can't align things by hand, I can't get sizes of different
buttons the same by hand etc.
 
But those guidelines are at the end of the day, autolayout containers and
autolayout constrains: autolayout tools.

With IB you just use autolayout tools from IB to get the layout right,
then drop all autolayout tools/ideas you've used, and save to the file
only the final position/size information.

With Renaissance, you save to the file the autolayout logic instead, so
that the system can use the autolayout information to produce the window
according to your wishes even on another platform.

Personally, given enough time, I would have generated exactly the same
window on Apple Mac OS X as Renaissance automatically does.  Renaissance
is just automating the process of taking buttons, sizing them, aligning
them to guidelines and applying basic autolayout tools and constraints.  
Which is precisely the way I develop windows with an IB.  Once Renaissance
has an enough powerful autolayout system that I can express fully how I
want the layout of my window to be made, then Renaissance is just doing
what I'd do in IB myself.



> 4) The intelligent layout (GSVBox and GSHBox) features will be somewhat
> restrictive.

Whenever you feel they are restrictive, you can turn them off and fall
back to do things manually.

There are cases you might well want to do this - an Info Panel for
example.