Select All by Stroke or Fill Color

[Bug Importer]

This is a simple feature from Illustrator that I find
myself using a lot. If I have an object with an orange
fill color selected I can use Select>Same>Fill Color to
quickly select all objects with that same orange fill.
 Good for when I am working with a limited color design
and need to adjust my colors (maybe change all of my
orange objects to a yellow-orange). Illustrator also
has other useful options under the Select>Same menu,
though not all would apply to Inkscape.

Select>Same>Blending Mode
Select>Same>Fill & Stroke
Select>Same>Opacity
Select>Same>Stroke Color
Select>Same>Stroke Weight
Select>Same>Style
Select>Same>Symbol Instance

[Breem42 (breem42)]

I too appreciate this feature in Illustrator, and in fact have a project
that would benefit from it. Certainly it could be fudged using groups or a
union of the objects of the same colour, but the flexibility would be
appreciated.

breem42
Vancouver, Canada

[darthkat (lisakat-wa)]

Any update on something like this? I see this was a while ago. I can select by color in one app that doesn't have simplify once the pieces are joined together, and In AI I can select by color but can't join contingent lines. It would be perfect if inkscape could select by color, then I could join and simplify in one program!

[hash (hash-g)]

Related Bug #171934 #171181

[Dithers (dithers)]

to select everything that uses a specific color you can right click on the color and choose copy color, and enter it into the find under style. add" fill:" in front of it select fil only "stroke:" for stroke. Many more attributes to select all by can be found in the XML editor.

[LucaDC (lucadc)]

Dithers, I often use the method you described to select similar objects so I can say with knowledge that it is really not straightforward: sometimes I prefer selecting objects by hand rather than going through it (if they are not so many).
Ok, it works but everyone that used other programs that give this option probably don't feel it's enough. Sure it's much more flexible because you can do whichever filtering you need, but for quick, simple, often used selections it's too heavy.
So, let's say that what's asked is not implemented in Inkscape yet, but if really needed there is a workaround to do something similar.

I hope the true one will come soon.
Thanks for your work.

[Antonio Roberts (hellocatfood)]

The workaround does indeed work but I do agree that there should be an easier way to do this.

[dopelover (dopelover)]

Selecting multiple objects by some properties is nicely implemented in AutoCAD. It is known as a Quick Select and it is, in my opinion, one of the most brilliant features in that piece of software. The idea is well described on this web page: http://www.ellenfinkelstein.com/autocadtips/AutoCAD_tips_quick_select.html
Introducing similar selection mechanism in Inkscape would make Inkscape more powerful.

[jtakalai (jutakala)]

Dithers: No need to open the XML window or anything.

