Hi, my previous warnings of my lack of XML experience apply here too :-) Martijn van Beers wrote: > [...] > > 6) There is no mention of white-space handling which I reckon is needed > > if the .glade files are to be easily human-readable. > You need to specify white space in the DTD!?! Well every element can have an XML-SPACE attribute (DEFAULT | PRESERVE) that tells the XML processor how to handle white space that exists immediately before or after markup (in certain cases). > > 7) I like the modular principle but wouldn't it be easier if widget > > properties were grouped in the same way that Gtk does. What I mean is > > that window/widget/misc properties could effectively be inherited. > How would you do that? All I meant was that you could change your !ENTITYs like GtkWindow.attributes so that you group them in the same hierarchy that Gtk itself uses. Then, for instance, GtkWindow.attributes would use GtkContainer.attributes that would use GtkWidget.attributes and GtkLabel.attributes would use GtkMisc.attributes that would also use GtkWidget.attributes just like the Gtk Object Hierarchy. > > 8) There are no attribute enumerations so that validation of say widget > > classes is not possible. I guess that these should be modular and > > congruent with the Gtk/Gnome enums. > I don't understand what you're saying here. If you had attribute enumerations (stored in !ENTITYs ?) that mirrored the Gtk enums you could easily validate attributes like GtkWindowPosition while defining them centrally for new values (eg GTK_WIN_POS_CENTER_ALWAYS) > > 9) There is still no differentiation between the <signal> element and the > > <signal_to_emit> property of <accelerator>. These should be probably also > > be ID/IDREFs in any case. > What do you mean there's no differentiation? The accelerator property > is an attribute, and the <signal> is an element. Very true, I was getting confused thinking about two structures :-) > > 10) Do you have plans to define some <!ENTITY>s, I reckon that they'd be > > vital to ensure a valid XML structure. > I do have some entity's, but from what I have heard, they are just a > sort of macro. I don't see how they have anything to do with validity > checking. I was thinking that if you used !ENTITYs instead of literal values, you get a sort of validation, like using constant names instead of strings in program code. > > 11) Have you thought about using an XML-DATA schema? The w3c NOTE at > > http://www.w3.org/TR/1998/NOTE-XML-data offers most of what (I think) > > that you want with validation and so on. I don't know what status the > > submission has but it may be worth hanging on for a better solution. > I'll take a look at that. If I understand it correctly (unlikely :-)) it gives you data typing and validation, even for element contents and this would give the benefits that you are looking for without changing the XML structure. > > There are some improvements to Glade that would be more useful to me than > > a super-rigourous XML structure, working styles would be great. > You're free to work on those :) Although I don't think they're very > useful anymore with the theme stuff. I don't really understand themes but I was thinking about simple things like changing a single widget's background colours - still that's probably another few threads. 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.
