On Jul 31, 2005, at 2:24 PM, Alan Horkan wrote:
The standard UI XML for GTK+ is approaching the problem from the
complete opposite direction of what we need (presentation vs.
information, physical vs logical, etc) and actually complicates things.
... that sounds highly illogical.
Maybe it is unintentional and if you mention it to the Gtk+
developers and propose things they will listen. Does take a terribly long
time for their changes to reach the desktop where you can depend on them
though.
No, not illogical at all. The point makes perfect sense.
It's very intentional in their part. It's a completely different problem they're solving.
They had a complex setup with much low-level pixel-tweaking being exposed through an XML wrapper. It's very much in line with Glade or XUL.
On the other hand our needs line up with wanting something abstract and high-level that operates purely in the logical realm instead of the physical. That is very much in line with XForms and CSS.
One interesting example is XForm's "<trigger>" element. On a form, this is often represented as a button. However, stylesheets could be used to present it in many forms, and if it's contained in some form of menu, it could appear as a menu item instead.
Functionally a menu item and a button are pretty much the same. They differ in where they are placed and how they look, but otherwise work the same.
So...
Just as when doing nicer HTML authoring there is no need to go and put "<FONT FACE="Verdana, Arial" SIZE="2">" on every single LI element. Just toss it in CSS once for all LI elements. That's the general type of thing we'd want.
Also... there's additional information that we'd need to get the UI functioning better. Since the GtkUIManager needs to be fed only valid GMarkup, we can't safely extend the markup and send it in with extra stuff.
Oh, and also there are limitations with it not being able to deal with custom widgets and such. It's been crafted to serve certain purposes, and in hand with Glade markup it does a decent job at that purpose, but our needs are different.
(BTW, since they added GtkAction as of GTK+ 2.4 we can start shifting to leveraging those also, but there still are subtle issues with that)