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