discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some somewhat cooler thoughts...


From: Nicola Pero
Subject: Re: Some somewhat cooler thoughts...
Date: Fri, 24 Jan 2003 14:03:57 +0000 (GMT)

> A Renaissance UI-Editor, on the other hand, may choose to put different 
> information into the .gsmarkup file (not relying on GSCoding) and rely on the 
> Renaissance framework to initialize a fully functional object.  In fact 
> the User will have to tell the RUI-Editor which attributes to save and 
> which to leave for the Renaissance library.

Precisely.  That's exactly how it would work.  You will choose which
attributes you want to save in the .gsmarkup.  Usually a very few
attributes for each widget (the ones you manually edit).  All other
attributes will be chosen at run time using the platform native defaults.



> Well actually I think everything currently encoded in the .gmodel format 
> is representable in the .gsmarkup format.

Hmmm.

Well, yes, sort of - there could be different interpretation of this
sentence.

I'm not sure I'd be interested in working on that though (or that there
would be much interest in that). :-)

I sort of feel that .gmodel is just getting obsolete as a separate format
... it's now only an intermediate portability format from Apple .nib to
GNUstep .gorm, and I don't see much future for it.

I'm not sure there is much interest in working more on it.


>                                           (Independant of what the rest 
> of the Renaissance-framework currently makes of it, so I agree with Adam 
> that .gmodel becomes obsolete.)  That means to say, that the file format 
> already just as easily supports the WYSIWYG paradigma of .nib/.gorm 
> files.  The .gsmarkup format merely *allows* (a) additional layout 
> information and (b) the omission of information which can later be 
> enriched the by the parsing mechanism used (Such as Renaissance's 
> autolayout mechanism for example.)

Yep.  It also allows additional processing (such as translation of
localized strings during decoding), and the addition of information which
is not directly related to a specific ivar (or stored in a specific ivar),
but which can be used by the library to adjust the widget native
attributes to get that `effect'.  I don't have great examples except
(a) itself :-)

 
> I would even go so far as to say that the .gsmarkup format could be
> used as generic a portable object archive (well actually it already
> is.)

Basically ... yes.

If you look at Renaissance source code, you see that there is a Markup
directory, which can be compiled and installed as a standalone library,
and doesn't depend on the AppKit.

You can compile that library standalone, and use it to read/write generic
stuff, having nothing to do with gui objects (you need to provide your own
tag library).

Generally, as it is, if you just want to do 'standard' encoding/decoding,
the Markup library can be quite cumbersome to use compared to standard
encoding/decoding, because I implicitly tried to push into it part of the
data structures needed by the future graphical builder.  Maybe I got it
all wrong, and will rewrite all the internals better. :-)



>  But to be more concrete, there is nothing stoping us from writing a 
> GDL2-gsmarkup extension library that include an 
> EOGSMarkupArchiver/Unarchiver which would use EOModel information to 
> arichve an enterprise object graph.  Of course feeding this file to the 
> current Renaissance library would not be meaningfull (I guess give you 
> the object graph in memory but no UI  representation).  But my point is 
> that if you compile the this GDL2 extension against an EOF-App (which 
> also implements the clases that are referenced in the .gsmarkup file) 
> the object archive in the .gsmarkup file are fully poratable!

Ok.  I'm not familiar with it, so I'm not sure if you want/need .gsmarkup,
or if a simple standard XML/plist encoding/decoding would be best.

But yes, you could use the Renaissance markup reader/writer, coupled with
a EOF-specific tag library, and use it to get a portable format.

It's possible that a simple traditional encoder/decoder using XML (or
plists or any ASCII text format) as the file format might get the same
result though. :-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]