1:48 p.m.
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)
2:09 p.m.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
4:27 p.m.
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
4:43 p.m.
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
5:30 p.m.
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
11:25 p.m.
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
11:52 p.m.
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?
1:22 a.m.
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 :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
6:58 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:37 p.m.
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
11:47 p.m.
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
5:16 a.m.
-----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
7:09 p.m.
> 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.
2:34 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:18 a.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2:18 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:55 p.m.
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 already
are.
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
it
already
had a pointer to where it needed to go. Removes usage of
globals.
Boo globals!!!
Good start on that.
7:11 p.m.
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 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.
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.
11:39 p.m.
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
11:56 p.m.
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
6:56 a.m.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:35 p.m.
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
1:28 a.m.
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
4:06 a.m.
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
3:09 a.m.
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.
6:59 a.m.
And one more thing... you know the mantra :) Please fill in the
release notes for all the new stuff.
Thanks!
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
4:16 a.m.
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
5:34 a.m.
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:
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.
OK, what about this: if you're already zoomed to selection, 3 will
perform previous zoom, otherwise zoom to selection. Makes sense?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:31 a.m.
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.
--
View this message in context:
http://www.nabble.com/NEW%3A-Lots-of-stuff-tp19663014p20058401.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:52 a.m.
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
11:44 p.m.
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
1:29 a.m.
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]
1:48 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
3:51 a.m.
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
--
View this message in context:
http://www.nabble.com/NEW%3A-Lots-of-stuff-tp19663014p20076311.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:10 a.m.
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
7:36 a.m.
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.
--
View this message in context:
http://www.nabble.com/NEW%3A-Lots-of-stuff-tp19663014p20080250.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9:01 a.m.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:35 a.m.
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
--
View this message in context:
http://www.nabble.com/NEW%3A-Lots-of-stuff-tp19663014p20081957.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
11:49 a.m.
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!
12:46 p.m.
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.
4:46 a.m.
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
4:32 a.m.
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
5:37 a.m.
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
1) try to make them similar, like F12 and Shift+F12;
2) 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"?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
5333
days inactive
5360
days old
inkscape-devel@lists.inkscape.org
45 comments
12 participants
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