Re: Some somewhat cooler thoughts...

[Gregory Casamento]

Nicola,

Please read below...  :) 

--- Nicola Pero <nicola@brainstorm.co.uk> wrote:
> 
> > > 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. :-)

I believe that, at the very least, we should componentize support in Gorm for
both .gorm files and .gsmarkup files, if we want to have ONE UI Builder.
  
> 
> > ** 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.

Yes, it solves the portability problem *for GUIs*.   It, however, *does not*
address the interoperability problems which have plagued GNUstep since it's
inception.   My point was the the *encoding* format between MOSX and GNUstep is
incompatible, not just for GUIs, but for data in general.
   
What good is an application which can be built on multiple platforms if the app
cannot read files saved on one on another.

For instance, if I encode a

> > 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.

I was *actually* referring to the encoding used by all objects which implement
NSCoding, not *just* GUI objects.  See above.

> > 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.

Here, again, I was referring to *INTEROPERABILITY*.   Not just with GUIs, but
with *everything*. 

> > 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.

Please see my references to *INTEROPERABILITY* above.

> 
> > 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*), 

Gorm.app and *gorm* files *work* now too.

> 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.

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.

> 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.

I never ever said that it didn't work. :)  I simply said that I find the model
supported by .gorm and .nib files to be more comfortable for me personally.

> You don't like it - fine.
>
> But it *works*.

I also never said I didn't *like* it.   ANYTHING which helps GNUstep get
noticed is fine with me. :)   GNUstep deserves to be noticed.

> 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.

Kindly find in the message that I wrote where exactly I am saying that
Renaissance doesn't work.   I never actually said that.   I said it *may* not
look as intended on all platforms.  

> > > For me that sums up the pro side of the discussion - and I admit that I
> > > 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.

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.
 
> 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.

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.
 
> 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.

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?

> 
> > 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 doing things manually.
>
> There are cases you might well want to do this - an Info Panel for
> example.

I was unaware that this feature could be turned off.

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.

Later, GJC

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. :)










=====
Gregory John Casamento
------------------------------------------------------------------------
Please sign the petition against software patents at:
http://www.petitiononline.com/pasp01/petition.html
Petition to make Lighthouse Application Suite Free Software at:
http://www.petitiononline.com/laafs/petition.html
------------------------------------------------------------------------

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com