Bullet point list time!
- Can I move the KRunner window when it's attached to the screen edge? Yes, just click and drag it around the top of the screen.
- Can I move it to another screen edge other than the top? No, but I'd be happy to get patches that make this possible. Most of the hard work should already be done at this point in making it attachable to the top of the screen. Making the dragging code move it to different screen edges and setting which borders to paint based on the scren edge shouldn't be hard at all.
- Wouldn't it be cool to just move KRunner to the edge of the screen have it attach itself? Yes, it would. Again, patches welcome as 4.4 is looming and I have a serious TODO list sitting on my desk still. :/
- Does it animate when it shows up? Yes, but you need desktop effects turned on, just as with autohide panels. The animation is very smooth and definitely helps one spot KRunner's entrance, but the screencast didn't capture it at all unfortunately; the animation would have to be uncomfortably long for recordMyDesktop to capture it.
- Does it work with Yakuake? Yes. I'm a Yakuake user, so this is not surprising. ;) They will happily overlap each other but you can also move them out of the way of each other.
- Does it work with a top panel? Yes.
- Why not integrate KRunner with Kickoff? KRunner uses a plugin system that is entirely in libplasma so that such things are possible, and in 4.4 Kickoff does indeed use these same plugins for its search thanks to work done by Ivan.
- How about a stand-alone plasmoid for KRunner that you could put in a panel or on the desktop? Great idea, one that's been posited a few times. I think there's even one or two such widgets out there on kde-look.org? If you want to propose adding such a widget you've written to KDE's Software Distribution releases (maybe in kdeplasma-addons?) I'd be happy to see it go in.
- How about making this code more generic to make edge bound windows easier? The majority of the code is already in libplasma in the form of Plasma::Dialog and Plasma::WindowEffects. What's "missing" is something that sets the window geometry according to a screen edge and the click-to-move code. Not difficult stuff to implement, but I'm not sure what the exact use cases would be. We can already use the Plasma Desktop panels for most "stick it to the edge of the screen" use cases.
- What about people who prefer it in the middle of the screen? That is why I introduced an option, something I don't do lightly but when there are certainly good reasons for the various use cases the option represents.
- What about some default matches when you first open it? While possible, and indeed something we do in Plasma Netbook, I'm not sure it really fits very nicely with the intended KRunner workflow in terms of "how often they would be used". It's why we keep a query history in the text edit, however.
- Why isn't there a scrollbar when there are more matches than fit at once? KRunner is meant to be a quick search and launch interface, not a query and wade through 100s of returns interface. Scrolling isn't the primary use case, and a scrollbar diminishes the visual layout; the current scroll buttons could be improved, however. Patches welcome. :)
- Why isn't krunner keyboard navigable? Are you telling me that your keyboard doesn't have a tab key?
Edit: two more quickies that I forgot the first time around:
- Is the multi-screen behaviour where it pops up on the screen the cursor is on preserved? Yes.
- How about making it pop down when the mouse moves to that screen edge? This would be nice, but would require a bit of work in two places: first, it should share the code for this with plasma-desktop (thankfully both apps live in the same module, so code sharing is easy) and secondly, it shouldn't interfere with panels on the same screen edge (easy to detect by looking at the available geometry on a screen). Patches welcome.
24 comments:
thx Aaron for all the answers, just a comment to the last one regarding krunner and keyboard navigation. in my opineon following keynavigation would be much more intuitive: as long as the text edit hasn't received a printable character from the keyboard, up and down keys scroll through history but from the point I press a character, the up and down keys move through the listed apps. after the text edit has been clear e.g. by backspaces the keys scroll again the history. just my two cents...
About the second to last point, I think it depends on how you use krunner. If you use krunner often as an application launcher, or even as your primary application launcher, having your most commonly-used applications available right from the beginning without having to type anything fits with that workflow perfectly in my opinion.
>> How about making this code more generic to make edge bound windows easier?
...but I'm not sure what the exact use cases would be.
Some plasmoids (especialy taskbars like fancytasks or Stasks) could benefits from this feature because they don't really need to be embedded in a panel. One can even imagine to have a specific "flag" which tells to the plasmoid that it is bound to an edge of the screen so that it can adapt it's display.
It could be useful too for plasmoids created by drag'n'drop. So if you drop something near a desktop edge, the plasmoid is bound to the edge of the screen and you don't have to create a panel (it could be great to create a quick preview of something and have it always shown above my main window.)
Maybe one can even imagine to drag a window near an edge of the screen and a live thumbnail is created and kept on top of all others windows. An other idea :dragging a window near an edge could create a "shortcut" to this window (something like the docked cashew): it reacts like an entry in the taskbar but you can place it where you want and hide/show the window by clicking on it (It could be great when managing a lot of windows because you can organize "spatialy" your taskbar entries.
(sorry for the long post and my english)
Just an other idea: why doesn't krunner automatically appear when the mouse cursor is moved to the upper screen edge. Because many KDE users still don't know krunner, this way more people would discover it.
@DanaKil: "Some plasmoids (especialy taskbars like fancytasks or Stasks) could benefits from this feature because they don't really need to be embedded in a panel."
i'm not sure i understand this sentence. it seems to be saying "they don't need to be in a panel, so put them in a panel". what, exactly, in your mind is the difference between "a panel" and whatever you'd put the plasmoids you listed in?
and maybe keep in mind that you can write panel containment plugins while you answer that, since you may end up describing a nice little project for yourself or someone to take on.
"So if you drop something near a desktop edge, the plasmoid is bound to the edge of the screen and you don't have to create a panel"
patches welcome, but this would precisely end up being a "automatically create a panel in plasma when dropped on a screen edge". getting this to work smoothly will not be trivial (mostly due to user interaction issues, e.g. trying to put something on the desktop but it ending up in a panel, but also party due to some limitations in the current plasmoid dragging support as implemented (without good reason for it not being better other than manpower availability))
"(It could be great when managing a lot of windows because you can organize "spatialy" your taskbar entries"
having tried these systems, i'm still not convinced they are real-world practical. an experimental project implementing such features might help us turn the ideas into something that actually flows well (or prove to ourselves that it's not a workable idea)
@bearsh: "as long as the text edit hasn't received a printable character from the keyboard, up and down keys scroll through history but from the point I press a character, the up and down keys move through the listed apps"
even that probably isn't necessary; press down could go to the first match when at the bottom of the history.
but even then it doesn't work great in use cases like this one:
alt+f2
up arrow N times to reach "konsole" in the back scroll
now, how do you select the second search result?
pressing down arrow, as if you had typed konsole manually, won't work (it should go to the next item in the history, right?).
one again, we're back to the tab key.
and heaven forbid that we ever move the relative position of the text edit and the results :)
@toddrme2178: "If you use krunner often as an application launcher, or even as your primary application launcher, having your most commonly-used applications available right from the beginning without having to type anything fits with that workflow perfectly in my opinion."
you're describing a primarily mouse based interface, not a keyboard driven one (which is what krunner is). in which case, i would suggest using kickoff for that which already provides you all those capabilities.
It took me a few times before I realised that I should use the tab for navigating. It seemed totally intuitive to me to use the arrow keys. You use them all the time in the browser with the proposed search queries (like google).
>>this would precisely end up being a "automatically create a panel in plasma when dropped on a screen edge"
>>what, exactly, in your mind is the difference between "a panel" and whatever you'd put the plasmoids you listed in?
actually, I though about a new formFactor (??), something like "planar", "mediacenter" and now "docked". So they are not in a panel, they are just like the docked KRunner (well, but I don't really know the underlying technologies so don't worry about what I said ;)
And thanks for your reply.
@Pascal: "You use them all the time in the browser with the proposed search queries (like google)."
which is what we use them for in krunner. search results are different than search query suggestions. google's interface makes the exact same differentiation only it doesn't show search results "live": you have to press enter or hit the Search button first to get your list.
@DanaKil: "I though about a new formFactor (??), something like "planar", "mediacenter" and now "docked""
the FormFactors you are looking for are Horizontal and Vertical. they are exactly what we use in the panel and what we'd use for such a docking system (meaning the docking system may as well just be a panel :)
"How about making it pop down when the mouse moves to that screen edge?"
if KRunner were made into a regular plasmoid, wouldn't this be achieved automatically if it were place into a auto-hidden panel?
Windows has this "Show more results" button next to the search query, when you prees it it will show Windows Search interface, Im cool with that.
@mmmike: "if KRunner were made into a regular plasmoid, wouldn't this be achieved automatically if it were place into a auto-hidden panel?"
yes; and making such a plasmoid wouldn't be very hard at all (all the display code in krunner uses QGraphicsView and nearly all the search logic code is in libplasma).
however, we intentionally made krunner a separate process from plasma-desktop so that if one or the other gets into trouble, there's at least *something* left to interact with.
ah, and regarding the krunner plasmoid, i should probably add: patches welcome :)
As far as the stand-alone widget goes (the quicksilver-esque one that is), doesn't krunner have a dbus-interface with the ability to show/hide the ui on demand? I can't find one right now but that can mean either:
1. It doesn't have one. In which case, forget this idea.
2. My experitise of dbus is lacking (quite likely).
Anyway, if it does have one I can't see the need for a specific plasmoid. As far as I can tell, it would only require the icon-plasmoid with the appropiate qdbus command-line much like you can script kwin to switch desktops with the help of qdbus.
@Jonas: it has a dbus interface ..
aseigo@independence:~/Documents> qdbus org.kde.krunner /MainApplication | grep org.kde.krunner.App
method void org.kde.krunner.App.clearHistory()
method void org.kde.krunner.App.display()
method void org.kde.krunner.App.displayWithClipboardContents()
method void org.kde.krunner.App.initializeStartupNotification()
method void org.kde.krunner.App.query(QString term)
method void org.kde.krunner.App.showTaskManager()
method void org.kde.krunner.App.showTaskManagerWithFilter(QString filterText)
method void org.kde.krunner.App.switchUser()
method void org.kde.krunner.App.clearHistory()
method void org.kde.krunner.App.display()
method void org.kde.krunner.App.displayWithClipboardContents()
method void org.kde.krunner.App.initializeStartupNotification()
method void org.kde.krunner.App.query(QString term)
method void org.kde.krunner.App.showTaskManager()
method void org.kde.krunner.App.showTaskManagerWithFilter(QString filterText)
method void org.kde.krunner.App.switchUser()
query and display are probably what you're looking for. but even then, it would "work better" as a proper plasmoid (esp as it wouldn't be a huge amount of work) since it could live more nicely on the desktop or other full screen interfaces (fully embedded) and wouldn't popup on the "wrong" screen just because the mouse was elsewhere.
still, an icon that pops up krunner ia dbus could be nice for some people. "Run Command" in the application launchers and context menus do exactly that, of course.
@toddrme2178: I use krunner as my primary application launcher too - I don't use kickoff as a launcher.
@aseigo: no this is a perfectly valid keyboard based interface workflow.
alt+f2 opens krunner that shows recently used items. up/down/left/right arrows browse the recently used items, but whenever any other key is pressed you start filling in your search entry clearing the recently used items. So I dont see how this is being moved from a keyboard driven interface to a mouse based one.
And why would you use krunner? because you want to run something fast instead of finding it from kickoff, your panel is hidden, you dont know the key combo for kickoff etc.
A central alt+f2 is ideal for all application launching needs when it gets a recently used list.
"which is what we use them for in krunner. search results are different than search query suggestions. google's interface makes the exact same differentiation only it doesn't show search results "live": you have to press enter or hit the Search button first to get your list."
With Firefox, Google, and just about everyone else you need to hit return to select the entry you want from history. In some places this also launches the search.
Once the search is launched the focus in KRunner would move on to the results. So don't start searching for items in history until they've been selected.
"and heaven forbid that we ever move the relative position of the text edit and the results :)"
True when taking habits that are specific to KRunner into account, while ignoring habits from other interfaces. However, I think using the arrow keys to shift focus to the next item you want to select might in fact be (heaven forbid!) intuitive. You might also say about tabs that a user who is used to using 3 tabs to get to the results will be confused if it were suddenly change to 1 tab, as he'd end up selecting the wrong thing. But a user who is accustomed to moving in the direction he wants to focus on might not get confused when that direction happens to change.
These are great news!
I like a lot the panel autohiding, even that I use usually the "windows can cover panel" function.
The autohiding has the great feature to glow the panel position when mouse cursor moves near it. But it has bad functionality, the mouse cursor needs to be like 15-20 pixels away from the edge to get that glow effect. I hope we could extend it to 200-250 pixels where it would start glowing and then on 150-200 pixels it would glow as strong as possible. This way the mouse is about 1/4 of the edge when the glowing starts and the panel can be noticed.
Same thing I hope for this KRunner if someone implents the edge functionality with mouse so it would pop-up.
Is there such reason to visual notification of panel when there is only few pixels to actually try the edge?
Hmm, I think this is getting a bit ridiculous....
Thanks for taking the time to reply to the comments in a new post. I know you're busy and won't be able to take the time to interact with your audience for absolutely everything KDE-related that you touch, so I really appreciate it.
RE: How about making this code more generic to make edge bound windows easier?
maybe some theme could use it to show modal dialogs always this way? doesn't apple do that? :)
RE: How about making it pop down when the mouse moves to that screen edge?
screen edge actions are already possible? maybe not with a random executable?
RE: Is the multi-screen behaviour where it pops up on the screen the cursor is on preserved? Yes.
thanks! gotta love that feature :)
Thanks for leaving the option of having krunner somewhere in the middle of the screen; it'll save us lots of arguing.
But do you really need to have a radiobutton UI for this option ? If you can use the mouse to drag krunner to this or that edge, you should be able to drag it somewhere in the middle too.
The only argument against that is discoverability but then again, you need to fix this issue for the "drag along the edges" case anyway.
Those who likes the draggin idea, please test the amarok/konversation OSD setting how you can drag the OSD window around screen and middle line on the screen to wanted position.
That kind functionality it then could be if wanted to be attached by manually.
Post a Comment