[Glade-devel] XUL and Glade - Some more ideas and links

[luxorxul yahoo ca (Gerald Bauer)]

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