Ted Gould wrote:

So, for a little project I made all the menus configurable by a file in your home directory ~/.inkscape/menus.xml. They use the verb ids, and you can pretty much move things around how ever you'd like. There are still some rough edges, but it should be stable enough to have people start passing around files of how they'd like the menus for discussion. Then people can try them out.

Is there a way to use this to allow effect authors to position their effects in an arbitrary menu as jimmac has requested?

Aaron Spike

On Jul 31, 2005, at 7:33 AM, Alan Horkan wrote:

Is this custom XML or the standard UI XML other Gtk Applications are using?

I think it's the GTK+ standard stuff. As we move forwards, I'd want to get to custom XML.

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.

However... it might be that we end up with some logical XML markup and then translate parts of that to physical XML and pass it on into the existing GTK+ manager.

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)

On Sun, 2005-07-31 at 14:08 -0700, Jon A. Cruz wrote:

On Jul 31, 2005, at 7:33 AM, Alan Horkan wrote:

...

Is this custom XML or the standard UI XML other Gtk Applications are using?

I think it's the GTK+ standard stuff. As we move forwards, I'd want to get to custom XML.

No, actually it's custom. It is a little bit simpler than the GTK+ stuff, which seemed like overkill for what we're doing here.

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.

However... it might be that we end up with some logical XML markup and then translate parts of that to physical XML and pass it on into the existing GTK+ manager.

I think that all the menus.xml file is really doing is providing a menu list, which is entirely display. I think it keeps a good separation between the functionality and the layout, this file is entirely layout. Perhaps I'm not understanding what you're saying.

--Ted

On Sat, Jul 30, 2005 at 02:29:42AM -0700, Ted Gould wrote:

Okay,

So, for a little project I made all the menus configurable by a file in your home directory ~/.inkscape/menus.xml. They use the verb ids, and you can pretty much move things around how ever you'd like. There are still some rough edges, but it should be stable enough to have people start passing around files of how they'd like the menus for discussion. Then people can try them out.

Okay, I'm going to bed.

--Ted

Very cool Ted!

(Fwiw, gtkmm has a similar built in functionality for menus, toolbars, and keyboard shortcuts...)

Bryce

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.

On Wed, 2005-08-03 at 11:51 -0400, mental@...3... wrote:

Quoting msevior@...79...:

...

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.

Jon Cruz articulated one set of issues, but another which is important to me personally is that glade (when used for code generation in particular, but even if you're just using libglade) seriously gets in the way of refactoring.

It's a bigger issue in Inkscape than in AbiWord or Gnumeric because we necessarily have so many more custom UI elements.

It's not that we haven't tried Glade. We earnestly tried it but found it very burdensome in this regard, back in the days when we were still Sodipodi.

Ah OK. We think the other way I guess. We try to make standard widgets do what we want. We only have a few custom widgets in AbiWord.

I would *never* recommend using glade generated code. For most of what we need using glade/libglade cuts down code size by about 50% in dialogs and reduces the time needed to code a dialog by many hours. It can be subsequently tweaked to comply with the GNOME HIG by non-core coders who ARE interface experts.

But if you guys need custom widgets then this approach is clearly not feasible.

I'm surprised that you can get what you need via an XForms-style description that appears to give even weaker control on what you can do.

It was just a suggestion. I'm mightily impressed with inkscape. Please keep up the great work :-)

Cheers

Martin

-mental

On Thu, Aug 04, 2005 at 11:11:47AM +1000, Martin Sevior wrote:

Ah OK. We think the other way I guess. We try to make standard widgets do what we want. We only have a few custom widgets in AbiWord.

I would *never* recommend using glade generated code. For most of what we need using glade/libglade cuts down code size by about 50% in dialogs and reduces the time needed to code a dialog by many hours. It can be subsequently tweaked to comply with the GNOME HIG by non-core coders who ARE interface experts.

But if you guys need custom widgets then this approach is clearly not feasible.

Well, it's not even just custom controls but other more advanced gtk controls like the tree view. The stuff glade seems to make easy, like basic dialogs with some checkbuttons and text inputs, aren't really that hard to do in plain C either. But the things that are hard to do in C, appear to be impossible to do in glade anyway.

I think we all earned a very healthy distrust of glade back when we were doing development on Sodipodi, and we just haven't seen enough evidence to change our views of it. It seems to be adequate for quick and dirty stuff or for small applications with modest dialog needs, but it seems that too many of Inkscape's needs lay outside glade's scope.

Bryce

Quoting Martin Sevior <msevior@...79...>:

I'm surprised that you can get what you need via an XForms-style description that appears to give even weaker control on what you can do.

I wouldn't say that -- XForms doesn't constrain the choice of widgets up-front, so you can set up any sort of control binding you want.

-mental