Sorry, I got off on a branch and ended up with a bunch of things. I'm just going to flatten and merge... Here's the list.
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.
* Created what I'm calling "Quick Zoom." The idea here is to have a modal zoom for touching up something with fine detail and then returning to what you're doing. This is activated with the letter "Q" on the keyboard. When you release it, you return back to where you were. This will zoom in on selected objects, or if you're in the node tool selected nodes.
* Added .svg on the temporary files in extensions. This'll make many of them happier. This only works on recent versions of GLib, but shouldn't break older ones more than they already are.
* Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsure whether we should be putting crash dumps in .config or .cache though.
* Removed 'tools_switch_current' because every usage of it already had a pointer to where it needed to go. Removes usage of globals.
* Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)
On Thu, Sep 25, 2008 at 1:48 AM, Ted Gould <ted@...11...> wrote:
Sorry, I got off on a branch and ended up with a bunch of things. I'm just going to flatten and merge... Here's the list.
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.
So we have full screen (F11), show/hide dialogs (F12), and now this. I think it starts getting confused. Can you perhaps merge your functionality with shiw/hide dialogs and rename it "hide UI" or "slideshow mode"?
* Created what I'm calling "Quick Zoom." The idea here is to have a modal zoom for touching up something with fine detail and then returning to what you're doing. This is activated with the letter "Q" on the keyboard. When you release it, you return back to where you were. This will zoom in on selected objects, or if you're in the node tool selected nodes.
Is this really much more convenient than just zooming into something and then pressing ` key to get back to previous zoom? I think having to hold Q is very clumsy. Also, what is this mode's relation to tools - is this a separate tool? does it work in all tools or not?
* Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)
Wow. Can you please post a screenshot for those who, like me, have an antiquated video card and no compositor?
On Thu, Sep 25, 2008 at 7:09 AM, bulia byak <buliabyak@...400...> wrote:
On Thu, Sep 25, 2008 at 1:48 AM, Ted Gould <ted@...11...> wrote:
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.So we have full screen (F11), show/hide dialogs (F12), and now this. I think it starts getting confused. Can you perhaps merge your functionality with shiw/hide dialogs and rename it "hide UI" or "slideshow mode"?
Yes, merging this two functions sounds like a good idea. But I would vote for <TAB> and not <F12>, because then we'll have the same shortcut than Gimp. And that would make my live a little bit esyer.
Regards, Tobias
On Thursday 25 September 2008, Tobias Jakobs wrote:
Yes, merging this two functions sounds like a good idea. But I would vote for <TAB> and not <F12>, because then we'll have the same shortcut than Gimp.
Hasn't TAB been used for ages to iterate over the currently relevant elements, like objects or nodes? I find it annoying enough (though understandable) that TAB doesn't work when a docked dialog still somehow has the focus.
Daniel
On Thu, Sep 25, 2008 at 9:43 AM, Daniel Hornung <daniel.hornung@...173...> wrote:
On Thursday 25 September 2008, Tobias Jakobs wrote:
Yes, merging this two functions sounds like a good idea. But I would vote for <TAB> and not <F12>, because then we'll have the same shortcut than Gimp.
Hasn't TAB been used for ages to iterate over the currently relevant elements, like objects or nodes? I find it annoying enough (though understandable) that TAB doesn't work when a docked dialog still somehow has the focus.
Yes, you are right. TAB was a bad idea. Then lets go with F12
Regards, Tobias
On Thu, 2008-09-25 at 02:09 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:48 AM, Ted Gould <ted@...11...> wrote:
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.So we have full screen (F11), show/hide dialogs (F12), and now this. I think it starts getting confused. Can you perhaps merge your functionality with shiw/hide dialogs and rename it "hide UI" or "slideshow mode"?
How about "Show/Hide toolbars"?
* Created what I'm calling "Quick Zoom." The idea here is to have a modal zoom for touching up something with fine detail and then returning to what you're doing. This is activated with the letter "Q" on the keyboard. When you release it, you return back to where you were. This will zoom in on selected objects, or if you're in the node tool selected nodes.Is this really much more convenient than just zooming into something and then pressing ` key to get back to previous zoom? I think having to hold Q is very clumsy. Also, what is this mode's relation to tools
- is this a separate tool? does it work in all tools or not?
Heh, well I think using ` is clumsy ;)
For me at least it makes sense with how I work on a document. I tend to stay at a high level and then go in an tweak something. This is probably because, for the most part, the things I do are relatively simple compared to other documents. But, having a whole undo stack is overly complex and too much to think about. I guess for me, it's "undo stack lite." I also like having it tied to the physical action of letting go of the key -- as this also reminds me that I can undo :)
It is tool agnostic, but only grabs the points and does something special with them in the node tool. Otherwise it works off of the selection.
* Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)Wow. Can you please post a screenshot for those who, like me, have an antiquated video card and no compositor?
Here is an old screenshot, the look is the same, it just works much better now :)
http://gould.cx/ted/blog/Out_Out_Toolbox_
As an interesting side note, compositors don't require that powerful of a graphics card. One of the Compiz developers was showing me it running on his 5 year old laptop. It's really more about the drivers providing good access to the hardware and not falling back to software support.
--Ted
On Thursday 25 September 2008, Ted Gould wrote:
Heh, well I think using ` is clumsy ;)
For me at least it makes sense with how I work on a document. I tend to stay at a high level and then go in an tweak something. This is probably because, for the most part, the things I do are relatively simple compared to other documents. But, having a whole undo stack is overly complex and too much to think about. I guess for me, it's "undo stack lite." I also like having it tied to the physical action of letting go of the key -- as this also reminds me that I can undo :)
How about "3" to zoom on the selection and "`" (just three keys to the left) to zoom back?
On Thu, Sep 25, 2008 at 11:25 AM, Ted Gould <ted@...11...> wrote:
So we have full screen (F11), show/hide dialogs (F12), and now this. I think it starts getting confused. Can you perhaps merge your functionality with shiw/hide dialogs and rename it "hide UI" or "slideshow mode"?
How about "Show/Hide toolbars"?
But if it's not only toolbars but also dialogs, don't we need a more generic name?
For me at least it makes sense with how I work on a document. I tend to stay at a high level and then go in an tweak something. This is probably because, for the most part, the things I do are relatively simple compared to other documents. But, having a whole undo stack is overly complex and too much to think about.
You absolutely don't need to think about it :) Just press ` and you go back to old zoom. If it's not "old enough", press it again until you're where you want to be. What can be simpler?
I guess for me, it's "undo stack lite."
Well, having two stacks for the same thing seems terribly confusing to me. Stack is by itself a simple concept already. Are you sure we really need it?
I also like having it tied to the physical action of letting go of the key -- as this also reminds me that I can undo :)
But using a whole finger - and partly, a whole hand - just as a reminder... isn't it wasteful? :)
I'm also not aware of any analogs of this UI ("zoom in while key pressed") in other software. Are you?
It is tool agnostic, but only grabs the points and does something special with them in the node tool. Otherwise it works off of the selection.
As pointed out already, you can always press 3 to zoom to selection, then ` to go back. Using a single letter for something that's not a tool is inconsistent - we have reserved this for tools only.
I have first to upgrade gtk and gtkmm, before that it fails to compile for me so I cannot test this new functionality. As soon as I can I will test it and then get back with a more substantiated opinion :)
On Thu, Sep 25, 2008 at 1:22 PM, bulia byak <buliabyak@...400...> wrote:
I guess for me, it's "undo stack lite."
OK, I just tried it, and I really don't see any added value in this. Pressing/releasing Q is exactly the same as pressing 3 and then `. You save one keystroke, but at the expense of having to keep the Q pressed, which essentially makes any non-trivial work in zoomed-in mode impossible.
On Thu, 2008-09-25 at 18:58 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:22 PM, bulia byak <buliabyak@...400...> wrote:
I guess for me, it's "undo stack lite."
OK, I just tried it, and I really don't see any added value in this. Pressing/releasing Q is exactly the same as pressing 3 and then `. You save one keystroke, but at the expense of having to keep the Q pressed, which essentially makes any non-trivial work in zoomed-in mode impossible.
I disagree :)
My thoughts are that let's leave it in, let people play and try it out for a while. Then open up the debate again. For me, I have really found it to be much more intuitive than the undo stack. I hardly ever use that, but I use this regularly.
--Ted
On Fri, Sep 26, 2008 at 6:37 PM, Ted Gould wrote:
My thoughts are that let's leave it in, let people play and try it out for a while. Then open up the debate again. For me, I have really found it to be much more intuitive than the undo stack. I hardly ever use that, but I use this regularly.
+1
Let's see how it works out
Alexandre
-----Original Message----- From: Ted Gould [mailto:ted@...11...] Sent: vrijdag 26 september 2008 16:38 To: bulia byak Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] NEW: Lots of stuff
On Thu, 2008-09-25 at 18:58 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:22 PM, bulia byak
<buliabyak@...400...> wrote:
I guess for me, it's "undo stack lite."
OK, I just tried it, and I really don't see any added value in this. Pressing/releasing Q is exactly the same as pressing 3 and then `. You save one keystroke, but at the expense of having to keep the Q pressed, which essentially makes any non-trivial work in zoomed-in mode impossible.
I disagree :)
My thoughts are that let's leave it in, let people play and try it out for a while. Then open up the debate again. For me, I have really found it to be much more intuitive than the undo stack. I hardly ever use that, but I use this regularly.
I think it is a nice feature. However, for me it does not zoom at the mouse cursor. It would be super if it would zoom exactly at the mouse pointer (regardless of selection), just like mousewheel scroll does (with certain pref setting). It would make selection of close knots quite a bit easier and quicker.
Cheers, Johan
On Thu, 2008-09-25 at 18:58 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:22 PM, bulia byak
<buliabyak@...400...> wrote:
I guess for me, it's "undo stack lite."
OK, I just tried it, and I really don't see any added value in this. Pressing/releasing Q is exactly the same as pressing 3 and then `. You save one keystroke, but at the expense of having to keep the Q pressed, which essentially makes any non-trivial work in zoomed-in mode impossible.
I disagree :)
My thoughts are that let's leave it in, let people play and try it out for a while. Then open up the debate again. For me, I have really found it to be much more intuitive than the undo stack. I hardly ever use that, but I use this regularly.
Why is the action controlled by 3 and ` in the first example? These keys ARE NOT close in other keyboards distributions like Spanish, where both are nine keys apart. And even with that, it still doesn't recover zoom position. 3 works but ` doesn't. Maybe I'm doing something wrong. The equivalent menu option "Previous zoom" works, thought.
Actually a switch key would work better. Like push 3 for zoom in, push 3 again to zoom back. I don't like the idea of keeping Q stroked.
I think it is a nice feature. However, for me it does not zoom at the mouse cursor. It would be super if it would zoom exactly at the mouse pointer (regardless of selection), just like mousewheel scroll does (with certain pref setting). It would make selection of close knots quite a bit easier and quicker.
Cheers, Johan
Agree ;) It should zoom to the cursor position.
On Sat, Sep 27, 2008 at 6:09 AM, Pajarico <pajarico@...400...> wrote:
Why is the action controlled by 3 and ` in the first example? These keys ARE NOT close in other keyboards distributions like Spanish, where both are nine keys apart.
If you're using a different keyboard layout, just create a different keys/default.xml file which would reflect the proximity and availability of keys on your keyboard. If you submit it to us (and most importantly, commit to maintain it so it does not get behind), it will be a great service to all users of Spanish keyboards, but this is no reason to make it less convenient for the users of English/US keyboards.
Caveat: Not all keys are currently remappable via default.xml, only global verbs. But this is fixable, and all we need to fix this is a push from someone who needs this. If we hear people saying "please make this and this a global verb, I want to remap it," I will try to help as soon as I can.
And even with that, it still doesn't recover zoom position. 3 works but ` doesn't. Maybe I'm doing something wrong. The equivalent menu option "Previous zoom" works, thought.
Most likely your keyboard just issues some other keycode on pressing this key. Again, it's only you who can investigate that and propose a fix.
Actually a switch key would work better. Like push 3 for zoom in, push 3 again to zoom back. I don't like the idea of keeping Q stroked.
That wouldn't work. We have much more zoom keys - 1, 2, 3, 4 etc all have their functions. Not everyone zooms in with the intention to zoom back again. If you want to zoom to selection _again_ and instead it zooms you out to some previous zoom, it wouldn't be good usability. So, a single key which travels back through your history of zooms is a much better solution.
Just to add a little confusion to this discussion :)
I really like the concept of ` undoing the zoom, but it doesn't work as I would expect, which would be to zoom back out to the last used zoom. For example, when I ctrl-scroll, I want ` to unzoom to the level it was at when I first pressed ctrl, instead of stopping at every in-between step. Would this be possible to implement? Seems more intuitive, and more likely to be a compromise between the two.
JF
Ted Gould wrote:
On Thu, 2008-09-25 at 18:58 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:22 PM, bulia byak <buliabyak@...400...> wrote:
I guess for me, it's "undo stack lite."
OK, I just tried it, and I really don't see any added value in this. Pressing/releasing Q is exactly the same as pressing 3 and then `. You save one keystroke, but at the expense of having to keep the Q pressed, which essentially makes any non-trivial work in zoomed-in mode impossible.
I disagree :)
My thoughts are that let's leave it in, let people play and try it out for a while. Then open up the debate again. For me, I have really found it to be much more intuitive than the undo stack. I hardly ever use that, but I use this regularly.
--Ted
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Sep 26, 2008 at 10:18 PM, Joshua Facemyer <jfacemyer@...400...> wrote:
Just to add a little confusion to this discussion :)
I really like the concept of ` undoing the zoom, but it doesn't work as I would expect, which would be to zoom back out to the last used zoom. For example, when I ctrl-scroll, I want ` to unzoom to the level it was at when I first pressed ctrl, instead of stopping at every in-between step. Would this be possible to implement? Seems more intuitive, and more likely to be a compromise between the two.
Sure, scroll must only remember the start and end of each scroll in the stack. Should be easy enough to add.
On Sep 24, 2008, at 9:48 PM, Ted Gould wrote:
Sorry, I got off on a branch and ended up with a bunch of things. I'm just going to flatten and merge... Here's the list.
Yay Ted!!!!!
* Added .svg on the temporary files in extensions. This'll make many of them happier. This only works on recent versions of GLib, but shouldn't break older ones more than they alreadyare.
Yay!
I'll check about some older systems.
* Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsure whether we should be putting crash dumps in .config or .cache though.
Ooh! this one is major.
I'll check on the cache question. I think using the glib calls for XDG locations would be the next step. If I can get to it this weekend I'll fill you in on what I can find.
* Removed 'tools_switch_current' because every usage of italready had a pointer to where it needed to go. Removes usage of globals.
Boo globals!!!
Good start on that.
On Sep 24, 2008, at 10:55 PM, Jon A. Cruz wrote:
On Sep 24, 2008, at 9:48 PM, Ted Gould wrote:
* Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsurewhether we should be putting crash dumps in .config or .cache though.
Ooh! this one is major.
I'll check on the cache question. I think using the glib calls for XDG locations would be the next step. If I can get to it this weekend I'll fill you in on what I can find.
I've got a first bit done. The preference dir is now built using the glib call instead of a fixed ".config/Inkscape" string. I also hooked in a bit of logic to fall back to ".inkscape" if that's present in the specified location and "Inkscape" is not.
So what that means is that preferences location (and many other things) are now dynamic and easily switchable at runtime.
If I run as
inkscape
it looks for ~/.config/Inkscape on my current system.
However... you can now do this
XDG_CONFIG_HOME=~ inkscape
and it will fall back to use the old settings. Also one could do these
XDG_CONFIG_HOME=~/inky047 inkscape XDG_CONFIG_HOME=~/PrintSettings inkscape XDG_CONFIG_HOME=~/WebSettings inkscape
To use specific settings for certain configuration for different inkscape versions or different tasks being worked on. There are still some issues to finish cleaning up, including fallback for data dir lists and switching a few more things away from the single hardcoded path in path-prefix to use a dynamic list based on the XDG stuff. However I think this step is testable now.
On Thu, Sep 25, 2008 at 4:48 AM, Ted Gould wrote:
* Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)
Will it be possible to not use it all? :-)
Alexandre
On Thu, 2008-09-25 at 14:39 +0000, Alexandre Prokoudine wrote:
On Thu, Sep 25, 2008 at 4:48 AM, Ted Gould wrote:
* Made it so that dialogs will be transparent when not focused. This is an alternate to having the docked, and one that I like better as I feel it gives me more screen area. You can adjust how much transparency and the speed of the animation in the preferences dialog. (Note: this requires GTK+ 2.12 and a compositor, but gracefully degrades if you don't have either)Will it be possible to not use it all? :-)
Yes, if you go to your preferences you can set the focused and unfocused transparency to both be 100%. Then it'll detect that and not adjust it.
You can also set the length of time that it takes to animate. I have defaulted this to 0 on Windows because the GTK documentation says that it'll flicker on Vista otherwise. Though, I have no way to test :)
--Ted
On Thu, Sep 25, 2008 at 1:48 AM, Ted Gould <ted@...11...> wrote:
* Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsure whether we should be putting crash dumps in .config or .cache though.
For those who upgrade, this basically means that they old prefs are lost. Can we do something about it? E.g. just add reading from ~/.inkscape on startup if ~/.config/Inkscape does not yet exist?
On Thu, 2008-09-25 at 18:56 -0300, bulia byak wrote:
On Thu, Sep 25, 2008 at 1:48 AM, Ted Gould <ted@...11...> wrote:
* Moved the Inkscape configuration directory on Linux from ~/.inkscape to ~/.config/Inkscape. This is the new way to do things with the cross desktop naming spec. I'm unsure whether we should be putting crash dumps in .config or .cache though.For those who upgrade, this basically means that they old prefs are lost. Can we do something about it? E.g. just add reading from ~/.inkscape on startup if ~/.config/Inkscape does not yet exist?
Well, the part I dislike about that is that we're going to have to keep that check around for theoretically forever. Which, even by a little, slows down our startup.
I'm working on trying to solve this desktop wide right now, this isn't uniquely an Inkscape problem. If that isn't ready by the time 0.47 ships, I think we should put it in 0.47, but drop for 0.48.
--Ted
On Friday 26 September 2008, Ted Gould wrote:
Well, the part I dislike about that is that we're going to have to keep that check around for theoretically forever. Which, even by a little, slows down our startup.
No, checking (for the standard config dir) is done at startup anyway. All additional checks for the old location would only be done once, since the next time ~/.config/Inkscape does already exist.
Daniel
On Fri, 2008-09-26 at 18:28 +0200, Daniel Hornung wrote:
On Friday 26 September 2008, Ted Gould wrote:
Well, the part I dislike about that is that we're going to have to keep that check around for theoretically forever. Which, even by a little, slows down our startup.
No, checking (for the standard config dir) is done at startup anyway. All additional checks for the old location would only be done once, since the next time ~/.config/Inkscape does already exist.
So then what should happen, move the directory? What if someone wants to use their old Inkscape again?
This is a hard problem where you're bound to piss someone off. I think that we do need to migrate to the XDG Directories though, as that is important.
I'm not sure that the best solution isn't to put it in the release notes and let users make the choice.
--Ted
On Sep 26, 2008, at 12:06 PM, Ted Gould wrote:
On Fri, 2008-09-26 at 18:28 +0200, Daniel Hornung wrote:
On Friday 26 September 2008, Ted Gould wrote:
Well, the part I dislike about that is that we're going to have to keep that check around for theoretically forever. Which, even by a little, slows down our startup.
No, checking (for the standard config dir) is done at startup anyway. All additional checks for the old location would only be done once, since the next time ~/.config/Inkscape does already exist.
So then what should happen, move the directory? What if someone wants to use their old Inkscape again?
This is a hard problem where you're bound to piss someone off. I think that we do need to migrate to the XDG Directories though, as that is important.
I'm not sure that the best solution isn't to put it in the release notes and let users make the choice.
With modern OS's, file systems and directory caching, I think we won't see any noticeable delay for the check on old location. So that's probably a non-issue.
When a new version first starts up, I'd suggest that if the target directory does not exist *and* the old directory does, then we create the target directory and copy over settings from the old (with any needed translation of setting values).
If we start up and the target does not exist, and there is no old directory then we just create the new directory.
If we start up and the target does exist then we just use it.
One factor is trying to keep things linked. That is, as things like the list of recent files get updated, we could update the list in the old location. However I think this would 'contaminate' a lot of use scenarios, so it's probably best to just keep things separate.
Then if someone did want to run the new version such that it shared, they just need to launch with the XDG environment variable(s) pointing to the old location and they would be tied. And using XDG will make it easier to keep different versions of Inkscape installed in parallel.
And one more thing... you know the mantra :) Please fill in the release notes for all the new stuff.
Thanks!
2008/9/25 Ted Gould :
* Created what I'm calling "Quick Zoom." The idea here is to have a modal zoom for touching up something with fine detail and then returning to what you're doing. This is activated with the letter "Q" on the keyboard. When you release it, you return back to where you were. This will zoom in on selected objects, or if you're in the node tool selected nodes.
So I gave this feature quite a lot of testing and my impressions are:
1. It is useful indeed to be able to zoom into/out of selection with just one key. 2. It is really not comfortable to have to keep one finger on Q all the time while doing tweaks of all kinds (especially those requiring hotkeys).
Thus my vote is to keep this feature, but make it a combination of "zoom to selection" and "previous zoom", so that second pressing of Q brings you back.
Alexandre
On Sat, Oct 18, 2008 at 4:16 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
So I gave this feature quite a lot of testing and my impressions are:
- It is useful indeed to be able to zoom into/out of selection with
just one key. 2. It is really not comfortable to have to keep one finger on Q all the time while doing tweaks of all kinds (especially those requiring hotkeys).
Thus my vote is to keep this feature, but make it a combination of "zoom to selection" and "previous zoom", so that second pressing of Q brings you back.
OK, what about this: if you're already zoomed to selection, 3 will perform previous zoom, otherwise zoom to selection. Makes sense?
I see that there's a lot of discussion about this new UI option, and some concern over whether it will be useful or not. I for one am rather annoyed with the feature that changes colors when I try to drag & drop from the style indicator in the bottom left. So instead of being able to copy the style of the selected item to other ones without actually filling the clipboard I have a color adjustment function that's imprecise and generally much less useful than going to the stroke & fill dialog.
I think others may feel the same about other UI features. The solution to those would be to A) make the extra UI features opt-in via prefs B) move them to extensions I would vote for B), but it is a rather long-term goal as it necessitates creating a robust extension API for binary extensions.
On Sun, Oct 19, 2008 at 9:31 PM, Krzysztof Kosiński wrote:
I see that there's a lot of discussion about this new UI option, and some concern over whether it will be useful or not. I for one am rather annoyed with the feature that changes colors when I try to drag & drop from the style indicator in the bottom left. So instead of being able to copy the style of the selected item to other ones without actually filling the clipboard I have a color adjustment function that's imprecise and generally much less useful than going to the stroke & fill dialog.
So you want to disable a major 0.46 feature :)
What I think should really be done here is implementation of *real* assets management where you have a *dynamic* color swatches palette that has all colors used in a document. That way you would even have to select an object :)
Alexandre
Alexandre Prokoudine wrote:
I see that there's a lot of discussion about this new UI option, and some concern over whether it will be useful or not. I for one am rather annoyed with the feature that changes colors when I try to drag & drop from the style indicator in the bottom left. So instead of being able to copy the style of the selected item to other ones without actually filling the clipboard I have a color adjustment function that's imprecise and generally much less useful than going to the stroke & fill dialog.
So you want to disable a major 0.46 feature :)
What I think should really be done here is implementation of *real* assets management where you have a *dynamic* color swatches palette that has all colors used in a document. That way you would even have to select an object :)
Alexandre
This would be an awesome feature. Whether it should be a palette option or a separate dialog/widget is a good question, though. It would be nice to have a standard palette while also being able to access easily the currently used styles (which could include such things as stroke styles and gradients). Maybe according to this concept a dialog would work best.
JF
On Sun, Oct 19, 2008 at 10:31:38AM -0700, Krzysztof Kosiński wrote:
I see that there's a lot of discussion about this new UI option, and some concern over whether it will be useful or not. I for one am rather annoyed with the feature that changes colors when I try to drag & drop from the style indicator in the bottom left. So instead of being able to copy the style of the selected item to other ones without actually filling the clipboard I have a color adjustment function that's imprecise and generally much less useful than going to the stroke & fill dialog.
+1 on this one for me as well I'm afraid. The previous behaviour was more intuitive (at least for me, but than again perhaps it is not intuition but a habit).
Cheers,
-- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Mon, Oct 20, 2008 at 1:29 PM, Marcin Floryan <mfloryan@...1877...> wrote:
+1 on this one for me as well I'm afraid. The previous behaviour was more intuitive (at least for me, but than again perhaps it is not intuition but a habit).
What previous behavior?
Before I implemented the color gestures, dragging the swatches from selected style indicator had no effect whatsoever. Dragging color onto object only worked for the swatches in the palette, not in the selected style widget.
bulia byak wrote:
Before I implemented the color gestures, dragging the swatches from selected style indicator had no effect whatsoever. Dragging color onto object only worked for the swatches in the palette, not in the selected style widget.
Well, +1 Informative on that. Honestly I didn't try doing that before I read about the color gestures feature. Anyway, I would expect it to work that way if I didn't know what it does. Maybe the color gestures could get a separate widget (an icon or the like) next to the style indicator?
Regards, Krzysztof Kosiński
On Mon, Oct 20, 2008 at 10:51 PM, Krzysztof Kosiński wrote:
if I didn't know what it does. Maybe the color gestures could get a separate widget (an icon or the like) next to the style indicator?
Just for the record, color gestures works for stroke now as well. And stroke already has line width to the right. So how do you imagine that? ;-)
Alexandre
Alexandre Prokoudine wrote:
Just for the record, color gestures works for stroke now as well. And stroke already has line width to the right. So how do you imagine that? ;-)
Alexandre
There could be small icons (for example color wheels with a hand) next to the style indicators for stroke and fill. Dragging on them would trigger the color gesture behavior while dragging on the color indicators would drag & drop the style. The color wheel icons could have a tooltip explaining how they work.
My suggestions are mainly motivated by the fact that Inkscape gets a lot of praise for its simple yet powerful UI, which is very easy to learn even for the beginners. The color gestures take over the style swatch and there is no outside indication for this functionality, so I think it may be beginner-unfriendly. In other words, the feature is good but it's put in a strange place in the UI.
Regards, Krzysztof Kosiński.
2008/10/20 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On Tue, Oct 21, 2008 at 2:36 AM, Krzysztof Kosiński wrote:
the beginners. The color gestures take over the style swatch and there is no outside indication for this functionality,
I think I understand both viewpoints. Of course I like the color gestures (and use them all the time), but I also agree that where there's a swatch, a new user will likely try to drag and drop it somewhere. So perhaps the most important question is, is the action "drop the color of selection on some non-selected object" common enough to enable it as an option?
Alexandre Prokoudine wrote:
On Tue, Oct 21, 2008 at 2:36 AM, Krzysztof Kosiński wrote:
the beginners. The color gestures take over the style swatch and there is no outside indication for this functionality,
Quite in opposite, it says exactly this: "$COLOR, drag to adjust" :-)
A tooltip is a rather weak outside indication, as it requires a mouse dwell to discover it. I meant something that looked draggable at first glance. (But to be honest, I didn't spot the tooltip before.)
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Alexandre Prokoudine wrote:
On Tue, Oct 21, 2008 at 2:36 AM, Krzysztof Kosiński wrote:
the beginners. The color gestures take over the style swatch and there is no outside indication for this functionality,
Quite in opposite, it says exactly this: "$COLOR, drag to adjust" :-)
A tooltip is a rather weak outside indication, as it requires a mouse dwell to discover it.
Oh give me a break. Is this some sort of troll? The first intuitive thing I do for a button or widget I can't remember or don't know, is to dwell over it (for all of a micro second) and read the tooltip. In fact, if there is no tooltip, I'm quite unhappy since I often don't remember the different functionalities. So to the rest of the crew, keep up the nice tooltips!
On Oct 20, 2008, at 7:49 PM, MilesTogoe wrote:
Krzysztof Kosiński wrote:
A tooltip is a rather weak outside indication, as it requires a mouse dwell to discover it.
Oh give me a break. Is this some sort of troll? The first intuitive thing I do for a button or widget I can't remember or don't know, is to dwell over it (for all of a micro second) and read the tooltip. In fact, if there is no tooltip, I'm quite unhappy since I often don't remember the different functionalities. So to the rest of the crew, keep up the nice tooltips!
Actually it is a poor solution for a great number of users out there. Some people try to check for tips, but some others (who even have been using computers for some time) don't.
Tooltips also are sometimes problematic for input devices such as tablets. Even when using a drawing tablet's "mouse", it's possible for the hi-res input to jitter to much for tips to be triggered. With my Wacom Intuos, for example, I often have to move the cursor over a widget and then *very* carefully lift my stylus straight up in order to get a stable "float" to trigger a tip.
Counting on tooltips also goes counter to the concept of discoverability. The best UI signals it's use from how it looks, and new users are drawn to just move "things" to get a program to work.
I'm not saying that tooltips are not good, just that *depending* on tooltips is poor UI design.
On Sun, Oct 19, 2008 at 12:34 AM, bulia byak wrote:
Thus my vote is to keep this feature, but make it a combination of "zoom to selection" and "previous zoom", so that second pressing of Q brings you back.
OK, what about this: if you're already zoomed to selection, 3 will perform previous zoom, otherwise zoom to selection. Makes sense?
Yep, it does :) Makes me wonder, however, if all other keys like that should work same way.
Alexandre
2008/9/25 Ted Gould :
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.
Regarding this one. If we *absolutely* want to have two separate commands that temporarily clean up screen space in different ways, then at least we should
1) try to make them similar, like F12 and Shift+F12; 2) make both of them available from View menu.
IMHO, if the intention is to maximize screen area on small screens (eee pc and the like), then the command should remove all dialogs too. I really can't think of a reason why someone would want toolbars to go away and keep (docked) dialogs around, when in Inkscape vertical space is a *lot* less used then horizontal space (Filter Effects dialog makes me itch :))
Just my 0.02$CURRENCY
Alexandre
On Sat, Oct 18, 2008 at 4:32 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
* Added a focus mode activated by Shift+F11. The goal of this mode is to remove all toolbars for a short period so that you maximize screen area. Useful on small screens. Also when you know lots of shortcuts.Regarding this one. If we *absolutely* want to have two separate commands that temporarily clean up screen space in different ways, then at least we should
- try to make them similar, like F12 and Shift+F12;
- make both of them available from View menu.
I think when we discussed this, no one objected to merging Shift+F11 into F12 and renaming that to "Show/Hide UI"?
participants (12)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
Daniel Hornung -
Jon A. Cruz -
Joshua Facemyer -
Krzysztof Kosiński -
Marcin Floryan -
MilesTogoe -
Pajarico -
Ted Gould -
Tobias Jakobs