Description: This is a small patch for kwin and ksysguard. It will add a new menu entry to the "advanced"-submenu of each window.
When you select the new "Process Information" menu entry, ksysguard will be started and the corresponding process will be selected.
This can be useful if a program is stuck or starts eating memory or whatever. It makes it easy to find out the correct process, even if there are several processes of the same name running, like it's the case for konqueror for instance.
What do you think about it usability wise? Is it good to let mom find out about processes or not?
From the usuability point of view... I believe it's redundant.
If a programm hangs I push the close button, wait 5 seconds and kwin is asking me if I want to terminate/kill the process.
If a program blocks my cpu, it is hard to get the cpu time to open the menu at all! So why this menu item if it's not reachable in those situations?! I prefer Ctrl+Alt+Escape for those cases to kill any app. Works fine for me. I really believe, this menu item is not necessary.
Where it is necessary that is: Opening ksysguard from kicker's taskbar. And if you want ksysguard to know the process of a window, give ksysguard this function (like it's working in ksnaoshot): Press the button "select window process", the ksysguard window will hide until you press another button, ksysguard determines the process id of the window you cliked on.
Best regards
Sebastian
hi, i am the same opinion...
sometimes it is hard to get the cpu time to even kill an application if this hangs up the system..
But, there could be more improvements to the Taskmanager:
1. the taskmanager doesn't save the view-settings (i always have to press Tree-view" option again when opening the taskmanager)
2. running Programms, for example "gimp", "Licq", "knotes" and other applications from "taskbar" or "systemtray", maybe EVERY user-application (also apps like xsnow that the user started even if they don't appear in taskbar or systemtray) should be displayed in a diffrent Tab inside the Taskmanager. Like this way, it is easy to find out. which of my running applications are laggy or hanging up the system.
3. the Taskmanager shoudn't be accessable by only Keyboard-shortcut or click on an Icon. it should also be accessable from one context-menu. maybe the context-menu when a user right-clicks on kicker or taskbar or systemtray.
maybe that would be some nice requests for wishlist on http://bugs.kde.org
thanks
The idea was that you should be able to find out a little more about why a program is hung before killing it.
If you don't know about ksysguard, then you won't be able to find out about it when you need it.
If I want to make a tgz from a folder, I right-click it and select "compress as tar.gz", instead of opening ark, search for the folder and compress it then. That's the idea of context menus. So why not using the same for windows?
Putting it into kicker's taskbar is just as good, but not all windows appear in the taskbar.
And regarding ksnapshot - why not putting it into the window menu too?
Each window could have a complete action menu, just like files, which lists all programs that can operate on a window or application.
The proper place for such a patch is kde-core-devel. You should post the patch and a description of why you think it is a good idea. It will be discussed and the relevant maintainers can have a look. If it's approved then you can wait for the freeze to end and commit.
It's certainly too late for 3.4, and there are more important things to be discussed on core-devel until end of march. Here it's easy to find for everyone who is interested, along with a nice screenshot.
But maybe you are right, it's just a small patch and not a large enhancement that has to be maintained. What do you think is the right place for it, kde-usability, core-devel or the bugtracker?
I think it's great, and if you're worried about Mom, there just needs to be a simple "Hide Advanced" preference in KDE control center that lets all KDE apps (including stuff as simple as the system menu) hide more advanced (and potentially dangerous) settings.
This would go a long way to making the KDE desktop less confusing for ma & pa, but accessible for advanced users.
Honestly, I'm not really worried that my mother will ever discover this menu. It's in a submenu with the name "Advanced". You get what you ask for.
I'm just not sure if it really improves usability, not only to kill half-dead programs, but also to encourage people to find out more about what is happening in the background. ksysguard isn't complete enough for that - it would be nice to see what the program is doing, what files it is touching, where it is sending data to etc.
But even then it's yet another new menu item. I think it's worth it, but I'm sure that not everyone will agree ;)
But how do you know that it's dead enough? It should be easy to find out more about the problem instead of only working around it.
I have also just implemented the Action-Menu idea, so I can add new tool to the window action menu without recompiling. ksnapshot is the next candidate for this menu. Or maybe a kdialog-based script to display open files and sockets.
Ratings & Comments
10 Comments
mom wouldnt touch the "advanced" menu of that app. (dad would dig the source code of that app ;)
From the usuability point of view... I believe it's redundant. If a programm hangs I push the close button, wait 5 seconds and kwin is asking me if I want to terminate/kill the process. If a program blocks my cpu, it is hard to get the cpu time to open the menu at all! So why this menu item if it's not reachable in those situations?! I prefer Ctrl+Alt+Escape for those cases to kill any app. Works fine for me. I really believe, this menu item is not necessary. Where it is necessary that is: Opening ksysguard from kicker's taskbar. And if you want ksysguard to know the process of a window, give ksysguard this function (like it's working in ksnaoshot): Press the button "select window process", the ksysguard window will hide until you press another button, ksysguard determines the process id of the window you cliked on. Best regards Sebastian
hi, i am the same opinion... sometimes it is hard to get the cpu time to even kill an application if this hangs up the system.. But, there could be more improvements to the Taskmanager: 1. the taskmanager doesn't save the view-settings (i always have to press Tree-view" option again when opening the taskmanager) 2. running Programms, for example "gimp", "Licq", "knotes" and other applications from "taskbar" or "systemtray", maybe EVERY user-application (also apps like xsnow that the user started even if they don't appear in taskbar or systemtray) should be displayed in a diffrent Tab inside the Taskmanager. Like this way, it is easy to find out. which of my running applications are laggy or hanging up the system. 3. the Taskmanager shoudn't be accessable by only Keyboard-shortcut or click on an Icon. it should also be accessable from one context-menu. maybe the context-menu when a user right-clicks on kicker or taskbar or systemtray. maybe that would be some nice requests for wishlist on http://bugs.kde.org thanks
The idea was that you should be able to find out a little more about why a program is hung before killing it. If you don't know about ksysguard, then you won't be able to find out about it when you need it. If I want to make a tgz from a folder, I right-click it and select "compress as tar.gz", instead of opening ark, search for the folder and compress it then. That's the idea of context menus. So why not using the same for windows? Putting it into kicker's taskbar is just as good, but not all windows appear in the taskbar. And regarding ksnapshot - why not putting it into the window menu too? Each window could have a complete action menu, just like files, which lists all programs that can operate on a window or application.
The proper place for such a patch is kde-core-devel. You should post the patch and a description of why you think it is a good idea. It will be discussed and the relevant maintainers can have a look. If it's approved then you can wait for the freeze to end and commit.
It's certainly too late for 3.4, and there are more important things to be discussed on core-devel until end of march. Here it's easy to find for everyone who is interested, along with a nice screenshot. But maybe you are right, it's just a small patch and not a large enhancement that has to be maintained. What do you think is the right place for it, kde-usability, core-devel or the bugtracker?
I think it's great, and if you're worried about Mom, there just needs to be a simple "Hide Advanced" preference in KDE control center that lets all KDE apps (including stuff as simple as the system menu) hide more advanced (and potentially dangerous) settings. This would go a long way to making the KDE desktop less confusing for ma & pa, but accessible for advanced users.
Honestly, I'm not really worried that my mother will ever discover this menu. It's in a submenu with the name "Advanced". You get what you ask for. I'm just not sure if it really improves usability, not only to kill half-dead programs, but also to encourage people to find out more about what is happening in the background. ksysguard isn't complete enough for that - it would be nice to see what the program is doing, what files it is touching, where it is sending data to etc. But even then it's yet another new menu item. I think it's worth it, but I'm sure that not everyone will agree ;)
well "to kill half-dead programs" you got xkill (Ctrl+Alt+Esc i think). ;)
But how do you know that it's dead enough? It should be easy to find out more about the problem instead of only working around it. I have also just implemented the Action-Menu idea, so I can add new tool to the window action menu without recompiling. ksnapshot is the next candidate for this menu. Or maybe a kdialog-based script to display open files and sockets.