You can select all by color by first finding out the color code (take the color picker tool on hover over the wanted color, look at the status bar), pressing Ctrl+F and then typing it in the code (e.g. #FF0000) into the Style textbox. It's quite fast actually, as long as the parts have exactly the same color.

[Antonio Roberts (hellocatfood)]

A thought for generally improving this function.

Would it make more sense to have a "Select by Attribute" function instead? We already have interpolate by attribute, so why not extend it to this feature?

[cem (cemelmaci-hotmail)]

Thankyou for the tip.

(take the color picker tool on hover over the wanted color, look at the status bar), pressing Ctrl+F and then typing it in the code (e.g. #FF0000) into the Style textbox.

Regards

[Azzurra (azzizuc)]

Hi!! I am trying to use this tool (select>Same menu) but I can't because I have only the "Select All" option. How can I do? Please, help me!!!

[Antonio Roberts (hellocatfood)]

Azzurra: Inkscape doesn't have that menu. That is a description of what the options a proposed menu could contain

[Azzurra (azzizuc)]

Oh no...
Sorry but I was a Corel Draw user until l yesterday!! So, how can I do to select same objects not by the same color (i.e. by using XLM editor) but by the same shape (circle to circle, line to line, ...)??
Thanks a lot!!!

[DDJJ (jldai)]

This is my No. 1 feature request.

[Tiina Uimonen (tiina-uimonen)]

I used this feature to select all same coloured objects and I have to say it is not easy nor quick way to do it. Is it possible to improve this, as others have also suggested?

[Aapo Rantalainen (aapo-rantalainen)]

Hi, attached very simple (and hack) patch for make it easier to 'select all with same fill color'

When Edit->Find... is used, 'style' is automatically (and always) prefilled with last used color (this might not be what user wants).

Patch is against version 0.48.2 (from Ubuntu 11.10 repository).

--
This patch is just for testing is this feature useful and what would be the best way to use it (maybe it is that submenu described on first post). This patch writes current color to /tmp and reads it later (there must be easier way to pass used color, but I can't figure it out [http://sourceforge.net/mailarchive/message.php?msg_id=28442799]).

[Joshua Damron (joshua-damron)]

I have been using Inkscape out for only a few weeks and I have found this missing feature to be source of frustration. I would love to see this feature implemented.

Aapo: I apologize but I am not good with code and have no idea what to do with your patch script.

Dithers: I tried your method and was not successful. It doesn’t seem to matter what I place in the “style” field of the “Find” dialogue box, the status bar says “no objects found" (this goes for all of the fields in the “Find”, it simply does not seem to work, any ideas why this might be?).

For your information there is a burgeoning market of cartographers using geographic information systems (GIS programs like qGIS and ArcGIS) software who greatly utilize Adobe Illustrator for touching up their maps and exhibits. Due to the cost of Adobe Illustrator I was hoping to utilize Inkscape, however the lack of an on the fly “select same stroke/fill” capability is a significant draw back.

This may seem like a minor thing to many graphics art designers, however in cartography the number of features which share the same symbology (stroke/fill) on a single map can be staggering, and the number of revisions to the maps features can seem endless. Take a common density map like the ones found here: http://sedac.ciesin.columbia.edu/gpw/maps/chndens.pdf , when repeatedly adjusting hundreds of features a quick click of a button to select all like features is priceless.

[John Smith (john-smithi)]

Patch to add this feature as a new submenu to the Edit menu

Edit > Select Same > Fill and Stroke
Edit > Select Same > Fill
Edit > Select Same > Stroke

Also added "Select Same Fill and Stroke" to the context menu.

Not sure if that is the best UI location for this feature...
Suggestions and improvements more that welcome...

[John Smith (john-smithi)]

Committed to trunk as r11141.
You can try it using a development version from inkscape.org/download.

Tested on Ubuntu 11.10 and Windows 7.

[LucaDC (lucadc)]

Thanks a lot, John! This is really a great speed up when managing many objects that share common settings. I've tested on Windows XP and it works as expected.

Let me point out only one aspect for (maybe, I hope) further development: while the fill has mainly its color (or gradient), a stroke is (visually) characterized by more than its color only. I feel that the thickness is at least as important as the color and also the applied dash could be considered pretty relevant (visually, at least).
I wonder if it would be more correct considering the general "having the same stroke" a more restrictive concept than simply "having the same stroke color". Personally, I'd find more useful considering thickness also, at least, but I would be happy the same (or maybe even more) if all parameters in the "Stroke style" dialog were considered for this quick select (for sure, the new powerful "Edit -> Find" dialog is the right place to go to for more elaborate or personalized filtered selections, but it's still not so much straightforward for a simple "same fill" or "same stroke" search).

[John Smith (john-smithi)]

Hi LucaDC,

Sure, lets change the options to whatever is most useful ...
What kind of options would you like to see ?

Select Same > Fill (Color)
Select Same > Stroke Color
Select Same > Stroke Style (include stroke width and dashes and markers ) ?

Then the right click "Select Same Fill and Stroke" to mean ... Select same Fill and Stroke Style ?

[LucaDC (lucadc)]

Oh, well, if it's that easy... Go for it! :)
I hope someone else will make proposals if this is not the right way.
For me it's ok.
Thanks

[su_v (suv-lp)]

>> (…) considering thickness (…)
> Select Same > Stroke Style (include stroke width and dashes and markers ) ?

Bug #831012 has some comments why selecting by stroke width possibly won't work precisely as expected (rounding issues due to scaled objects or different units - stroke width in Inkscape is stored in px (SVG user unit) in the SVG source), and there are probably other feature request about this (I didn't to a in-depth search atm). I wonder whether this could easily implemented as simple menu option - or would that menu then rather be called 'fuzzy select by stroke style'?

[ScislaC (scislac)]

John,

We need to stay away from different clicks do different things in menus. It's non-obvious and we don't do this anywhere else in the menus.

I can see the following things being useful (over the top and no doubt incomplete list, also, the Fill Type description was for explanation here, not in the actual menu):

Select Same > Style
Select Same > Fill and Stroke
Select Same > Fill Type (color, linear gradient, radial gradient, swatch, pattern, etc)
Select Same > Fill Color
Select Same > Stroke Style
Select Same > Stroke Width
Select Same > Stroke Color
Select Same > Stroke Dash Pattern
Select Same > Stroke Markers
Select Same > Stroke Start Markers
Select Same > Stroke Mid Markers
Select Same > Stroke End Markers
Select Same > Text Style
Select Same > Text Font
Select Same > Text Size
Select Same > Opacity
Select Same > Filter
Select Same > Live Path Effect

[su_v (suv-lp)]

John Smith wrote:
> Also added "Select Same Fill and Stroke" to the context menu.

The entry in the context menu is present and active if the context menu is opened while hovering a selectable object, but fails as long as no object is actually selected.

Could you change the context menu entry so that it tests for a current selection and only is sensitive if applicable (one or more objects are selected)?

[John Smith (john-smithi)]

@ScislaC, agreed lets keep the menu's consistent in naming and meaning.

I assume "Fill and Stroke" == Fill Color + Stroke Color + Stroke Style ?

@suv, thanks will ensure something is selected before enabling the context menu item.

>rather be called 'fuzzy select by stroke style'?
ScislaC suggested we could go with another submenu like "Select Similar" instead of "Select Same" with tolerance values stored somewhere.

[LucaDC (lucadc)]

> ScislaC suggested we could go with another submenu like "Select Similar"
> instead of "Select Same" with tolerance values stored somewhere.

That would be really useful, I see a nice application of this feature: you could select all widths inside a given tolerance, then apply exactly the same width in the "Fill and Stroke" dialog. So selecting "similar" objects should not be the default, but be used only to "clean" messed up designs.
You can't take full advantages of such a selection mechanism if the styles are not well specified.
Personally, I pay a lot of attention to applying exactly the same style to objects that must share it, so rounding problems don't affect me. Of course, if you create an object with a 2 mm stroke width and then rescale it to 50% (having the "rescale stroke" option active), you could not get exactly the same stroke of an object created with a 1 mm stroke width, and I feel this is reasonable because the operations done are not adequate for getting a precise drawing. But this even worse with colors: it's almost impossible to apply exactly the same color to two objects after manipulating the two: you have either to copy one to the other or use the palette or numeric input.
So, to me the "similar" approach is an useful option for correcting messy drawings, but I'd vote for the stricter "exactly the same" approach for the default behavior (and this could be achieved setting to 0.0 the tolerance parameter, so each user could specify what needed).

[John Smith (john-smithi)]

Committed r11146 ... adding the Stroke Style option

The Edit menu should now show ...

Select Same > Fill and Stroke (includes Fill Color + Stroke Color + Stroke Style)
Select Same > Fill Color
Select Same > Stroke Color
Select Same > Stroke Style (includes Stroke Width + Dashes + Markers )

Context menu "Select Same Fill and Stroke" is the same as the "Select Same > Fill and Stroke" menu.

Will try to add some more options and the idea of a "similar match" ...

[su_v (suv-lp)]

John Smith (john-smithi) wrote
> Select Same > (…)

1) What's the scope of the search: current layer, all layers (visible only, or hidden as well)?

2) Is the search based on the 'style' attribute as stored in the SVG source (AFAIU that's how it works in the 'Find…' dialog), or does it search in computed values (e.g. consider parent style attributes and transformations inherited by objects inside containers)?

[LucaDC (lucadc)]

@SiclaC,
you suggested a long list of possibilities, but I think that splitting all properties is not so good.
What if you have some squares that have different stroke widths, dash patterns, and stroke colors, all mixed and you need to select all squares with the "same stroke" from a visual point of view? The most intuitive concept of "same stroke" is that they "look the same".
I think that all attributes of the stroke should be considered together, while having one by one is not so useful. And if you have more specific needs the Find dialog lets you specify exactly what you need (also if it should be made a little more user friendly for specifying attribute values).
Anyway, the "fill type" option is a good idea, considering also the "no fill" option.

@John,
in the "Select Same > Stroke Style" I would include the color too, for the reason explained above.

[su_v (suv-lp)]

LucaDC wrote:
> I pay a lot of attention to applying exactly the same style
> to objects that must share it, so rounding problems don't affect me.

You completely ignore other users, who are likely to use a variety of different workflows and also might have an interest in refined selection methods based on different stroke style properties.

> (…) an object created with a 1 mm stroke width (…)

A stroke width of "1 mm" is stored by Inkscape as 'stroke-width:3.54330709' in the SVG source (mm -> px (SVG user unit)). This result of the conversion from 'mm' to SVG user units (based on Inkscape's internal resolution of 90ppi) is already a rounded value, and probably not as reliable to find as e.g. a stroke width of 1px.

Not to mention work flows heavily based on working with e.g. imported PDF files, whose content is scaled (pt -> px) by a 'transform' attribute on the parent layer to begin with? A quick test with r11146 shows that the selection does not consider transforms of parent layers: searching in mixed content of an imported PDF file and new objects drawn on new layers fails even if the same stroke width (e.g. in 'mm') is shown in the 'Stroke style' tab.

[LucaDC (lucadc)]

~suv wrote:
>You completely ignore other users
No, I don't. I just said that, in order to not have this sort of problems, I pay a lot of attention, so rounding problems don't affect me. No other user is involved in this, only me.

Also, I work a lot with imported PDFs so I perfectly know what you are (and I am) talking about.
I already stated that the selection with tolerance would be really useful, exactly in these scenarios.
But it shouldn't be the only possibility (at least without the option of setting the tolerance to 0) because I don't want to have "similar" strokes to be selected, but only identical ones. The "similar" concept is too subjective and could fit for someone but not for others. Just to be explicit, this is _my_ workflow and I don't want to say that it's the only possible one or that it's better than others'. It's simply the one I need in a search engine to be useful for me.

Moreover, I can assure that if you always specify 1 mm as stroke width, no matter how it's internally represented, but it will always be the same for all objects and the exact match will always occur, so it's reliable (if you also are in specifying values). The same is true if you copy-paste stroke attributes.
Regarding the px unit, it suffers of the same problems as all other units if you start stretching and scaling objects.

> [...] and also might have an interest in refined selection methods based on different stroke style properties
This approach ends up in tons of selection options. This wanted to be just a quick and handy one. A dialog is better suited for this kind of needs: the "Find" one is the right place and should be better developed in this way.
I was just reasoning on what "same stroke" could mean, in a general scope and simply expressed my thoughts. I'm still waiting for different interpretations.

With regard to the parent's attributes, it's a difficult aspect.
Let's say you select all 1 px width strokes but there are some that have a 2 px width but their parent have a 50% reduction. So all have a graphical width of 1 px. Would you select them all? If so, what if you redefine all as 1,5 px width? They are not going to look the same width as before.
And if you decide to select all 1 px width disregarding their parents' transforms, you'll end up having selected strokes that have different "visual" widths.
I can't say what's better to do with this. For my approach, I'd prefer the second scenario (disregarding parents' transforms), but it's just my taste.

[LucaDC (lucadc)]

I've tried with a group of 6 lines with the transform attribute scale(0.2,0.2) and stroke width 12 px. There is also a line outside the group (no transform) with stroke width 2.4 px (actually 2.4000001 px).
All lines show a 3 px width in the Fill and Stroke dialog (because there is a parent transform scale (1.25, 1.25)).

If I select the outside line and "Select Same Fill and Stroke", nothing else is selected.
If I enter the group, select one line and "Select Same Fill and Stroke", all the lines in the group _and_ the external line are selected.
If I ungroup the group with the Optimized transformation option, all its lines get 2.4000001 px width, and this explains the rounding discrepancies.
If I ungroup the group with the Preserved transformation option, all lines keep their transform attribute and stroke width but all always get selected (toghether with the one without the transform attribute).

So the function seems to work, it just doesn't (correctly) enter groups from the outside.
It takes into considerations all transforms, as the Fill and Stroke dialog does when exposing the "visual" width: to be honest, I hadn't noticed this before, so my speculations on parents' attributes in the last post were simply wrong (they were based on the XML Find and Replace experience).

[su_v (suv-lp)]

> I was just reasoning on what "same stroke" could mean (…)

Parent transforms are not the only transforms which affect the computed stroke width btw. What would you expect to be selected by "Select Same Fill and Stroke" in the attached sample file? Note: the width of each object in 'Fill & Stroke > Stroke style' shows the same "precise" value of 10px.

> If so, what if you redefine all as 1,5 px width? They are
> not going to look the same width as before.

Please test with the attached sample file: select all objects (e.g. with 'Select same > Fill color'), and change the stroke style for the selection from 10px to e.g. 5px (using 'Fill & Stroke > Stroke style > Width'): the objects will visually all appear to use the same new stroke width (5px), but selecting by 'Select Same Fill and Stroke' will again fail to find them all.

This inconsistency (show and edit computed value for the stroke width, but don't select based on it) is difficult to explain to users (there is no indication in the GUI which could help to understand the different resulting selection sets) and can create confusion. On the other hand there will be other use cases where selecting based on the actual stroke width stored in the style attribute of the individual object, independent from any parent or object transformations, is required - be it fuzzy (allowing a tolerance) or not.

<opinion>
Personally, I'm not sure if selecting based on stroke width belongs into a single sub-menu item which cannot offer additional search criteria or options. IMHO such a feature calls for a separate tool (e.g. 'Smart select' as described in bug #171685), now that the focus in the refactored 'Edit > Find…' dialog has shifted to a 'Search & Replace' tool.

The discussion about selecting based on stroke width possibly ought to move to bug #831012 - this report (bug #170378) is specifically about selecting by color, which is easier to be added as predefined search menu item.
</opinion>

[LucaDC (lucadc)]

@~suv: I'll soon take a look at your file. In the meantime, I was going to post mine where everything seems to work.

This discussion is not about "same color" selection: in the first post there are other options reported from Illustrator. It's more about the "select same..." topic. I feel that considering only the color would be too restrictive.
And my proposal is to take into account not each single attribute alone, but all altogether when speaking about "same stroke". So I agree with you that the "same width" option is of little interest if taken alone.

I was wondering if, when inside a group, it's correct to select also objects outside the group. I feel that restricting the search inside the group could be more expected from the user.

[LucaDC (lucadc)]

@~suv, you've made an horrible enough example :)
I see that the search doesn't work over layers (is it because they are managed as groups?).
Also, the two bottom right shapes are not selected with the others on the same layer because their transform attributes introduce rounding differences not shown in the "Fill and Stroke" dialog. My test case was much simpler, indeed. I admit that the PDFs you start from are much worse than mine ;)

Anyway, I wouldn't mind if the selection doesn't work here because there are so many heterogeneous objects (also if visually so much similar).
I'd move the problem into flatting the transform properties (is it possible? I don't know how to do), then selecting all inside a given tolerance (with the option we spoke about before) and finally really applying the same attributes to all, if this is the desired result. Personally I'd prefer not having all objects selected so I could spot unwanted transform attributes and get rid of them.
I agree that working with such files is legitimate, but I don't think they cover a big percentage of use cases to justify systematically loosing the matching criteria for everyone. Anyway, the tolerance settable to 0,0 should solve all this problems. Please, don't hesitate to correct me if I'm wrong.

