I'm using Inkscape 0.46, built Apr 1, 2008, on Windows XP SP2.

When I select an object (any object, be it rectangle, circle, text, whatever), go to the 'Fill and Stroke' toolpad and set the Opacity slider to 0%, the object disappears. Why?
And how do I get it back?

I cannot select it or see it anywhere. Even when I make sure that the object is on the top layer before I move the slider, the object cannot be selected again. I can move the slider down to 0.1% and the object is still selectable and functions normally, but the very moment that slider hits 0%, it's like the object is deleted.
Not even a drag selection with the mouse can catch it again.

Edit: The same thing happens when I set the Alpha on the color wheel or any of the other color selection modes. I assume it does the same thing as the Opacity slider.

Is this a bug in Inkscape?

It may or may not be intentional that you can't select an object when it's invisible. If you can, it will certainly make it easier to find them again. You might like to search the launchpad site and if there is no mention of it you could log a request.

Until then, you can press Tab to cycle your selection through all objects until it selects the invisible one.

Not able to reproduce problem in 0.45 on XP sp2. Could be a new bug in 0.46.

This was one of the things that I noticed right off the bat in v0.46. This behavior wasn't there in v0.45.

I swear that I reported this issue on Launchpad but I cannot find it. Either I never did or the report/question is gone. Richard Querin and I had a similar conversation a few weeks ago. I think he discovered it on his own for the very first time. I have gotten into the habit of setting the transparency to "1" so that I can still find an invisible entity on my canvas by windowing around something.

Until then, you can press Tab to cycle your selection through all objects until it selects the invisible one.

better way is to go in outline mod [View/Display mode/Otline] or just press Ctrl+KP_5 and then select object with node tool

heathenx wrote:I swear that I reported this issue on Launchpad but I cannot find it. Either I never did or the report/question is gone.

The only bug report on this that I can find is this one: bug 196453

Hmm...I don't remember seeing that bug report. I'm sure I tried to get involved in someway on Launchpad regarding this. Nevertheless, it looks like like the 0 transparency behavior was and is intentional.

Thanks for all your replies. I've reopened the bug and insisted that it is indeed a bug. I can't imagine how it could be anything else, why would you even want a functionality that lets you make an object unselectable and unmovable?

I also find it greatly counter-intuitive in terms of UI design that if you want your object to be fully transparent, you're supposed to set it to 1% opacity and not 0%, because that turns it into some sort of zombie object that is neither dead nor alive

The View-Outline mode can show me the object and I've found that you can select it again with a drag box, assuming you don't have too many other overlapping objects interfering nearby. But even when it's selected you can't do anything with it other than increase the opacity, you can't even move it. It is essentially a useless object.

In addition, making an object 0% opacity and putting it on the top layer makes it not just unclickable, but you can actually select other objects that are behind it on lower layers. Maybe there is a misunderstanding between programmers and artists here? (i.e. artists would think of a 'fully transparent object' as one that is invisible but still there, whereas programmers would think of the object as being truly gone in programming terms?)

I dont see how its a bug that you cant click to select something you cant see. If you've turned the fill off then click on the stroke, if you've turned off the stroke as well, then what are you trying to select? If you draw a zig zag with the pen tool, and dont set a stroke then clicking in the bit between the lines wont select the object, it'll select whatevers behind it. If you set the fill, then drag it down to 0 opacity so it looks exactly like the object with no fill set, then it behaves the same, wheres the bug in having consistant behaviour?

You can select the object with the arrow tool if you mouse around it. Would be nice to simply click the item. Does this happen in Linux as well? I might have to check.

It may or may not be a bug. I guess only the devs could tell us that...and since a couple of them here think that it may not be then I'll take it on board that it is a feature. However, I'm trying to understand this "feature". Making something 0 transparent almost locks the entity away from further use. A user wouldn't know that it exists in the document unless he uses outline mode in order to see it.

This has only really been a problem for me on my web page templates that I have designed in the past. I made a few things 0 transparent so that I could slice up the entire graphic. These were all drawn in v0.45. My workaround still remains the same, setting transparency to 1 in v0.46. 0 and 1 are so close that I cannot tell the difference anyway.

