Bug 154485 - do not zoom out maintenance buttons
Summary: do not zoom out maintenance buttons
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 154513 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-22 18:09 UTC by Maciej Pilichowski
Modified: 2008-02-26 20:34 UTC (History)
0 users

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 Maciej Pilichowski 2007-12-22 18:09:05 UTC
Version:            (using KDE KDE 3.97.0)
Installed from:    SuSE RPMs

Currently when you choose to zoom out the desktop to get back you have to click on "zoom in" button. Obvious. But the problem is "zoom in" button (and the rest of them) are also zoomed out so they are barely readable.
Comment 1 Chani 2007-12-23 11:16:02 UTC
*** Bug 154513 has been marked as a duplicate of this bug. ***
Comment 2 Chani 2007-12-23 11:18:32 UTC
I agree, this is silly behaviour. the only thing I'm unsure about is the best way to zoom in on the correct desktop.
Comment 3 Maciej Pilichowski 2007-12-23 13:18:57 UTC
The other report is rather not duplicate, so just in case:

zoom tool: maintain its position during zoom out/in 
 a) wrong analogy -- when using magnifying glass, it is not magnified itself nor moved 
 b) usability violation -- user has to move the mouse cursor half of the screen back and forth to get to _the same_ items (think: handicapped people) 
Comment 4 Aaron J. Seigo 2007-12-27 15:12:51 UTC
yes, it is a duplicate. please don't change bug reports like this. once they are triaged leave them that way. if you disagree comment on the BR but leave the triaging up to those doing the triage. less wasted effort results. thanks.

*** This bug has been marked as a duplicate of 154513 ***
Comment 5 Aaron J. Seigo 2007-12-27 15:14:42 UTC
erg. the *other* bug was duped to this one. *sigh* i hate bugzilla. still, yes, they are dupes.

anyways, as to the duped BR: this is fundamental misunderstanding of what the toolbox is and how it works. and no, moving to another widget hardly has an accessibility issue: if moving the pointer is a problem the user will likely be using other means to activate widgets in the first place. not that plasma is a11y compliant right now as we don't expose near enough internal information to the usability bus, but that's another matter.

anyways, all that probably needs to be done is having the ignore transformation flag set on the toolbox.
Comment 6 Maciej Pilichowski 2007-12-27 15:33:46 UTC
Aaron, who -- me? I didn't change anything, I just added comment from the other one -- the status was intact.
Comment 7 Dario Panico 2008-02-22 14:59:20 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Sebastian Sauer 2008-02-25 18:55:09 UTC
bug #154535 is imho somewhat related since there the request was, that there should be an option to disable the top-right desktop-toolbox to prevent it from popping up while moving with the mouse on it. Same is for sure valid for xinerama-setups (where to display the toolbox and how to keep it accessible?), for the kiosk-mode (I can already imagine the calls to the help-center cause "something change while just pressing something") or just for users/administrators who don't like to have the toolbox all the time visible/accessible.
Comment 9 Aaron J. Seigo 2008-02-25 21:56:27 UTC
> there should be an option to disable the top-right desktop-toolbox to prevent
> it from popping up while moving with the mouse on it

why, exactly? (other than "everything should be configurable")

> Same is for sure valid for xinerama-setups

in xinerama set ups you lose the fitts law nature of the corners, but i don't see a real issue here.

> for the kiosk-mode

this would be instrumenting the zoom buttons, then, not the toolbox.

> just for users/administrators who don't like to have the toolbox
> all the time visible/accessible

there is not enough information on the table to make this decision at this point.

btw, this was fixed by ruphy yesterday.
Comment 10 Sebastian Sauer 2008-02-26 15:58:23 UTC
> why, exactly? (other than "everything should be configurable")

Something goes wrong if things start to popup/fade in/blink/trade your soul with a donut/etc just cause you moved your mouse. Just moving the mouse should never lead to actions without an option to turn that behavior off.

Also why should somebody lose a corner that could be else used to e.g. activate a kwin-effect, to turn on the screensaver, to switch (in future) between plasma views, etc.

> in xinerama set ups you lose the fitts law nature of the corners, but i don't see a real issue here. 

Cause someone needs to be able to define at which output-medium the toolbox got displayed since they probably don't wanna have it e.g. at tv-out, at a monitor-station, small devices, presentation mode aka presenter view, not at montor #1 but at monitor #2, etc.

Guess one of the problems is, that there is just no information around what this thing is for and a "you will see" is hard to take cause "we already see" and what is visible so far did already lead to massive feedback and it's needed to deal with that feedback somehow and may it only to collect the points. To just say "nada, nada, I'll not listen and do what I like to do" misses the "it's all about the users" as well as the "be free" points. Hell, even Microsoft does listen (if you have enough money or are able to put pressure on them). What is done out of it, is written down on another piece of paper (and in the case of MS the result mostly sucks even more, heh).

>> for the kiosk-mode 
> this would be instrumenting the zoom buttons, then, not the toolbox. 

and a toolbox without any buttons/functionality makes no sense. Sometimes it's wanted to provide just _no_ functionality except starting and closing some programs.

> there is not enough information on the table to make this decision at this point. 

yeah, cause it's work on progress, as sayed on bug #154535 already, and there still stays a lot of time to s/WTF\?/WOW!/gi;

Well, it's not about decisions anyway. It's all about not wasting more time with this and to provide a way users can offer feedback somehow and somewhere as well as to let them know, that work is done there and the current state is only a temp one.
Comment 11 Aaron J. Seigo 2008-02-26 17:21:01 UTC
> Just moving the mouse should never lead to actions
> without an option to turn that behavior off.

of course, this happens in all sorts of places in our UI. hover interfaces are actually very nice: they are discoverable and ergonomic.

> lose a corner

you don't lose a corner. i've pointed out the obvious a few times, but it probably doesn't hurt to do it agian: it doesn't interfere with usage of that corner. it's not mutually exclusive to kwin, other windows, etc.

> needs to be able to define at which output-medium the toolbox got displayed 
> since they probably don't wanna have it e.g. at tv-out, at a monitor-station,
> small devices, presentation mode aka presenter view, not at montor #1 but at
> monitor #2, etc. 

and that's why i invented Containments in the first place. there is no "desktop", it's just a containment. for presentation, t.v., small form factors, etc you simply will NOT want to use the DefaultDesktop containment in the first place.

> no information around what this thing is for

yes, i know people would be far more happy if i spent the next N months writing documentation about all the technical internals, UI externals, etc. i wish i had that time too. unfortunately i have lots of code to write so people can enjoy plasma fully and then i can start writing all that great docu. in the meantime, it's a great zen exercise for the soul to see, not understand and be at peace. ;)

> lead to massive feedback

lots of people watch wrestling on t.v., but that doesn't make it a productive use of time. (though i understand it is fun =)

> I'll not listen and do what I like to do

you're crossing a line here, Sebastian. in the OTHER bug report that was about this which i close with WONTFIX where you are also active i specifically noted that i've heard and listened to the feedback. i really don't appreciate you assigning motives that i do not have and actions that i have not taken. thank you.

> even Microsoft does listen

ah, the "you're worse than even MICROSOFT" defense. lame.

> and a toolbox without any buttons/functionality makes no sense

when you approach a problem with a dogmatic solution in mind, you end missing the obvious path: when there are no tools in the toolbox, it would deactivate. pretty obvious, huh?

> provide a way users can offer feedback somehow

they've offered feedback. i've heard it. there is nothing that says that people have a right to unending time to speak on a matter. as you said, it's about not wasting time. so here i'm left with two options:

a) people respect that my time is as precious as theirs and stop wasting *my* time with repeating the same (often just plain wrong, see above) comments

b) i just stop listening to people because at least i respect that my time is precious.

i'd much rather not do (b) because that sucks for everyone (and there, i guess, goes your "you willfully don't listen" idea). there's some basic responsibility to be shown on the other side of this.

and that's the position i'll stick with unless someone turns up with a personal masseuse and a private jet for me. then i might clear some room in my schedule for them to whinge ;)
Comment 12 Maciej Pilichowski 2008-02-26 17:57:32 UTC
Aaron, I am just reassuring myself -- the status is FIXED, because the __report issue__ is fixed, right? Not the issue(s) in comments?

Comment 13 Dan Meltzer 2008-02-26 18:08:02 UTC
Well, Yes.

One Resolves a bug based on the issue the bug was created to fix, not based on whatever direction the comments attempt to derail it in.
Comment 14 Aaron J. Seigo 2008-02-26 18:08:56 UTC
Maciej: yes. i triaged the bug as reported, as Dan noted =)
Comment 15 Sebastian Sauer 2008-02-26 20:34:50 UTC
> and that's why i invented Containments in the first place. there
> is no "desktop", it's just a containment.

okeli, added and extended  http://techbase.kde.org/index.php?title=Projects/Plasma/Architecture so ppl like me don't keep on to wonder/ask :)
 
>> I'll not listen and do what I like to do 
> you're crossing a line here [...] WONTFIX

Well, it is how it feels and why I put it in "" for that reason. Really, I am sure complaining will not go away till there is an open report for it with some details like "this is work in progress and will change" and "in the meantime apply that patch to use trunk without those annoying feature that is not done yet".
 
>> even Microsoft does listen 
> ah, the "you're worse than even MICROSOFT" defense. lame. 

Nah, no defense but an experience we continue to learn with MS. First they run for OOXML-standard, then for open there old binary formats and now even, the 4th time, a promise to coperate. Guess we are on the win there :)

Well, I am specially interested to see if they got it managed to sell enough votes for there own "standard". We will see soon ;)
 
>> provide a way users can offer feedback somehow 
> they've offered feedback. i've heard it.

It's not only about you. An open report will also show up once somebody else likes to create yet one more report about this while I am not that sure that closed reports are taken into account at all (e.g. myself never looks for closed except I search for regressions). Result: hopefully less dups.

Also that way ppl are able to see, that there is progress on that (no wonder you need to repeat yourself since the replies are rendered useless in a closed report imho).

> stop wasting *my* time with repeating the same

y, one more reason to try to have one open report for that issue and point everybody who asks to the content in there. That's why I added the patch and the link btw.

> just stop listening to people because at least i respect that my time is precious. 

np, let others handle that report. May an idea to create a bugreport against bugzilla and asking for a per-user "ignore reports: ___" function or something like this. Well, maybe assigning the report to !=panel but /dev/null would already help.