Re: Some somewhat cooler thoughts...

[Gregory Casamento]

Hey Pete,

Being the current Gorm maintainer, I thought I would make my feelings known on
the subject...

--- Pete French <pete@twisted.org.uk> wrote:
> Hmm, looking back on today I think I might have been arguing in a somewhat
> unhelful  way for part of today, for which I appologies. I just read through
> a number of the posts again, and decided to write something a bit calmer.
> 
> So, here goes...
>
> Renaissance is (or will be when complete as far as I am aware) capable of
> fencapsulating all the verbait information that is currently held in .gorm
> and .gmodel files. Maybe the impression was given that this isnt the case,
> and thats what bothered people.
>
> 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.   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.

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

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

> This doesnt loose anything - but it does give us two big wins. The first
> being instant portability. You can just type 'make' and away it goes under
> OS X. Yes, the interface will need tweaking and maye re-laying out to make it
> look nice... but it allows you to start (instantly) from the position of a
> running, fully functional application. Imagine also if nib2gmodel was
> turned into a nib2gsmarkup utility - you then ahve a way of migrating
> code backwards and orwards across the three platforms with relative ease.
> 
> I know some pople dont consider cross-platform to be important, but if
> we can get it "for free" without taking away from those people who dont care
> then thats surely a win ? You could even then run Gorm under OSX. I'm also
> trying to get it running under OS42 so then theres a way of supporting legacy
> systems too.

That's cool...  let me know about your progress.   :) 

** Renaissance only solves half the problem. **

You will STILL have the issue that the encoding formats between the two systems
is incompatible, which is one part of the problem.   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.

To make GNUstep *TRULY* crossplatform we need to solve this and other problems.
  Simply making it possible to create GUIs for both platforms is not enough.

We have an encoding difference between the two systems *in general*.

> Secondly it allows those of us who prefer to use autolayout to do so. Without
> disrupting the lives of anyone else. Thats also a bit bonus for me writing
> new code.

Gorm has the same autolayout features which were present in IB using the
spring-tension model.   In the size inspector when creating a GUI you can set
up how your widget should relate to others around it by using this.

I personally believe that *less* intelligence in the layout model (as with IB
and Gorm) allows the developer more flexibility.   With Renaissance, it seems
as though I'll be constrained to doing things in a particular way.

Renaissance uses much the same paradigm that is used for laying out webpages,
which I personally find somewhat restrictive.

> This also then outs us in the positiong of ahving a single file format across
> all platforms. Currently we have .gmodel, .gorm and .gsmarkup - all trying
> to do rougly the same job.  Whats that buying us ? Why not just decide to
> adopt a single cross-platform standard and use it for everything ?

This was my main concern when Renaissance came out.   I became concerned that
we seem to be reinventing the wheel, when the current wheel (Gorm) is pretty
much done.   Also, the fact that we are doing this when so much else (printing
and other things in gui) remains to be done elsewhere concerns me.   

Renaissance presents a model which some people like.   I personally like the
Gorm and IB way of doing things, but to each his own.

FYI, the original purpose of .gmodel was as a temporary/intermediate format for
porting.   Gorm can currently import .gmodel files and save the result as a
.gorm file.    Renaissance is only the latest addition.
 
> 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.
2) GUIs created using .gsmarkup on one platform may not look as intended even
with the "autoformatting" capabilities which Renaissance provides.   
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.
4) The intelligent layout (GSVBox and GSHBox) features will be somewhat
restrictive.

> -bat. [sorry if I raised any temperatures earlier today...]

:) Apparently too late...   I saw some of the earlier messages.

BTW, Gorm is now fully functional.   You are all welcome to try it.   Please
report any bugs back to bug-gnustep@gnu.org and feel free to ask help from me
personally in using it.   Any documentation that is available for IB should
suffice as Gorm is identical in it's operation.

I am in the process of writing some comprehensive docs for Gorm so that people
who haven't used IB before won't have difficulty with some of the concepts it
introduces.

Thanks, GJC              


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