On Aug 3, 2005, at 12:15 AM, msevior@...79... wrote:
I still don't undestand why you guys don't use glade and libglade. It really worked well for the AbiWord project.
Maybe you need to rethink this decision. libglade has been fully ported and debugged on windows. The gnumeric on windpws project has no trouble with it.
yes.
The main problem is that libglade is solving the wrong problem.
It works well now for what it was designed to do. However... that's not what we'd want.
It's basically a way to wrap up calls to the pixel-level GTK+ widget creation and layout routines. It's very close, in that regard, to XUL used in Mozilla. Basically it pulls one into the pre-CSS HTML era of pixel-tweaking UI for one platform, but away from others.
In general, all it buys you is pulling the creation calls out of the .c files and putting them in .glade files instead. Though it's better that it was, it's not really a shift to a new direction, just moving existing code from one spot to another.
What we want, on the other hand, is something higher level and abstract. XForms falls in this general area.
Here's a snippet of a .glade file from a tutorial
<widget class="GtkButton" id="button1"> <property name="border_width">10</property> <property name="visible">True</property> <property name="can_focus">True</property> <property name="label" translatable="yes">button1</property> <property name="use_underline">True</property> <property name="relief">GTK_RELIEF_NORMAL</property> </widget>
First of all, I'd say that's a pretty decent .glade file. Many things were avoided, especially more of the physical settings that could have been used. Still, that's a bit verbose and mainly focused on *how* the widgets get tweaked into place, not *what* the widgets mean or will do. (I don't have glade installed at the moment, otherwise I'd have given a more complete example)
A similar bit from XForms XML would look more like
<trigger id="button1"> <label>button1</label> </trigger>
Then for the more common cases, such as setting a value, we'd get
<trigger id="button1"> <label>button1</label> <setvalue ev:event="DOMActivate" ref="SomeBase/val1" value="../ other/prod" /> </trigger>
And for an example to input some value
<input ref="SomeBase/val1"> <label>Base Value 1</label> </input>
That's it. Notice that there's just the generic "input" element. No specific type. And unlike Glade where that was done for the simplicity of the DTD and the element type is actually set via a named property, there is no other element. Instead it would be bound to the type of the data element that "SomeBase/val1" resolves to.
A plugin author would then only have to concentrate on his input and output parameters and what the values do, not all the pixel-tweaking to get them presented nicely. And since all that "tweaking" is done inside Inkscape, we get a consistent UI with all things of a similar logical purpose getting a similar physical layout.
There's a lot more, but that's an initial pointer to things.