- My corners are already occupied (Possible solution: user moves the toolbox)
- It disturbs the feng shui of my wallpaper (Research: less intrusive default appearance ... improved themability?)
- I don't have a use for it (Deferred: revisit when zooming is complete)
Past pain points that have been fixed include:
- It "spasms" if you mouse over it the wrong way
- Innactive state is too bright
- It animates out when not intentionally triggered (e.g. when closing a maximized window)
- It shrinks when I zoom out
- When I zoom out on the second screen, the toolbox is no longer visible, leaving me without a way to get back
If I'm missing pain points for the toolbox, put them in the comments section here and I'll add them to the list.
I really need a tool for managing this. Something collaborative, a bit more structured than a wiki but as easy to use. Bugzilla is way too clunky and defect reporting oriented (not to mention that as a user, I dread being confronted with a bugzilla report form =/). Something like review-board, but for enumerating feature sets, recording pain- and plus-points, gathering votes on them, noting possible avenues of research, recording cures for the pain points as they happens ... Right now I'm keeping lists pretty much manually and as a user I would have no idea where to effectively drop my pain point.
32 comments:
Thank you. Much better :)
How about: It looks like the gnome logo? ;)
Whine point:
I should be free to do whatever I want with my desktop; there shouldn't be anything like Kicker which I can't remove [in a simple way].
Pain point:
I have two screens, let's call them 1 (left) and 2 (right). The toolbox appears on both. The zoom tool seems to only affect one screen, so that makes sense.
However, there is another problem. First I activate the toolbox by moving the mouse pointer to the top-right corner of screen 1. Now, if I move the pointer to the right (to screen 2), the toolbox doesn't deactivate.
It's not a huge problem, but it does annoy you after awhile.
Artistic pain point:
Like before, I activate the toolbox on screen 1. There's an nice animation, the buttons slide from the top-right corner to their intentioned position on screen 1. However, you can see a small part of the buttons on screen 2 (top-left corner) as they slide. Not very nice.
The strange thing is, this had been "fixed" in the past. In some SVN revisions, this "bug" didn't exist - only to return in later revisions.
My guess of a possible fix: the containment on screen 2 (in my case) should have a higher z-order than the one on screen 1. Close?
Thank's for the list.
Since you wanted plus points as well:
* since the box has now become so unobtrusive, it no longer disturbs the feng-shui of my wallpaper
* the toolbox is still useful in it's current state, since I can add widgets (to the taskbar; see pain point) without having to find a bit of desktop space to right-click on first
now a pain point:
* when clicking "add new widget", make the desktop go into "widget mode" (or whatever it's called that ctrl+F12 does) so that I can drop them on the desktop without needing to clean it up first
On an unrelated note:
Is a two-row display for the system tray planned, like in KDE3 when the icons were 48px small?
Hi Aaron,
If I anderstand correctly the main goal of this toolbox is for system that don't have a right click.
If i'm correct, the toolbox should offer more option (like change my wallpaper)
btw, as I lock my desktop so I wont move a widgets around in a mistake, so the toolbox become useless (no action possible). This make sense, at least to me.
But as it become useless, why not remove it completly.
I know you want it to stay there for feature that will be coded in a near futur. Anyway there are many people that would love to be able to remove it.
You dont want to create a work around to let the code clean, which is fine. But actually I think that the toolbox is already a work around of the early day. Now we have a standard way to put widget on the destop that is called plasmoid. Why not make this toolbox a plasmoid.
pros:
- the toolbox will be themable
- user will be able to put it where they want,
- user will be able remove it (as we, users, seam to want this :D)
- no work around
- code cleaner ( the toolbox is not a part of plasma)
cons: I'll let you find these.
this is just a simple idea from a long time kde user. I'm not even sure that it make sense, as I did'nt read the code just yet
yours,
Sebastien
@anonymous: "Thank you. Much better :)"
glad you like it. i'm not.. really.. sure.. what changed as this is the process i've been stumping for from the start =)
@anonymous: "It looks like the gnome logo?"
ehehe.. it's a CASHEW i tell you, a CASHEW! ;)
@hans:
"Now, if I move the pointer to the right (to screen 2), the toolbox doesn't deactivate."
hover events are a bit messed up in QGV right now. they are better than they were, but there are still bugs. we're working through them.
"you can see a small part of the buttons on screen 2 (top-left corner) as they slide."
yes, this was reintroduced by a well meaning but errant commit. i'll need to track it down, see what it was really trying to fix and then deal with it there.
@Sokrates: "since I can add widgets"
we also have Lock Widgets in there now as well.. more tools to join the party as well.
'make the desktop go into "widget mode"'
that's a really interesting idea. especially now that we have an Add Widgets on the panel containments... hmm.. i'll play around with this at some point if no one else does.
@Sébastien: "like change my wallpaper"
yes, that isn't there right now because we're still working on having a generic containment configuration dialog. we decided to "grow out" the DefaultDesktop dialog first, and then generalize based on that. once we have that in place, then the "Configure ..." tool will appear.
"so the toolbox become useless (no action possible)"
these days it also has Lock/Unlock in the toolbox.
"will be coded in a near futur"
in trunk, the future is now =)
"Why not make this toolbox a plasmoid."
because it violates the design principles of a Plasma::Applet entirely. it would require special casing in a few places in the code to work properly and i'm really, really, really hesitant to go the "Just make it a plasmoid" route because of that.
A different way to discuss this would be good. But about:
"I don't have a use for it (Deferred: revisit when zooming is complete)"
It seems to me, that for a zooming UI to really work, it would need shortcut keys and/or mouse gestures to really provide a smooth transition between tasks, etc. In that case, the toolbox is still unnecessary (except for discoverability).
For instance, I'm using KDE 4.0.1 on my EeePC (800x480 screen). I removed the panel, because I can just use alt-tab to switch windows, and alt-F2 to run a program, and I have the clock on the desktop. The panel did nothing for me other than render portions of my screen unusable.
"It disturbs the feng shui of my wallpaper (Research: less intrusive default appearance ... improved themability?)"
Since this is a matter of research I'll refrain from final judgement but the two points you bring up as possible solutions are problematic:
1. No matter how "less intrusive" the toolbox will be, there will always be color combinations which will actually be intrusive to the user unless Plasma comes with a recommended color scheme for wallpapers. Plus, if it's too "less intrusive" people might actually miss it place if it's not pointed out to them in the first (e.g. a Plasma tutorial at first login).
2. Making the toolbox more themeable sounds like offloading the aesthetic problems with the toolbox on the user himself by making him responsible for hunting down a theme which will match his chosen background. Or will automatically adapt to the background color?
I'm still not terribly convinced by the arguments for leaving out a "hide" button (and yes, I've read and understood your previous blog post) especially when considering that you can remove it once the toolbox reaches the desired status. Your arguments that you may be unable to remove the "hide" funtionality due to people getting used to it once introduced sounds a bit, well, silly when considering that you don't seem to have qualms forcing your design philosophy on people in this particular case.
Here's a simple solution - get rid of the thing. It IS useless.
If toolbox is there for systems where you can't right click, then surely for systems where you can right click you should be able to right click on the desktop and disable it.
Unless it is needed in all scenarios why is it mandatory feature? To use a car analogy: A pink fairy may be cute but I don't want one stuck to the dashboard of my Ferrari :)
Maybe a way to improve the situation, would be to define clearly what this toolbox is supposed to do.
When everybody will _understand_ and agree on this, it will be far easier to discuss.
For example, yesterday you explained that a use case of this toolbox is for touchscreen or system without a right click. Now, that he understand this, Sebastien proposes an improvement : add the possibility to change wallpaper.
See what I mean ?
You state that with the future zooming capabilities, everybody will like this toolbox.
Honestly, I often read your blog (and the rest of planetkde), and I'm not completely sure what it is all about :\. When I read
http://techbase.kde.org/index.php?title=Projects/Plasma/ZUI
the only mockup available looks like what compiz can do. Moreover, it does not match what I understand of that paragraph "Description (initial idea)".
So, in the name of the community, I ask our worshipped guru : may you share your vision with us ?
This might also have the unexpected effect of attracting more worshippers to help you in your quest of Freedom
Amen
Hi!
Please excuse my chiming in with the "remove it" crowd, and please don't be shocked if you read the reason:
I don't use widgets.
That's right. I've been a Mac OS X user for something like four years now (and a KDE user since 1.0) and I never used a single dashboard widget. Ok, I used the calculator sometimes, until I figured out that a second, non-widget calculator is also shipped with Mac OS. The same goes for Superkaramba, KDE, Yahoo, Google or whatever Widgets, Gadgets and so forth. I don't know why most people seem to be so obsessed with checking weather forecasts, stock quotes, fancy clocks of all kinds, but I'm not one of them.
I understand that Plasma is one of the selling points for KDE4, but not the only one. For me, the attraction lies more in Oxygen (which looks far better than any previous KDE style), cross-platform capabilities and stuff like Phonon or Solid. Just give me a working taskbar/tray combo and a configurable desktop background and I'm a happy camper.
So, to sum it up: I don't use widgets, much less groups of widgets so large that I need to zoom in and out between them because they won't fit in 2560*1024px. You might say that this could change at some point in the future and that widgets will replace traditional windowed apps and what not. But frankly, I just don't see this happening in the next five years. And until then, zooming and related features are pretty useless to me.
BTW: this discussion reminds me of a talk by Keith Packard about X.org I saw recently. He kept on and on about the cool multiscreen features they implemented and once or twice he asked his audience how many of them were working on one screen only. More than half of the hands went up. He was apparently surprised and tried to make fun of them, but still it was clear that most of his great improvements were simply missing the point, i.e. the intended audience.
So... I guess what I'm trying to say is... It takes all kinds, people use software in different ways, and if they can't do it, they might as well use different software.
But I don't want to end my post with a subliminal threat to switch to Gnome or Mac OS fulltime. So let's try it like this: Maybe, maybe in some distant future, I, too, will see the light and brilliance of all this and add all kinds of crazy and colorful widgets to my desktop, just to brigthen my day. But please let me do this in my own time, by my own choosing.
Another issue (or solution for those who do not like it): if you put your panel on top of the screen (probably same if you put it on right side), panel overlaps the toolbox, making it hidden/useless. ;-)
lure has been faster then me...
however: please don't remove it, since i am using widgets (and want to write one some day myself :D).
@Anonymous
>I don't use widgets.
You do if you are using KDE 4. The start menu(s), taskbar and the desktop are all "widgets".
You are hampered by your missconception that plasmoids are limited to the traditional "thingy on desktop" widgets you have experienced. But Plasma is more powerfull than those traditional systems, as shown by the above examples.
And by being the desktopsystem rather than a add-on, you get a whole different level of integration and corresponding possibilities.
simple question. i have a right mouse button so why do i need the toolbox?
In a follow up to Sokraates' pain point, perhaps having the "Show Widgets" (or dashboard or whatever it is that Ctrl+F12 does) added into the toolbox would be help that feature's discoverability. The only way I found out about it is by following this blog and comments on the dot.
Also, I notice you've been taking a lot of flak from others. Try not to let you down at least a few of us users really appreciate what you and the other KDE developers are doing. That includes the transparency available here and on the other blogs, the dot and the planet. In closing, thanks.
Jonathan
P.S., Not that you probably have any control over it, but the Name/URL option for posting a comment doesn't seem to be working.
My pain point: the desktop toolbox doesn't close if the mouse leaves the toolbox area without hovering over the toolbox on the way out.
I have the Compiz's Scale plugin bound to the top-right corner of the screen, and the toolbox is activated en route to that corner; however, the toolbox isn't deactivated once the mouse leaves the toolbox area (maybe because of Scale's screen grab?). The only way to deactivate the toolbox is to mouse over some part of it again after exiting Scale mode, then mousing out without touching the top-right corner.
The same thing happens with KWin's Present Windows plugin when it's bound to the top-right corner.
My personal pain point - I hate being called an idiot every time I read your blog for wanting my desktop to look the way I want it to look instead of the way a certain developer thinks it should look. ;)
That said, it has certainly improved a lot and I think it will be acceptable once I can move it around freely to place it where I want it to be.
Can I ask why this was placed on the desktop to begin with? To me, it seems like it would make perfect sense and be much less intrusive to place it on the panel, maybe right next to the clock. AFAICT, this is just part of your personal vision of the way the desktop should work by being more plasmoid-centric and less file-centric? I'm certainly open to that vision, but skeptical at the same time - there's a reason the current system is so popular, after all.
"I hate being called an idiot"
and i haven't called you (or anyone else) one.
"instead of the way a certain developer thinks it should look."
that's not what is going on here.
"Can I ask why this was placed on the desktop to begin with?"
because it controls that containment.
"To me, it seems like it would make perfect sense and be much less intrusive to place it on the panel, maybe right next to the clock."
except that it doesn't control the panel containment. and guess what? the panel containment is slated to get its own toolbox as well.
"AFAICT, this is just part of your personal vision of the way the desktop should work by being more plasmoid-centric and less file-centric?"
the concept of the desktop being more than just a place for icons and the toolbox are not derived one from the other. in fact, the are completely orthogonal.
"I hate being called an idiot"
and i haven't called you (or anyone else) one.
well, no, not directly. that's just the message i'm getting from your arguments and tone about this issue - "just trust me, i know what i'm doing. you aren't seeing the big picture, and i am". Your arguments are probably correct, but it still sounds as though you're saying, "bug off you idiot, i'm smarter than you". I think that's why there's been a lot of negative feedback on the issue, because of that tone that's been taken.
Again, let me stress that I think your arguments are probably correct - but they tend to sound quite dismissive of regular user's opinions in the process.
In the end, this whole argument isn't going to matter much. It's pretty much guaranteed that the major distributions will allow users to remove it in their downstream code if there's a big outcry for the ability. And honestly, that's probably where all these people complaining should go lobby.
"Can I ask why this was placed on the desktop to begin with?"
because it controls that containment.
So what? The menu's that are on the panel don't have anything to do with the panel. I view the panel as an all-purpose control area, where you can put anything that you want to have visible to users at all times. It would leave the desktop symmetrical and look better IMHO.
and guess what? the panel containment is slated to get its own toolbox as well.
Ahh, now that makes sense. I hadn't heard about that. I'm assuming combining them together would probably cause it all to get too messy.
> "just trust me, i know what i'm doing.
> you aren't seeing the big picture, and i
> am". Your arguments are probably
> correct, but it still sounds as though
> you're saying, "bug off you idiot, i'm
> smarter than you".
so give me a phrase that means "i've got it handled, give me time; i realize you don't have all the puzzle pieces in hand so i don't expect you to fully grok it yet" which doesn't wound your ego and i'll happily use it.
it's really the only accurate description of the situation. as i've suggested elsewhere recently, i could just lie instead and say something like, "oh yeah, that's a great idea. we'll get right on that." whenever anyone suggests anything. would you prefer that? (that's a serious question, not sarcasm)
(i don't know how i'd manage that with patch submissions, though. one more reason to love decentralized SCM tools like git, maybe, since i could just ignore the less appropriate submissions?)
> So what? The menu's that are on the
> panel don't have anything to do with
> the panel.
when you select "Panel Settings" from the panel context menu, do you expect to get the desktop wallpaper configuration dialog? or vice versa?
the toolbox contains entries that are rather specific to a given Containment.
> I hadn't heard about that.
there are many pieces of the puzzle that are not common knowledge unless you really pay attention to plasma development conversation but which will become rather obvious as the code goes in.
> I'm
> assuming combining them together would
> probably cause it all to get too
> messy.
yes, it makes zoom control and other features for which the containment is the context impossible to present clearly.
and what happens when you end up with 12 containments (a couple panels, two screens plus one per project/activity grouping? 12 will be really easy to achieve) .. can you imagine the number of entries?
I'm comment #40 on http://bugs.kde.org/show_bug.cgi?id=154535 , and comment #41 put me far more at ease about the thing than this blog post. My entire opinion on the thing is this: "I'm fine with the thing defaulting to 'on' but give me a dead easy way to make it go away." I'm quite happy happy to let people who spend a lot of time thinking of these things come up with the 'vision' of how to do this. As I said, default it to 'on'--- Just let me make it go away, in a very simple way, because I curse the thing at least twice a day. (or I'll keep posting in rhyme. :p )
"I really need a tool for managing this"
Bugzilla! :)
"Bugzilla is way too clunky and defect reporting oriented"
eh, ok. probably my own habit of trying to limit the webareas I've to deal with / monitor on a regular base to techbase and bko only.
btw, afaik moz/ff, OOo, webkit, etc. are all using Bugzilla for review and "generic issue collection". The advantage here isn't only for the devel, but also for the user(s) since it's all at one central place.
Just a detail: in the future, I have no doubt that the menubar-on-top will again become a visible (and working) option.
Ina panel -- because with a widescreen there would be wastage if only the menu was on top.
And this will somehow conflict with the toolbox -- if it is moveable, a user will be able to fix it -- but perhaps some automoving will be in order.
Or simple the panel-with-menu is another containment and they never overlap....
To all the "remove it" voters I can only comment on the reality of what you are asking for. You want something you don't use, you don't need, and that doesn't interfere with what you are doing to go away. Because of this you really come off as sounding silly or even worse perhaps. You are complaining about something that doesn't affect you but something that just rubs your the wrong way. "It upsets my perfectly blank and empty desktop" argument is just bunk. You aren't using KDE if you just sit around looking at the pretty or blank desktop you desire. That's right, for this toolbox to do anything that is disagreeable you have to go out of your way to make that so.
Aaron you're doing a great job. Your ideas and goals for plasma are going in the right direction and bringing KDE to forefront of user interfaces even if some people just want a blue desktop with a panel. ;) Keep up the great work!
I don't own any touchscreen, but this is what i wanted to ask:
As a bugfix you introduced correct "border crossing" some the last days. That means you need to drive the mouse over a certain area. Wouldn't it be better to do this by click, especially for those thouchscreenowners? That would also make the people not feel so disturbed. Or make it optional, so they can chose how they want to activate.
Another "Feng Shui" thing could be making it even more transparent. On mouseover give it more opacity/color, on click-> show menu. You also could add a little "pulse"-effect, when e.g. all windows are minimized, or give it a timer (any 10 min. a short pulse - configurable).
This way the users who don't like it still can access it by time (to see the advances) but don't get disturbed, and the "Plasma-Beginners" get informed about the possibility.
I know, that's a try for a solution (which you probably don't like), but thaty's what I had in mind...
BTW: I don't feel so much disturbed that i want to turn it off completely. I just like kde4 and love to watch the daily advanes :)
I've just read the comments here and in the bug report regarding zooming the toolbox and I find myself confirmed that the toolbox is _the_ topic to provoke emotional discussions.
While I'm one of the persons who have emotional issues with the toolbox, I've learned from my job that one should _think_ before speaking and keep your opinion to yourself if it wouldn't prove productive in any other way than to vent your issues.
So I've kept my mouth shut and my fingers restrained and I've seen the toolbox evolve, improve and become something useful.
Therefore, Aaron, keep up the good work and keep the improvements coming.
Regarding my question on the icons in the system tray: I've installed KDE 4.0.2 on my Kubuntu Hardy laptop and after changing the height of the taskbar (actually I was only scanning the options and then set it back to "normal") the icons in the system tray were now displayed in two rows. Strike one more (non-toolbox) pain point.
http://en.wikipedia.org/wiki/Category:Free_project_management_software
Personally i like Trac.
> "It upsets my perfectly blank
> and empty desktop" argument is
> just bunk. You aren't using KDE
> if you just sit around looking
> at the pretty or blank desktop
> you desire.
Remember, many people are using linux because of freedom: they can do whatever they want with their desktops. And many people prefer KDE over Gnome for this reason.
What about many other config options that are stupid and rarely usefull in you personal opinion ? Have you ever used focus-follow-mouse thing ? Or may be you think that making all icons on the panel black-and-white is stupid and useless ? Lets remove that options ! Hey, now you got that gnome way !
I've always thought that the ability to alter things is one of the most important idea in FLOSS (and this is one of the four freedom that GPL grants for you). But adding configuration options we are helping people who can't code to use this freedom !
I actually think the toolbox is very pretty and I love the animation, so if it had a purpose I'd love to have it just for the sake of eye candy. The zooming thing doesn't make sense to me at the moment, but I'll hold off any judgment until its finished or further along.
That being said, it does annoy me that it conflicts with the compiz/beryl corner features. I would actually like to see a corner toolbox for controlling xgl/aiglx/expose effects, although I understand that there is a vision for Plasma that I am ignorant of.
OK a few day late in the game, but thought I'd add a few points. I'll skip the aesthetic ones, even though they do 'pain' me, since they've been done. I also understand that you are aware of the bug where if you move your mouse from the toolbox directly to a window, the toolbox doesn't pull back in. This also sometimes occures after zooming in from a zoomed out state.
Right now onto a couple of 'new' points. Mainly the fact that the menu targets that pop up are hard to hit. No so noticable with a mouse perhaps, but moreso if you're on a laptop some kind of less than ideal pointing mechanism.
Especially if you've zoomed out twice on a small laptop screen, then the zoom in button is a) unreadably so you have to know where it is and b) only a few pixels tall. Not a showstopper admittedly, but certainly a usability annoyance.
Secondly why are the buttons not closer to where the mouse pointer ends up when activating the toolbox? At the risk of quoting Fitts law (which I promised myself I would never do), why not make the whole toolbox area clickable, and extend the buttons to take up the full space which the toolbox occupies anyway. Now one has to move ones pointer up to the corend to activate the toolbox and then back down to the, relativly small, buttons. One idea would be to divide the quarter cricle that pops out into radial pie slices and make each slice a button. Top slice adds widgets, middle slice zooms in, bottom slice zooms out etc.
Post a Comment