In my opinion, the selection through layers should be added.

[su_v (suv-lp)]

> I see that the search doesn't work over layers (is it because they are managed as groups?).

'Select Same > …' does work across layers (at least in my earlier tests with a "normal" simple multi-layered SVG document): AFAICT the issue here is the difference between computed stroke width and the value stored in each object's 'style' attribute:

The SVG file is actually based on a PDF file (with the upper half being the original content, and the lower half added on a new layer without any transformation on the layer group): the original layer (named after the original PDF file) has the earlier mentioned transform attribute (scaling the content by 1.25 and flipping it vertically). This transform attribute corresponds to a unit conversion (pt -> px) and reverting a vertically flipped coordinate system (PDF uses a "normal" right-handed coordinate system, unlike SVG).

> the two bottom right shapes are not selected with the others

I was under the impression that it's not related to rounding issues at all, but due to object types which scale with a preserved transform attribute (e.g. ellipse/circle and star/polygon) -> see my question to John in comment #31.

> (…) (also if visually so much similar).

Based on my experience providing user support - that's what users get and understand: the visual appearance. Technical details explaining the underlying differences are very hard to convey to casual users - they expect that things work as they are visually presented to them in the GUI.

> I'd move the problem into flatting the transform properties (…)

I don't think you can force users to flatten preserved transforms if they want to select by stroke width: preserved transforms (e.g. on containers) do have many legitimate use cases in SVG, and sometimes simply cannot be flattened at all (consider clones for example). At least personally, I'd oppose this as a requisite for 'Select same' (note: I'm not against having such a command available in general).

Please test with attached modified file: 'Select same' does work across layers, and it selects based on the value in the objects' 'style attribute, not on the computed width (select the rectangle inside the red circle, and use 'Select same Fill and Stroke' fgrom the context menu).

[John Smith (john-smithi)]

r11154 committed - should fix transformed stroke width issue.

@suv,

> 1) What's the scope of the search: current layer, all layers (visible only, or hidden as well)?
Scope is all layers, visible only. Can be changed to include hidden easily if that is preferred ...

