NEW: better statusbar tips for multiple objects in selection
For multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays
5 objects of type Group in layer LayerName.
instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example:
5 objects of types Group, Path, Rectangle in layer LayerName.
The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example:
5 objects of 4 types in layer LayerName.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Cool,
Where is the code that determines the types? Is there a list of possible types somewhere. That was one of the gating items for the verb sensitivity stuff I was working on a while back.
--Ted
On Fri, 2006-03-17 at 18:12 -0400, bulia byak wrote:
For multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays
5 objects of type Group in layer LayerName.instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example:
5 objects of types Group, Path, Rectangle in layer LayerName.The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example:
5 objects of 4 types in layer LayerName.
On 3/18/06, Ted Gould <ted@...11...> wrote:
Cool,
Where is the code that determines the types? Is there a list of possible types somewhere. That was one of the gating items for the verb sensitivity stuff I was working on a while back.
For now I just did a quick hack right in selection-describer - a list. Later we'll probably need to add another method to SPItem that returns the brief one-word description, probably more granular than the object type (e.g. differentiating stars and polygons). There's sp_item_description but it's too long for this.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Sat, 18 Mar 2006, bulia byak wrote:
On 3/18/06, Ted Gould <ted@...11...> wrote:
Where is the code that determines the types? Is there a list of possible types somewhere. That was one of the gating items for the verb sensitivity stuff I was working on a while back.
For now I just did a quick hack right in selection-describer - a list. Later we'll probably need to add another method to SPItem that returns the brief one-word description, probably more granular than the object type (e.g. differentiating stars and polygons). There's sp_item_description but it's too long for this.
Hmm, I was thinking a little bit differently. Like keeping a mask of the selected types.
If I was going to do the senesitivity on the menu items, which types would you be interested in distinguishing that they are selected? Any SPItem type? Just paths, shapes, text?
--Ted
On Mar 21, 2006, at 9:51 PM, ted@...11... wrote:
If I was going to do the senesitivity on the menu items, which types would you be interested in distinguishing that they are selected? Any SPItem type? Just paths, shapes, text?
Does this mean turning menu items enabled and disabled?
If so, would that involve GtkActions at all yet?
On Tue, 21 Mar 2006, Jon A. Cruz wrote:
On Mar 21, 2006, at 9:51 PM, ted@...11... wrote:
If I was going to do the senesitivity on the menu items, which types would you be interested in distinguishing that they are selected? Any SPItem type? Just paths, shapes, text?
Does this mean turning menu items enabled and disabled?
Yeah, that's the plan. They currently can be done, but nothing as useful as being able to change them based on the selection. You'll notice that the "Last Effect" menu item isn't active until you've used an effect.
If so, would that involve GtkActions at all yet?
Nope. I'm still happy with SPActions :) As much as I'm for using more library code and supporting less, I think they're too different for anything less than a major refactoring effort. I don't care enough for that.
--Ted
On Mar 21, 2006, at 10:09 PM, ted@...11... wrote:
If so, would that involve GtkActions at all yet?
Nope. I'm still happy with SPActions :) As much as I'm for using more library code and supporting less, I think they're too different for anything less than a major refactoring effort. I don't care enough for that.
Yeah... but we need that.
:-)
Actually, in order to get the main UI bug fixed that's been annoying Bulia for a while we'll need to get things redone to use GtkAction at some point. That's why we have the toolbars keeping the UI too wide. As soon as we get verbs giving us consistent GtkActions, we can switch the toolbars to standard Gtk ones and we'll get a nice, shrinkable UI again.
Of course I'm not asking you to do that, just wanted to point things out so that people can get things slowly worked into that direction.
(Oh, and then I'll also end up no annoying Bulia quite as much)
On 3/22/06, Jon A. Cruz <jon@...18...> wrote:
Actually, in order to get the main UI bug fixed that's been annoying Bulia for a while we'll need to get things redone to use GtkAction at some point. That's why we have the toolbars keeping the UI too wide. As soon as we get verbs giving us consistent GtkActions, we can switch the toolbars to standard Gtk ones and we'll get a nice, shrinkable UI again.
Will this also give us draggable toolbars like all other apps have (even Xara on Linux)? If yes, I'm for it. If no, just shrinkability alone is not worth the trouble, IMHO.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mar 22, 2006, at 6:39 AM, bulia byak wrote:
On 3/22/06, Jon A. Cruz <jon@...18...> wrote:
Actually, in order to get the main UI bug fixed that's been annoying Bulia for a while we'll need to get things redone to use GtkAction at some point. That's why we have the toolbars keeping the UI too wide. As soon as we get verbs giving us consistent GtkActions, we can switch the toolbars to standard Gtk ones and we'll get a nice, shrinkable UI again.
Will this also give us draggable toolbars like all other apps have (even Xara on Linux)? If yes, I'm for it. If no, just shrinkability alone is not worth the trouble, IMHO.
Yes. It should do that, and a few other things as well. Many of them are probably not of interest to everyone, but they do cover things like accessibility, thus are good for many things in the long run.
On Tue, 21 Mar 2006, Jon A. Cruz wrote:
(Oh, and then I'll also end up not annoying Bulia quite as much)
What? Annoying Bulia isn't the point? You guys HAVE to tell me when we change these things! ;)
Have refactored the Verbs once (and minimizing my plans when realizing how big it is) I don't envy the person who tried to take this one on. It's a lot of connection code, where everyone depends on specific little minimally documented features of the Verbs and Actions. Not saying it can't be done, but warning those about the trip ahead.
--Ted
On 3/22/06, ted@...11... <ted@...11...> wrote:
Hmm, I was thinking a little bit differently. Like keeping a mask of the selected types.
I don't care much about specific implementation. I just think it's more logical to make this a parallel to sp_item_description and to store the code in SPItem subclasses which are better prepared to answer the question "what are you, exactly".
If I was going to do the senesitivity on the menu items, which types would you be interested in distinguishing that they are selected? Any SPItem type? Just paths, shapes, text?
I'm interested in all "easily selectable" ones, which means those that can be selected by clicking on the canvas. (For example tspans can also be selected by the XML editor, but it's an exotic possibility so I didn't include that). For now the list of easily selectable items is in type2term() in selection-describer.cpp. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (4)
-
unknown＠example.com -
bulia byak -
Jon A. Cruz -
Ted Gould