the "run command" dialog is a venerable part of kde and it has a number of cool tricks up its sleeve, like allowing you to run a process as another user or answering math problems.
of course, it's part of kdesktop but i want to turf kdesktop and replace it with plasma. this means i need to do something with that run command dialog. what i've decided to do is create a separate app whose primary purpose is to handle that dialog. this should help ensure it doesn't crash (smaller code base == easier to get it right) and may even allow us to do neat things like run it with a higher priority so the user has a better chance of getting it to come up if some other process starts going crazy.
i suppose i could have ripped the run command dialog widget out of kdesktop and just wrapped it up with a kapplication and been done with it, but i'm not really too happy with how the current one looks and acts. so i started writing a new one yesterday. unfortunately i had to deal with one unexpected task after another yesterday which left me with only a couple hours of coding time so i only got so far.
right now it loads up an svg image for its background, uses an argb window if you have a composition manager running for extra bling and accepts input via a line edit at the top. as the user types, the input is passed by a chain of "runners" one by one until one claims that it can handle it. the self-selected runner then populates the possibilities that match and the user can select from that. there's a little "options" label at the bottom which activates when the given runner advertises the ability to set additional options.
i need to write a cute little animation where the options "slide out" in a little drawer-like-thing. it's all about the organics =) this too will be themeable with an svg image so one can make it as obtrusive or non-obtrusive as desired. right now i'm keeping all the images in share/apps/plasma/desktoptheme/default. the goal with that is to create one place where these image files can go so people can create alternative themes (nice for accessibility?) and so other apps can use standard imagery using the Plasma::Theme class.
i also need to make the runners pluggable so that packagers can, for instance, select what search system they wish to use (e.g. strigi or beagle) and supply the runner plugin for that search. other apps could also supply their own plugins i suppose as well. i'm half (but only half) thinking of playing with kross a bit for this as well.
anyways, not counting the new class in libplasma (which actually builds now on my machine ;) it's a little under 400 lines of code at the moment but will probably triple that once it's done. and then i can scratch one more thing off the plasma todo list.
i'll post screenshots when it's a little less clumsy lookin'
Subscribe to:
Post Comments (Atom)
16 comments:
Personally I feel the text entry on the new SuSE kicker replacement provides a good starting point for how the run dialog should behave. I see this dialog as being most useful as a quick way to use the keyboard to do things. Do things could include
* Run programs (as currently)
* Perform quick calculations (as currently)
* Open documents, emails, music files, photos, etc. by name, artist, tag, or other information
* Mark items on my todo list as done
* etc.
Bear in mind using the keyboard goes beyond simply typing in a keyword or command name, it means when presented with a list of options it is important to quickly be able to select one of them with the keyboard (tabbing through just doesn't cut it).
The second thing I would want to see in this is the 'quick' part of its name. I'm very fond of the way in current KDE it tends to appear *instantly*. This is the advantage of having it part of kdesktop, though hopefully this kind of responsiveness will be possible from a separate process as well. Also on this note once started I feel it should operate quickly - fancy animations are nice as long as I don't have to wait for them to do their thing.
The minidialog is one of the parts of KDE (outside the apps) so it would make me sad were it not to be at least as good in KDE4. I'm sure I'm not alone in this. Having said that there is definitely scope to increase its usefulness, and I'm sure the plasma team will put in the effort to do so. :-)
I'm not sure of the correct terminology, but here it goes...
I'd like to see the run dialog functionality as a kpart. Then wrapped for different uses.
1. Popped up in a dialog window like a traditional run dialog.
2. Placed on the desktop.
3. Placed on a panel.
4. Added to a side panel.
5. Added to a kicker style menu.
6. Select 1 or more files or directories in a konqueror window, right click on a selected item/group and select Run (a GUI enhancement to find | xargs since you could direct the filename or optionally parts of the filename to any point in the run command).
7. Like the above, but piped to from the shell (find | krun).
8. Added to any kde program.
As anonymous already said, the first priority for a run dialog is that it needs to be FAST. Really fast. Instant fast. Basically, if I hit Alt-F2 after the desktop has loaded and it is not ready to accept input by the time I can move my fingers to the keys its too slow. There shouldn't be any visual feedback necessary to confirm that the run dialog has indeed popped up and is ready to accept input.
For example, in Windows, if I want to delete a file, I usually hit shift-delete and enter to confirm the prompt. Unfortunately, Windows likes to twiddle its thumbs for a few hundred milliseconds between getting the delete command and popping up the confirmation dialog which means sometimes it is not there by the time I hit enter, and I execute the file instead. KDE does this right, in that the delete confirmation comes up instantly I never have to worry about it. Same concept applies to the run dialog.
Long story short, this work sounds really cool, but please don't forget about speed.
i'm quite aware of the need for it to be fast. the process will live for as long as the desktop session so it will pop up instantly. not sure what i said gave you all the impression that it would be slow.
as for making it multi-function, that's the whole point of the runner class.
as for making it embeddable in other parts of the desktop interface, i have thought about interaction with the start menu, panels, desktop, etc ... and i found a good number of ways that it is quite different, ranging from form factor (the desktop layer itself is an exception here) to functionality requirements.
Hello Aaron,
How will you provide access to the run dialog's facilities from the task bar?
One of the great features of recent Gnome releases in the Deskbar applet which allows you to enter search queries, application names, website names etc. and the applet will pop up a list of 'answers' to your query.
It also allows for the possibility that there is more than one possible meaning of the text you entered. For example, if you enter a web address you may want to view that website or lookup information ABOUT that website. The "runner" mechanism you proposed presumably stops once it finds something that matches.
Another point to think about is KDE on constrained devices. Is the addition of 'yet another' process going to be a problem for them?
> How will you provide access to
> the run dialog's facilities from
> the task bar?
via a plasmoid that likely works rather similarly but in ways that make more sense for the panel. the use case of "run command" is not quite the same as the deskbar applet.
> The "runner" mechanism you
> proposed presumably stops once it
> finds something that matches.
i've considered this quite a bit: do we let one runner reply, do we let each one provide matches ...... i'm really not sure that such a multitude of matches is what is actually called for here. i'm not trying to create an all-in-wonder search interface, but a way to run "commands" quickly which might be a shell command like "killall -9 plasma" or the natural language name of an app like "Plasma" or "Spreadsheet" or a file to open or maybe an email address to start an email to.
this isn't the interface to find conversation snippets from joe about pigs in the last 3 months, however.
> not sure what i said gave you all the impression that it would be slow.
Nothing really, it just sounded like its doing a lot, which usually means it takes longer. But if it's always running then of course it doesn't matter. (the nag in me thinks of lubos's recommendation to cut down on the number of processes though)
Sounds cool anyway, can't wait to see the screenshot.
> nag in me thinks of lubos's
> recommendation to cut down on the
> number of processes though
well, with kdesktop and kicker (and if you run superkaramba, that too) all in one process, we will have made spare room for another. ;)
one of the problems we've had in the past with the run dialog is that if kdesktop crashes, the run command dialog isn't available. it really doesn't belong with the desktop ...
i suppose it could be a kded module, but that shifts the problem to kded: if a kded module locks up ..... there's already sooo many things running in kded.
if weight of the process does become a problem i can always look at the kded solution.
I always envisaged plasma replacing the start menu with a sort of semitransparent fullscreen 'start sheet' a bit like Apple's dashboard, only useful, which had a 'guess what I want to do' text entry box (like gnome deskbar) prominently in the middle.
Just realised this isn't a particularly useful comment.
> one of the problems we've had in the past with the run dialog is that if kdesktop crashes, the run command dialog isn't available. it really doesn't belong with the desktop ...
Good point, I didn't think of that. And the run dialog is pretty important if you want to bring kdesktop back up.
Don't forget the guys making katapult - maybe the would like to work together on this one because they are really keen on providing a new runner experience for Kubuntu...
One thing for the runners; it would be great if you add to the Interface of such a runner the possibility to create a QDrag object based on the currently typed string.
One thing I miss in the minicli is to drag the showing icon to kicker or to konqueror where it would create either a shortcut or a .desktop file to run a command.
Cool stuff, keep it up!
I would like to see this becoming the Quicksilver of KDE. That would rock!
well, as long as it is going to as fast as the present solution.... running separate command will never be that fast, believe me. So, don't tell us it is going to be easier to maintain, because that's not true.
But the fact is, it needs to do more than just running programs. I would love to see it doing simple math (just like bc). With C-Like interface, so I can do:
0x600+100+(66<<2) ,etc.
@tzander: yeah, making the icon(s) draggable is something that i want as well. it annoys me in kde3 too =)
@stelian: well, i don't know about becoming the quicksilver of kde. it's going to start out simple. we can take it from there one step at a time. with enough interest and love, though, who knows =)
@gregj: "running separate command will never be that fast, believe me"
what do you think kdesktop is? a magic fairy that lives in your computer? no, it's a process that runs like all the others except that it gets started when you log in and runs until you log out. same thing will happen with this new program.
> don't tell us it is going to be
> easier to maintain, because
> that's not true.
erm. a smaller code base in a single-function app tends to be more easily maintained, yes.
> But the fact is, it needs to do
> more than just running programs.
that's one of the primary motivations for providing the runner class.
"it's a process that runs like all the others except that it gets started when you log in and runs until you log out. same thing will happen with this new program."
Ah, okay. Like others commenting, I had assumed separate process == started on demand. And in my admittedly anecdotal and nonscientific experience, opening Konsole is *much* slower than opening the minicli, especially when it matters the most (a process is putting the system under heavy load and I want to kill it). A Konsole is certainly much heavier than a minicli, but I doubt it accounts for all of the difference.
If it's possible with some voodoo magic to let this background minicli process run at -19 or even realtime priority without compromising security, that's something I would very much approve of. A way to avoid it getting swapped out, even more so. (My system gets bogged down to literal unusability due to memory usage far more often than from CPU usage).
Post a Comment