Review Request: Window runner to switch windows and desktops

[Aaron Seigo]

> On 2009-07-26 15:44:49, Ryan Bitanga wrote:
> > trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp, line 129
> > <http://reviewboard.kde.org/r/1114/diff/4/?file=9093#file9093line129>
> >
> >     One of the reasons I worked on multiple action support for KRunner in 4.2 was so that we could avoid this exact use case of having multiple subkeywords and instead make it easier for the user by providing a standard set of actions to choose from. I know this is isn't exposed in the default interface but I think the solution should be to expose it in the interface rather than have a more complex language in a runner.
> >     
> >     I also suggested you use libtaskmanager to avoid a long chain of if clauses like the one here. Using libtaskmanager also provides a more consistent feel than directly calling methods from KWindowSystem because it the user will be prompted with the same actions in the window menu and the task bar. It also simplifies the run method to a simple call to action->trigger().
> 
>  wrote:
>     I used the actions and reverted all changes in my git repository for various reasons. The most important: a runner for window management should be fast. It's a complete difference if I have to "kop close" to close my kopete window, or if I have to first search the kopete window and than to select the action. Nevertheless having the powerfull commands does not limit to add additional actions. But as long as there are no actions in the default run interface I consider it as a nice to have feature.
>     
>     About libtaskmanager: I am a KWin def. For me KWindowSystem is very high level ;-) I want to have the power KWindowSystem provides. If the plasma devs tell me to use libtaskmanager I might consider to change it, but personally I don't see any reason for it and for me the code is still good structured and easy to read.

right, so the question is "when are actions most suitable?"

to me, krunner should allow one to easily and quickly "talk" to the computer. so "kop close" is just about perfect: it's quick, it's succinct and it's me "talking" to my computer.

actions should be there, at imho, to give additional options not directly related to the query on something that does match the query. e.g. if i type in "quarterly report" and that pops up the pdf of the last report from the e.V. then selecting that action should open it ... but maybe there are other things i'd like to do with it that aren't really related to the direct query, such as deleting it or opening it with a non-default application or ...

now, we could just list all of those possibilities as other possible matches with low, but that really doesn't scale and would be a lot less convenient to navigate.

in this case, i think that showing "min/max/etc" as actions when the user just types in "kop" which brings up the kopete window as a possibility makes sense. that way the user can find the window, then access various actions on it.

this is a duplication of function ("close kop" vs "kop" and select the close action) but is likely the most flexible and natural, depending on how the user wants to go about it. i don't think such duplication of functionality will be overly common, however. most items nicely divided between "object" and "action without object"

sooo... i think the code as it stands in this patch is fine, and that adding actions to the general match case would be a nice bonus.


- Aaron


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1788
-----------------------------------------------------------


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> -----------------------------------------------------------
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> This runner lists the windows and virtual desktops. It allows to activate a selected window or switch to a selected desktop. The runner works in the following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to restrict like in first case. Following sub queries to restrict search are possible:
>    * name=: restrict on name
>    * class=: restrict on window class
>    * role=: restrict on window role
>    * desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a '=' will be interpreted as a name restriction if there is no explicit name restriction. In that case it's ignored. Example query: "window desktop=2 class=kmail role=composer" will list all open KMail composer windows on desktop 2.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1114/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin
> 
>