> 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
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
