Version: (using KDE 4.4.1) OS: Linux Installed from: Debian testing/unstable Packages This is a meta bug report. I find Plasma activities quite unbearable to use and configure due to: [Bug 232172] plasma sometimes forgets which activity is assigned to which desktop [Bug 232203] New: plasma shuffles around activities for other desktops when I change the one for the current desktop [Bug 232205] plasma sometimes does not provide a handle to switch to a certain activity [Bug 232206] please implement a cancel button to the activity selection view [Bug 232211] New: activity overview view is very slow on my ThinkPad T42 [Bug 232214] New: plasma sometines invents a new generic activity Lower priority: [Bug 232209] please show activity names in activity overview For me due to all of this using and configuring plasma activities is a *very frustrating* experience. Instead of this activity overview view at the moment I would even prefer a simple configuration window where I can assign activities to desktops and be done with it. Especially Plasma should remember my setup. It should not ever change it except when I tell it to do so. I *know* what I am doing and Plasma should let me configure my desktop environment as I wish. Right now I perceive Plasma activities as unfit for regular use. For me its like using experimental software. Please feel free to add other bug reports that diminish the usability of Plasma activities to this meta bug report.
AFAIK the Activities are being reworked for KDE SC 4.5, and the ZUI (zoomable user interface) was removed.. as it was buggy and slow.. Regards
i think this bugreport should be closed...
Why? I think it could serve as a good reminder on what the new activity system planned for KDE SC 4.5 should improve upon. Well might sound a bit like a rant. And yes, I was upset fiddling for hours to fix up my setup. But then the individual bug reports are as concrete as I could make them and I tried to give constructive suggestions. Well if the activities system of KDE 4.5 SC is a complete rewrite, I would not have much of a problem, closing this meta bug report and maybe also the other ones. And reconsider the situation once KDE 4.5 SC is out. But then thats about 4 months from now still and Debian Squeeze + Ubuntu 10.04 LTS and others will likely stick with KDE 4.4 SC for quite a while. Thus it might make sense to fix at least the most critical bugs for KDE 4.4.x. I guess I will follow debian unstable/experimental/experimental-snapshots for latest KDE versions and thus will have KDE 4.5 sooner than Squeeze+1, but others might prefer to go a stabler route for perfectly valid reasons. Aside from that I find it a good habit to close a bug report when it is either fixed or it is decided that it won't be fixed or is invalid. And not because it might get fixed in the future. Then why not just wait and close it then?
I don't want to close it because it might get fixed, but because it's not really a bugreport, but a "meta bugreport". From what i know we don't have that concept in the kde bugtracker. But i did not yet close it and try to contact other people about it.
<offtopic>Meta reports are sometimes used. But you need to set the "Depends On:" field with the bug report numbers properly. That way, the only way to close the "main" meta report is to close all its children/dependencies</offtopic>
Ok, point taken. It does seem to me that I do not have the bugzilla karma to add those depends. I just see a Depends on in the bottom of this page, but no GUI controls to add dependencies.
If it was a developer or triager who was using this mechanism to track reports they were working on, that would be fine. But I really don't need a meta-duplicate-report to manage. The individual reports are quite enough.
Ok, thanks for looking at my bug reports. I admit, it was partly a rant, but I let the activities system annoy me a lot back then. Now I just log out and do a cp -p /home/martin/Backup/KDE/share/config/plasma* /home/martin/.kde/share/config where in Backup there is a fcron-job triggered two daily rdiff-backup copy of ~/.kde. Its nice to hear that you KDE developers rewrite Plasma activities from scratch. Its IMHO the best you can to do it. But really important to me is: Finish that work then, too! Main problem of the current Plasma activities system IMHO is: It looks *unfinished*. Actually it looks like unfished beta or even alpha quality software. (A problem some other areas of KDE 4 face, too, IMHO.) As I manage to take time I am willing to help with testing the new activities system. Hopefully a newer plasma can be compiled by itself without compiling all of KDE 4 on my ThinkPad T42 which doesn't have the latest and greatest CPU with lots of cores. Ideally I find a way to build debian KDE plasma packages from trunk. Probably shouldn't be that difficult.