[Glade-devel] XUL and Glade - Some more ideas and links
Gerald Bauer
luxorxul@yahoo.ca
Thu, 8 Apr 2004 08:47:25 -0400 (EDT)
Hello,
> What benefit would this give? There is a pretty
> huge impedance mismatch
> between the two languages.
I suggest offering an "official" alternative compact
XML UI format in addition to your current
super-verbose XML UI format. If you have a
super-compact XML UI format in the HTML-style
tradition you get lots of benefits.
First, you can handcode your XML UI if you want to.
Using your super-compact XML UI formats locks you into
Glade. Or you can use server-side scripts such as
XSL/T, PHP, Velocity and so on to create XML UIs.
Second, by treating the XML UI format as first-class
citizen in the REST-style tradition you open the door
for new tools such as as alternative designers,
browsers, doctools and so on. Just witness everything
that is build around the HTML format.
> Your prototype looks completely unmanageable. First
> of all, it loses a
> lot of information found in the glade file. Second
> of all, it would
> require changes to the XSLT for each new
> widget/property. Furthermore,
> what would you do with this alternative
> representation?
I agree the prototype is completely useless.
However, it let's you use the Glade designer to create
forms that run with different toolkits such as Java
Swing, Mozilla and so on.
> Once again, why would a Qt application author want
> to use this? It
> looks like your program would require modifications
> as each new widget
> was added, and more code would be needed to build Qt
> widgets from the
> new file format. The existing Qt designer file
> format maps directly to
> Qt widgets, which limits the amount of code needed
> to process UI files.
Again, if you want to lock-in your users into using
Glade and Gtk+ or Qt/Designer and Qt than using a
super-verbose XML UI format is the way to go.
> It is also worth noting that the geometry management
> of GTK doesn't
> match that of XUL. So to convert a XUL interface to
> GTK widgets, we'd
> probably need to implement new container types.
> Using the name XUL for
> a variant that had different semantics would just
> cause confusion (and
> the XUL authors have specifically asked that people
> don't do this).
Again I suggest creating your own alternative
super-compact XML UI format in the
HTML-tradition/REST-style.
> Overall, it looks like this would be a lot of effort
> for little or no gain.
Well, I guess you somehow missed out on the HTML
success story. Why not repeat it?
- Gerald
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca