GNOME Bugzilla – Bug 47948
Visual indication (transparency) for cut icons.
Last modified: 2010-09-19 19:13:52 UTC
When you cut a file in Nautilus, it does not become opaque. John Sullivan mentioned in #nautilus that Darin was going to do this, but never got around to it. Dekar thought that Arlo had specified a particular opacity level that should be used. * REPRODUCIBLE: Always * STEPS TO REPRODUCE: 1. Right-click on a desktop icon, and select "Cut" * ACTUAL RESULTS: The icon does not become opaque, as it would on Windows. Might this confuse Windows users, to wonder if the Cut operation failed? ------- Additional Comments From darin@bentspoon.com 2001-04-02 10:02:44 ---- A nice interface refinement that we considered. ------- Additional Comments From darin@bentspoon.com 2001-04-02 10:09:31 ---- *** Bug 47955 has been marked as a duplicate of this bug. *** ------- Additional Comments From darin@bentspoon.com 2001-04-02 10:09:53 ---- Bug 47955 has some alternate user interface suggestions, too. ------- Additional Comments From darin@bentspoon.com 2001-04-02 16:44:56 ---- This would be fun to implement, and not super-hard. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:19 -------
*** Bug 76637 has been marked as a duplicate of this bug. ***
*** Bug 90322 has been marked as a duplicate of this bug. ***
Please implement it! I've been na still am a windows user and always get confused. I have to think about it for a second "oh, right, nautilus doesn't show in any way, I just cut that file".
I've submitted a patch against this issue. If you're willing to try it out, see [1]. [1] http://mail.gnome.org/archives/nautilus-list/2005-June/msg00018.html
*** Bug 318313 has been marked as a duplicate of this bug. ***
*** Bug 506413 has been marked as a duplicate of this bug. ***
*** Bug 110283 has been marked as a duplicate of this bug. ***
We could use an effect like the one for dragged files introduced in bug #500084.
Please its been 7 years. Please fix this. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/194213
What is holding the developers back from fixing the *basic* things first? (no comment here, just a question) I.o.w.: why has it been so long?
*** Bug 523628 has been marked as a duplicate of this bug. ***
*** Bug 554773 has been marked as a duplicate of this bug. ***
Dear Cosimo Cecchi, If you know anyone who could help with completing this functionality, please let them know. Otherwise, could this be suggested for a Google Summer of Code project? What is needed is for 'Cut' items to have their icons dimmed (and a scissor emblem added probably). Why are 7+ year old bugs not prioritised?! Even just a thorough review would be better than nothing.
[In reply to Comment #13] > could this be suggested for a Google Summer of Code project? No, this is way too small for a GSoC project. > Why are 7+ year old bugs not prioritised?! Because it's unimportant, because there's much more important stuff, because there's no unlimited manpower. Because age does not say anything. Feel free to provide a patch.
Andre, so basic UI elements are not important for Gnome? You mean issues like mentioned in this slashdot post? http://developers.slashdot.org/article.pl?sid=09/03/14/1619227 That could imply that these basic UI elements were shoved aside for the good of the `bigger` things which are not in a good shape yet. If true, what rationale is that? No, this is no criticism, just free speculation of what could be the matter. I am not a programmer, just a user that sees this bug almost every day. On the other hand, Christian's patch (see #4) wasn't used nor did the method that Alexander Larsson described in his comment to this patch in 2005 lead to a solution at this point in time. One could come to concluding that there's a priority problem somewhere. Having said I am not a programmer, I *can* do testing. Just provide me with your patch(es) and I can provide feedback so we can ultimately fix this bug.
(In reply to comment #15) > Andre, so basic UI elements are not important for Gnome? I assume you do know that nobody ever stated this, hence nothing to answer here. > One could come to concluding that there's a priority problem somewhere. While I conclude that this ticket simply does not have a high priority. I know that many people and hackers here get demotivated by "hey! OMG! Filed 45 years ago and still not implemented! gnome has totally wrong priorities. Plz fix asap!!!!!" comments. This is still a bugtracker, not a forum, and whining about 7 years doesn't help at all getting this fixed or fixed faster. That's how open source works: Patches accepted.
Please give the appropriate place to communicate any further because you did imply that basic UI elements are not important with your comments in #14.
(In reply to comment #17) > Please give the appropriate place to communicate any further because you did > imply that basic UI elements are not important with your comments in #14. > > Why are 7+ year old bugs not prioritised?! > Because it's unimportant, I should have been more clear here. "Unimportant" refered to the age of the bug report, not to the bug itself. Sorry.
Please refer me to a person with gnome-authority that can explain why basic UI functionality can be less important than all other things gnome. Yes, I know this is not a forum but the lack of progress makes a lot clearer.
There is no "authority". This is open source. Patches welcome, but no need for repeating.
There was a patch. It was not used. I won't ask why. And if there is no authority who thinks BASIC desktop functionality is less important than everything else that runs on that desktop?
(In reply to comment #21) > There was a patch. It was not used. I won't ask why. Reasons are mentioned in the follow-ups to the email you refer to.
André, I couldn't find the reason in the email (seriously), was it a problem with the patch or just don't we want this feature? If the patch is just out of date I might be able to bring it up to date.
In could *guess* andre means: Alexander Larsson <alexl redhat com> writing at http://mail.gnome.org/archives/nautilus-list/2005-June/msg00044.html : Given discussions at guadec i think we're moving towards a shelf-based system instead, which solves this in a different way. That was 4 years ago. Is he still moving towards a shelf-based system instead? Does everybody think so? Did we change course? I.o.w.: what is the acceptable solution direction?
After googling a bit: does Alexander really mean the shelf/table view differences as mentioned at http://developer.gnome.org/projects/gup/hig/1.0/icons.html ? If so: what relevancy do they have for making an icon slightly opaque? I do think the acceptable solution direction is very important here.
I'm sorry but I don't really know what a shelf-based system is and how it would fit the dim files when cutting (?). Would anyone care to explain?
Marcus see the url I posted about shel/table views.
Gnome 2.28.1 did not show any changes w.r.t. this feature.
(In reply to comment #28) > Gnome 2.28.1 did not show any changes w.r.t. this feature. Of course, else this bug would be closed
The icons are opaque. Opaque is the antonym of transparent. — opaque (comparative more opaque, superlative most opaque) 1. neither reflecting nor emitting light . 2. allowing little light to pass through, not translucent or transparent. [...]
redhat does not care about 'upstream': https://bugzilla.redhat.com/show_bug.cgi?id=544532
GSOC?
(In reply to comment #31) > redhat does not care about 'upstream': > https://bugzilla.redhat.com/show_bug.cgi?id=544532 That statement is bullshit, and I think you even know (which makes it worse). The redhat report basically just says "Go upstream, as RedHat uses upstream and prefers to see work getting done upstream". If work is done by RedHat or by somebody else is a completely different issue, but your tone and aggressive style are not helping at all in pushing your request. So please refrain from polarizing and don't spam this report with useless comments just to take your personal frustration into public that your favorite issue is not being worked on. Otherwise your account might get disabled.
Of course we interpret stuff the worst way. Disabling my account will really help. The thing is that this not so big patch could be fixed by e.g. redhat so we could be done. Instead redhat disagrees that this issue has been open for too long and/or really needs a solution now. This is not frustration but just an explanation. Thanks for fixing this issue.
Udo, just do it. But don't waste everybody's time by adding comments here. Yes, disabling your account WILL help all other people subscribed to this report to not get useless bugmail anymore, triggered by your comments. Please understand what Bugzilla is, how it works, and the difference to a forum.
Too bad I had to step in. :-( Quit with the non-productive behaviour please. Attach patches, discuss how to solve it technically, etc. Anything else is not meant for Bugzilla. Bugzilla is NOT a forum.
*** Bug 617879 has been marked as a duplicate of this bug. ***
I have a branch for this that expands on Christian's patch, and is almost ready. Will attach a patch when I'm done.
Created attachment 161530 [details] [review] patch that was committed
This is what I committed to master. Cut highlight works in all the views, and is smart enough to remember the cut files even after you close the window, as long as there are no other cut-copy operations in the meantime. Closing as FIXED.
I think the contrast is too low. It is not very noticeable. Too little of a different. The contrast should be improved to be stronger, to make the icons more distinct.