Bug 154535

this is intentional.

Aaron, you mean there will be now way of getting rid of this utility?

I don't want to make anybody angry, I can see plasma is cool and everything, but did usability issues were completely dropped while designing this software? For now I see a new star of coolness, yes, everything is peachy, but in usability area... well. 

You don't provide any actual data or at least good arguments.

Just calling something you'd like to see "usability" makes it any more a valid.

Take a look at KMenu, taskbar, desktopview, clock, systray, panels (I am using KDE3) -- all those are configurable. You can use them, you can turn them off. You can place them wherever you want. I don't know how about other KDE users but I am used to such degree of my freedom.

What is the point of showing digital clock if you don't use it. Or you have another means of use it (for example -- show on demand, e.g. keyboard shortcut).

Now, where this zoom tool fits in? You cannot turn it off -- no matter how you use it and no matter if you use it at all. This is usability concern and I think valid one.

This widget does more harm than good -- each time I close the app I get animations of button, which I didn't want, not mentioning that I don't use this tool at all.

Why to have a tool in front which is not used?

I also would like the possibilty to remove that widget:

- I would rather trigger one of KWin's effects with that screen edge
- I don't need that widget, and it just clutters the desktop for me

+1 to add an option to remove this widget. I would even consider this to be the default, as you can already add widgets by right clicking the desktop. It just annoys me.

> ------- +1 to add an option to remove this widget. I would even consider
> this to be the default, as you can already add widgets by right clicking
> the desktop. It just annoys me.


some devices have no right-click. and some people won't think to try the 
right-click menu. so the toolbox *will* be on by default at the very least.

How does this sound as a proposal? I think it'll make everyone happy. 

"Lock Widgets" should hide or remove the toolbox from the desktop. The toolbox contains actions specific to the manipulation of the desktop and it becomes pretty non-functional when widgets are locked. Of course one could argue it still has the zoom functionality, but I don't think those functions should be enabled when the desktop is in lockdown mode.

Here's an even cleaner idea, why not hide the toolbox when no tools exist inside it? Hide the zoom tools on "Lock Widgets" and then there won't anything in the toolbox and goes invisible. The toolbox isn't gone and will still popup in ctrl+f12 because hide dashboard will be there, but won't exist otherwise.

Craig, is it a bit over complex? I think that treating this widget as a widget would do the trick. It could be the only one default widget turned on, but user should be able to call widget dialog and click "remove" next to the zoom widget to remove it.

Consistent, straightforward, user in control. 

Sebastian, Aaron, could this report be opened at last? -- you get pretty list of arguments.

I don't get what most of this bug-report is about.

Some claim that the tool violates usability. I never had it interfere with closing a window, since it _never_ gets above any window. It animating is certainly not a usability issue.

Some want that corner for a kwin-effect, yet that does not make sense because that effect (in contrast to the tool) would be triggered, even if there is a window covering that corner, i.e. that would really be a usability issue. The upper-right corner is for closing and must not interfere with that action.

Adding a remove-button is completely senseless, because although they are all called widgets, they are not the same. (Which is why "Lock widgets" does not make sense in the first place!) The desktop-background is a widget and nobody would claim that it makes sense to add a "remove action" to it. Further, if one really thinks that one has to add "remove" to the plasma tool because it is a widget, one would have to agree on having to add rotate, resize etc. -- because it is a widget, isn't it?

There is a point to "locking desktop" including not being able to zoom, so at the current state, since the tool does not provide anything more than adding and zooming, I do see why it should be hidden when the desktop is locked. Yet that would no longer be the case if other actions were added to the tool, like "unlock desktop" for example. Currently devices that do not provide a right-click are not able to (un-)lock the desktop. So the question is: What other actions are planed to go into the tool?

Since the bug-title is about removing the tool and not hiding on lock, it is indeed a WONTFIX. I'll open a wishlist-item for locking hiding the tool though.

> I don't get what most of this bug-report is about. 

In short -- ability to close/hide the zoom tool-widget.
 
> I never had it interfere with closing a window, since it _never_ gets above
> any window. 

The [x] widget in window decoration when the window is maximized is exactly at position of zoom widget-tool.

> It animating is certainly not a usability issue. 

Yes, it is -- ask any psychologist if animation causes focusing on animation (hint: that is why all ads are animated). However, this is just additional argument, not the main one.

> Adding a remove-button is completely senseless, because although they are
> all called widgets, they are not the same.

It was a _suggestion_, not a wish itself, please don't catch me on words now. 

>  Since the bug-title is about removing the tool and not hiding on lock, it
> is indeed a WONTFIX.

And why? "it is by design" is not an answer. I didn't hear _one_ argument why it should be non-removable. One. Everything is configurable, but not a zoom tool -- it is better hardcoded.

The bottom line is -- why to clutter the desktop with tools user does not use?

> > I never had it interfere with closing a window, since it _never_ gets
> > above any window.
>
> The [x] widget in window decoration when the window is maximized is exactly
> at position of zoom widget-tool.


So? It is below the window/button, there is no interference. So what's your 
point? Does it hinder you in closing a window?

> > > I never had it interfere with closing a window, since it _never_ gets
> > > above any window.
> >
> > The [x] widget in window decoration when the window is maximized is exactly
> > at position of zoom widget-tool.
> 
> 
> So? It is below the window/button, there is no interference. So what's your
> point? Does it hinder you in closing a window? 

The point is that when you close a window it disappears. So every time you close a maximized window under which there is only desktop, the toolbox "blinks".

> > So? It is below the window/button, there is no interference. So what's
> > your point? Does it hinder you in closing a window?
>
> The point is that when you close a window it disappears. So every time you
> close a maximized window under which there is only desktop, the toolbox
> "blinks".


Honestly? That is your point? You think this is a usability issue because the 
toolbox animates _after_ you closed a window? I give up.

Craig, i think hiding it with desktop locked makes perfectly sense

>>  The [x] widget in window decoration when the window is maximized is
>>  exactly at position of zoom widget-tool. 
  
> So? It is below the window/button, there is no interference. So what's your 
> point? Does it hinder you in closing a window? 

Ok, I try to explain in simpler words. [x] widget is at position 100x100. Zoom "widget" is at position 100x100. When you close the window, "zoom widget" sees the mouse cursor as its placement and starts animation.

And no -- it is not BELOW, it is in the background.

Is the screenshot needed? Be my guest.
 
> Honestly? That is your point? You think this is a usability issue because
> the toolbox animates _after_ you closed a window? I give up. 

What purpose serves this animations if you don't use zoom tool at all?  Could you answer this simple question? -- thank you. 

> What purpose serves this animations if you don't use zoom tool at all? 
> Could you answer this simple question? -- thank you.


This is just silly. You are against the toolbox because it animates even if 
you don't need it. That has nothing to do with usability, no matter how hard 
you try.

If I move my mouse from the bottom-right of the screen to the top-left and 
dolphin happens to be inbetween the files the mouse hovers get 
painted/animated, although I just wanted to get to the top-left of the screen 
and not do anything with dolphin. Silly dolphin! It should get an option to 
disable it because it is bad usability and disturbs me to an extent I cannot 
work with!

keep it cool, the solution is simple, just make it a applet, so that everybody that does not want it, can remove it from the appled dialog

Sven,

> This is just silly. You are against the toolbox because it animates even if 
>  you don't need it. 

No, please read with understanding -- I don't need the zoom "widget", __SO__ I don't need animation from zoom widget too.

And if I would be user of it I would place it where I see it fits.

> If I move my mouse from the bottom-right of the screen to the top-left and 
>  dolphin happens to be inbetween the files the mouse hovers get 
>  painted/animated,

Dolphin is nowaydays hardcoded in the middle of the screen? 

#18th comment -- still no answer what is the purpose of the hardcoding the zoom "widget".

