My recent experience with Inkscape
I've been working with Inkscape a lot lately, and while it was mostly a lot of fun, I could think of a number of small changes that could make Inkscape even better. Most of them seem to not be so difficult to implement as far as I can tell. I'm not sure if this is the right place, but I didn't want to just post a bunch of enhancement requests - I'd rather get some user and developer feedback first.
So, here's my list:
The layer window icons are not identical to those on the layer menu. While this makes Inkscape similar to Gimp, it also makes its own visual language inconsistent! I think Inkscape should be consistent with itself first. Plus, the layer icons on the menu are so much better looking.
I'd like to see menu items and keyboard shortcuts to globally turn snap on and off. Ideally, they should be similar to Adobe's (with the same keyboard shortcut), and placed in the "View" menu. Yes, these all exist in the document preferences, but I find I turn snap on and off a lot, even while working on a single path (imagine wanting to snap just one or two nodes here and there), and I see a need for something more useable than having a large floating dialog that takes a lot of screen space.
Similarly, I'd also like to have menu items to toggle different snap modes on and off. They should be placed in a sub-menu right after the "snap" toggle, and the sub-menu labeled as "Snap To...". If the "global snap" mentioned above is turned off, then (as in Adobe products) these have no effect.
Hiding and locking is not very easy right now. For example, I don't see a way to hide or lock multiple selections. There's a need for "Hide selected", "Lock selected", "Unhide All", "Unlock All" menu items in the "Object" menu. Possibly also "Hide" and "Lock" as right-click menu items.
Inkscape should remember all floating dialogs' show/hide status on exit so that if they were visible when Inkscape terminates, they are visible in the next session.
"Swatches" should probably move from the "Object" menu to the "view" menu as they are not related to objects.
I don't think the "Export Bitmap" dialog should switch between "Page", "Drawing" or "selection" when the selection is changed. In my experience, sometimes you export the entire page a number of times, while making small changes here and there. All the while, the export dialog automatically switches to "selection" whenever you do something and then switches back to "drawing". You have to return it to "drawing" all the time. I can see how the current setup is useful - when exporting multiple selections as multiple files - but I think the earlier use pattern I mentioned is more common. At least, a method to turn this behavior off should be supplied.
When copying and pasting objects between files, stops in gradients should be automatically renamed so that objects don't accidentally receive the wrong gradient because of two different gradients in the two files having the same name. Yes, this happened to me a number of times!
The last one is an important bug fix for us Windows users: make all dialogs and tool windows float above the canvas. I remember this was done in Gimp about a year ago. I think it had something to do with the version of GTK used. I also remember seeing it as an open bug in some previous Inkscape version prior to release - what happened with that? Were there no volounteers found to fix it?
I'd like to hear your feedback, especially developers!
Michael
On Mon, 6 Nov 2006, Michael Grosberg wrote:
Date: Mon, 6 Nov 2006 14:02:39 +0000 (UTC) From: Michael Grosberg <preacher_public@...9...> Reply-To: Inkscape User Community inkscape-user@lists.sourceforge.net To: inkscape-user@lists.sourceforge.net Subject: [Inkscape-user] My recent experience with Inkscape
I've been working with Inkscape a lot lately, and while it was mostly a lot of fun, I could think of a number of small changes that could make Inkscape even better.
Most of them seem to not be so difficult to implement as far as I can tell.
It usually seems that way until you are nose deep in the code trying to do it yourself, so unless you are a C++ programmer it is very hard to know for sure what is easy.
I'm not sure if this is the right place, but I didn't want to just post a bunch of enhancement requests - I'd rather get some user and developer feedback first.
The Inkscape request tracker on sourceforge is the right place to post suggestions but sometimes it is better to discuss suggetions first. Also when you do get around to posting requests please do try to: log in; check for duplicates; and provide plenty of reference information if possible. Reference information such as links to this discussion in the mailing lists archives, descriptions and screenshots if you have them, and be careful not to assume developers are familiar with competitors software as they may not have access to it.
So, here's my list:
The layer window icons are not identical to those on the layer menu. While this makes Inkscape similar to Gimp, it also makes its own visual language inconsistent! I think Inkscape should be consistent with itself first. Plus, the layer icons on the menu are so much better looking.
This reminds me of another inconsistency Gimp uses the term "New Layer" in the menus but Inkscape uses the term "Add Layer". I've even created a quick patch to change the label, I'll leave adding the same Ctrl+Shift+N shortcut as GIMP for another day. http://sourceforge.net/tracker/index.php?func=detail&aid=1591552&gro...
The layer dialog seems to be using the stock gnome icons and although I can understand why some people might prefer the menu icons which are more specific to just Layers I think using the GTK stock icons in both places would make things easier for maintaince and make it easier and more consistent for anyone creating themes.
== Snap ==
I'd like to see menu items and keyboard shortcuts to globally turn snap on and off. Ideally, they should be similar to Adobe's (with the same keyboard shortcut), and placed in the "View" menu.
Things were rearranged and efforts were made to try something different with the snap options and keep the menus relatively tidy. Unfortunately this hasn't worked out as well as hoped and I do think a menu item for snapping to grid will need to be reintroduced.
Yes, these all exist in the document preferences, but I find I turn snap on and off a lot, even while working on a single path (imagine wanting to snap just one or two nodes here and there), and I see a need for something more useable than having a large floating dialog that takes a lot of screen space.
[spelling: use, usable, usability. sorry pet peeve of mine when people spell that word incorrectly.]
Similarly, I'd also like to have menu items to toggle different snap modes on and off. They should be placed in a sub-menu right after the "snap" toggle, and the sub-menu labeled as "Snap To...". If the "global snap" mentioned above is turned off, then (as in Adobe products) these have no effect.
I have some concerns about the menus getting horribly cluttered but I think several other programs do things like this and it may be unavoidable if we are to give users what they expect and would be comfortable with.
Hiding and locking is not very easy right now. For example, I don't see a way to hide or lock multiple selections. There's a need for "Hide selected", "Lock selected", "Unhide All", "Unlock All" menu items in the "Object" menu. Possibly also "Hide" and "Lock" as right-click menu items.
I believe this work is still in progress. Features shown in the context menu always need to be shown elsewhere.
Inkscape should remember all floating dialogs' show/hide status on exit so that if they were visible when Inkscape terminates, they are visible in the next session.
there are few existing request along these lines and I doubt anyone will argue with the idea the trick will be getting someone interested in doing it.
"Swatches" should probably move from the "Object" menu to the "view" menu as they are not related to objects.
... or maybe even moved into a Windows menu with the other Panels/Palettes like another program we know
/me dons asbestos suit, ducks and covers
I don't think the "Export Bitmap" dialog should switch between "Page", "Drawing" or "selection" when the selection is changed. In my experience, sometimes you export the entire page a number of times, while making small changes here and there. All the while, the export dialog automatically switches to "selection" whenever you do something and then switches back to "drawing". You have to return it to "drawing" all the time. I can see how the current setup is useful - when exporting multiple selections as multiple files - but I think the earlier use pattern I mentioned is more common. At least, a method to turn this behavior off should be supplied.
providing loads of behaviours to turn things on and off gradually becomes harder and harder to maintain and test properly. hopefully a better overall solution can be found that requires less fiddling around and micro-optimisations.
When copying and pasting objects between files, stops in gradients should be automatically renamed so that objects don't accidentally receive the wrong gradient because of two different gradients in the two files having the same name. Yes, this happened to me a number of times!
There are known issues will gradient names colliding on imported files, possibly a symptom of the same underlying problem.
The last one is an important bug fix for us Windows users: make all dialogs and tool windows float above the canvas.
I believe this sort of works now and much effort has gone into fixing it. It would help if you could try out a recent testing build.
I'd like to hear your feedback, especially developers!
I'd encourage you to file at least one or two request when this discussion tails off. Thanks for your feedback and thanks for choosing Inkscape.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
Alan Horkan wrote:
On Mon, 6 Nov 2006, Michael Grosberg wrote:
I don't think the "Export Bitmap" dialog should switch between "Page", "Drawing" or "selection" when the selection is changed. In my experience, sometimes you export the entire page a number of times, while making small changes here and there. All the while, the export dialog automatically switches to "selection" whenever you do something and then switches back to "drawing". You have to return it to "drawing" all the time. I can see how the current setup is useful - when exporting multiple selections as multiple files - but I think the earlier use pattern I mentioned is more common. At least, a method to turn this behavior off should be supplied.
providing loads of behaviours to turn things on and off gradually becomes harder and harder to maintain and test properly. hopefully a better overall solution can be found that requires less fiddling around and micro-optimisations.
This does seem odd to me, when would you ever need that dialog to switch its "mode" (page/drawing/selection/custom) based on what you do in the drawing. I can see roughly two uses of this dialog: - Regularly export the entire drawing/page - Export multiple selections, one after the other In either case there is no need to switch modes (you'd have to do it manually once per session, worst-case). In addition the current behaviour seems somewhat unintuitive (apparently it only switches modes if you first selecting nothing and then selecting something, it's not enough to just change the selection).
All in all, I'd recommend simply removing the "switching" behaviour (hopefully making its behaviour simpler, more intuitive and more efficient). (Submitting a feature request might be a good idea.)
On 11/6/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
This does seem odd to me, when would you ever need that dialog to switch its "mode" (page/drawing/selection/custom) based on what you do in the drawing. I can see roughly two uses of this dialog:
- Regularly export the entire drawing/page
- Export multiple selections, one after the other
In either case there is no need to switch modes (you'd have to do it manually once per session, worst-case).
Not really. If you started with a selection in Selection mode but then deselected, you have no choice but to switch to some other mode.
behaviour seems somewhat unintuitive (apparently it only switches modes if you first selecting nothing and then selecting something, it's not enough to just change the selection).
If you change selection, it just updates width/height while remaining in Selection mode. Seems logical to me.
bulia byak wrote:
On 11/6/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
This does seem odd to me, when would you ever need that dialog to switch its "mode" (page/drawing/selection/custom) based on what you do in the drawing. I can see roughly two uses of this dialog:
- Regularly export the entire drawing/page
- Export multiple selections, one after the other
In either case there is no need to switch modes (you'd have to do it manually once per session, worst-case).
Not really. If you started with a selection in Selection mode but then deselected, you have no choice but to switch to some other mode.
Why not stay in selection mode? Why the need to automatically switch modes at all? The only case it would really make sense to me to automatically switch modes would be when you're constantly exporting both a selection and the entire drawing/page, which seems a bit strange.
I do understand the need for a good default (when opening the export dialog), and I could imagine you'd want it to be set per document, but the latter even seems overkill.
behaviour seems somewhat unintuitive (apparently it only switches modes if you first selecting nothing and then selecting something, it's not enough to just change the selection).
If you change selection, it just updates width/height while remaining in Selection mode. Seems logical to me.
If you are in selection mode, yes, but if you're not in selection mode it doesn't change the mode (in itself a good thing, but read on). If you deselect it stays in the drawing/page mode (fine by me), if you then select something again it suddenly does change the mode...
I'd say either go for: selected something->selection mode, selected nothing->drawing/page(/custom), or (which I think actually makes the most sense) simply go with what the user selects and don't try to be too smart.
Jasper van de Gronde wrote:
bulia byak wrote:
On 11/6/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
This does seem odd to me, when would you ever need that dialog to switch its "mode" (page/drawing/selection/custom) based on what you do in the drawing. I can see roughly two uses of this dialog:
- Regularly export the entire drawing/page
- Export multiple selections, one after the other
In either case there is no need to switch modes (you'd have to do it manually once per session, worst-case).
Not really. If you started with a selection in Selection mode but then deselected, you have no choice but to switch to some other mode.
...
behaviour seems somewhat unintuitive (apparently it only switches modes if you first selecting nothing and then selecting something, it's not enough to just change the selection).
If you change selection, it just updates width/height while remaining in Selection mode. Seems logical to me.
If you are in selection mode, yes, but if you're not in selection mode it doesn't change the mode (in itself a good thing, but read on). If you deselect it stays in the drawing/page mode (fine by me), if you then select something again it suddenly does change the mode...
I'd say either go for: selected something->selection mode, selected nothing->drawing/page(/custom), or (which I think actually makes the most sense) simply go with what the user selects and don't try to be too smart.
Thinking about this some more I'm beginning to see why you might want the dialog to switch modes automatically, as in many cases you'd already deselect before exporting the drawing/page(/custom) and select something before exporting it.
However, if you do change modes automatically, I'd still recommend modifying the current behaviour to be more consistent/direct as mentioned above. So setting it to selection mode whenever you select something and to drawing/page/custom whenever you deselect. That way it's more obvious what the relation between the mode and selecting things is.
And it would definitely be good to remember which of drawing/page(/custom) was selected, as currently it seems to forget that (so if you select Page and (deselect, )select, deselect something it returns to Drawing).
On 11/7/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Not really. If you started with a selection in Selection mode but then deselected, you have no choice but to switch to some other mode.
Why not stay in selection mode?
Because there's no selection anymore. When you have a selection again, it will switch back to selection mode. If it tracks selection's width and height, why not let it track the fact of there being a selection or not? I don't really like the idea of it becoming "disabled" or something like that when you deselect.
If you change selection, it just updates width/height while remaining in Selection mode. Seems logical to me.
If you are in selection mode, yes, but if you're not in selection mode it doesn't change the mode (in itself a good thing, but read on). If you deselect it stays in the drawing/page mode (fine by me), if you then select something again it suddenly does change the mode...
So, hence the compromise we are discussing: if your drawing mode was automatic (caused by deselection), switch back to selection. If you clicked on Drawing explicitly, stay there. I think this might work.
I'd say either go for: selected something->selection mode, selected nothing->drawing/page(/custom),
Which is what we have now, no?
or (which I think actually makes the
most sense) simply go with what the user selects and don't try to be too smart.
OK, I agree that we should limit our "smartness" as described above, but I don't think we should eliminate it completely.
bulia byak wrote:
On 11/7/06, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
If you change selection, it just updates width/height while remaining in Selection mode. Seems logical to me.
If you are in selection mode, yes, but if you're not in selection mode it doesn't change the mode (in itself a good thing, but read on). If you deselect it stays in the drawing/page mode (fine by me), if you then select something again it suddenly does change the mode...
So, hence the compromise we are discussing: if your drawing mode was automatic (caused by deselection), switch back to selection. If you clicked on Drawing explicitly, stay there. I think this might work.
I'd say either go for: selected something->selection mode, selected nothing->drawing/page(/custom),
Which is what we have now, no?
Unfortunately not, as I tried to describe above, it distinguishes between "changing" the selection and selecting something after having had no selection. Which is probably why it comes across as confusing. As I mailed later I'm beginning to see the logic behind automatically changing the mode, but it would be nice if it wouldn't make this distinction and would remember the mode you were in (so it doesn't switch back to Drawing when you had previously selected Page).
Michael,
These are all good suggestions, but you need to submit them as RFEs to our tracker because otherwise they may be lost in the mailing list traffic. Some comments:
On 11/6/06, Michael Grosberg <preacher_public@...9...> wrote:
The layer window icons are not identical to those on the layer menu. While this makes Inkscape similar to Gimp, it also makes its own visual language inconsistent! I think Inkscape should be consistent with itself first. Plus, the layer icons on the menu are so much better looking.
I think there was some reason to make them different, but I don't remember it. Anyone?
I'd like to see menu items and keyboard shortcuts to globally turn snap on and off. Ideally, they should be similar to Adobe's (with the same keyboard shortcut), and placed in the "View" menu. Yes, these all exist in the document preferences, but I find I turn snap on and off a lot, even while working on a single path (imagine wanting to snap just one or two nodes here and there), and I see a need for something more useable than having a large floating dialog that takes a lot of screen space.
Certainly doable.
If you know AI shortcuts, please take time to review share/keys/adobe-illustrator.xml to make sure all shortcuts are listed there correctly in comments (if we don't yet have corresponding actions) or are assigned correct actions (otherwise). If you find an error or something that can be improved, submit your fixes. You can also take time to describe the not-yet-assigned Adobe shortcuts in comments - just a brief sentence on what each shortcut does (it's not always obvious!) so as to make it easier for the developers to create/match Inkscape actions for them.
(Of course this request is not only for Michael - anyone who knows Adobe Illustrator can help!)
Similarly, I'd also like to have menu items to toggle different snap modes on and off. They should be placed in a sub-menu right after the "snap" toggle, and the sub-menu labeled as "Snap To...". If the "global snap" mentioned above is turned off, then (as in Adobe products) these have no effect.
Also doable, file an RFE on that too.
Hiding and locking is not very easy right now. For example, I don't see a way to hide or lock multiple selections. There's a need for "Hide selected", "Lock selected", "Unhide All", "Unlock All" menu items in the "Object" menu. Possibly also "Hide" and "Lock" as right-click menu items.
While it's also doable, I'd like to point out that locking individual objects is not recommended currently. You're supposed to lock/unlock and hide/unhide layers, not objects. Is there a reason why this won't work for you?
Inkscape should remember all floating dialogs' show/hide status on exit so that if they were visible when Inkscape terminates, they are visible in the next session.
There's already a bug on that, but it will have to wait until the basic problems with dialogs-on-top are resolved.
"Swatches" should probably move from the "Object" menu to the "view" menu as they are not related to objects.
Agreed, I moved it to View and rearranged the View menu a bit.
I don't think the "Export Bitmap" dialog should switch between "Page", "Drawing" or "selection" when the selection is changed. In my experience, sometimes you export the entire page a number of times, while making small changes here and there. All the while, the export dialog automatically switches to "selection" whenever you do something and then switches back to "drawing". You have to return it to "drawing" all the time. I can see how the current setup is useful - when exporting multiple selections as multiple files - but I think the earlier use pattern I mentioned is more common. At least, a method to turn this behavior off should be supplied.
OK, let's formulate it that way: if the user has explicitly clicked on Page or Drawing, do not automatically switch it away from that. Please submit that to the RFE tracker.
When copying and pasting objects between files, stops in gradients should be automatically renamed so that objects don't accidentally receive the wrong gradient because of two different gradients in the two files having the same name. Yes, this happened to me a number of times!
That's a well-known long-standing problem which requires quite some rearchitecturing for solving it. It's already in our bug tracker.
The last one is an important bug fix for us Windows users: make all dialogs and tool windows float above the canvas. I remember this was done in Gimp about a year ago. I think it had something to do with the version of GTK used. I also remember seeing it as an open bug in some previous Inkscape version prior to release - what happened with that? Were there no volounteers found to fix it?
Another well-known problem. There's been some progress on that front recently, but we could really use some help from programmers familiar with GTK (contact me if you think you can help out).
On Nov 6, 2006, at 6:30 PM, bulia byak wrote:
On 11/6/06, Michael Grosberg <preacher_public@...9...> wrote:
The layer window icons are not identical to those on the layer menu. While this makes Inkscape similar to Gimp, it also makes its own visual language inconsistent! I think Inkscape should be consistent with itself first. Plus, the layer icons on the menu are so much better looking.
I think there was some reason to make them different, but I don't remember it. Anyone?
Yes. There was some good logic, as they convinced me to change things (I did the bulk of the layer window). I think a quick search of the mailing list archive should locate some of that discussion for you.
It, however, also makes the visual language *more* consistent from some viewpoints. The main thing is that the menu item is a very specific combo action, while the buttons in the layer window itself are generic actions. In a menu, you have things like layers and selections mixed around in there, whereas in the layer dialog you are operating solely on layers.
It really just depends on how you view things. We'll probably have to revisit a little as I'm adding in more internal changes to use GtkAction throughout more of our code, so we might address this issue then
bulia byak <buliabyak@...125...> writes:
Michael,
These are all good suggestions, but you need to submit them as RFEs to our tracker because otherwise they may be lost in the mailing list traffic. Some comments:
I added an RFE for snap menu items.
If you know AI shortcuts, please take time to review share/keys/adobe-illustrator.xml to make sure all shortcuts are listed there correctly in comments (if we don't yet have corresponding actions) or are assigned correct actions (otherwise). If you find an error or something that can be improved, submit your fixes. You can also take time to describe the not-yet-assigned Adobe shortcuts in comments - just a brief sentence on what each shortcut does (it's not always obvious!) so as to make it easier for the developers to create/match Inkscape actions for them.
I'll be happy to do that, although I use (well, I have it installed, anyway) CS1 and not CS2. Hopefuly there were no shortcut changes.
While it's also doable, I'd like to point out that locking individual objects is not recommended currently. You're supposed to lock/unlock and hide/unhide layers, not objects. Is there a reason why this won't work for you?
Good point - I actually don't use it. But I did notice there were these two checkboxes on the object properties dialog which make it possible for a user to lock or hide an object with no way to unlock or unhide it (unless the user understands the XML structure of an SVG file and can edit it). Maybe it would be for the best if they, too were removed.
OK, let's formulate it that way: if the user has explicitly clicked on Page or Drawing, do not automatically switch it away from that. Please submit that to the RFE tracker.
OK, I added an RFE.
As usual, thanks for the kind feedback on my post.
Michael
participants (5)
-
Alan Horkan -
bulia byak -
Jasper van de Gronde -
Jon A. Cruz -
Michael Grosberg