Re: [Inkscape-devel] Inkscape review
Is there a simple command that will tell me what "sort" of object the mouse is on?
No signle command, but there are macros SP_IS_RECTANGLE, SP_IS_USE, SP_IS_PATH and so on.
- what "mode" the mouse is in (selector, rectangle, text, etc)
I think there's a function for that in tools-switch.cpp
- what object is under the mouse. (and notice "multiple selections")
The number of selected items is easy to get from SPSelection.
Is there an enum of object types anywhere? At least the sense of object vs stroke?
What do you mean by "object vs stroke"? Maybe a shape (rect, star, etc) vs. arbitrary path?
Also, should the menu be long or deep?
Use your judgement. The menu cannot be too short, Inkscape is a complex program. I think using submenus is OK - after all, this is what people have always done in Sodipodi, and some of them even like it, who'd-a-thought...
For example, if multiple items are selected, the set of boolean operations should be included, but that would make the top-level menu very long. A different way would be to make a separate "boolean" submenu... thoughts?
Yes, booleans in a submenu sounds good to me. But again, I never use that menu, so cannot really judge its usability.
_________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Sat, 15 May 2004, bulia byak wrote:
Also, should the menu be long or deep?
Use your judgement. The menu cannot be too short,
Judgement is very important.
I think it is better to have a menu that is longer than having too many submenus but balance is essential.
If you have tearoff menus some would argue that lots of categorisation and submenus is useful (but only if you really use tearoff and leave lots of those little menus open does it really become useful and all that means is that the application really should be using more toolbars and have better keybindings)
Inkscape will definately need submenus (especially when you have to try and categorize a load of effects and filters, scripts and plugins) it is a complicated application. I think 15 items is considered the standard upper limit for number of items in a menu but that is only a rule of thumb, be flexible.
A menu with only as few as (two or) three items are actually too short (but if you have a top level menu with close to 15 items it is probably acceptable to push them to a submenu) but consider using seperators first to make things clearly.
submenus should try not to go more than one level deep, and definately no more than two deep.
when the menus start getting crowded it is important to consolidate some items and remove others into transient dialogs. the only example i can think of offhand is Convert to Path, Convert to Filled Path because either you want to create "Convert to Path..." pop a dialog and give some options or just convert to path and if users just want the fill not the outline then they can turn off the stroke (set style:none).
program. I think using submenus is OK - after all, this is what people have always done in Sodipodi, and some of them even like it, who'd-a-thought...
some people like submenus, some people like them so much they dont mind an extra right click each and every time they want to do anything and are perfectly happy with everything in the context menu, but this approach appeals to a minority (the majority of applications have a menubar, gimp dia and inkscape now all have a menubar for those who want it).
A big part of what i think has made and continues to make inkscape so good to use is that features are close to the front, not too deep in submenus, not in dialogs hidden behind too many tabs. I'm very glad that bulia and others put so much thougth into it.
Sincerely
Alan H.
participants (2)
-
Alan Horkan -
bulia byak