Theodore Papadopoulo wrote:
>
[...]
> > I would support any pressure to keep the structure the same (for now).
> > I am glad that there is some inertia here because it would be too
> > easy to make (probably many) new structures so that the use of Glade
> > XML would be impossibly complicated. You would have to be ridiculously
> > optimistic to think that a brand new DTD (and all the processing
> > mechanisms) would be right first time.
>
> This answer may be naive....
>
> Reading this thread leaves me with the idea that something is
> very wrong with the current parsing process. In theory, it should be
> possible to keep both versions of the parsing code around for some
> time so that all glade files can still be read but only the newest
> format is written. This would allow for a smooth transition between
> file formats.
>
> This simply means that the file contains close to its top a flag that
> allows to retrieve the version of the format and which is used to
> toggle between various parsers. If such a mecanism is not available
> then I believe the format should be changed as soon as possible to at
> least allow for such a behaviour (a simple version number close to
> the top is sufficient).
>
> Am I missing something ???
As I said later in my posting, this approach is possible but implies
that _every_ app that uses Glade XML supports the new format and therefore
is amended at every XML change if they are to be able to parse the 'latest'
XML. I reckon that this approach is guaranteed to force a 'only works with
Glade <= 0.5.5' message from most apps.
I agree that any 'new' format Glade file must have a glade_version number
specified somewhere so that developers who are attempting to stay at the
bleeding edge can interpret the XML but I think that it would be a mistake
to expect _every_ other app to be able to cope with _every_ version of
Glade XML if they are to be useful. Yesterday I came across a 0.4.1 Glade
file and, guess what, my module couldn't cope with it correctly because
it expects >= 0.5.0. This is just possible to deal with at the moment but
think of the problems of parsing 0.4.1, 0.5.3, 0.5.4, 0.5.5, 0.5.6 etc
especially when the changes are unexpected and unannounced.
If my module is to be useful it must be able to deal with Glade files, not
Glade 0.5.3 through Glade 0.5.7 but all of them. If I have time, I will
track the Glade changes and update my code but I think that it would be
unreasonable for the Glade developers to expect everybody to jump when
they decide that a new data format is desirable. This is the Micro$oft
approach that claims some proprietory rights over a file format. They
can get away with it (at the moment) but IMO it is not an 'open' approach.
I am not against real improvements in the data structure, but I am worried
that Glade will lose favour if it becomes a fast moving target like so
much promising but unusable software. I hope that there is a way to improve
the file structure (which is not _Glade_ after all) while still getting all
the benefits of such a beautiful UI builder.
I can feel the temperature rising :(
Regards, Dermot
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