+1. I suggest reopening this one. It's annoying enough to enough people that somebody will do this sooner or later, anyway.

nope, not re-opening. and if someone does provide a patch to make this go away or configurable or what not it'll happily live outside of trunk/.

seriously, give us a couple of releases so you all actually start to be able to see what we're working towards.

the people in this report seem to be working from mostly simplified or outright incorrect assumptions. i don't expect otherwise since it's really not possible to get the proper context right now from the outside. we're working on fixing that, and time spent right now making this configurable just detracts from those goals. it also means that a good portion of people won't actually start to grok why it's there in the first place.

the recent commit by Binner to show the tools automatically when dashboard comes up is a good example of why we want it, btw.

so .. yeah. i respect your viewpoints, but they are not based on a solid understanding of the issues at hand.

peace.

> and time spent right now making this configurable just detracts from those
> goals

So it is rather "later" than "wontfix". And nobody said it has to be implemented right now, as with any report.

Even for people who would like to use it, it is (at least) awkward -- there are right-handed, left-handed, vision impaired, color-blind people, you name it, but the zoom tool is "one fits all", top, right corner, hardcoded.

Seriously, you won't find any tool as limited as zoom "widget" and I am surprised there is even discussion about "configurable vs. fixed".

We live, we'll see... what can we do else, right? ;-)

no, it's WONTFIX.

the request is to be able to remove the box, and that's not going to happen. as for moving it, etc, yes there are already plans for various improvements there for 4.1 .. but that is not what this BR is about, is it?

> but that is not what this BR is about, is it? 

Aaron, indeed.

############################################################################

VOTING:

The report is closed, but voting for this report is still possible 
( http://bugs.kde.org/votes.cgi?action=show_user&bug_id=154535 ) so if anyone is interested in having fully configurable desktop environment (KDE) please vote via bugzilla voting mechanism, not only by "+1" commenting :-) (however I'll appreciate that too). Thank you in advance.

############################################################################

+1 for this too. Like most people, I never use this either and find it annoying.

If there really are big plans for it to be fixed why can't you give examples? Instead of just saying "from the outside you don't understand"? Or, until those goals are met, why can't it be removed?

/+1.

Can easily be postponed to post-4.1.

- Gilboa

Please reopen, the zoom widget is not needed by me and I cannot imagine why anyone would ever use it (unless you develop plasma widgets, most of us would like to simply use them...)

I must admit that is a bit un-KDEish, I would expect something like this from GNOME 'Spatial browsing is the tops' Project or Microsoft 'ICS host should be on 192.168.1.1' Windows, but not from KDE. IMHO, you should be able to disfigure KDE so badly not event it's own core developer would recognize it, at least at first glance. Remember, K stands for 'konfigurable'. ;)

+1 too. btw, this _is_ a usuability issue cause it's an accessibility issue. What is valid for the web is even valid for the desktop; http://www.w3.org/TR/WCAG10-TECHS/#tech-avoid-movement

btw, see (and vote) at bug #154485 which is related and open :)

btw, 

At http://developer.gnome.org/projects/gap/guide/gad/gad-ui-guidelines.html

Section "Graphical Elements";
* Don't show GUI elements that look pretty but don't actually do anything, unless you also provide an option to switch them off.
* Provide an option to hide graphics that don't convey essential information. Graphical images can be distracting to users with some cognitive disorders.

Section "Animation";
* Used sparingly, animation can be useful for drawing attention to important information in your application— and it can look cool, too. However, it can be problematic for some users, so make sure they can turn it off.
* Make all animations optional. The animated information should be available in at least one non-animated format, at the user's request.

 http://www-03.ibm.com/able/guidelines/software/swanimation.

"Provide an option that enables users to stop animation, and ensure that all information conveyed by the animation is still conveyed"

U.S. federal government's Section 508 http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

"§ 1194.21 Software applications and operating systems.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user."

Seb, as far as I can tell your last bunch of comments are on a different issue entirely.  Whether or not the toolbox uses animations is not the same as whether or not the toolbox can be used/removed.  Please make a different bug report about it, it is a different issue.

Dan, I don't believe it's that different since
1) the toolbox is animated and at least some comments like comment #5 and comment #14 indicate that this is part of the problem.
2) All the sources outline the "option of the user" part very strong, related to comments like comment #4 and comment #6, what handling this wish as WONTFIX does not respect.
3) See here also my last comment to bug #154485 why I guess that this all falls into the same category. Well, also http://weblog.obso1337.org/2008/desktop-zooming-wtf/ is related here and it all comes down to the same issue; That feature is not done yet. So, for me it makes quit sense to try to bundle the different requests on a not yet done functionality to one single report rather then to open here n^m different reports for each single aspect.

and once more, comment #24 says it btw already;

"yes there are already plans for various improvements there for 4.1"

So, this is just a temp state and will change (just like it was disabled for 4.0.0). So, imho the best thing someone is able to do here is to collect the various points that show up (like that it's always at the top-right, not movable, animated, etc.) and collect them at a single report.

This should provide the advantage that it's not needed to walk through 20 reports to just discover they are all dealing with something that is work in progress anyway while it may also easier to take those collected points into account if there exist only one report that lists them all :)

Sebastian,

Collecting several ideas in one report is not good -- some of the ideas will be rejected, some of them will be fixed, and so on, and the status of such report would be...?
The principle is -- one issue, one report.

And about on/off issue and animation -- they are closely related, but I can perfectly imagine hardcoded zoom tool in left, upper corner with context menu (without animation). Could you then please open another report and link one to another, thank you in advance.

Created attachment 23710 [details]
patch that removes aka hides the toolbox

The patch above is only for those that can't live with the toolbox for the
meantime. While it does the job it's just a quick hack and I hope nobody makes
me responsible for it, heh.

apply with;
cd kdebase/workspace/libs/plasma && patch -p0 < plasma_no_toolbox.patch && make
install

@Maciej
Well, as sayed I don't see a reason to create a new report for it. Probably I
would mark my new report as duplicate of this one only anyway ;)
Well, 4.1 is not out yet and I am pretty sure it will change in some way
anyway. btw, also related is
http://techbase.kde.org/index.php?title=Projects/Plasma/ZUI

let me spell it out in very clear terms:

firstly, it's *not* an accessibility issue because we already provide a way to turn off animations in plasma

secondly, saying "i don't like it, make it configurable!" on every little bit and nobble in the interface results in software that has tons of configuration options that do .. what? cover up issues.

those kinds of options are there *only* to take away the pain/annoyance/whatever of a feature (or mis-feature, depending on the case). instead, if one works on tooling that feature into something better .. one gets a better tool and doesn't add yet more to the configuration load.

and yes, high configuration load does have a very negative impact on the user experience.

worse, if we let you turn this off now .. where will we get feedback on what we do with it so that we can figure out when/how it is more acceptable? no, you'll just all turn it off and never look back at it again. i'd rather try and *fix* issues rather than cover them up, with the result being a mess of code paths and half finished features.

moreover, as a feature in development, i'm very against making the implementation yet more complicated than necessary until we have some of the other fundamentals in place.

and finally, no, you probably don't know what the toolbox is intended for and no i'm not going to sit here and write pages explaining it. there is purpose to it, you'll see it as the code emerges. explaining it beforehand is not going to resolve the situation any faster.

now, i hear you when you say "i don't like it moving", "when i close a window, then it animates on me" ... i'll try and address those issues. the RIGHT way. you know, by addressing those issues.

but i'm not going to turn it into "Just another applet" (why? explaining it would require familiarizing you with the internal design of plasma) nor will i provide an option to remove it at this point in development.

Aaron, animation is just annoyance, zoom tool "applet" is not needed (by me), because it is... not needed -- I don't intend to use it, and even if I did, I would remove it from the desktop because I like my desktop clean -- I have no apps, shortcuts, icons, karamba applets, all panels are auto-hidden, nothing is on my desktop. And I like to keep it this way. Pure and simple.

Even if this applet triple resolution of the screen, double the memory it would still not justify hardcoding it into the desktop.

Anyway, I'll wait.

I have to echo comment #39. Give me a drop down someplace that has: 'on', 'auto-hide', 'auto-hide on widget lock', and 'off'. Heck, default it to 'on' under the 'sensible defaults' or 'it needs exposure' mantras. Just give reasonable people a way to make it go away easily.

@ James

as far as I understood it, it will be possible to disable it. Just not in that way. So, rather then to explicit provide options for everything, someone is able to just use another "desktop plugin". The desktop itself is a plugin just like the panel is. That means, it's easy to provide here additional drop-in "replacments". E.g. one desktop where it's enabled while at another one it's not. That sounds pretty cool to me and follows the logic like we have e.g. with the menu launchers. One for kickoff, one for traditional and even more for other cool things. Everybody is able to choose what matches best here for him.

So, as I understood it, we are switching away from a "there is one monolithic thing and you can configure it" to a "there are plugins and that means it's easy to switch one implementation with another". That this is now extended to even the desktop itself and not only to applets and panels sounds imho like a pretty cool way to provide even more choose while keeping the interfaces small.

Though at trunk it's enabled now while there is no such alternate way yet without doing patches your own. Well, it's trunk and trunk is expected to suck sometimes aka don't be full polished but have round ages everywhere. Well, at least it does not crash and it seems to help developers to move faster forward. So, all in all I am sure 4.1 final will provide somehow a way to fullfit the requirment somehow. Let's wait and see :)

Hopefully such a desktop plugin will also give the possibility to just display the contents of ~/Desktop by default

Aaron wrote (comment #38):
> secondly, saying "i don't like it, make it configurable!" on every little bit
> and nobble in the interface results in software that has tons of
> configuration options that do .. what? cover up issues.

That's exactly what Havoc Pennington and other GNOME developers say and what has lead to the current state of GNOME 2 where there's hardly any option left. KDE, on the other hand, has always been about sane defaults, sure, but with the option to change them. This is exactly what the angry users are referring to when they say in rude and impolite ways that "KDE 4 is becoming the next GNOME". So let me respectfully disagree with that statement.

Also, GHNS isn't a 'cure' for much of anything. OK, at some point we'll be able download a desktop containment without the toolbox. Swell. So let the get flowering of desktop containments commence... Where you'll have 15 desktop containments and a completely divergent desktop experience for everybody, with vendors shipping there own, or patching yours. (All to spare the world one checkbox or menu item.) Have fun with that.

It's largely the same issue with Plasma themes... Aya's great, and 'the vision' thing behind Plasma and with the artwork is all fine and dandy, and the same goes for Kwin and Ozone vs Oxygen, but for the love of God if a user wants to tart up 'the vision' by honouring the colour scheme, or making seemingly discrete components go away you should bloody well let them, IMHO.

There talk of 'options hiding issues' but ATM there's 499 votes saying that the inverse can be equally true.

I can confirm that this bug still affects KDE beta 1 and also affects the panel now. (TWO CASHEWS without any functionality) Should the bug not be reopened?

The widget you see in the panel is for configuring panel -- very bad UI, report about it already posted. Lock the widgets to remove the extra controls.

About reopening, I am afraid Aaron would close it in seconds, right Aaron? ;-) Which is sad because it would be more flexible to have several components, pretty much as Lego bricks, not monolithic like current one. But somehow Aaron sees it, it is more flexible in current way.

> I am afraid Aaron would close it in seconds, right Aaron?

i would close it again, yes.

> Which is sad because it would be more flexible to have several components

Maciej, i've really appreciated your extensive reporting this last week or so. it would be nice, however, if in situations like this you refrained from commenting on architectural issues unless you actually are familiar with the architecture you are commenting on.

in this case, we *do* have things as components that are like lego bricks: they are called containments.

if you'd like to get involved and work on the architecture of things, please grab the code and dig in. it's a lot of fun and many people have contributed. otherwise, i don't particularly need to open my inbox, go through the bug reports and read this kind of stuff.

if you want this communications channel to work, e.g. have your wishlists and bug reports dealt with in a timely manner, operate with some respect and civility. if you just want to make a point without care for the impact on the final product and this user<->developer communications medium, keep going as you are.

> in this case, we *do* have things as components that are like lego bricks:
> they are called containments.

I meant lower level. But let's keep it as it is, and I explain it further when 4.1 will be fully polished, so we have a subject to discuss about, ok?

> if you want this communications channel to work, e.g. have your wishlists
> and bug reports dealt with in a timely manner, operate with some respect and
> civility. 

It was unprofessional indeed -- my fault, I am sorry.

> I meant lower level. But let's keep it as it is, and I explain it further when 
> 4.1 will be fully polished, so we have a subject to discuss about, ok?

that would be great. the best place for this discussion would the mailing list: panel-devel at kde dot org.

note that in 4.2 we will be breaking up the functionality of containments into three parts: background rendering (e.g. wallpaper), applet management (organization, layout and control interfaces) and context menus. that may already address issues you are concerned about.

+1, please reopen.

Aaron, I think you're missing what a lot of people here are saying.

The pain point is the toolbox itself -- there's this thing on my desktop that *I* didn't put there, and I can't get rid of.  What it does, or how great/wonderful it's supposed to be, is _irrelevant_ if we never use it.

For my part, I will never use it unless it's the *only way* to do something.  (And even then, I would grumble.)  Why?  Because it's clutter and because I like context menus better.  Purely personal preference.

But I think that personal preference should be respected, especially when a lot of people have expressed it.  Yes, I buy the usability/discoverability argument that it should be on by default.  That's fine.  But please include the option.

Also, I think having to replace my whole containment just to get rid of one little toolbox isn't really a solution.  Does that mean I have to fork the default containment?  How is that better than forking Plasma?

Votes: thank you for that.

The rest: do you wish to have functionality of current containment but to get rid of this super-plasmoid and have access to its features via desktop context menu? If yes this goes in a little different direction -- because for me, I don't need this super-plasmoid widget as well as its features. So I will be happy with blank containment with KDE 4.1, but for you I see reopening would be justified -- now, that is the matter if the design of KDE4 allows to interact with containment at the desktop level (I don't know). 

(I had to look just now to see what was even there. ;) )

It looks to me like the only feature that's in the toolbox but not the context menu is "Zoom Out".  I never use it, but my understanding is it's a work in progress.  So I don't know.  It might be a good idea to put in the context menu just so it's still accessible when the toolbox is hidden.

I could live with a separate, blank (toolbox-free) containment as well... it just seems to me like a very sub-optimal way of solving this bug.

I'm not a usability expert, but my suspicion is people will think in terms of "I want to get rid of the toolbox", not "I want to replace my desktop containment to make the toolbox go away" -- assuming they even grok what a desktop containment is.  Reading over this bug, and over various kde-devel@ threads, I get the impression that desktop containments are very non-intuitive.

they are non-intuitive because we haven't offered a GUI to swap between them. this will be coming in 4.2. it means that people need to understand the technical details rather than point and click at something a bit less abstract on their screen.

also keep in mind that anything you haven't known before is "unintuitive". that includes the nipple (no, i'm not joking; and yes, that's a Steve Jobs reference).

i'm tired of dealing with this issue, mostly because the comments here are from people who seem to feel they understand something they have really very little understanding of.