> 2) Is the search based on the 'style' attribute as stored in the SVG source (AFAIU that's how it works in the 'Find…' dialog)
Should now include transformations and be equivalent to the Fill and Stroke Style dialog "width" value.
Seems to work with the test files in comment #36/39 (note: the bottom right diamond object has computed width = 10.00001 - hence difference not seen in the Fill and Stroke dialog and not selected).

@LucaDC

Let me know if this works for your test cases too, i couldn't tell if it works for your test case (comment #37) or not.

[LucaDC (lucadc)]

Well, it was already working in my (too simple) test case.
Now I retried and realized that upon saving the file, some of the segments in the middle beveled rectangles have taken a slightly different width (12.00000095 and 2.4000001) so what was working just after creation of the objects, now doesn't work anymore. Oddly, the problem hasn't appeared in all other segments which share the same properties. I must have done something while trying and before saving.
Anyway, after a ctrl-c, shift-ctrl-v everything works as expected.

[su_v (suv-lp)]

> Scope is all layers, visible only. Can be changed to include
> hidden easily if that is preferred ...

Thanks. Based on a quick test (r11155), currently excluded are:
- hidden | locked layers
- hidden | locked objects

This is fine for me and makes sense as default for such a preset search (but needs to be documented ;-) )

[LucaDC (lucadc)]