Can someone with some inside information explain why the current 0 transparency behavior makes sense to work this way?

If you can select things that are invisible then we'll have a bunch of bug reports that its selecting things that arent there and they cant select what their trying to. Seriously, where is the sense in you being able to click on a completely empty canvas, and it selecting something? Selection is a visual process, requiring someone to know theres an invisible thing there and then click on it is a seriously weird UI concept. If ya want to temporarily disable objects, then a layer you can turn off is a beetter way to approach it.

Well, if you think you would get into trouble by reverting to the behavior that we were accustomed to in 0.45 then I won't argue with you there. If 0.45 was the wrong way of doing things then I must confess that I got used to it. It made sense to me at the time so when it changed in 0.46 I can honestly say that it felt more like a bug than a change.

I do use layers when I use transparent items, by the way. I suppose that's a good habit to get into.

Thanks, Simarilius.

In the past when working with transparent objects I wished they were selectable, so this is my preference as a user.

Im also interested in hearing different opinions and reasoning behind it, two heads are better than one. There is sense in following the rule that if an object doesn't have a fill you can't click on the fill area to select it. But in that case you really don't have a fill assigned to it (a path that is only stroke). When an object is transparent it still can have a stroke or fill color assigned to it. The only difference is that alpha is of a different value. Im not totally convinced that 0 alpha should be discriminated like this. It may be silly to compare like this but it does give a different perspective: if alpha is 50% should the object then be 50% clickable?

I agree that a no-fill object shouldn't be selectable by clicking on its fill area (although I can tell you it was a bit confusing when I first started using Inkscape, I came from bitmap world), but as far as alpha goes I think it deserves a rethink. Maybe someone can come up with a holy grail solution here...

Like I said, we have a really simple rule, if its visible its selectable. If you set the opacity to 0 then theres nothing to see to click on to select. if the opacity is anything else then its visible, if only a little and so its selectable. hence the 'discrimination'

This sounds like an opportunity for a "user settable option", where usage does not have to follow logic or the developers idea of how it should be used - and yet where both strategies can win. The logic within the current code must be a simple test for "zero", and therefore a simple exception based on an "user setting" should be real easy to implement.

I wonder how other similar products, such as Illustrator or Corel, handle it.

Aha! I did post this issue on Launchpad. I didn't report it as a bug. I inquired about it in the Answers section. It was closed out due to no activity (most likely my inexperience with Launchpad). It was Question #30630. I posted this on 04-24-2008 and it was closed out on 05-10-08.

https://answers.launchpad.net/inkscape/+question/30630

For a second there I thought that I was loosing my mind.

Right now I think all this is silly. But one day in the near future, I will need to work with a 0 opacity object, and I will be very bothered by it.

-You can see how other programs handle this by using those free trials.

Well, it's not really even a big issue with me. If that's the way it's programmed to work then I can except it and move on to other things.

Eldonb46 wrote:The logic within the current code must be a simple test for "zero", and therefore a simple exception based on an "user setting" should be real easy to implement.

Please dont make assumptions on how easy something must be to implement. Things are invariably a LOT more complex than you think, so unless you can point me at a line in the source code with the 'simple test' that needs changing then try not to make statements like that. I just looked though and having tracked the selection code through 6 files I still hadnt got to the actual check for its opacity. Theres also obviously more than 1 path that the code takes as the drag select does pick it up. (which probably IS a bug according to the selection logic....)

microUgly wrote:I wonder how other similar products, such as Illustrator or Corel, handle it.

I have Adobe Illustrator CS2. 0% transparency items can be selected and moved around the canvas.

But Inkscape is better, right? Or is it just more legal?

Eldonb46 wrote:The logic within the current code must be a simple test for "zero", and therefore a simple exception based on an "user setting" should be real easy to implement.

I fully agree with this idea. The 0% opacity apparently means different things to different people all of a sudden, even though I haven't managed to find a single other drawing, painting or vector program that does the same thing.

I've been arguing with one of the developers about the twisted logic that has led to this change from 0.45 to 0.46 on the bug report: https://bugs.launchpad.net/inkscape/+bug/196453

I invite you to chime in on the board there.