if you find that an annoying statement, i suggest you go talk to your local quantum physicist about the small scale world all around (and in) us to find another topic you are similarly out of your depth in (assuming you aren't a quantum physicist ;) and then you and i can commiserate together on how much it sucks to not have a deep understanding of everything in the world.

between now and then, like it or hate it or don't care about or whatever, but stop wasting my time by chatting about it here where it ends up in my inbox.

realize that my other option is to just unsubscribe from all bug reports and start ignoring every report out of respect for my time and energy. that seems like a far worse thing than you simply accepting the conclusion in this report.

watch how things evolve, by all means. you won't be disappointed. perhaps that makes it a bit more frustrating too: we're working to get everything in place where everyone can be happy and while we do so people continue to waste time with these discussions as if nothing is happening. 

On Sunday 22 June 2008 22:10:55 Aaron J.Seigo wrote:
> also keep in mind that anything you haven't known before is "unintuitive".
> that includes the nipple (no, i'm not joking; and yes, that's a Steve Jobs
> reference).


Let me clarify my question: How are people supposed to make the connection 
between "get rid of that annoying cashew-thing in the corner" and "change my 
desktop containment"?

> i'm tired of dealing with this issue, mostly because the comments here are
> from people who seem to feel they understand something they have really
> very little understanding of.


Let me explain what I do understand:

(a) I have a nifty Plasma desktop, with applets and panels and things on it.  
(Cool.)
(b) I can do everything I need with the context menu.  (Also cool.)
(c) There's this toolbox thingy I never use taking up space in the corner.  
(Eh, it's not hurting anyone.)
(d) Short of patching, I can't get the thingy to go away.  (Frickin' 
annoying.)

I'm not sure how a greater understanding of the Plasma vision/architecture is 
at all relevant to the above.  Yes, there may be a whole host of 
architectural/design reasons why the above are true.  But none of those 
reasons fix my problem.

> watch how things evolve, by all means. you won't be disappointed. perhaps
> that makes it a bit more frustrating too: we're working to get everything
> in place where everyone can be happy and while we do so people continue to
> waste time with these discussions as if nothing is happening.


Maybe.  You have yet to explain to me how you're planning to solve my problem.  
All I've read from you in this bug amounts to hand-waving, and really 
complicated ways of saying "YOU DON'T UNDERSTAND, so STFU!".

I won't be disappointed?  Great!  HOW will I not be disappointed?  How does 
your Plasma vision include a solution to this bug report?

I understand these are hard (that is, frustrating and/or annoying) questions.  
And if they're really that frustrating, maybe walking away for a bit is a good 
thing.  But when you have calmed down, please do us the professional courtesy 
of answering them.

To be blunt, the "Cashew" or "Aaron's Annoy Me Box", and the inability of people to remove it in a sensible way is an poor issue for a 'visionary' to go to the wall over...

So instead of one visible option, that adds one line of text, and probably no more than a couple of dozen lines of code we'll have:
-Distros X, Y, and Z using methods 1, 2, and 3 to let users hide it. Oh, and distros a, b, and c won't patch that. If people get really lucky X, Y, and Z may synchronize their patches at some point, but probably not. So you've just made busy work for distros X, Y, and Z and caused a source of debate for distros a, b, and c.

If your distro doesn't patch it:
-You can change the default containment to the folder view via a hidden config option in 4.1. If you actually want an icon free desktop I suppose you could set the filter to something non-existent or point it at an empty folder. So you've just cost every user 5-10 min of their day in an annoying process. That just "screams sexy".

or

-Wait to download some other containment from GHNS (or whatever it is now). Use the hidden option to set that as the default containment. Great if you love installing binary blobs that's not not in your native package format to the $HOME of each user. On the plus side you've generated a free software itch-- but why you'd want that itch to be a proliferation of desktop containments instead of 'cooler plasmoids' is beyond me.

Moving along to 4.2:
-We'll get a pull-down to choose the containment... Adding strings and widgets to System Settings which really doesn't need it. I am quite sure there would be NO REAL DEMAND to do this via the GUI if the "Cashew" could be made to go away. A hidden option would be more than fine if you could turn off the "Annoy Me Box".

For the lifetime of KDE 4:
-You have consigned your users to explaining this to trolls and their peers.
-On account of this being in the range of 'reasonable people disagreeing' people are going to lob complaints well into the future. Up until very recently it was only the 'early adopters' here. How many paragraphs have you typed? What was the opportunity cost of 'going to the wall' for this issue? So you're just going to stop talking... That just foists it back to 'loyal users'.

On your general tone:
-Up until very recently the people you've been basically labeling 'counter visionary' have actually been your early adopters. The people willing to jump through hoops. How many of them have have been alienated by this branding?
-In this bug report, and in many other places, you spout 'vision' and 'the new jargon' (which you largely invented) while having to be dragged into concisely addressing the issue at hand. This seems 'smarmy' and further alienates people.


Regardless of 'expert opinion' the sheer amount of interest in this does indeed seem to indicate that a large body of otherwise reasonably people disagree. Quite frankly 'opportunity cost' on this issue has been huge. You've taken a minor and popular wish and transformed it into a huge cost for you, your peers, the 'loyal users', and the 'annoyed users' that will run well into the future. It in no way strikes me as 'worth it'. The decision to go to the wall on this makes 'reasonable people' far less reasonable. If going to the wall over things that reasonable people can disagree on is counter visionary then I'm proudly "Counter Visionary" and am becoming increasingly happy to reject the consensus of "The Grand Czars of Vision and the New New Jargon".

"You have yet to explain to me how you're planning to solve my problem"

you are operating under the misunderstanding that i'm beholden to do so. i'm not. what i *have* found is that explaining how things work is an utter waste of my time. see the three blogs i posted about desktop icons as a great example of this. stop wasting my time and stop flooding my inbox.

i'm not going to explain or discuss this further.

@James: your comment is a classic example of combining ridiculous vitriol ("Aaron's Annoy Me Box") with a complete lack of understanding. i'm sorry i can't fix your lack of a grasp on the topic. i'm doubly sorry i can't fix your attitude.

in any case, i will repeat my plea once more: you are filling my inbox and taking my time with these messages that will result in exactly zero useful response. cease, desist or go find some other software to use.

On Monday 23 June 2008 14:09:29 Aaron J.Seigo wrote:
> you are operating under the misunderstanding that i'm beholden to do so.


No, I am not.  I'm operating under a set of norms that says when someone asks 
you a polite question, the courteous thing to do is answer it.

You don't owe me an answer.  But understand that throwing a tantrum, instead 
of providing an answer, reflects poorly on you and accomplishes nothing.

[snip ranting]
> in any case, i will repeat my plea once more: you are filling my inbox and
> taking my time with these messages that will result in exactly zero useful
> response. cease, desist or go find some other software to use.


And that is purely because you have chosen not to respond usefully.

I've said "Hey, I have a problem!".  You responded with "Well, you don't 
understand how things work."  Alright, fine, I don't understand.  But when I 
ask you to explain, I get, "No, I won't explain, STFU."

What am I supposed to do with that?

Fork/patch Plasma, I guess.  Or maybe find some other kind Plasma developer to 
explain to me what I'm missing.

But Aaron, for the love of God take a vacation before you bite some other 
unwitting user's head off.

It's just a cashew, people.  Relax.

"I'm operating under a set of norms that says when someone asks
you a polite question, the courteous thing to do is answer it."

when the question is in context. these threads are wastes of my time. i have answered these issues before elsewhere, and that doesn't seem to help.

for anther example, see how long it took to get the desktop icons issue across to people.

regardless of why the 'provide an answer, people keep asking the same question in different words' happens, it's not useful to spend my time doing so. if you wish to speak about courtesies, i ask you to respect my time.

perhaps you aren't aware of just how much of my time is spent dealing with people just like you trying to have conversations just like this one. do you think it's a useful way to spend my time? i don't.

i guess that begs the question: why do i? probably in hopes that at some point more people who are involved as part of our enthusiast community will learn how to interact with developers in a more productive fashion to get what they want.

"You don't owe me an answer."

great.

"But understand that throwing a tantrum, instead
of providing an answer, "

it's hardly been a tantrum, and you're really working against your goal of having an open dialog by using such terms.

"reflects poorly on you and accomplishes nothing."

i don't care what you think of me, and my hope is that it accomplishes the result of fewer people wasting my time with these kinds of pointless threads.

"And that is purely because you have chosen not to respond usefully."

see, this gets painfully close to you acting like you feel you are owed an answer. if i don't provide a useful answer, have said i don't have time to discuss it further and i don't owe you an answer, then just accept it and walk away.

"But when I ask you to explain, I get, "No, I won't explain, STFU."

that's a rather mean characterization of what i've actually said in this thread. again, you're working against your own goal here of open communication by doing so.

"What am I supposed to do with that? "

walk away. seriously. stop asking me the same questions over and over. it's really simple.

"for the love of God take a vacation before you bite some other
unwitting user's head off."

it's not about me taking vacations, it's about dealing with people who behave in a way that isn't sociable. e.g. saying they don't think they are owed an answer, but then acting very much like they do feel that way.

"It's just a cashew, people.  Relax."

that's an ironic statement if i've ever read one. i agree: it's just a "cashew". so i don't get the energy, excitment and at times straight out vitriol in these threads. chill.

in any case, continue on ranting and weaving if you wish, i'm done.

I've been following this discussion since the beginning and have heard promises that the cashew was going to be a huge transformation. I understand there's a vision behind this, but there hasn't been any discussion on what it is. If a user has a feature request generally you add the feature OR explain to them why this isn't a good idea. 

Telling users for the past seven months you don't have time to discuss this issue and to wait is not the way to approach the problem. It's such a small feature request too, that has a huge visual impact on the user's screen. The rest of the desktop can be moved around and configured, but the cashew remains unconfigurable, featureless and fixed in place.

You make the argument that there are going to be great things coming for it, but why would you include a feature that's work in progress for a stable branch? Kwin has had their compiz like effects disabled by default for a while, not because they’re super unstable, but they’re not ready. People can opt-in to test them, but it’s not forced upon them. You’re doing the exact opposite, by displaying something that isn’t ready and forcing the users to adopt it. You create resentment for the feature and even if the cashew manages to cure world hunger people aren’t going to want to use it because they’re disgusted with it.

Let people disable it easily and when the time comes for this feature to mature they should want to use this feature. Features don’t become successful by shipping them useless and incomplete and telling users to wait until they’re coded. It’s like having a button on an application that when clicked displays a message box saying “coming soon.” That button shouldn’t be there. I’ve offered in the past to help get features in there, but you never given any direction toward what this cashew is going to be doing. Create a blog post discussing your intentions for the cashew, let people work on it and get people interested in the thing. Or if you've explained this thing, link us to some written dialog on the matter.

"@James: your comment is a classic example of combining ridiculous vitriol ("Aaron's Annoy Me Box") with a complete lack of understanding. i'm sorry i can't fix your lack of a grasp on the topic. i'm doubly sorry i can't fix your attitude."

Over time my vitriol becomes increasingly justified. In fact your comment pretty much only renforces my opinion of you, and echos exactly what I said. (By pretty much confirming that otherwise reasonable people who disagree are simply "Idiot Counter Visionaries", and once again saying that you're taking your ball and going home.) So please spare me from you desire to 'fix me'.

On Monday 23 June 2008 15:53:13 Aaron J.Seigo wrote:
> "I'm operating under a set of norms that says when someone asks
> you a polite question, the courteous thing to do is answer it."
>
> when the question is in context.


This is a bug report.  Asking how the bug is going to be addressed is 
definitely in context.

> these threads are wastes of my time. i
> have answered these issues before elsewhere, and that doesn't seem to help.


Where?  If you have, I'm obviously not aware of it.

> perhaps you aren't aware of just how much of my time is spent dealing with
> people just like you trying to have conversations just like this one. do
> you think it's a useful way to spend my time? i don't.


You could've just pasted the URL to the answer, and we would've been done a 
long time ago.

And if there's one, authoritative place for such a thing, a bug report is it.

> "But understand that throwing a tantrum, instead
> of providing an answer, "
>
> it's hardly been a tantrum, and you're really working against your goal of
> having an open dialog by using such terms.


I think it's an accurate label.  You are obviously very frustrated, and that 
seems more important to you than the bug right now.  My choice of the word 
"tantrum" reflects that.  I'm sorry if you felt that characterization was 
somehow insulting -- it wasn't intended that way.

> "And that is purely because you have chosen not to respond usefully."
>
> see, this gets painfully close to you acting like you feel you are owed an
> answer. if i don't provide a useful answer, have said i don't have time to
> discuss it further and i don't owe you an answer, then just accept it and
> walk away.


I was reacting to the implication that your frustration, and your refusal to 
answer the question, was somehow specifically my fault.

> "But when I ask you to explain, I get, "No, I won't explain, STFU."
>
> that's a rather mean characterization of what i've actually said in this
> thread. again, you're working against your own goal here of open
> communication by doing so.


"Just accept it and walk away" sounds like a sugar-coated way of saying "STFU" 
to me.  It's more polite, certainly, but the underlying meaning is the same.

> "for the love of God take a vacation before you bite some other
> unwitting user's head off."
>
> it's not about me taking vacations, it's about dealing with people who
> behave in a way that isn't sociable. e.g. saying they don't think they are
> owed an answer, but then acting very much like they do feel that way.


Most of my issue has been with your tone.  I totally understand "I don't have 
time for this", but the way in which you delivered that message has, in turn, 
frustrated and pissed off a number of people, myself included.  My persistence 
has been rooted in trying to punch through the emotional noise and reach a 
conclusion which is acceptable to more than just Aaron Seigo.

Besides, I think we've expended more effort in beating the meta-issues to 
death than we would have spent had you answered the question in the first 
place.

And what happens when the next annoyed user comes along and finds this bug?  
Are we going to go through this whole thing yet again?

This has devolved into a meta-discussion, which is off-topic for a bug report.  
Worse, it has become confrontational.  So I'm done as well.

Aaron, I do not understand, why you still answer to these kind of bugs.

They do not change your mind, so just don't and listen to people around you 
instead. I am sure they will mediate the "general opinion" to you in a lot 
less never-wracking way.

To others, you won't change Aaron's mind with this bug-report, simply because 
it is just a dead discussion, no matter who's right or wrong or has to justify 
xy. Aaron wants to show you the vision by implementing it and he will do so. 
If you don't like it, you will simply have to hope that you are not a 
minority. If not, there might be people who start another desktop, i.e. some 
replacement or variant of plasma, Aaron won't.

AFAIK, in opensuse there is a hidden setting for 4.0.x and maybe even the 
4.1.x packages, if they are released, to disable it, just google for the blog 
that reports which it is. If you distro does not provide it, bug them or 
change to the distro that meets your needs.

No matter what or how or why, this bug-report is dead and dows not produce any 
value but just annoy everybody connected to it.

> AFAIK, in opensuse there is a hidden setting for 4.0.x and maybe even the
> 4.1.x packages, if they are released, to disable it, just google for the blog
> that reports which it is.

http://kdedevelopers.org/node/3501

An example:
Usually I don't have anything maximized and DO use the applet. But for some reason someday I do maximize a window. Now I want to use the widget and automatically click at the right-upper corner. Woops. The program is closed -> possible data loss (depends on the program) but definite annoyance.

At least make it configurable where it is placed. I think the upper-right corner is a bad place. Upper left would be better but hey, KDE users are accustomed to configure the position of anything and they might place the [x] button at the left side like in OS X.

I love KDE because everything is configurable. The next time I'm asked why I love KDE I'll have to say: Because everything but the zoom widget is configurable.

+1 for the bug

This is my last comment on and in bug #154535. (To the relief of myself and probably all).

@Comment #62 From S. Burmeister
"Aaron wants to show you the vision by implementing it and he will do so. 
 If you don't like it, you will simply have to hope that you are not a 
 minority."

Being "Not Aaron" doesn't make you a minority, it just makes you "Not Aaron". I suspect the majority of people are simply apathetic. I suspect there are a minority that like the cashew, or the future potential of the cashew. I suspect there's a larger minority that is slightly annoyed and silent, or annoyed and vocal. This suspicion is re-enforced by the rapid aggregation of votes for a closed wishlist item with no possibility of redress (and opinions expressed in other places).

On that note:
"No matter what or how or why, this bug-report is dead and dows not produce any 
 value but just annoy everybody connected to it."

More words 'here' won't help. Agreed. More votes probably won't either, BUT: growth in votes on a closed wishlist item with no possibility of redress within KDE proper is the only real method available to quantify displeasure (by comparison if nothing else). So even if you don't want to stir the pot do vote. While more words here won't help, speaking POLITELY, PUBLICLY, and with ALL DUE RESPECT shouldn't be discouraged by a project advertising under the mantra of "be free" (even said words are ultimately futile).

I'm done.

Mathias,
Configurable placement, take a look here: https://bugs.kde.org/show_bug.cgi?id=161774 

James, 
About voting -- true, so please keep voting. Thank you all in advance.

+1 to remove the zoom in/out tool.

Aaron, why are you being so stubborn? This is not Pidgin, this is KDE. Your points, and my answers:

> firstly, it's *not* an accessibility issue because we already
> provide a way to turn off animations in plasma

There are animations that people want to have. This particular animation is annoying.

> secondly, saying "i don't like it, make it configurable!"
> on every little bit and nobble in the interface results in
> software that has tons of configuration options that do ..
> what? cover up issues.

We don't want to cover it up, but rather make it go away completely. I don't need the zoom app, so I don't want it. Even if it's animation did not annoy I would not want it.

>those kinds of options are there *only* to take away
> the pain/annoyance/whatever of a feature (or mis-feature,
> depending on the case). instead, if one works on tooling
> that feature into something better .. one gets a better
> tool and doesn't add yet more to the configuration load.

But we don't want the tool, better or not!

> and yes, high configuration load does have a very negative
> impact on the user experience.

What?!? Not being able to configure has a negative impact. Those who don't want to configure can use Gnome. KDE's selling point has always been configurability.

> worse, if we let you turn this off now .. where
> will we get feedback on what we do with it so that
> we can figure out when/how it is more acceptable?

The same place that KDE gets all it's feedback: beta testers. The feedback that you are currently getting is that people do not want this feature and you are ignoring that feedback.

> no, you'll just all turn it off and never look back at
> it again.

Yes, that is what we do with features that we don't need.

> i'd rather try and *fix* issues rather than cover
> them up, with the result being a mess of code paths
> and half finished features.

You can fix the feature, but there will still be people who want to disable it.

> moreover, as a feature in development, i'm very against
> making the implementation yet more complicated than necessary
> until we have some of the other fundamentals in place.

Nothing is being made complicated by letting users disable a feature that they do not use.

> and finally, no, you probably don't know what the
> toolbox is intended for and no i'm not going to sit
> here and write pages explaining it.

I am not interested in what it is intended for, especially if it is so complex that it would require pages to explain rather than a simple sentence.

> there is purpose to it, you'll see it as the code
> emerges. explaining it beforehand is not going to
> resolve the situation any faster.

In the meantime, until the code emerges, we don't want the zoom feature. In fact, I doubt that I will ever want it at all.

> now, i hear you when you say "i don't like it
> moving", "when i close a window, then it animates
> on me" ... i'll try and address those issues. the
> RIGHT way. you know, by addressing those issues.

Even if it didn't animate, I would not want the feature. There are people who simply don't want this feature, animated or not.

> but i'm not going to turn it into "Just another
> applet" (why? explaining it would require familiarizing
> you with the internal design of plasma) nor will i provide
> an option to remove it at this point in development.

So explain away. You are part of a community, Aaron. We are in a dialog. Your work is appreciated, however, it seems that you are turning it into a pet project and making things more difficult for your users with absolutely no justification? Maybe you (or the NSA) is using this code to eavesdrop on KDE users in a fashion similar to the Underhanded C Contest:
http://developers.slashdot.org/article.pl?sid=05/06/11/1341244&tid=156
Being so secretive with your code makes users suspicious. I really am not accusing you, but rather expressing why your stubbornness and secrecy is harmful to KDE's image. That said, I really do appreciate your work and I hope that you understand that my goal is not to attack you. All in all, I thank you for your contributions to KDE.

Please consider reopening this bug.

Hi Dotan,

thank you for your comment!

You might be aware of the recent trouble we had in our community because of comments like yours. So I would like to advise you against contributing in the way you did in the future.

If you are not aware of the recent trouble, you should take this as an even stronger indicator that you are not in the position to personally address anyone in the way you did.

Please also have a look at:
http://techbase.kde.org/Contribute/KDE_Community_HOWTO

Thanks you,

michael

@Michael:
I am unaware of recent trouble regarding comments like mine. So, apparently I am not in the position to personally address Aaron or anyone else the way that I did. I apologize, and I will be sure to read the Community Howto before I file any more bugs or comment on bugs.

I will also search bugzilla and try to find the recent offending comments, so that I will know what _not_ to do. Being how vast Bugzilla is, and it's limited search facilities are obviously not designed for this type of search, so if you could link to the offending content I will read it and learn.

Obviously, my intentions are to help make KDE better, for myself and for other KDE users. I tried to tread very carefully and explain myself in my post on this bug, yet to express the harm that is being caused by such secrecy and ignoring of user's wishes. I have no intention of trolling nor of upsetting the devs, quite the opposite, I encourage and support the KDE devs. Although I cannot contribute code, I have contributed money to KDE via Paypal several times, in fact, twice in 2008 alone.

Again, I apologize if my comments were seen as an attack, and I hope that there are no hard feelings. That said, I still am surprised and disappointed to see comments such as "nope, not re-opening. and if someone does provide a patch to make this go away or configurable or what not it'll happily live outside of trunk" by a KDE developer. I personally feel very unwelcome in a community with that attitude.

I have read the Community Howto, and I quote:
"Collaborate: communicate with others,..."

However, I am not seeing collaboration nor communication from the developer handling this bug. I am not angry, nor do I want to anger anyone, but I really feel that as a community member it is my responsibility to point this out.

Other than that, I congratulate and support ALL the devs working on KDE4. I am enjoying watching 4.1 take shape and I'm proud to be a user and a bug filer. You guys are doing an amazing job, with very little resources available to you, I know. You have my respect and my loyalty, even when issues like this turn up.

Hi Dotan,

I noticed a couple of your recent contributions to KDE and, though I occasionally disagree, I have no reason to doubt you intentions. If I sounded like I did, I'm sorry; because this time around I'm not in the position to doubt anyone's intentions.

To read up on the recent turmoil, you could use http://ervin.ipsquad.net/2008/06/25/about-stop-energy/
as a starting point.

My disagreement was solely with the way you presented your dissent. The NSA reference was surely rather ridiculous and when commenting on a feature, especially when you are commenter number 60-something, you should definitely know about that feature, as well as know about the preceding discussion.

So in this case the (stupid) off-hand reaction should have been: Aaron's stubborn, so it's no use I comment here and waste my time (and everbody else's time).

The mature reaction should have been: the lead developer of this project is of a different opinion. He's trustworthy and has a track record of knowing what is good for this project; in code and otherwise. Plasma is a really daring experiment, with new ideas in UI design. Probably I'll write him an email: Hi Aaron, I'm having trouble understanding what this toolbox does, others do as well. Could you please point me to the right information, so I can learn about it and probably even educate others.

This, of course, does not only apply to you. It's the behaviour we all should have shown from the beginning. I brought it up in reply to your comment only because our miscommunication has already done harm to this community and I hoped my remarks could help to prevent further damage.

So, Dotan, your contributions are of course greatly appreciated. We all should just try to communicate in a way that shows our mutual appreciation of each others contributions.

michael

@Michael: thanks. i had ignored Dotan's comment precisely for the reasons you noted, it's nice to have someone step up and deal with it so that i didn't have to do so yet again.

@Dotan: please just move on. i've collaborated and communicated extensively on this particular topic. i may not have collaborated with you as an individual or some of the other people in this thread. i'm not exactly beholden to interact with everyone person who happens along though. in fact, there aren't enough hours in a day to do that if i wanted to. trying to hold me to such a standard is really unrealistic.

so, let's summarize the facts here so people don't have to get lost, as you did Dotan, in the amazing number of comments on this report:

some don't like the feature, others love it. thankfully for the former group, there are ways to make it go away already. (that's the point of containments) as a specific feature, it's a lot more refined than it was a few months ago.

that is the final resolution of this issue as per the maintainer of the project (that's me).

No problem, Aaron, devs and users won't see eye to eye on everything. I appreciate your work and I look forward to seeing your developments and improvements. Take care.

*** Bug 165394 has been marked as a duplicate of this bug. ***

without reading the whole thread my 2cents:

please make that toolbox thing in the top right corner optional only, it is visually very distracting and gets in the way when trying to to window management besides it doesn't seem to have any useful function anyway, everything it does is/can be covered by a simple right click. 

For the zoom function I suggest right click mouse wheel or for keyboard users ctrl or alt or "windows key" + arrow keys and then have it zoom from the mouse position (compiz zoom plugin style...)

Ffi,

> without reading the whole thread my 2cents:

Please, read it next time, because you just repeated the wished functionality. And I don't see any point in repeating the same issues again and again. Thank you in advance.

Hi ffi,

pretty smart: not reading the other 74 comments. They're probably useless anyway and someone not as smart as you will surely just step up to explain for the 75th time what the solution for you is.

You are commenting on the default containment, that has the toolbox as an essential feature. This means it cannot be removed from this containment. There could however be various other containments, that do not have the toolbox essentially or at all. And you might be delighted to learn that indeed such containments do already exist.

I'm not stupid enough to also look the name of this containment up for you and tell you how to enable it for your desktop. But you might try to enquire on panel-devel@ about it.

michael

@Michael: Thanks for the link. I read. I understood. I'm subscribing to the dot RSS feed to keep more informed.

@ffi (comment #75): Don't be scared off by the responses to your comment. You have no idea what you just stepped into! Just blow it off and learn to read all the comments, even when they near triple digits, before commenting on bugs.

I wish a happy and productive week to all!

Since this thing is still swirling in my inbox, I just like to proffer and apology for anything unduly harsh I said here. Sorry.

I have to say, I love the overall look of Plasma...but I really do hate the thing in the top-right corner.  I feel like it clutters my desktop and just looks ridiculous.  Imagine buying a new LCD monitor and having a permanent logo painted in the top-right corner of the monitor.  It would be annoying.  Now...imagine you call the manufacturer and request they stop painting this logo on the viewable part of the display, but the manufacturer adamantly refuses to stop this.  I don't know about you, but I think I would throw the monitor out and go with a different manufacturer.  Between the annoying animated tool in the corner and the fact that the widgets I close come right back the next time I log on, I'm seriously thinking about ditching KDE 4 altogether in favor of Gnome or one of the lighter window managers.

I have been refraining to tell this for a long time to avoid spaming everyone. But since that bug has been fixed one way or an other (by allowing to change the default containement to a containement without the logo). Shouldn't this bug be marked as 'FIXED' ? This would remove the confusion brought by the 'WONTFIX' for a wish that has been 'FIXED'...

@Robert Kit:

"imagine you call the manufacturer and request they stop painting this logo on the viewable part of the display, but the manufacturer adamantly refuses to stop this."

it's not there to be a logo, nor is it hardcoded into plasma. it's part of the desktop containment, no more, and that is switchable.

"Between the annoying animated tool"

it isn't animated in 4.1

"that the widgets I close come right back the next time I log on"

also fixed in 4.1

"I'm seriously thinking about ditching KDE 4 altogether in favor of Gnome or one of the lighter window managers. "

if it prevents me from having to answer the same question yet again on this BR or having to deal with people who have unrealistic expectations for plasma in 4.0.x, please do.

@Cyrille: "Shouldn't this bug be marked as 'FIXED' ?"

maybe. i dunno; the exact feature asked for, providing a config option in DekstopContainment, is not implemented and won't be. there simply is another way to achieve what they want.

one more reason having an open-to-public-interaction bugs repo is a pita: you end up playing stupid PR games on it rather than actually use it to get work done.

Cyrille, this report is not FIXED and for those who don't like this containment at all, true, they could (? I just believe in it) use another. But for those who would like to use it but keep the desktop clean there is no other choice (*).

I am not taking seriously into consideration having several containments which are basically the same but have one plus or minus hardcoded widget.

Maciej: what would you think about wallpaper plugins that paint the background but which offer rather different functions, like a world map or a web page background or some animated stuff? i mean, why have a whole other plugin for just one hardcoded feature? that's what kdesktop did in kde3 and nobody complained. why? because ... that one hardcoded feature was the entire point of the plugin.

and that's *exactly* what Containments are, only not for wallpaper drawing but the functional layer between the wallpaper and the widgets on top.

in 4.2 these two functionalities (wallpaper layer and containment layer) will even be configured in the *same* dialog. to the user it won't even look like anything very special. i even plan to offer previews in the little monitor so as you switch between Activity Containers (or whatever we end up calling them in the UI, i haven't done any user testing for that verbage yet, but suspect we can do better than "Activity Container") you can see it change in real time in the dialog.


=== Editorial ===

please, please, please people: don't try and get involved in discussions of design. if you are technically capable of doing so, read the code and jump on panel-devel and discuss things with the rest of the team in a reasoned and well-informed manner.

otherwise, just describe your paint point (what you expected, what actually happened, the difference, etc). leave out the editorials and don't offer suggestions on how to code your preferred solution. editorials just annoy people and have no actually useful content in them (that includes calling people names, judging their competency and character, etc), while coding suggestions about a code base you aren't familiar with is .. well .. bizarre.

and yes, i realize the irony in asking people to hold the editorials by means of an editorial. but you see: that's my role here, not yours. on your project, you get to play editor and i get to play reporter-of-my-pain-point.

my commitment to you is that if you leave out the editorials and the design suggestions, i won't have a reason or a need to editorialize either.

btw, there is already an alternate desktop-plugin located at http://websvn.kde.org/trunk/playground/base/plasma/containments/blankdesktop/ and there is some work done in a gsoc that deals with it. Also it should be pretty easy to e.g. take those blank-desktop, put ~15 lines of code in to xembed e.g. mplayer and have a full video as background :)
At http://doc.trolltech.com/main-snapshot/qx11embedcontainer.html is even the sample code how to embed such a movie, anyone motivated to create such a desktop-plugin? :)

Aaron: Actually I wanted to stay out of that since there's already enough harm done here. Please know that I deeply respect your work and am far from wanting to attack you. But I need to point out to you to reconsider if you should maybe rethink something. You said in your latest reply:

***
otherwise, just describe your paint point (what you expected, what actually happened, the difference, etc). leave out the editorials and don't offer suggestions on how to code your preferred solution.
***

Actually, I think this is exactly what the submitter of this bug did. But by saying "this is intentional" because it is intentional for the *default* containment, you took the discussion to the code architecture level. If you would just have said "this will be configurable in 4.2 by the means of changing the desktop containment but won't go away for the default containment because it is part of what it is all about" and left the report open I doubt that there would have been as much controversy around this. Maybe I'm wrong about this. But I feel the main point of the arguments were that people felt you were telling them that there will be no choice for them when many of us believe that KDE is all about choice. So maybe we should all learn from this bug: we, the submitters that we should trust in the coders' vision when they say something is intensional and you, the coder, that if you expect us to describe problems on a non-architecture level you should also explain solutions on a non-architecture level (and I believe on a non-architecture level this bug is NOT a WONTFIX). Ok, sorry for using this again for communication but I just had to add this. All the best, Tobias

*** Bug 166375 has been marked as a duplicate of this bug. ***

let me give my 5 cents.

Please make the zooming thing an own plasmoid that can be connected to a certain container, so it will eg stay in the upper right when you zoom out. also please make that plasmoid a container itself. id love to put stuff in it. or remove it if unneeded.

Please think of all the "Adrian Monk"s in us: that non-removable thingy interferes with my sense of visual equability and balance, it actually hurts to have it there and not being able to remove it. 

There shouldn't be *any* fixed item on the desktop the user cannot configure to look the way s/he wants. I cannot change the icon, I cannot change the position, I cannot change the size, I cannot remove it completely. This dictatorical behaviour is completely against what KDE stood for.

It's that simple: I don't use it, I don't want it on my desktop. I want to put applets I actually use in all the corners.

thank you for this fundamentally new insight, peter. :-D

*** This bug has been confirmed by popular vote. ***

With a minimum of "Feces Flinging" has any consideration been given to shipping Open Suse's "Plain Desktop" in KDE proper. ( http://www.kdedevelopers.org/node/3734 ) While I know it's too late for 4.2, I really think a wired to the net, GHNS (or whatever it's called now), per user, 3rd party, and non-vendor packaged solution is suboptimal. By all means default to the toolbox, but I'd love to see "Plain Desktop" shipped.

*** Bug 190128 has been marked as a duplicate of this bug. ***

Frankly speaking, read all the conversation for over a year, spent two evenings trying to grok what the cashew does - and could not understand it... 

Only reading help gave an idea about activities, but I found them really inconvenient... and useless: i have to dig to desktop, find the cashew, zoom out, the zoom in to the other activity... and find myself with the same empty desktop and the same panel. Virtual desktops are more helpful. Oh, yes, I don't see any reason to have anything but wallpaper on my desktop. So activities are worthless for me, although I would not mind to have different panels for different time of day (which, I suppose, I can't).

And I completely don't understand why "Zoom out" can't appear in menu on right mouse button click and the cashew which does nothing useful can't be hidden...

Yes, it would be nice to have the cashew's menu in the right or middle mouse button desktop context menu so there would be no need for the cashew. Especially now that I discovered that a tiny panel at the top of the desktop can cover a whole big cashew I'd love to see it in the context menu. Though I really like that it can be made invisible that way I felt totally helpless without the (apparently gone) cashew('s functionality) because I couldn't zoom out without it. Maybe at least the zoom out action should go to the desktop's context menu too in case the cashew is hidden.

But I have to say now that the cashew isn't colored anymore and can be dragged away from the corner it doesn't disturb that much anymore.

*** Bug 204436 has been marked as a duplicate of this bug. ***

@94 - I would like to see activites bound to a specific virtual desktop - like folder view for desktop 1, twitter plasmoid on desktop 2, weather forecast  on desktop 3 and TV programme on desktop 4.
That would be really useful.

*** Bug 205656 has been marked as a duplicate of this bug. ***

#94 - Made a fool of myself as this is possible in 3.1. But it is still very difficult to find and not working completely as expected.

My god, this is the single most stubborn thing I have seen in KDE.. We are now at KDE 4.9, not super far from KDE 5 probably in the near future, and is there any easy way to remove this damn thing?.. Nope..

*Some one* wants to remain cryptic and not give any tangible answers as to what to actually expect, or what you can do about this issue.. If you have any problems with removing this eye-sore of a widget, you just "don't understand the all of the complexities of the KDE framework, and what we are ultimately building up to in our giant master plan"..

Sorry, but the reality is, these people don't *have* to understand all of the ins and outs of the KDE universe to realize that they don't want to keep staring at the same ugly widget 24 hours a day when they use their computer.. If I didn't know any better, I would think I am on the gnome forums..

And if your answer for this was to use that blank-desktop containment thing, then for god's sake, include blank-desktop containment in KDE by default, with out having to go to some site and download it.. Don't worry, it doesn't have to be the one that KDE uses by default.. But at least the option would be there for the vast majority (am I wrong?) that can't stand the cashew..

When I go on reddit or 4chan and see "post your desktop" threads, I can always tell some one is using KDE instantly when I see up in the corner is the cashew, eternally sitting there watching, advertising its self like "LOOK, I'M KDE!! I hope you like me, because we are going to be together for a looooong time.."

We are the 99%!.. The ones who are sick of having an incurable wart sitting on our desktop, day in and day out.. Sucking up desktop real-estate 24 hours a day, just in the infinitesmally minute chance that some day, some where, some one will want to change activities and are too lazy to use the right-click context menu like a sane person..


....Re-open this bug *now*....and fix it....

Have to agree with you Baconmon, the cashew and the decision to make it so difficult to remove is moronic and gives KDE a bad taste.  Aaron Seigo comes across as an egotistical nut on this issue.  In any case, have moved on from the sillyness, as I'm sure other KDE users and supporters have.

I agree, the fact that there is something on my desktop that is forced upon me goes against the very nature of Linux in the first place. KDE is still my favorite desktop, but there is a lot of clutter that doesn't belong, I think things can be consolidated quite a bit. There is nothing within the cashew icon I can't already do elsewhere on the desktop.

> I agree, the fact that there is something on my desktop that is forced upon me
> goes against the very nature of Linux in the first place.

The truth is that I feel as passionately about the cashew as you do. I have seen my supported users suffer with it and I have had to find workarounds.

However, I disagree that anybody is forcing you. As you stated, forcing someone goes against the very nature of Linux. You are free to use any of the other desktops, and you are free to fork KDE. In fact, there is a very nice Qt-based desktop, Razor, which also uses Oxygen themes and other KDE elements.

The reason that we feel 'forced' to suffer the cashew is because KDE is so much better than the other desktop environments that we don't want to forsake it. As with all the desktop environments, there are advantages and disadvantages. The cashew is KDE's big disadvantage. Do you realize what that means? It means that KDE is great.

Fork KDE? Sure, I'll get that done tonight. Seriously though, I think those types of comments are silly. If I had the skill level to alter KDE to suit my purposes, or fork it, I wouldn't need to submit bug/wish reports. Also, using an inferior desktop environment is not a valid solution either.

You do make valid points, however. KDE is definitely great. But the cashew icon is not necessary at all. But the cashew icon isn't my only complaint, there are others (such as performance issues on both of my machines, but that may not be caused by KDE). I still stand by my point that forcing the cashew on users goes against the nature of Linux. Not everyone is a coder that can remove it themselves, and they shouldn't have to be. If users don't want it, they shouldn't have to have it.

I support the bug, too. But I don't want to see an additional entry in the context menu. What about a simple option in one of tha tabs of System Settings -> Workspace. It could be something similar to the lock widgets functionality. Without the cashew, the activity configuration becomes unchangeable and the user cannot reactivate the cashew or change the activities inadvertently because there is no context menu and the option is only within the system settings dialog. There are a lot of people who don't want the cashew and who don't want to use activities at all. I think we should give them what they want. We want people to feel comfortable when using KDE and not to feel dominated.

Jesus, this bug report is ridiculous.
I bet it took a longer time for the developers to argue with all these people than it would have taken to fix it.

BTW: +1 (my reasons are already stated)
a quick fix is here: http://kde-apps.org/content/show.php/Py-Cashew?content=147892

Well, I see that KDE is still controlled by the same "the user doesn't know what he/she wants" attitude copped by all bogus, unskilled and narrow-minded developers.

*** Bug 320916 has been marked as a duplicate of this bug. ***