Put your menu where your mouth is
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
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 Sun, 2005-07-31 at 08:50 -0500, aaron@...749... wrote:
Is there a way to use this to allow effect authors to position their effects in an arbitrary menu as jimmac has requested?
In theory yes, but not quite yet. It is going to have to mature a little bit first. Right now it can only handle the staticly defined verbs.
--Ted
On Sat, 30 Jul 2005, Ted Gould wrote:
Date: Sat, 30 Jul 2005 02:29:42 -0700 From: Ted Gould <ted@...11...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Put your menu where your mouth is
Okay,
So, for a little project I made all the menus configurable by a file in your home directory ~/.inkscape/menus.xml.
Is this custom XML or the standard UI XML other Gtk Applications are using?
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.
I look forward to trying this out real soon.
Thanks.
Sincerely
Alan Horkan
Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Alan's Diary http://advogato.org/person/AlanHorkan/
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 Sun, 31 Jul 2005, Jon A. Cruz wrote:
Date: Sun, 31 Jul 2005 14:08:52 -0700 From: Jon A. Cruz <jon@...18...> To: Alan Horkan <horkana@...44...> Cc: Ted Gould <ted@...11...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Put your menu where your mouth is
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.
Good to hear.
As we move forwards, I'd want to get to custom XML.
Not so good but ...
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.
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.
Sounds plausible. I expect it will work out well somehow.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
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 Mon, 1 Aug 2005, Jon A. Cruz wrote:
Date: Mon, 1 Aug 2005 10:00:14 -0700 From: Jon A. Cruz <jon@...18...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Put your menu where your mouth is
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.
I've created enough web pages for this to make a lot of sense to me.
From there I went to creating java user interfaces and they are generally
designed to flow and be rescalable much like web interfaces. Learning the box layout of Gtk felt like a giant step backwards.
Gnome focussing on the fixed style and placement seems like it is intended to solve current problems but strikes me as something of an evolutionary dead end. I'm surprised Sun haven't taken a stab at improving Gtk but that would go against their efforts to get everyone to use Java.
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.
the gimp script-fu includes a few input types which can be represented using different widgets, and I made suggestons about taking it futher (a radio list and a drop down menu can be used to represent the same information depending on the length of the list and the amount of space available).
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.
I'd be extremely surprised if their future needs were not similar so it may yet be possible to keep things compatible.
(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)
Thanks again Jon
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
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 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.
--TedVery cool Ted!
(Fwiw, gtkmm has a similar built in functionality for menus, toolbars, and keyboard shortcuts...)
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.
Martin
Bryce
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
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.
-mental
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 Aug 3, 2005, at 6:11 PM, Martin Sevior wrote:
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.
Ahh, but that's the whole point. It gives one no control on pixel- tweaking.
Instead the idea is to focus on the logical and business logic.
The key is to get something that abstracts all the functionality needed, but leaves all the presentation out of it.
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
On Thu, 2005-08-04 at 00:55 -0700, Bryce Harrington wrote: [snip]
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.
libglademm allows you to to do both. You can lay out the window/dialog in Glade, including your custom widget, and then specify the details for the custom widget in your code. get_widget_derived() helps here. For instance, I tend to always derive a TreeView class, and I don't mind that I don't see the correct column names in Glade.
You can also layout custom (well, composite) widgets in glade and use get_widget() to access the child widgets.
[snip]
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
participants (7)
-
unknown＠example.com -
Alan Horkan -
Bryce Harrington -
Jon A. Cruz -
Martin Sevior -
Murray Cumming -
Ted Gould