Simarilius wrote:Please dont make assumptions on how easy something must be to implement. Things are invariably a LOT more complex than you think, ...
I just looked though and having tracked the selection code through 6 files I still hadnt got to the actual check for its opacity. Theres also obviously more than 1 path that the code takes as the drag select does pick it up.

Well someone managed to change this behavior from 0.45, so it must be possible to put a big selection block around it based on a Preference setting.
I understand how click-through objects can be very convenient when you do websplicing, but surely there must be a better way to implement this than to sacrifice good UI interaction for the rest of us who have no desire to hide objects.
If you really need to make objects click-through and non-click-through that often in your workflow and the "right-click properties and select hide" approach is too bothersome, why not put a 'hide' selection in the Fill and Stroke toolpad or something? (Preferably next to the Opacity slider instead of inside the Opacity slider). Or you could just do like we've done before: select no stroke and no fill. I see no reason to get Opacity mixed into this at all.

As you mention, the code is so spread out and complex that setting 0% opacity doesn't even make an object behave like it does when the 'hide' property is selected. Maybe because it was never meant to.

Simarilius wrote:Like I said, we have a really simple rule, if its visible its selectable. If you set the opacity to 0 then theres nothing to see to click on to select. if the opacity is anything else then its visible, if only a little and so its selectable. hence the 'discrimination'

Opacity is not the same as hiding. It's not even analogous in any way. The word 'opacity' means "the degree to which an object lets light pass through it". It's like glass, and if I polish glass really well so the maximum amount of light passes through it, I don't expect to suddenly be able to stick my hand through it as well. The opacity slider is supposed to adjust how much color is visible from underlying objects, not adjust how clickable my object is.
Opacity is the Alpha channel, which is just a color channel like any other (RGBA). If I set my Red channel to 0% that doesn't mean I can suddenly click red objects underneath because "it has ceased to exist on a red level".

The visibility of an object is already implemented as the 'hide' property in Inkscape and if you really want an object to be hidden you would set that property. You wouldn't expect Inkscape to change that property for you when all you're doing is adjusting a color channel.

Simarilius wrote:If you can select things that are invisible then we'll have a bunch of bug reports that its selecting things that arent there and they cant select what their trying to.

Every other application I can get my hands on and test this with works as expected (i.e. the 0.45 way). I seriously doubt these other developers get flooded with bug reports from users complaining that an object they put there themselves is actually selectable?
You can't escape the fact that the user created an object, changed the opacity to 0% and put it exactly where they are now clicking. How can this be a surprise?

Simarilius wrote:Seriously, where is the sense in you being able to click on a completely empty canvas, and it selecting something?

For the same reason I expect to be able to select a black object on a black background: Because something is there. And the user is immediately informed of this fact because a large selection box appears around the invisible object. There's really no big mystery here.

On the other hand, I find it magnitudes more frustrating that Inkscape now wrests control of my objects away from me when I change the opacity. If a user really wants to be able to click through an invisible object, the user will set the 'hide' property on it.

Simarilius wrote:

Eldonb46 wrote:The logic within the current code must be a simple test for "zero", and therefore a simple exception based on an "user setting" should be real easy to implement.

Please dont make assumptions on how easy something must be to implement. Things are invariably a LOT more complex than you think, so unless you can point me at a line in the source code with the 'simple test' that needs changing then try not to make statements like that. I just looked though and having tracked the selection code through 6 files I still hadn't got to the actual check for its opacity. There's also obviously more than 1 path that the code takes as the drag select does pick it up. (which probably IS a bug according to the selection logic....)

Simarilius wrote:Like I said, we have a <b>really simple rule</b>, if its visible its selectable. If you set the opacity to 0 then there's nothing to see to click on to select. if the opacity is anything else then its visible, if only a little and so its selectable. hence the 'discrimination'

Sorry, I assumed from your previous post that simple logic was used to make a deliberate change from an unwanted behavior in revision 45, to a desired behavior in revision 46, and that knowledge was still fresh. I also, understand the multiple logic paths used to implement its functions as you suggested in "drag select" and I suspect another for "Ctl-a select". If it helps, I will continue to Google the source for a possible (easy) logic insertions to implement a user selectable option.

Again, Sorry,
Eldon