Martijn van Beers wrote:
>
> On Wed, Nov 10, 1999 at 06:52:27PM +0000, Dermot Musgrove wrote:
> > Hi, an attempt to find the third way :)
> >
[...]
> > As Damon said, a massive structural change to the data would mean an
> > enormous amount of work for a lot of people whose software processes
> > the Glade XML.
>
> I'd think if the app was nicely structured (unlike glade itself), it
> wouldn't be _that_ much work.
I don't think that we can make assumptions like this about other people's
code. My ideas of structure may not be exactly the same as those of other
coders, or even possible or desirable in the languages they program in.
> > 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.
>
> No, the DTD won't be used until we have it right. It's not that hard.
Yeah :)
> and besides, the first versions would be in a development branch,
> which normal users should ignore. As an add-on developer, you can
> happily ignore them too, until you are assured it works.
Right, like we all use the stable branch of anything? When there has been
a 'stable' version of Glade for a while I will agree, this is not a snipe
at Glade, none of us use version numbers over 1 after all but people will
upgrade, you know they will, as soon as a new version appears.
> > Imagine if every release of Glade had an XML structure that was
> > incompatible with every previous and future version, isn't this is
> > what a rigourous DTD means?
> No, it doesn't. The only time the DTD changes is when new widgets get
> added.
Widgets are being added at every release and there are still a few that are
planned, and this doesn't even take account of bugs or 'enhancements' that
are needed.
> Gtk+ and GNOME are pretty stable now, so that shouldn't be a
> problem until gtk+ 1.4 and GNOME 2.0.
This might be a problem whatever whatever happens to the XML. Perhaps
Glade will coordinate its version number with Gtk/Gnome. I don't know
how people are going to know which version of Glade to download and use
otherwise. But then so should my module and libglade and gate and eglade
and Gtk-Perl and any other packages that use the Gtk/Gnome libs. I dunno,
has anyone got ideas about this?
> Daniel Veillard also said he
> would make it possible to have a different DTD for every library. So,
> no. I don't think that will be a problem.
I don't understand what you mean by 'library' here.
> > I don't want to even think about the problems of supporting all the
> > different versions of XML (in parallel) in a separate package. IMO, the
> > time-lag in development cycles would make the whole idea unworkable.
>
> You don't. A version of your package supports a certain version of
> the glade DTD and nothing else.
I fear that this is the Micro$oft option again - track us or die.
> > see at http://www.w3.org/TR/xmlschema-1/ (5 Nov 1999) that there is now a
> > working draft from w3c (moved on from a NOTE :-)) so I guess that they
> > are definitely comming.
> I bet it will take a LONG time before it will be a Recommendation. I
> don't think it's a good idea to wait for that.
Fair comment. I suppose that it all depends on the timescales but I was
just suggesting that long term judgements shouldn't be affected by short
term obstacles. I can understand your worries that this might mean that
nothing happens at all though :)
> > > This might not be good reasons to change in themselves, but what we
> > > have now is a bunch of tags thrown together as you went along,
> > > and it doesn't make sense.
> > The present structure does have the great advantage of being very easily
> > extensible. Such a simple structure allows widgets and properties to be
> > added without any DTD or parser-specific changes.
>
> That's not an advantage of the current structure, but a result (I
> wouldn't call it an advantage) not using a DTD
You may not call it an advantage but I, most definitely, do. Again I am
pleading, selfishly, that you take into account the problems that you
might cause to developers who are using and _supporting_ Glade.
> > However, in the long term I think that a more rigourous approach will be
> > necessary.
> The earlier we do this, the better. In a year, there will probably
> be even more apps that use glade output, so there'll be even
> more resistance from people that don't like changing all their
> hard work around.
>
> > I reckon that the only way that you can change the structure at this late
> > stage is for Glade to maintain two parallel files of XML. One as now the
>
> Sure, we should probably allow new versions of Glade to import
> the old structure for a while, so users can easily upgrade.
I think that it is important to export the old format too. Otherwise my
module (and many others) becomes useless as soon as Glade users upgrade.
Even if Glade itself uses the new format XML to load and save, it would
be _so_ much more helpful if it continued to export the present format in
parallel.
There is a middle way here somewhere, I'm sure :)
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.