What bout now not entering groups and what to do when inside a group?
With entering groups implemented, I think that limiting the scope to the current group (and its subgroups), when inside, could be useful and reasonable.
I'm not so sure, but I tend to think that entering groups and subgroups could be a good thing (as it's possible to do when selecting paths with the node tool). Otherwise, if you have many objects grouped in different groups, this feature could be severely limited if not almost useless.

[su_v (suv-lp)]

> I tend to think that entering groups and subgroups could be a good thing

Agreed - it works like this e.g. in 'Edit > Find…'.

Sample file with different nested groups and the same structure as sub-layers attached:
Layer 1: contains top-level objects as well as nested groups containing objects which have the same fill&stroke
Layer 2: same structure as Layer 1 created as sub-layers
Layer 3: duplicate of Layer 1 (top-level objects and nested groups groups with objects having the same fill&stroke)

--> 'Edit > Select Same…' finds objects on the current drawing (group) level (see layer indicator in the status bar) and those upwards in the same SVG branch which are not inside a different group container (branch). Layer and sub-layer groups OTOH are handled transparently (they are not 'selectable' objects in Inkscape).

--> 'Edit > Find…' searching e.g. for the fill color "fill:#ff8080" in 'Properties' does find all objects with the same color, regardless of whether they are inside (nested levels of) groups.

Probably related questions:
1) What would be the expected behavior if 'Select same' is used on a selection which doesn't define a style attribute at the SVG source level (e.g. a regular group)?
2) If groups are to be handled transparently, do they need to be excluded as valid "source" for 'Select Same…'? OTOH there will be use cases where attributes are solely defined as parent style attributes of container elements (SVG files hand-written or generated by other tools, e.g. matplotlib), as it is often used in SVG reference files (style inheritance being an important feature of SVG).

[John Smith (john-smithi)]

Here is a patch that does a recursive search (same as Find dialog ) inside "grouping objects".
Please test it if you can, it seems to work with the svg in comment #44, but i am not convinced it covers all cases.

Scope options (hidden objects & locked objects) are now picked up from the existing user preference "Behavior->Selecting". All layers is still assumed.

>1) What would be the expected behavior if 'Select same' is used on a selection which doesn't define a style attribute at the SVG source level (e.g. a regular group)?
It matches other objects that have the same style - "No paint", "Paint undefined", "No style" etc

[John Smith (john-smithi)]

Committed r11217 - Recursive search within grouped objects.

[tsingi (graham-rick)]

Someone else said this, so just to reiterate... AutoCAD has a quick select feature that is very similar to this. Extremely useful.