InfoPalette

This memo will serve to be the genus for what I would eventually like to propose. I'm hoping for plenty of feedback from everyone to make this tool as useful as possible. The core concept is quite simple really, enumerate and visually explain all editable parameters of a given shape on the canvas in a single floating palette.

1. Problem Although much work is being done to promote existing dialogs to the status of sane players on the workspace front, there are still pitfalls in having all manner of oversized and disproportionate dialogs open on the screen. Namely is simple visual clutter. Having several windows open at once can cause both new users to become lost quickly, and more seasoned users wasting time fidgeting with dialogs to position them according to their wishes.

I agree that the number of dialogs should be reduced. One idea we were discussing long ago was merging "transformations" and "size and position" in some useful way. You'll need to look up Sodipodi programming tasks and list archives on this one. I hope to return to this idea when I have time. --bb

---

Agreed. The dialog situation is a frequently mentioned concern from new and potential users, and getting it wrangled and simplified would do a world of good.

A commentor on GnomeDesktop writes: "But, you've got to clean up the menus/interface - when the drawing starts it's really a mess and first impressions to users mean a lot. It really should open up a frame with menus across the top and toolbars whereever. While it was easy enough to create a new drawing - I couldn't figure out how to resize the page/drawing. These are the first things a user does so it should be there and be good. Compared to Karbon, the toolbar/menu thing is a mess. This should be relatively easy to fix and will go a long way to winning over users."

---

Sure, if anyone has any specific suggestions, be vocal. If they are simple I may have a look at once. To start, I will unify the names of the dialogs and corresponding menu commands which are now confusingly different. --bb

2. Accessibility concerns Using many dialogs, users that cannot or do not use the mouse are asked to traverse 3 tiers of information to edit shape data outside the canvas. First they must achieve focus on a dialog ( ctrl+# ) , second they must select ( in some cases ) a tab containing the subset of data they wish to manipulate ( tab key? ) and third they must gain focus on the cell or control that allows them to make the edit ( tab key? ).

Tab switching I think should be ctrl-pageup/pagedown, any other suggestions? --bb

3. Solution Provide an additional ( or alternative depending on how you lean ) palette for editing shape properties that contains an hierarchical list of property groups and properties. This window would behave exactly as other palettes ( esc to focus canvas, enter to affect change ), but would centralize object properties in one dialog minimizing the memory cost to the user for keyboard shortcuts to open dialogs ( they would only need one, and we could make it an easy one, cmd+i // get info // ) Once the dialog has focus, the user could then use the arrow keys to locate the property they wish to edit and affect the change desired. While it may seem that we will lose the specificity of multiple dialogs, this interface would provide us with a more open method of combining property sets, and in the future it could be used as the basis for generating custom property dialogs per user utilizing xml documents to store dialog layout information.

Also needed is a proposed rule for how to discriminate what should and

should not be in this dialog box. Perhaps go through the current dialog boxes and identify which should be incorporated here, and which should not. - bryce

http://www.inkscape.org/mockups/layers_palette_with_props.png

This looks pretty similar to the current XML editor. Perhaps we could use it as a base for such a palette, or better, develop the XML editor itself to be more "visual" so that you could e.g. edit a color in a CSS specification by clicking on it and choosing from swatches. Still, the ability to edit XML freely should be preserved in any case. --bb

Overall, I doubt if such a palette will really be convenient to use in a large document. You could have hundreds of objects, and even if grouped in layers, they will still make the collapsing tree very unwieldy. I think you'll spend too much time scrolling the tree and collapsing/expanding its branches. However it's indeed convenient to see all properties of an object nicely lined up, so on a second thought I do think that developing the current XML editor to be more visual and less XML-ish is the best strategy. Such as, for example, making CSS specs display as interactive widgets instead of long text strings. --bb

4. A few key points It appears that currently, you cannot enter a numerical value in the float fields of the color dialog, is this intended behavior?

---

Wrong question. Is this the _expected_ behavior? If users need to have the capability of entering numerical values, then this should be submitted as a feature request, so it can be implemented as resources allow.

---

Yep, I thought about that too. Perhaps it's a simple thing like editable bit set on the control. I'll look into it. --bb

Users would be able to close tree paths in this new properties palette that they might not use often, this allows the user to immediately improve their productivity when performing these types of edits.