A few thoughts on Gorm/Renaissance integration (was Re: Renaissance)

[Gregory John Casamento]

Calvin,

I am the maintainer of Gorm, in case you were unaware of this, so it's safe to
say that I know it's internal workings better than anyone. :)  So please read
on...

--- Calvin Mitchell <calvin674@yahoo.com> wrote:
> To The Illustrious Mr. Baehr:
> 
> I understand and appreciate your concern...
> but what are we talking about here???
> 
> XML.
> 
> How more cross-platform can you get?
> 
> Let Renaissance volunteers create their editor....
> Hand the code over to the Gorm volunteers so they can
> quickly add the capability to produce Renaissance/XML
> output ...
>
> Voila!
> 
> NeXT (pun intended) thing you know, Apple developers
> are going to want Renaissance output for
> Cocoa/Interface Builder--because it's EASIER and MORE
> INTUITIVE.

It's not quite as easy as you seem to think. :)
 
> Then the Gnome/KDE folks are going to want Renaissance
> integrated with their tools (Glade, etc.).

So far as I know, this would require a complete re-write of Renaissance to use
GNOME/KDE widgets.   Glade produces code, last I checked.

> I mean, let's face it: every hour someone's coming up
> with a new application of the XML technology BECAUSE
> XML SOLVES PROBLEMS.

While XML does make it easy to read and write in a common format, without a
detailed understanding of how things work within an application it's difficult
to say if XML will solve all problems.

> <at this point XML pundit takes applause and runs
> offstage before tomatoes are thrown>

Your postings on this topic have forced me to talk about this subject a little
sooner than I was planning to.

Integrating Gorm and Renaissance
================================
This question has been asked a number of times.   I will try my best to address
all questions here.

A little background on Gorm
---------------------------
Gorm follows the IB model very closely in the sense that it uses the paradigms
for autoresizing and encoding of the object graph in the same was as IB does.

Gorm uses the encodeWithCoder: and initWithCoder: methods in the GUI library to
read and persist the object graph.  When a .gorm file is loaded it is the
initWithCoder: methods in each one of the gui classes which play a vital role
in  loading the .gorm file into a running application or loading it into the
Gorm application for editing.   When persisting, the encodeWithCoder: methods
are called by Gorm to write out the data for each object in the object graph.

Additionally, custom objects are handled by stand-in objects that are present
within the Gorm file since the actual instance of the class is unavailable from
withing Gorm (since the user is probably just implementing it :) ).

The .gorm model files also utilize the autolayout features available within

So... what does all of this mean for Renaissance?  Read on...

A little background on Renaissance
----------------------------------
Renaissance was created to provide a crossplatform XML format for GUI creation.
 It utilizes a paradigm similar to a web browser (the box-in-box paradigm) to
determine the relative positions of the widgets with respect to one another. 
This feature can be turned off and the user can utilize absolute positioning.

Renaissance uses the GSMarkupCoder/Decoder classes to encode and decode itself.
 While it is possible that these could be utilized in Gorm to output
Renaissance files the main issue is not with encoding/decoding.

Renaissance uses box-in-box paradigm and an automatic translation feature which
might make full integration into Gorm difficult since neither is easily modeled
graphically.

In conclusion
-------------
While it's certainly possible to make Gorm output Renaissance files, it would
be difficult to modify Gorm to take advantage of some of the features of
Renaissance.   Also, some of the features of Renaissance are at odds with
existing features of gorm files.   

We should explore the possibility of having Gorm be able to export gsmarkup
files to provide a starting point for users of Renaissance.   Gorm's main focus
would, however, remain the editing of .gorm files and not .gsmarkup files.

GJC

=====
Gregory John Casamento -- CEO/President Open Logic Corp.
-- bheron on #gnustep, #linuxstep, & #gormtalk ---------------- 
Please sign the petition against software patents at: 
http://www.petitiononline.com/pasp01/petition.html 
-- Main Developer of Gorm (featured in April Linux Journal) ---

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/