Up spake vellum:

My immediate thought on seeing it was "AAAAAAAAGGGGHHHHHH!!!!!! It's SodiPodi come back." I crossed my fingers and muttered appropriate soothing mantras. I like our Inkscape UI Interface as it is and SodiPodi's used to drive me bananas. I was so glad to leave it.

EXACTLY my thoughts.

In this design the user is presented with buttons that do nothing when you haven't selected the appropriate tool. I think that is a bad idea.

Jiaxiang, what advantages do *you* think this design has over the current one? Presumably you prefer it?

On Sun, 2 Jan 2005, Jon Phillips wrote:

I think what would be a better mockup to work on would be how to dock palettes, like fill and stroke, xml editor, etc, around a document window. That is what I would really like to see. Then, the current toolbars and aux. toolbar could be made draggable around a document window.

Yes, I'd *love* to see a mockup like this. This is an area we definitely have plans to try to implement, but it's very fuzzy how this would look/work so mockups of ideas to do this would be very helpful.

I like in the Inkscapeinterface.png mockup seeing the embedded layer editor - that gives some interesting ideas... I'd like to see more experimentation with mockups around that idea.

Bryce

On Sun, 2 Jan 2005, vellum wrote:

My immediate thought on seeing it was "AAAAAAAAGGGGHHHHHH!!!!!! It's SodiPodi come back." I crossed my fingers and muttered appropriate soothing mantras. I like our Inkscape UI Interface as it is and SodiPodi's used to drive me bananas. I was so glad to leave it.

Sorry if that is strong but I hated the little collapsible/detachable toolbox compartments, especially when they didn't work properly.

From my standpoint, I like this screenshot as a challenge to attaining

interface flexibility. In other words, I would love it if our chrome was reconfigurable enough that we could have *both* our current interface layout, *plus* this one, and that the user could shuffle UI elements around to suit his or her desires.

In the gtkmm code, each toolbar button is attached to an 'Action' object. Actions can be activated in a variety of ways - the top menu, context menus, accelerator keys, and toolbars. Actions are organized into ActionGroups. I can easily see us provide an additional, optional toolbox that displays some/all Actions grouped into compartments as shown in the mockup.

Of course, the above pre-supposes a volunteer to do the work of implementing it. ;-) I think it's definitely doable, and worth accepting, but it's not very high on the priorities list for gtkmm. However if anyone feels like working on implementing it (even if they don't know gtkmm), I'd certainly welcome their participation on it!

I've added this mockup into the gtkmm codebase's 'mockups' directory.

Thanks, Bryce

...

From my standpoint, I like this screenshot as a challenge to

attaining

...

interface flexibility. In other words, I would love it if our

chrome

...

was reconfigurable enough that we could have *both* our current interface layout, *plus* this one, and that the user could shuffle

UI

...

elements around to suit his or her desires.

Flexibility is good, but if it is too easy to break the fundamental logic of the UI, flexibility turns into a mess. This mockup seems to totally disregard the distinction between tools and tool controls, and as such is hardly applicable to the current Inkscape UI.

I totally agree with you. No need to break the fundamental logic of one of the best UIs I've used.

However... one exception I see with the classification of tool/tool controls is with the Node editing tools. With Illustrator one nice thing is that you can tear-away all of the tools (doesn't really work with our setup for the most part), but it lets me have the node editing tools always available. Specifically add/remove/modify nodes.

Basically other than the dialogs being dockable, this is the one tool I can definitely see being useful to have those "advanced" functions available all the time. I know it's only one click or keypress to make them available (via the tool controls toolbar), but if you switch tools a lot, it's one less click or keypress to get to the tool I need. Plus all of the switching really adds up when you're working on complex projects (easily would have cut a few thousand clicks out of my last project... ones that were just to make the tools available).

Essentially for the other tools it's mostly parameters and such that are stored in the tool controls, but for the node tools, they're almost fundamentally individual tools... not just functions. Does that make sense?

-Josh

But add/remove nodes only makes sense when nodes are displayed and some of them are selected. Which means, only in the node tool.

One thing we need to do to make it faster is enable doubleclicking of an object to go to the corresponding tool. That is, doubleclicking a path goes to node tool, a rect to rect tool etc. I think there was an RFE.

I can definitely see what you're saying and the double click editing for objects sounds great. But, before I file an RFE (if one doesn't exist) about the one thing that makes the system that I'm talking about really work, I figured I'd post to the list for feedback first. It fills in the gap with having the paths/nodes displayed all the time...

Again, from Adobe Illustrator... there is an option that shows you an objects path by highlighting it on mouseover (not selecting in any way, just a highlight to show you what the mouse has attention of). It works really well when you have a bunch of objects overlapping.

(a separate but useful RFE to be made) In AI you can customize color of the above mentioned path highlight, on a per layer basis. For example, layer 1 all paths when selected are highlighted in blue, layer 2 has red highlighted paths, etc. It's purely superficial and just to make workflow a little easier in knowing what layer something is on w/o looking at the layer dialog. I only bring this up because in these pics Layer 1 is the rectangle and Layer 2 is the circle (both with different color highlighted paths).

Unfortunately the actual cursor was not captured in the screenshots, but you can see where it was (there's a little "x" there, which for this purpose is nice due to less obstruction).

All screenshots show the circle as being the selected object and I have my "add node" tool selected as my current tool.

http://www.scislac.com/inkscape/ai-node1.png ai-node1: you can see a little "x" as for where the mouse is located and it even has a label telling you that you are hovering over a path. Click there (on the path), it adds a node.

http://www.scislac.com/inkscape/ai-node2.png ai-node2: you can see a little "x" as for where the mouse is located and it's telling you that you are hovering over an anchor/node. Click there, it tells you that you can't add an anchor (as there's already one there). I only include this out to show that it identifies whether you are hovering over the path or an anchor/node on the path.

http://www.scislac.com/inkscape/ai-node3.png ai-node3: you can see a little "x" as for where the mouse is located and it's telling you that you are hovering over a place where the two paths "intersect" (superficially). Click there, it adds a node on the selected object (the circle in this case) at the intersection point. Very useful.

Anyway, these types of advancements to the node tools & path system would rock... In my opinion at least... anyway, I wanted to get input before I file the appropriate RFEs/or additions to existing RFEs:

1) for path highlight & coloring per layer... (superficially) 2) some more advancements to the node tools (add to the existing RFE)

I'm mostly curious about your thoughts Bulia...

-Josh