Here's a list of layer commands that we need to implement, comments and additions welcome:
Layers... // opens the Layers dialog ------------------- Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings Move to Layer... // let me choose the layer name to move selection to ------------------- Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers ------------------- Unlock All in Layer // unlock all children of the current layer Unhide All in Layer ------------------- Group to Layer // convert group to layer Layer to Group
I've added these to the roadmap
On Mon, 29 Nov 2004, bulia byak wrote:
Here's a list of layer commands that we need to implement, comments and additions welcome:
Layers... // opens the Layers dialog
Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings Move to Layer... // let me choose the layer name to move selection to
Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers
Unlock All in Layer // unlock all children of the current layer Unhide All in Layer
Group to Layer // convert group to layer Layer to Group
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2004-11-29 at 15:24, bulia byak wrote:
Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings
I think it would be better to match the visual ordering of layers as they appear in the selector and Layers dialog.
That basically means that "above" is a depth-first traversal of layers, avoiding the problem of constantly "coralling" the user into higher-level layers when using sublayers.
FWIW, depth-first traversal is already implemented with Inkscape::next_layer (for above) and Inkscape::previous_layer (for below), in layer-fns.cpp.
-mental
On Mon, 2004-11-29 at 15:24, bulia byak wrote:
Group to Layer // convert group to layer Layer to Group
Hmm, I'm not entirely sure either of these is really necessary.
Certainly "Group to Layer" would be handled by the hypothetical "from selection" option in the "New Layer" dialog.
Not sure about how much or if at all "Layer to Group" would be needed. Can you provide a use case?
-mental
Certainly "Group to Layer" would be handled by the hypothetical "from selection" option in the "New Layer" dialog.
Not sure about how much or if at all "Layer to Group" would be needed. Can you provide a use case?
Just convenience - when you work inside some group it's convenient to have it as layer, so as not to have to "enter" it all the time. When you're done working inside it and want to position or transform it, you need it to be a group again.
In old files, people may have used groups instead of unavailable layers as a way to organize stuff. It would be nice to allow them to convert these to proper layers easily. Making a layer with selected group and then ungrouping it is not too elegant, and as we now know ungrouping may not preserve appearance for textpaths.
Also there's a slight didactic value in these commands: they emphasize the relation between groups and layers which is an important thing to understand.
Sorry for the late reply, I wanted to play around with version 0.40 for a while before posting and then I forgot about having drafted this message.
On Mon, 29 Nov 2004, bulia byak wrote:
Date: Mon, 29 Nov 2004 15:24:09 -0500 From: bulia byak <buliabyak@...400...> To: inkscape-devel@lists.sourceforge.net, MenTaLguY <mental@...3...> Subject: [Inkscape-devel] layer commands we need
Here's a list of layer commands that we need to implement, comments and additions welcome:
First off you really dont want to have negative labels, they should be positive and the checkbox would indicate the state.
Layers... // opens the Layers dialog
New Layer
keybinding should definately be Ctrl+Shift+N
Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings Move to Layer... // let me choose the layer name to move selection to
For the moment it does make sense to have these directly in the Layer menu but as other features are added and depending on how full the menu gets it may make sense to have them in a submenu
Layers Arrange Move Above Move Below etc
Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?)
Unhide All Layers
If you are going to put this in the menus at all I would prefer to see (View in this case is analagous to Show)
Layers, View, Current Only All None Invert
and a simliar structure for
Layers, Lock, Option Option Option
Unlock All in Layer // unlock all children of the current layer Unhide All in Layer
Group to Layer // convert group to layer
While this makes a lot of sense from the way layers are already implemented as Groups I'm not sure this is the best way to go as it is very specific and not coming at it from the user point of view.
It might be better to have something more generic like "Convert to Layer" that would take the current selection and irrespective of it being a group or not and put it on a New Layer. (This would actually be the same as what I previously described as "New Layer from Cut").
Layer to Group
I could apply the same logic as above to this idea but I think it this case it might be more useful to retain the grouping.
In a hurry and dont have time to consider this in any further detail, hope these ideas help.
Sincerely
Alan Horkan
Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
An update on my post of two month ago:
On Mon, 29 Nov 2004 15:24:09 -0500, bulia byak <buliabyak@...400...> wrote:
Here's a list of layer commands that we need to implement, comments and additions welcome:
Layers... // opens the Layers dialog
This seems to have stalled pending the Gtkmm conversion. Bryce & Jizzbug, what are your current plans on this? E.g. I have in mind a feature which I'm holding back because it will require a new dialog, and I don't want to start a new dialog before the conversion. When is the next step after putting the Gtkmm code into the tree?
Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings
done (by me)
Move to Layer... // let me choose the layer name to move selection to
Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers
Unlock All in Layer // unlock all children of the current layer Unhide All in Layer
Group to Layer // convert group to layer Layer to Group
not done, and here's another one we need:
Flatten layers // merge all siblings with the current layer
On Sat, 5 Mar 2005, bulia byak wrote:
Date: Sat, 5 Mar 2005 12:39:53 -0400 From: bulia byak <buliabyak@...400...> To: inkscape-devel@lists.sourceforge.net, MenTaLguY <mental@...3...>, Bryce Harrington <bryce@...260...> Subject: [Inkscape-devel] Re: layer commands we need
An update on my post of two month ago:
On Mon, 29 Nov 2004 15:24:09 -0500, bulia byak <buliabyak@...400...> wrote:
Here's a list of layer commands that we need to implement, comments and additions welcome:
Layers... // opens the Layers dialog
done (by me)
Move to Layer... // let me choose the layer name to move selection to
Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers
Unlock All in Layer // unlock all children of the current layer Unhide All in Layer
The Gnome HIG discourages using negatives like "Unhide" and as far as I can remember it would recommend using "Show All in Layer" instead.
Group to Layer // convert group to layer Layer to Group
not done, and here's another one we need:
Flatten layers // merge all siblings with the current layer
Perhaps I'm misinterpreting your description but do you expect that this going to work like the GIMP/Photoshop where they have
Merge Down merges the current layer into the layer below it. Merge Visible merges all the visible layers together Flatten Image merges all layers down leaving only the bottom Background layer
(Photoshop uses the shortcuts Ctrl+E and Ctrl+Shift+E for Merge and Merge Visible respectively).
If I have misinterpreted could you clarify what you meant by "merge all siblings with the current layer".
Thanks
- Alan
On Sat, 5 Mar 2005 16:55:05 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
The Gnome HIG discourages using negatives like "Unhide" and as far as I can remember it would recommend using "Show All in Layer" instead.
Makes sense, especially since we already have Select All in All Layers.
Flatten layers // merge all siblings with the current layer
Perhaps I'm misinterpreting your description but do you expect that this going to work like the GIMP/Photoshop where they have
Merge Down merges the current layer into the layer below it. Merge Visible merges all the visible layers together Flatten Image merges all layers down leaving only the bottom Background layer
Yes, Merge Down is a good idea to have. But what is the difference between Merge Visible and Flatten Image? If it's only that the latter affects all layers including invisible ones, then I don't need we need a separate command for this. Instead we need a way to unhide all layers.
I think "Merge visible" should only work on the siblings of the current layer. So perhaps it's better called "Merge sibling layers", with "visible" being implied (we don't generally do anything to invisible/hidden layers). Also it may be useful to have a "Merge sublayers" command that would remove all sublayers copying their contents to the parent layer.
On Sun, 6 Mar 2005, bulia byak wrote:
Date: Sun, 6 Mar 2005 17:27:16 -0400 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: layer commands we need
On Sat, 5 Mar 2005 16:55:05 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
The Gnome HIG discourages using negatives like "Unhide" and as far as I can remember it would recommend using "Show All in Layer" instead.
Makes sense, especially since we already have Select All in All Layers.
Flatten layers // merge all siblings with the current layer
Perhaps I'm misinterpreting your description but do you expect that this going to work like the GIMP/Photoshop where they have
Merge Down merges the current layer into the layer below it. Merge Visible merges all the visible layers together Flatten Image merges all layers down leaving only the bottom Background layer
Yes, Merge Down is a good idea to have. But what is the difference between Merge Visible and Flatten Image?
If it's only that the latter affects all layers including invisible ones, then I don't need we need a separate command for this. Instead we need a way to unhide all layers.
Well the difference is that if you want to keep working on a layer you can hide it temporarily and flatten the rest and keep working with a more managable two or three layers.
You want to Include "Merge Visible" but not both with "Flatten Image"? I suppose that works, hadn't thought of it that way. Hopefully it wont confuse artists with bad habits too much.
I definately agree that Show All Layers is worthwhile functionality, irrespective of any layer merging functionality.
I think "Merge visible" should only work on the siblings of the current layer. So perhaps it's better called "Merge sibling layers", with "visible" being implied (we don't generally do anything to invisible/hidden layers).
Siblings seems extremely confusing to me, I hardly ever use the word siblings (brothers, sisters, family but almost never siblings) and I'm a native English speaker and as I user I wouldn't be sure what exactly it might mean (i did already have to ask) so it is bordering on complex jargon.
I'm still trying to understand what exactly you mean. Are you thinking of having an option called 'Merge sibling layers' that would merge the current layer with the layer below it and also the layer above it? This seems like overkill, it is confusing because I think it would be a rare enough use case. If the user wanted to merge three layers they could start on the top and merge down twice (it would of course need a good keybinding, preferably the same as either the GIMP or Photoshop but I think this is a common workflow at least from all the graphics tutorials I've gone through in magazines). Merging down repeatedly is really very effective, almost elegantly simple in its effectiveness.
I would urge you to implement the necessary infrastructure, but include menu items for the more straight forward "Merge Down" and whichever of "Flatten Image/Merge Visible" you prefer or both (and as usual I'm a firm believer in keeping consistant with other applications and I think this is a good case for it).
With that familiar functionality and the show/hide options you intend to implement users should be able to efficiently do all they need to do.
I would hope that user-developers in need of more complex functionality would be able to implement it using extensions. I'd be intersted in hearing more of what layer functionality you think would be useful as I might try implementing something similar as a Script-Fu script for the GIMP.
Also it may be useful to have a "Merge sublayers" command that would remove all sublayers copying their contents to the parent layer.
This all seems very complicated to use and catering to very specialised cases. Are we confident that most users will even use layers? I would have thought the average user with small projects would stick to groups and moving things around on one layer (it was years before I started using Layers in Dia and then only to break up more complicated diagrams).
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Dia is for Diagrams http://gnome.org/projects/dia/ Alan's Journal http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://www.abisource.com
On Sun, 6 Mar 2005 22:12:19 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
You want to Include "Merge Visible" but not both with "Flatten Image"? I suppose that works, hadn't thought of it that way. Hopefully it wont confuse artists with bad habits too much.
Yes.
Siblings seems extremely confusing to me, I hardly ever use the word siblings (brothers, sisters, family but almost never siblings) and I'm a native English speaker and as I user I wouldn't be sure what exactly it might mean (i did already have to ask) so it is bordering on complex jargon.
It's a standard term in XML and in pretty much anything tree-like. Our layers are hierarchical, so it's natural for us to use it. How else would you call layers which have the same parent as the current one?
I'm still trying to understand what exactly you mean. Are you thinking of having an option called 'Merge sibling layers' that would merge the current layer with the layer below it and also the layer above it?
Merge all layers that are under the same parent as this one.
seems like overkill, it is confusing because I think it would be a rare enough use case.
Perhaps most of the time one would use "Merge down" to merge just two layers. But there must also be a way to merge all siblings, and for a parent, to merge all children into the parent.
Also it may be useful to have a "Merge sublayers" command that would remove all sublayers copying their contents to the parent layer.
This all seems very complicated to use and catering to very specialised cases.
That's because there's no easy way currently to make sublayers. Once this is in, they will be quite common I believe. Adobe has hierarchical layers too.
On Sun, 6 Mar 2005, bulia byak wrote:
Date: Sun, 6 Mar 2005 18:37:34 -0400 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: layer commands we need
On Sun, 6 Mar 2005 22:12:19 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
You want to Include "Merge Visible" but not both with "Flatten Image"? I suppose that works, hadn't thought of it that way. Hopefully it wont confuse artists with bad habits too much.
Yes.
Siblings seems extremely confusing to me, I hardly ever use the word siblings (brothers, sisters, family but almost never siblings) and I'm a native English speaker and as I user I wouldn't be sure what exactly it might mean (i did already have to ask) so it is bordering on complex jargon.
It's a standard term in XML and in pretty much anything tree-like. Our layers are hierarchical, so it's natural for us to use it. How else would you call layers which have the same parent as the current one?
I understand now. You are thinking in terms of Trees.
I am only thinking of Layers in terms of stack (a very shallow tree). The way I understand what you are talking about is something quite different from the traditional concepts of Layers.
Tonight I will look at how Adobe Photoshop handles what it calls Layer groups, which is essentially several layers under the same parent. Perhaps that will provide simpler terminology and something that graphics users might already be familiar with.
Perhaps most of the time one would use "Merge down" to merge just two layers. But there must also be a way to merge all siblings, and for a parent, to merge all children into the parent.
I'd imagine that as you merge down the tree could be flattened in the process when only one layer was remaining at that level of the tree it would merged down onto the next branch of the tree.
That's because there's no easy way currently to make sublayers. Once this is in, they will be quite common I believe. Adobe has hierarchical layers too.
I dont know if Adobe Illustrator has this kind of hierachical layers yet. In a vector graphics the objects are all seperate and can easily be moved around, grouped, move up and down the z-order whereas in a raster graphics program you almost need to create a new layer for each and every object if you want that same kind of flexibility.
Thanks for your patience. I think I understand much better now.
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://www.abisource.com
On Sat, Mar 05, 2005 at 12:39:53PM -0400, bulia byak wrote:
An update on my post of two month ago:
On Mon, 29 Nov 2004 15:24:09 -0500, bulia byak <buliabyak@...400...> wrote:
Here's a list of layer commands that we need to implement, comments and additions welcome:
Layers... // opens the Layers dialog
This seems to have stalled pending the Gtkmm conversion. Bryce & Jizzbug, what are your current plans on this? E.g. I have in mind a feature which I'm holding back because it will require a new dialog, and I don't want to start a new dialog before the conversion. When is the next step after putting the Gtkmm code into the tree?
Refer to the status I wrote to your question on it last week in Jabber (you never responded, so perhaps you missed it). I was at Connectathon for the past week working exclusively on NFSv4. I had hoped to work on it in the evenings, but I could not get Inkscape to build on SuSE 9.2 (dependency problems). I won't have as much time this weekend as I thought (I have to find my cat that ran off).
I don't think Jizzbug's started working on the integrated gtkmm code. (Ironically, we've lost rather than gained activity by integrating the gtkmm code. Maybe we should have kept it separate longer?) Anyway, I'm definitely still working on it, but there's a heck of a lot of coding to do, and I only have a moderate amount of time to put into it, so if people are waiting for 100% of the gtkmm conversion to be done before they do any gui work themselves, things are going to get massively logjammed here pretty soon.
Bryce
On Sat, 5 Mar 2005 13:35:46 -0800, Bryce Harrington <bryce@...260...> wrote:
This seems to have stalled pending the Gtkmm conversion. Bryce & Jizzbug, what are your current plans on this? E.g. I have in mind a feature which I'm holding back because it will require a new dialog, and I don't want to start a new dialog before the conversion. When is the next step after putting the Gtkmm code into the tree?
Refer to the status I wrote to your question on it last week in Jabber (you never responded, so perhaps you missed it). I was at Connectathon for the past week working exclusively on NFSv4. I had hoped to work on it in the evenings, but I could not get Inkscape to build on SuSE 9.2 (dependency problems). I won't have as much time this weekend as I thought (I have to find my cat that ran off).
Thanks for the update. I really hope there will be some progress, because otherwise, we now have enough stuff to start thinking about a 0.42.
I don't think Jizzbug's started working on the integrated gtkmm code. (Ironically, we've lost rather than gained activity by integrating the gtkmm code. Maybe we should have kept it separate longer?)
I wonder why is that?
Anyway, I'm definitely still working on it, but there's a heck of a lot of coding to do, and I only have a moderate amount of time to put into it, so if people are waiting for 100% of the gtkmm conversion to be done before they do any gui work themselves, things are going to get massively logjammed here pretty soon.
Maybe you can write up some simple well-defined subtasks for people to try? This seems to have worked with SPRepr cleanups.
On Sun, Mar 06, 2005 at 07:51:27PM -0400, bulia byak wrote:
On Sat, 5 Mar 2005 13:35:46 -0800, Bryce Harrington <bryce@...260...> wrote:
This seems to have stalled pending the Gtkmm conversion. Bryce & Jizzbug, what are your current plans on this? E.g. I have in mind a feature which I'm holding back because it will require a new dialog, and I don't want to start a new dialog before the conversion. When is the next step after putting the Gtkmm code into the tree?
Refer to the status I wrote to your question on it last week in Jabber (you never responded, so perhaps you missed it). I was at Connectathon for the past week working exclusively on NFSv4. I had hoped to work on it in the evenings, but I could not get Inkscape to build on SuSE 9.2 (dependency problems). I won't have as much time this weekend as I thought (I have to find my cat that ran off).
Thanks for the update. I really hope there will be some progress, because otherwise, we now have enough stuff to start thinking about a 0.42.
The 0.41 release used up a lot of my time; I had to postpone work on gtkmm stuff for about a month. Making a 0.42 release would similarly stop progress on gtkmm for a long period. I don't think that's the right way to go. The gtkmm stuff has been bumped for several releases already; it would be a shame to do that again, when we clearly have plenty of energy going into development. We just need to get a bit more of it diverted into gtkmm.
Anyway, I'm definitely still working on it, but there's a heck of a lot of coding to do, and I only have a moderate amount of time to put into it, so if people are waiting for 100% of the gtkmm conversion to be done before they do any gui work themselves, things are going to get massively logjammed here pretty soon.
Maybe you can write up some simple well-defined subtasks for people to try? This seems to have worked with SPRepr cleanups.
Sure, how should this be done? I have a very detailed task list for this, that I keep updated, and have placed a lot of TODO's in the code itself. I'd love to know what could be done to get more people working on the code.
Bryce
On Sun, 6 Mar 2005 18:18:58 -0800, Bryce Harrington <bryce@...260...> wrote:
The 0.41 release used up a lot of my time; I had to postpone work on gtkmm stuff for about a month. Making a 0.42 release would similarly stop progress on gtkmm for a long period. I don't think that's the right way to go. The gtkmm stuff has been bumped for several releases already; it would be a shame to do that again, when we clearly have plenty of energy going into development. We just need to get a bit more of it diverted into gtkmm.
Sure, I'm not saying we should postpone it again. I'm just saying that if/when we get gtkmm done, we also have enough other stuff to justify the release.
Sure, how should this be done? I have a very detailed task list for this, that I keep updated, and have placed a lot of TODO's in the code itself. I'd love to know what could be done to get more people working on the code.
I think just write them up on Wiki and send a call for help to the list. And keep reminding about it until something starts rolling.
On Sun, Mar 06, 2005 at 10:30:01PM -0400, bulia byak wrote:
On Sun, 6 Mar 2005 18:18:58 -0800, Bryce Harrington <bryce@...260...> wrote:
The 0.41 release used up a lot of my time; I had to postpone work on gtkmm stuff for about a month. Making a 0.42 release would similarly stop progress on gtkmm for a long period. I don't think that's the right way to go. The gtkmm stuff has been bumped for several releases already; it would be a shame to do that again, when we clearly have plenty of energy going into development. We just need to get a bit more of it diverted into gtkmm.
Sure, I'm not saying we should postpone it again. I'm just saying that if/when we get gtkmm done, we also have enough other stuff to justify the release.
Okay, gotcha. I'm actually really glad to see the work you did with eliminating the need for the gradient editing in the fill&stroke dialog, because I was really not looking forward to gtkmmifying that code!
Sure, how should this be done? I have a very detailed task list for this, that I keep updated, and have placed a lot of TODO's in the code itself. I'd love to know what could be done to get more people working on the code.
I think just write them up on Wiki and send a call for help to the list. And keep reminding about it until something starts rolling.
Okay, although I've put out a few calls for help previously. Maybe I was not direct enough though... I'll give it a shot again once I've got the integration a little further along.
While we're on the topic - there's one area of the gtkmm work that I need your help - the Statusbar needs to be converted to Gtkmm. There has not been any work done on this yet, but I think it is important to do soonish since a lot of the other parts of the interface will be calling its code. If I pointed you at where this code fits in, would you be comfortable taking charge of doing this implementation? The current Gtk+ statusbar code is fairly good so I think this should be a straightforward conversion.
Bryce
participants (4)
-
Alan Horkan -
Bryce Harrington -
bulia byak -
MenTaLguY