Talking with a friend today, we came up with the idea of renaming the "Edit group" feature to "temporary ungroup", since that is closer to what it does (from the visual user's perspective). "Edit parent" would then become "regroup".
He also noted that Flash lets you do something comparable by double-clicking on a group. That seems like maybe a good idea here too.
Thoughts?
-mental
On Sat, 25 Sep 2004 14:38:49 -0400, MenTaLguY <mental@...3...> wrote:
Talking with a friend today, we came up with the idea of renaming the "Edit group" feature to "temporary ungroup", since that is closer to what it does (from the visual user's perspective). "Edit parent" would then become "regroup".
I don't like it because:
- It suggests that this is the same as ungroup, only temporary. In fact it's not, as the <g> is not going anywhere. For example two objects selected within a group and outside it will still not group together with a "You cannot group objects from different groups or layers" message. Also when you permanently ungroup, you don't add new objects to the group; when you ungroup "temporarily" you're doing just that.
- This operation is obviously connected to layers: the group id is displayed in the layer selector, etc. This must be somehow reflected in the name of the command. I think "Edit group as layer" is short and precise enough.
By the way, do your newly added commands for moving layers up/down in z-order work correctly with such group-layers? I think they should move the group you're in relative to the adjacent objects even if these objects are not layers. Do you agree? This would work the same as the regular z-order change commands on objects, but apply to the (temporary or permanent) layer. In fact, you can use those commands for it with a few modifications. Note that they move 1 step up/down relative to the objects that the selected object (or, in your case, layer/group) overlaps; I think this also makes sense to preserve for moving group-layers.
One other group of verbs we need is for moving a currently selected object to the next/prev/top/bottom layers. If several objects in different layers are selected, they're first sorted together in z-order in the layer of the topmost (for moving up) or bottommost (for moving down) layer, then the entire stack of selected objects is moved to the top of the next/prev/top/bottom layer. It should display something like "<b>10</b> objects moved up to layer <b>Layer1</b>" in the statusbar.
By the way your current "Move to next/prev layer" commands must be renamed. They don't _move_ anything, they _switch_ the current layer. A helpful statusbar message would be "New current layer: <b>Layer1</b> (at <b>2</b> of <b>5</b>)".
And the commands moving the layer in z-order should display, "<b>Layer1</b> is at <b>2</b> of <b>5</b> (moved up)" or "<b>Layer1</b> is at <b>1</b> of <b>5</b> (<b>not moved</b>, cannot move any further down)".
One more thing: when you update any shortcuts, please edit doc/keys.xml to reflect this (I could do this myself, but it would be useful to have at least one more developer familiar with that file :) Use <note>s to describe any non-obvious aspects of the commands.
He also noted that Flash lets you do something comparable by double-clicking on a group. That seems like maybe a good idea here too.
We don't process double click in select-context at the moment, but this can be added I think.
On Sat, 2004-09-25 at 15:16, bulia byak wrote:
By the way, do your newly added commands for moving layers up/down in z-order work correctly with such group-layers? I think they should move the group you're in relative to the adjacent objects even if these objects are not layers. Do you agree?
I think so. In principle I think they should work for "honorary layers" as implemented, since the code doesn't check whether the current layer is a "real" layer or not. It just obtains an SPObject * from SPDesktop::currentLayer() and runs with it.
I've not tested though.
This would work the same as the regular z-order change commands on objects, but apply to the (temporary or permanent) layer. In fact, you can use those commands for it with a few modifications. Note that they move 1 step up/down relative to the objects that the selected object (or, in your case, layer/group) overlaps; I think this also makes sense to preserve for moving group-layers.
? could you elaborate?
One other group of verbs we need is for moving a currently selected object to the next/prev/top/bottom layers. If several objects in different layers are selected, they're first sorted together in z-order in the layer of the topmost (for moving up) or bottommost (for moving down) layer, then the entire stack of selected objects is moved to the top of the next/prev/top/bottom layer. It should display something like "<b>10</b> objects moved up to layer <b>Layer1</b>" in the statusbar.
By the way your current "Move to next/prev layer" commands must be renamed. They don't _move_ anything, they _switch_ the current layer. A helpful statusbar message would be "New current layer: <b>Layer1</b> (at <b>2</b> of <b>5</b>)".
Well, the intent is that they will eventually move objects just as you describe. I just haven't implemented that part yet.
I'm still not sure whether we would really need a separate command for simply switching layers or not.
And the commands moving the layer in z-order should display, "<b>Layer1</b> is at <b>2</b> of <b>5</b> (moved up)" or "<b>Layer1</b> is at <b>1</b> of <b>5</b> (<b>not moved</b>, cannot move any further down)".
Ok.
One more thing: when you update any shortcuts, please edit doc/keys.xml to reflect this (I could do this myself, but it would be useful to have at least one more developer familiar with that file :) Use <note>s to describe any non-obvious aspects of the commands.
Hmm, ok.
-mental
This would work the same as the regular z-order change commands on objects, but apply to the (temporary or permanent) layer. In fact, you can use those commands for it with a few modifications. Note that they move 1 step up/down relative to the objects that the selected object (or, in your case, layer/group) overlaps; I think this also makes sense to preserve for moving group-layers.
? could you elaborate?
Try it with the regular z-order commands. If you have this z-order:
A B C
and you're moving A one step down, then it checks if the bboxes of A and B overlap. If they do, it puts A under B. If not, it checks the same for C, etc. In other words, z-order commands only consider the stack of objects that bbox-overlap the current object, not the entire z-order stack of the document. (Until I implemented that, one-step z-order changes were almost unusable in big documents.)
Now, with layers, I think it depends on what we're moving relative to what. If you're moving a layer relative to other layers, I don't think you need to check bboxes. However if you're moving a layer relative to sibling objects, you do need to implement the same bbox checks. I think this will be the expected behavior.
Well, the intent is that they will eventually move objects just as you describe. I just haven't implemented that part yet.
OK, then "Move" is appropriate.
I'm still not sure whether we would really need a separate command for simply switching layers or not.
OK, we'll see. That depends on how convenient and keyboard-friendly is the layers widget. If it's just "Shift+Alt+L, Up, Esc" to switch one layer up then indeed we may not need a verb for that.
On Sat, 25 Sep 2004, MenTaLguY wrote:
Date: Sat, 25 Sep 2004 14:38:49 -0400 From: MenTaLguY <mental@...3...> To: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] idea: "temporary ungroup"
Talking with a friend today, we came up with the idea of renaming the "Edit group" feature to "temporary ungroup", since that is closer to what it does (from the visual user's perspective). "Edit parent" would then become "regroup".
Renaming it doesn't seem like a great idea.
He also noted that Flash lets you do something comparable by double-clicking on a group. That seems like maybe a good idea here too.
The idea in principle sounds great, from the users perspective why shouldn't you be able to reach inside a group and change things? This would make for a more straight forward "realistic" kind of manipulation and save the users from needing to worry about the implementation detials.
Thoughts?
-mental
Bulia, I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar. It also risks creating a lot of extra work adding extra markup to the other status bar messages. The statusbar can and will be disabled so it should not be used for any really important information. Essential information that should not be ignored belongs in a Message Dialog.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO. I even had to replace gtk_statusbar by gtk_label to enable this. An added bonus is that this got rid of the ugly statusbar frame :)
It also risks creating a lot of extra work adding extra markup to the other status bar messages.
Don't worry, I already did this work :) Now most messages have this (where this makes sense, of course).
The statusbar can and will be disabled so it should not be used for any really important information.
It's not used for any "really important" information. The only change is that it now displays more helpful tips than before, and does it in a more accessible and easy-to-scan way. You can still work without the statusbar enabled if you know Inkscape well enough.
Essential information that should not be ignored belongs in a Message Dialog.
Sure.
On Sat, 25 Sep 2004, bulia byak wrote:
Date: Sat, 25 Sep 2004 20:26:30 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] idea: "temporary ungroup"
I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO.
While I am unsure of the reasoning behind it I would not dismiss it so quickly. I figure it is overkill and possibly distracting to have markup in the status bar messages (but I suppose if it was distracting I would have noticed it already).
If this information was also being used to help automatically generate API documentation it could be interesting.
I even had to replace gtk_statusbar by gtk_label to enable this. An added bonus is that this got rid of the ugly statusbar frame :)
Did you find out the reasoning behind it before going to all that trouble? using non-standard widgets could come back to bite you in the ass.
It also risks creating a lot of extra work adding extra markup to the other status bar messages.
Don't worry, I already did this work :) Now most messages have this
Presumably progress has been made in the past few years and markup no longer messes up translation as badly as it used to but it will at least mean extra effort for translators.
(where this makes sense, of course).
for the benefit of translators when does it make sense and what rules or pattern should they try and follow?
The statusbar can and will be disabled so it should not be used for any really important information.
It's not used for any "really important" information. The only change is that it now displays more helpful tips than before, and does it in a more accessible and easy-to-scan way. You can still work without the statusbar enabled if you know Inkscape well enough.
so long as no one dares blame users for failing to notice that status bar messages, and so long t is not used as an excuse for not improving things I dont really mind.
Essential information that should not be ignored belongs in a Message Dialog.
Sure.
- Alan
I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO.
While I am unsure of the reasoning behind it I would not dismiss it so quickly. I figure it is overkill and possibly distracting to have markup in the status bar messages (but I suppose if it was distracting I would have noticed it already).
If it distracts you, chances are you're seeing this particular message for the first time. Then it's a good thing because it gives you an immediate explanation of what happened. Once you get used to it, you will stop noticing it when you don't need it, markup or no markup.
The idea is simple: 1. Inkscape is a complex app. 2. To make a complex app easy to learn, you need to provide a lot of tips and explanations along the way, some of which may be quite longish. 3. To make longish tips readable, you need to highlight the important bits. That's all.
Did you find out the reasoning behind it before going to all that trouble? using non-standard widgets could come back to bite you in the ass.
gtk-label is very standard. gtk-statusbar uses it internally anyway. And we don't need gtk-statusbar for its message stack because it's too primitive for our purposes (we have our own MessageStack and MessageContexts).
Don't worry, I already did this work :) Now most messages have this
Presumably progress has been made in the past few years and markup no longer messes up translation as badly as it used to but it will at least mean extra effort for translators.
It will. So what? Do you suggest we should stop making our messages better for fear of giving translators extra work?
(where this makes sense, of course).
for the benefit of translators when does it make sense and what rules or pattern should they try and follow?
Three main rules:
1. Highlight the changing portion of the message, e.g.:
<b>3</b> objects selected.
This lets the user who knows what the message says to quickly focus on the important bit without scanning the entire message. If there are several changing portions, highlight the most important one.
2. In tips and error messages, highlight the most important part of the message so that the highlighted part makes at least some sense when read separately, e.g.:
Select <b>at least two objects</b> to group
Here, if the user is wondering why grouping did not work, he can read only the highlighted part ("at least two objects") and this will already give him a clear idea of what went wrong, without having to read the entire message.
Sometimes (sparingly), there may be two highlighted portions:
If you want to clone several objects, <b>group</b> them and <b>clone the group</b>.
This is because the message tells you to do two things, hence the two highlights.
3. In tips about keys and mouse, highlight the keys and shortcuts:
<b>Shift:</b> toggle select, force rubberband
or
<b>Rotate</b> the pattern fill; with <b>Ctrl</b> to snap angle
(this one uses rules 2 and 3).
so long as no one dares blame users for failing to notice that status bar messages, and so long t is not used as an excuse for not improving things I dont really mind.
Rather, it's used as an "excuse" to improve things. If something is broken, I won't explain this in the statusbar; instead I'll have to fix it first and then describe the correct behavior.
On Sat, 25 Sep 2004, bulia byak wrote:
Date: Sat, 25 Sep 2004 21:18:19 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] idea: "temporary ungroup"
I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO.
While I am unsure of the reasoning behind it I would not dismiss it so quickly. I figure it is overkill and possibly distracting to have markup in the status bar messages (but I suppose if it was distracting I would have noticed it already).
The idea is simple:
- Inkscape is a complex app.
Agreed
- To make a complex app easy to learn, you need to provide a lot of
tips and explanations
Agreed
along the way, some of which may be quite longish.
probably
- To make longish tips readable, you need to highlight the important
bits. That's all.
I'm not convinced about the need for markup that's all, due in no small part to the fact that some one went to the trouble of writing the Gnome Human Interface Guidelines to specifically tell developers not to do it.
I will try and find out the reason for it but I already doubt there are any brilliant reasons against it, or even any good enough to convince you not to do it.
I suppose only by trying it will the pitfalls be (re)discovered.
Did you find out the reasoning behind it before going to all that trouble? using non-standard widgets could come back to bite you in the ass.
gtk-label is very standard. gtk-statusbar uses it internally anyway. And we don't need gtk-statusbar for its message stack because it's too primitive for our purposes (we have our own MessageStack and MessageContexts).
okay, so that is a non issue.
Presumably progress has been made in the past few years and markup no longer messes up translation as badly as it used to but it will at least mean extra effort for translators.
It will. So what? Do you suggest we should stop making our messages better for fear of giving translators extra work?
As far as a I remember the markup makes it harder for some of the gettext systems to recognises similar strings that can be reused. It also adds the extra task of deciding where to put the markup.
Translation is difficult and fairly thanksless work and having tried doing it myself I do not think making it any more difficult is a good idea and I commend the hard work of those who produce the translations. Maybe the translators enjoy their work so much that they wont mind and I suppsoe those that do can use their discretion and simply skip it.
(where this makes sense, of course).
for the benefit of translators when does it make sense and what rules or pattern should they try and follow?
Three main rules:
- Highlight the changing portion of the message, e.g.:
- In tips and error messages, highlight the most important part of
the message so that the highlighted part makes at least some sense when read separately, e.g.:
- In tips about keys and mouse, highlight the keys and shortcuts:
Rather, it's used as an "excuse" to improve things. If something is broken, I won't explain this in the statusbar; instead I'll have to fix it first and then describe the correct behavior.
Like I said earlier only by trying it will the pitfalls be discovered.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
On Sa, 2004-09-25 at 20:26 -0300, bulia byak wrote:
I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
I know. A really stupid limitation IMHO. I even had to replace gtk_statusbar by gtk_label to enable this. An added bonus is that this got rid of the ugly statusbar frame :)
The frame being ugly is a a matter of the theme you use. I don't like the idea, since I'm theming.
David
I know. A really stupid limitation IMHO. I even had to replace gtk_statusbar by gtk_label to enable this. An added bonus is that this got rid of the ugly statusbar frame :)
The frame being ugly is a a matter of the theme you use. I don't like the idea, since I'm theming.
It's ugly not because of a particular theme, but because it's utterly useless and slightly misguiding (it suggests that the statusbar is something separate and standalone which it's not). Also there's an issue of a left margin; gtk_statusbar pushes the text against the left edge of the frame which is aesthetically bad (and not themable). With gtk_label I added a small skip there and it looks much better now.
On Tue, 28 Sep 2004, bulia byak wrote:
It's ugly not because of a particular theme, but because it's utterly useless and slightly misguiding (it suggests that the statusbar is something separate and standalone which it's not). Also there's an issue of a left margin; gtk_statusbar pushes the text against the left edge of the frame which is aesthetically bad (and not themable). With gtk_label I added a small skip there and it looks much better now.
I learned something else reading the HIG last night -- if you have interactive status bar widgets (as we do), non-interactive elements (like the message "statusbar") are not supposed to have frames.
So actually, our present statusbar arrangement represents an improvement in HIG conformance.
-mental
On Sat, 2004-09-25 at 17:48, Alan Horkan wrote:
The idea in principle sounds great, from the users perspective why shouldn't you be able to reach inside a group and change things? This would make for a more straight forward "realistic" kind of manipulation and save the users from needing to worry about the implementation detials.
Well, admittedly you can use ctrl+click in the selection tool for that purpose already, as far as that goes.
Bulia, I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
They don't. I looked.
It also risks creating a lot of extra work adding extra markup to the other status bar messages. The statusbar can and will be disabled so it should not be used for any really important information.
Right, the statusbar itself is supplemental, as is formatting.
But although I was skeptical at first, I think it does provide an incremental benefit (provided it's not overused).
-mental
On Mon, 27 Sep 2004, MenTaLguY wrote:
Date: Mon, 27 Sep 2004 20:48:28 -0400 From: MenTaLguY <mental@...3...> To: Alan Horkan <horkana@...44...> Cc: Inkscape ML inkscape-devel@lists.sourceforge.net, bulia byak <buliabyak@...400...> Subject: Re: [Inkscape-devel] idea: "temporary ungroup"
On Sat, 2004-09-25 at 17:48, Alan Horkan wrote:
The idea in principle sounds great, from the users perspective why shouldn't you be able to reach inside a group and change things? This would make for a more straight forward "realistic" kind of manipulation and save the users from needing to worry about the implementation detials.
Well, admittedly you can use ctrl+click in the selection tool for that purpose already, as far as that goes.
Bulia, I'm pretty sure the Gnome Guidelines prohibit or at least discourage the use of markup in the status bar.
They don't. I looked.
I looked too and there is nothing saying you shouldn't put markup in the statusbar.
I thought maybe instead there was something saying you shouldn't put markup in the window title but there wasn't.
There are still the other reasons that have been suggested but as the work is already done there is certainly no harm in trying it.
But although I was skeptical at first, I think it does provide an incremental benefit (provided it's not overused).
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
participants (4)
-
Alan Horkan -
bulia byak -
David Christian Berg -
MenTaLguY