Bug 311598 - To draw the markers of selection "+ /-" in grey / faded, unless is active.
Summary: To draw the markers of selection "+ /-" in grey / faded, unless is active.
Status: RESOLVED INTENTIONAL
Alias: None
Product: dolphin
Classification: Unclassified
Component: view-engine: general (show other bugs)
Version: 16.12.2
Platform: unspecified Other
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-12 23:02 UTC by Francesco Noacco
Modified: 2012-12-20 08:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Noacco 2012-12-12 23:02:03 UTC
For consistency intuitive, I suggest you draw the symbols in gray transparent until the pointer does not go above and is actually activated the function.
Thank you.

Reproducible: Always
Comment 1 Francesco Noacco 2012-12-12 23:04:22 UTC
*For more coherence intuitive, ...
Comment 2 Frank Reininghaus 2012-12-13 06:43:25 UTC
Thanks for the suggestion, but I don't get why gray transparent selection markers would be better. I think that would mostly make them harder to notice.

BTW, if you file many reports, please at least try to find the right component and use descriptive summaries. Thanks.
Comment 3 Francesco Noacco 2012-12-14 00:19:10 UTC
Note: I thought you were troublesome excessively long descriptions.

Translucent gray markers would be more than enough to realize the functions assigned and extremely evident when the mouse pointer enters the active function. As it is now is misleading and does not understand if you are selecting or opening a file. (let's also the pointer changes shape and complete the work, ironically speaking).
Comment 4 Christoph Feck 2012-12-17 23:49:04 UTC
This is actually bug 299328.
Comment 5 Frank Reininghaus 2012-12-18 06:40:33 UTC

*** This bug has been marked as a duplicate of bug 299328 ***
Comment 6 Francesco Noacco 2012-12-19 02:30:09 UTC
I am happy that also others give value to the small details (for me fundamental of the good sense). ..And as I, have had the determination and the patience to signal the inconvenient. :)
Comment 7 Francesco Noacco 2012-12-19 03:32:13 UTC
Oops, was escaped me the detail of the "glow" in the different versions (when the pointer activates the function).
I have made the signaling after having seen the "glow" (in the version 2.1 - 4.9.2 have again disappeared). Nevertheless this is not enough, I verify the same problem. For example as can understand a child (even more an elderly) that the symbol "+" green in reality doesn't make nothing as the symbol "-" red doesn't want to say that the file will be cancelled etc (for example if there is a single file, can easily give this impression!)
For this I believe that grey (or at least, faded) it means less than a strong or vivacious / grim color.
Thanks for the understanding (and also the signaling).
Comment 8 Francesco Noacco 2012-12-19 04:09:52 UTC
Memorial: During the pressure of the key Ctrl or Shift, the actual abearance (green / red color to the passage of the pointer) is functional.

I would appreciate to have (in option or default) the tender Area on the whole line (in the detailed sight). Does it require a new report? (..ok, knows already the answer)  :)
Comment 9 Frank Reininghaus 2012-12-19 09:47:25 UTC
(In reply to comment #8)
> I would appreciate to have (in option or default) the tender Area on the
> whole line (in the detailed sight). Does it require a new report? (..ok,
> knows already the answer)  :)

No new reports, thanks. Please re-read bug 311609 comment 8. I've spent quite a bit of time reading your reports and writing replies. After you insulted me, I'm no longer willing to do that.

*** This bug has been marked as a duplicate of bug 299328 ***
Comment 10 Francesco Noacco 2012-12-19 17:32:59 UTC
I hold an error to assign the tag "duplicated" since the bug 299328 ask for the functionality lost by the version 2.0 in then (I believe). (I don't have all the versions, but on Mandrivia11 with version 1.6.1 - 4.6.5, the "glow" it works, as also the pointer changes aspect / form.) But as I have already explained, it is not this the "desire in list."

As I have already tried to explain I have not wanted to offend, but I have made only a generic comparison.
And I have also specified that I don't abridge the free will. There are many other desires in list of which I have not received an answer.
Comment 11 Francesco Noacco 2012-12-19 18:10:12 UTC
To another person I have written how much it follows:
My thought however it is also this (and the good sense tells that each of us would involve equally): If I have a pair of shoes that hurt me, I don't go to the cobbler to point out the buttonholes / seams / etc they are hurt. I point out the points instead where to widen, or I ask a new pair. (because otherwise he/she will work a lot of time on a pair of small or unsuitable shoes).
I warmly hope to have explained the concept without having offended other people's sensibility.

I pray therefore, not to join my letter of request to others different.
Simply tell me: No, I don't like it.
Or ignored me, and I won't be offended me.
Comment 12 Frank Reininghaus 2012-12-19 18:56:18 UTC
OK, let's forget for a minute that you insulted me and considered it unnecessary to apologize.

(In reply to comment #10)
> There are many other desires in list of which I have not received an answer.

If you think that every wishlist report gets an answer some day: this is something that we really can't do. There are hundreds of reports and very little time to deal with them.

The reports that you filed are, unfortunately, often very hard to understand and look more like random ideas than clearly formulated feature requests. bugs.kde.org is unsuitable for such things. If you want to discuss such things, please use the forum. There might even be a forum in your language.

(In reply to comment #11)
> Simply tell me: No, I don't like it.

OK.

You are now kindly asked to not post further comments or new reports about random ideas. Even if you think that you are doing something useful if you do: this is not the case. You are wasting your own and our time here.

Even if a feature request is well written and everyone agrees that the feature makes sense, it's quite unlikely that it gets implemented soon simply because there are too few people working on the code. If a report is hard to understand, it's worse: you simply waste everyone's time (sorry if I repeat myself).
Comment 13 Francesco Noacco 2012-12-20 00:23:21 UTC
But if I don't remember badly, you have pointed out me to insert here, and in this way, the ideas.
I am fully aware that there is no need to add answers, or that there is not the material time to develop every thing. Nevertheless I believe (and I am still convinced) that can be always useful to have stared at her / written for being able him to make an image of together General (or for example to vaguely remember to have faced a matter similar to that in progress of development).
The trouble is that the interface doesn't allow the inspections, so the errors of writing remain also. :(
..Then we add the linguistic difficulty. (both we translate from the English to a third language) In fact certain things I have not understood her to 100%, even with the aid of the translator. However I have tried to be constructive and positive as pointed out by her and by the "Code of Conduct."
Hemm.. to say the truth, the ideas that I am writing exactly are not random, but they make party of what during the years I have always desired, but I have never dared to ask. :)
To be sincere I wonder me, (I would be curious to know) who and as has done to direct the transformation of kde from the version 3.5 to the 4.x.
Comment 14 Frank Reininghaus 2012-12-20 08:09:13 UTC
(In reply to comment #13)
> But if I don't remember badly, you have pointed out me to insert here, and
> in this way, the ideas.

I see, you are referring to bug 310835 comment 5. I see that this was a mistake, and I will never do that again.