general audience vs advanced audience

Reading Cyrille's blog entry today about Krita and GIMP appropriateness (or rather, how they are not appropriate) for a default OS installation, it got me to thinking about a common pattern we see emerge in applications.

We often end up with general audience apps that represent a good entry level position. They aren't wimps, but they certainly remain lean and the UI stays focused on what they are doing in a way that's approprirate for a general audience. They may make most people happy, particularly because the interface is nice and clean while offering the "things I want most", but they usually leave a more demanding user wanting, particularly people who are professionals in the field in question.

The professionals and enthusiasts will be looking for richer tools that Do More(tm) and often support more sophisticated models. These tools could be viewed as "upgrades" from the general audience applications except that for many people in the general audience these pro tools are vast overkill and even off putting.

The pro tools can't really be streamlined beyond a certain point without losing their audience, and the general audience tools can't be beefed up constantly without leaving behind their audience. Perhaps there is even a symbiotic relationship at play here, at least within the KDE world: the pro tools push the envelope of what's possible in ways that the general audience tools can add selections of features that straddle the general/pro audience but which are complicated to do and so more likely to show up in a pro tool in the first place; the general audience tools take the pressure off the pro tools from having to cater to too broad an audience, and the pro tools take the pressure off the general audience tools from the demands of demanding users.

(As an aside, for all the claims that one can simply have a UI adapt to the user's level of capability has never really been shown to be a real solution. I've seen it fail before, and where it has succeeded it's been for apps that themselves straddle between "general" and "advanced" in audience. Usually it just leaves a mess, and even more usually the suggestion that this is the solution comes from people who have never tried it. Aaaaanyways ..... ;)

The example of Gwenview, Digikam and Krita is a great one, I think.

With Gwenview, you get basic photo downloading from cameras and image manipulation. These "high end" (for Gwenview) features mostly comes from work laid down by the people working on the higher end photo management tools like (though not exclusively) Digikam. Sometimes feature improvements flow from the general audience app into the advanced tool app as well, but in my experience such improvements tend to be of the general audience pleasing type (as one might expect).

Meanwhile, Digikam can concentrate on being a great power tool for photographers, amateur and professional alike and Krita can concentrate on being a great power tool for artists, amateur and professional alike.

The result is a great set of apps for different audiences which help each other improve as they individually advance to better serving their specific target audience. What duplication of effort does exist is offset ten-fold by the resulting benefits for the users of each app in having something targeted to their needs. In KDE, that duplication is often very minimal.

There are other examples of this in KDE as well and they often follow very similar patterns. We have JuK and Amarok; KWrite, Kate and KDevelop; Dolphin and Konqueror ... can you think of some more?

Also, is there a pattern here that we can use when presenting our application clusters to the public?

Read More

some krunner updates

KRunner continues to grow into a really great tool to quickly get things done using words. It was intended to be something more flexible than the Run Command dialog in KDE3 that also looked nicer. I think we've achieved both of those things, and KRunner blends sexily into the rest of the Plasma Desktop. It runs asf its own process to allow some separation between the desktop and panels and the command dialog, which is also a bit different from KDE3 where it was part of the desktop itself.

I wasn't looking to create a specific work flow, per se, other than "type something in, get some results, pick one". Other projects try and create a very specific work flow (quicksilver being the grand daddy of them all), I opted for the Google-ish "a search line with results". There are strengths and challenges to both approaches, but I like the choice made in KRunner for general consumption purposes. Once can switch to a more work-flow defining mode in the configuration, however, by selecting the "Task oriented" user interface.

Since it's debut in the KDE SC4.0, KRunner has gotten a lot prettier, a lot faster, a lot more featureful and a lot more stable. It's a fairly healthy project in that regard. It's a multithreaded app that favours responsiveness, best seen in the as-you-type results, over CPU cycles (so there can be plugins running old queries that are no longer useful; KRunner just moves on instead of waiting for the to finish). The result is still very usable on low powered machines.

In KDE SC 4.4, the Runners (as KRunner's plugins are known) also power Kickoff's search and Plasma Netbook's Search and Launch activity page. Other apps can just as easily use them by linking to libplasma and using Plasma::RunnerManager.

Also new in 4.4 are support for actions-on-results in the default interface (the task oriented interface already had support for them in 4.3). They appear as little buttons attached to the respective entry, just like the configure button does. This feature uses the base work done by Ryan with Jacopo doing the UI integration into the default interace.

Jocopo's done a lot of other nice work for the 4.4 release as well, including "single runner mode" which allows a Runner to advertise that it's useful "all on its own". When it does so, with X-Plasma-SingleRunnerQueryMode in the .desktop file, one can launch KRunner with just that one runner active and an empty query box becomes synonymous with the default syntax the runner registers. Queries then get passed to just that one Runner, it's icon and name is shown in the user inteface to make this clear, and you can even set a global keyboard shortcut to bring up KRunner with a specific Runner in single runner mode. This is a really nice usage of the RunnerSyntax feature introduced in 4.3 for online help; in the apidox it is noted that RunnerSyntax might be used in the future to enable features that require knowing what a Runner is capable of, and with 4.4 we have the first application of that. Very cool.

There's also the new visual positioning of the KRunner window. While you can configure it to go back to the traditional "window floating in the middle of the screen" it now appears "glued" to the top of the screen. It plays well with top edge panels as well as applications like Yakuake (there's one top edge panel issue I still need to address before 4.4.0 is released, but there are a few months left for that to happen :), and you can move it by clicking and dragging inside the window or resize by clicking and dragging on an edge. When it's pushed into a corner, it removes the appropriate border of the window so it looks nice in such cases. The size and position are also stored and retrieved between sessions, and if you want to get it back to the center after messing around with it there's a "snap zone" in the center.

I have to admit it took me a day or two to get used to it popping out of the top of my screen after years of Alt+F2 causing a dialog to show up in the middle of my screen. With the adjustment period over (and it was quicker than I thought it might be), it feels so much more natural and is much more convenient when using KRunner to do things like unit conversions when reading a document, for instance, as the KRunner window now is now out of the way of the window. Pressing Alt-F2 a second time makes the window disappear when it is edge mounted, as well, which supports this kind of quick "check something" workflow nicely.

What isn't there is the ability to drag it to screen edges other than the top; that's probably something for 4.5. In fact, I'd like to get rid of the configuration option altogether for 4.5 and make it so that if you click-and-drag to move it and go more than X pixels from the screen edge it just pops off, and if you push it back up against a screen edge it just pops onto it. I just didn't have time to do this for 4.4; I was more concerned about getting the edge docking working nicely first. Next we can get fancy. :)

Speaking of fancy, the configuration is now embedded into the KRunner window. Dialogs-on-dialogs just sucks from a visual design perspective. There's one visual annoyance there right now, however, which I will fix for 4.4.0: the KRunner window should grow when the configuration is shown to give more room for it. The default size needed by it and a reasonable size for results is rather different. Separate windows sizes for each already works, I just need to make it automatically do this.

Of course, all this is nice and all but the real usefulness comes from what the Runner plugins themselves can offer. In addition to the usual stability, performance and feature improvements in KRunner itself, we've added some new Runners and improved on some of the existing ones. In the KDE Software Compilation v4.4 we will be shipping the following plugins for KRunner:

• KDE Workspace
  
  
  
  • Bookmarks: supports both KDE's and Firefox's bookmarks in 4.4, depending on the default browser setting
  
  
  • Calculator: still not as strong as I'd like; there were efforts to make it use libqalculate optionally (falling back to QtScript as the evaluator as it currently does), but nobody was able to confirm the thread safety of libqalculate
  
  
  • Kill: kill -9 from KRunner! New in 4.4.
  
  
  • Locations: network addresses, with some nice frills like automatically adding ftp or http depending on the domain name if a protocol wasn't provided
  
  
  • Nepomuk Search: aka "Desktop Search" in the user interface, does what you'd expect
  
  
  • Places - the places model known from Dolphin, the file dialog and kickoff, among other places (excuse the pun)
  
  
  • Powerdevil: desktop style power management from a command line! :) This includes the ability to hibernate or sleep.
  
  
  • Recent Documents
  
  
  • Services: aka "Applications" in the user interface, it's what launches applications and plugins like control panels that are registered with the system using a .desktop file (same thing that populates the app launcher menus)
  
  
  • Sessions: start new sessions, switch to existing ones, logout, shutdown and reboot
  
  
  • Shell: launch shell commands, including the ability to do things like "run as different user" or "launch in a terminal window"
  
  
  • Solid: Another new addition for 4.4, it lists storage devices allowing one to do what they might from the device notifier plasmoid in KRunner. What's really cool is that it uses the same Plasma::DataEngines as the widget, so code duplication is virtually non-existent.
  
  
  • Web Shortcuts: access all those funky "gg:", "qt:", etc. shortcuts you know and love from Konqueror; as an added bonus, it opens the URL in your default web browser .. which means they now work in Aurora, Rekonq, Firefox, whatever as long as you type it into KRunner
  
  
  • Windows: New in 4.4, this lets you switch between and manages virtual desktops and windows from KRunner's windows.
  
  


• Plasma Desktop




• Plasma Desktop Control: New in 4.4, it's the easy way to open the scripting console in plasma-desktop: desktop console




• Plasma Addons




• Audio Player Control: control any MPRIS enabled media player, which is most of the F/OSS ones. Defaults to looking for Amarok but can be configured to use different players. New in 4.4; it would be nice to see the need to configure it for the non-Amarok case removed or at least mitigated, though.


• Browser History: Return to where you've been in your browser history; speaking of which, I heard that rekonq has been using runenrs as well? If so, neat.


• Contacts: Search through your contacts and email them. Once Akonadi is in greater use (looks like contacts are there for 4.4) this should really be transitioned to use Akonadi; that will make this one a lot less of a performance hog.


• Converter: Convert units and currencies. Did you know that one carat is 0.0002 killograms? :) This uses libkunitconversion which joins KDE's Development Platform in kdelibs for 4.4


• Kate Sessions: Launch Kate sessions


• Konqueror Sessions: Launch Konqueror sessions


• Konsole Sessions: Launch Konsole sessions (a bit anti-climactic by now ;)


• Kopete: Control Kopete if it is running; go online and offline, set status messages, etc. It has code to do contact interaction, but right now Kopete's D-Bus interface isn't very amenable to this as it requires sending all the information over the wire to KRunner; so this support isn't compiled in by default for 4.4. When Kopete 2.0 comes out, we should be able to provide access to individual contact interaction features without penalty.


• Mediawiki: New in 4.4, Query mediawiki wikis. Adding a new wiki is just a .desktop file away, and we whip ones for Wikipedia, Wiki Travel, Techbase and Userbase, each appearing as a separate plugin in the configuration dialog even though they use the same plugin. That neat feature is available to any runner that would wish to do the same thanks to a clever little patch by Sebas.


• Spell Checker: Check your spelling quickly: alt+f2, spell <word>

Many more are possible, and some others are available on kde-apps.org. They can be written in C++, Python, Ruby or JavaScript (with limited functionality; I haven't yet gotten to fully expanding the JS bindings for Runners) and it would be great to see even more.

If you'd like to write one, be sure to visit the Creating Runners (C++) tutorial and find us on plasma-devel@kde.org.

Read More

Is it cold in here, or is just me?

Tomorrow the 25th (or, today the 25th, depending on when and where you are reading this ;) is when the feature and message freeze happens for the KDE Software Compilation v4.4. To quote from the schedule:

"Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.
[...]
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways)."

That means that if you haven't got a feature ready for merging yet, it's 4.5 material. If you have things in the kdereview module, please either move them to their final destination for 4.4, into extragear or back into playground. If you move something back to playground, you can move it back into kdereview when 4.5 opens up.

I spent the day clearing out the Plasma area of kdereview (there is one item left, it will probably move either into extragear or playground tomorrow), but there is still quite a list of items in there, including:

• controlflowgraph


• device-automounter


• ktimechooser


• networkmanagement


• polkit-qt-1


• solid-sysclass


• nepomuk-activities-service


• PolicyKit-kde


• guiplatformplugin_kde

If any of the above are your babies, please ensure they get dealt with quickly so I don't have to bug you about it. :)

Onwards to 4.4, and the feature completion, polishing and bug hunting season! Woo! :)

Read More

Istanbul was once Constantinople

I used to love the They Might Be Giants. In fact, I still harbor a soft spot for their whacky music. I think this is now the second time I've used that song for a blog entry title, and certainly not the second time I've made passing reference to them. However, this is not about them. It's about us. Who? KDE.

In case you've missed it, the 'K Desktop Environment' (which at one graciously brief moment of time was the 'Kool Desktop Environment') is now just 'KDE'. You can read more about how the KDE brand is being repositioned on TheDot, where the overall idea is explained with some detail.

To boil it down to bullet points:

• KDE is us, the people and the organization we form which produces these wonderful artifacts which are shared with all humanity. This highlights the community behind the success quite clearly and elevates 'KDE' to be a shared umbrella, owned equally by all involved.



• 'KDE' no longer refers to one specific piece of software as we have too many projects covering too many topics for that to work without huge confusion. "KDE releases KDE KDE version 4.4" was the old joke in the KDE promo team. Instead, each product or product grouping gets its own brand that stands next to the KDE umbrella brand.



• In one of the more important changes that occurs as a result, the "KDE desktop" is now the "Plasma Desktop" which is accompanied by the "Plasma Netbook" (and eventually "Plasma Mobile", something new-ish people are working on). It's still KDE's Plasma Desktop, and it contains not just the plasma-desktop binary but all the bits and pieces that make up the workspace. KWin, KSysGuard, KRunner, etc. are all part of the workspaces; you can find most of the components in the kdebase-workspace module. Why? Well ...



• This liberates our development libraries from the KDE workspaces. One can use Solid without requiring other pieces of software we create, or forcing your users to use a KDE workspace. That was not clear to many people in the past. Hopefully it will become clear as we take this new communication strategy on.



• This also liberates the individual applications from the KDE workspaces. It can now be clearer than ever that, yes, Amarok does run in XFCE very nicely and that, yes, Digikam does run on Windows. They are KDE software, but 'KDE software' is no longer synonymous with 'desktop'.



• Our epochal releases, such as the upcoming 4.3.4 and 4.4.0 releases, which contain our 'basic packages' providing an application platform, workspaces and many applications, are referred to as the 'KDE Software Compilation'. So it will be KDE SC 4.4.0, for instance. This is not however a brand. It is a common noun that we can use to talk about the epochal releases. It will not be marketed but it will allow us to talk to each other about our release engineering without perpetuating the confusion that "KDE is that exact bunch of stuff over there, meaning that other KDE software requires all the parts of that KDE thing".

It's not really a huge shift. We've kept the names that exist while moving some of them around a bit to make things that are clear to us internally clearer to those on the outside looking in. In fact, you can see some of these ideas already evident in official public communication over the last year or two. We've been actively discussing, designing and working towards implementation of these concepts since a little before the 4.0 release and so some of the ideas were put into practice sooner rather than later. Now is the time to draw up in a solid line, though, and implement it fully.

This is where we all come in as individuals. There is work to be done, from the About KDE dialog (which is already done, actually) to reworking our business cards to reshaping the language and layout of our websites. The work is being coordinated on the kde-promo@kde.org mailing list.

Just as important as that work is how we each carry the message of 'KDE' out into the public. We are each ambassadors of our community and that community's efforts to the world beyond. That world might be our friends and family, it may be our school or place of employment, it maybe a local technology enthusiast group, it may be the press. Wherever we go, we need to each try and communicate as clearly as we can what KDE is and avoid communicating what KDE isn't.

It will take quite a while before the message is fully realized and everyone takes for granted that 'KDE' is that awesome bunch of people who create that kick-ass software that's used all over the place. It will take consistent application of the brand names and, most importantly, the ideas behind them, over a period of time. This is the most important way each of us can help make the re-branding a success.

Which of course begs the question: what would success be? What exactly is the point? The goal is to help people understand what we're doing with enough clarity that they will be able to appreciate it as much as we do. As one person on TheDot commented, "I've always experienced KDE as a community"; that's very true for my own experience as well, and I'm sure for many of you it's been the same. It's time the whole world understood that idea, that feeling, that experience.

Maybe then they'll take another look at that one bit of KDE software that they were always interested in but stayed away from because they didn't want to get locked into using the "whole KDE catalog". Maybe they'll even discover new things to love that they didn't know we did, together, as KDE.

Read More

Javascript plasmoids

The other day I met with a couple of local entrepreneurs whom Chani had met at the recent Qt Dev Days in California. The four of us gathered around some tasty vegetarian vittles and discussed small devices, Qt and Plasma. It was a good time and we found a lot of common ground .. including agreeing that Javascript is a great language for writing little user interface elements quickly that will run reliably.

In that vein, I've been working on getting the Simplified Javascript API for writing Plasmoids ready for creating more than just toys. To that end, all the Plasma user interface elements (pushbuttons, etc) are available including the complex ones like the TabBar, Animations are fully supported, we have AnchorLayouts (and maybe even GridLayouts soon) in addition to LinearLayouts and, perhaps most exciting, we now have the ability to load API extensions.

An API extension is a security controlled set of functions and objects that are loaded on demand. These extensions are requested by the widget by listing the required and/or the optional extensions it wants loaded in its metadata.desktop file. This way, even prior to the widget being loaded we can know what it will want. The Simplified Javascript Engine then decides if the widget will actually get that extension or not.

There are a set of built-in extensions currently defined: FileDialog, LocalIO, NetworkIO, HTTP and LaunchApp. They each do what you expect, with NetworkIO being a generalization of HTTP. I'm busy implementing each of them between now and the end of next week. We aren't limited to these built-ins, however: any QScriptEngine extension plugin can be loaded, security willing, just by listing it in the metadata.desktop file. This means that widgets can be extended with arbitrary functionality.

The security framework is still in development, but all the hooks are there with some of the pieces in place now. Most importantly, we know exactly how we want to implement the missing bits. I'll be working on filling in the gaps as I can, and hopefully when Rob returns with hacking time again (or someone else steps up in the meantime) that will go a bit faster.

The other important bit has been to actually document what the Simplified Javascript API provides. The relevant file in kdebase/workspace/plasma/design/ has been morphing into increasingly comprehensive API documentation. What I need to do is turn this mammoth file int a nice set of web pages that I can add to a revamped plasma.kde.org. Any one out there up to doing some HTML slicing and dicing?

There are also a growing number of examples to augment the documentation and which are just begging for Techbase tutorials to be written around.

Add to this the progress being made with Plasmate and the ability to script plasma-desktop itself with Javascript and things are looking better and better for Javascript in 4.4. Huzzah.

In an unrelated side note, Markey's blog entry on finding a balance in software configurability is really well written and makes several excellent points with great clarity. A must read if you haven't already seen it, in my humble opinion. :)

Read More

let's do coffee ;)

Things have been crazy busy lately on every single front in my life. This has come at the expense of not blogging much at all, which has sucked. So much has been going on, a lot of it very interesting and fun and which I would have liked to share with you as it was happening. Such is life, but we need to catch up. So grab a coffee (or whatever you prefer, tea maybe? :) and let's catch up!

I ended up at a fencing competition as a spectator this weekend cheering on S. (and editing text from the sidelines for the Akademy sponsorship brochure that Claudia, Kenny and Nuno are working on; it's looking great!) and then out for dinner with old friends here in Vancouver the day after that. I also completed one of the last I-just-moved-to-a-new-province tasks as well: I got my car registered and insured with the locals here in B.C. Turns out that my B.C. drivers license expired the same year I got my now previous car insurance in Alberta, which led them to give me 14 years of safe driving and pushing me into the highest discount bracket (and one year away from the highest rating bracket over all). Still, it was one more thing that filled in my schedule.

The KDE promo team is in high gear as well, and that's keeping me a bit more busy. The promo sprint they just had was a great way to punctuate the increase in activity we've been seeing. A Dot story will apparently appear sometime soon detailing what went on at the sprint, but there have already been a number of blog entries on planet.kde.org about it. One outcome of the sprint is that we're starting to organize our communication strategies a bit more. This was not, by far, the most important result of the sprint, but it's the one that's kept me busiest. I was really impressed, and surprised even, to see how many people were at the promo sprint and, as a result, how much they accomplished. But when you have a larger group of people, you need to step up the coordination as well.

I remember the first KDE release announcement I ever wrote. It was just me and a text editor and Coolo reminding me it needed to be ready in a day or two, latest. My how things have changed (and for the better).

I've also been hacking my brains out in a few different areas for 4.4, though I'll blog about some of that later. With the feature freeze behind us, it's become apparent just which items are going to drop off my "can do for 4.4" list, however. Most notably, I'm not going to get to notification queueing or a replacement for the desktop zoom in/out feature. These will have to wait for 4.5 as I work on other items that I hope will have bigger pay offs for 4.4. The items that are being left on the cutting room floor for 4.4 will fit in well with 4.5, though, I think.

I've already come to a determination as to what the focus for the Plasma family will be in 4.5. We've already discussed it a bit on the mailing list, but I won't be announcing it publicly until Tokamak IV which will be in February in Nuremberg. We'll be toasting with the OpenSuse people (congrats on 11.2, btw!) and hopefully enjoying the company of a few friends from elsewhere in industry as well. Most importantly, we'll be setting the Plasma agenda for 4.5. Much love will be had. (Or something, it just sounded like a good ending.)

I'm also in another "prep for shows" cycle. I'm going to hopefully be making it to Fedora's FUDCon in December (congrats on F12 and the KDE spin, btw! Seems to be the most popular spin by a kilometer! :) and am gearing up for one or two others.

One show that caught my eye is the Linux Audio Conference. The people involved in getting it going are quality folk (a big shout out to Armijn!) and if there's an area that F/OSS needs attention it's audio. Our stack is a mess at the moment, and not because of API issues but because we're doing a poor job of system integration, shoving features out to our users way before the software is ready for that and the like. I'm hoping that LAC will be well attended and some positive, useful results that will lead to improvements in how we handle our audio stack with care and respect will emerge as a result. I think it's really interesting that LAC will also focus on using media and will be striving to get media content creators there as well. This should help widen the scope beyond infrastructure navel gazers when it comes to audio and get a lot of great feedback as well as grow our shared community around F/OSS audio.

Now, I couldn't mention shows without talking about the most important gathering in the next six months as far as KDE is concerned. Yes, I'm talking about Camp KDE. I'll be there and I plan to bring a truck load of hugs and inspiration with me. I hope to see you there!

Read More

constructive negativity

Some have noted that the tone on planet.kde.org has been relatively negative lately. Some have said that this is actually a good thing, because it's about being honest with ourselves and that there are silver linings waiting for us at the end. That it needs defending at all is telling.

Personally, what I get out of it is a draining of motivation and hope. It's not because these posts are negative, though. It's because they tend to have few hard facts in them, almost never offer concrete solutions and rarely sound like the author wants to be part of the solution. Which means we get left with, well, negativity and not much else. That sucks. What's worse: I don't think that's at all what is intended.

The KDE community historically has had a tendency towards pessimism. We wrap it in terms like "realism", "pragmatism" and what not, but honestly .. our community is moderately conservative and really good at identifying what's lacking, often more so than our ability to identify opportunities and potential. It's a very typical engineering-and-maths type thing to do. It's also rather easy to fall into a "being the clever critic is cool" mode, and when that's all we have to go on, our efforts suffer.

So I'd like to propose a solution, one that I'm going to do my best to follow as well. (And please remind me if I don't. :) When planning to write a critical or negative piece, something we all do from time to time and often with good reason, let's try to:

• Check our facts: do some research and bounce our thoughts off the people involved directly first. It may turn out we don't have all the facts or know all the details at play. Then we can share an accurate viewpoint versus spread misconceptions.


• Lead with facts: start from a factual basis and follow on with our opinions on the matter. There's a demonstrated tendency to leave out the facts we do know or leave them as little better than footnotes.


• Include the positives: if there are positive points as well, let's note them. It helps preserve balance and can help others discern possible motivations for the decisions thus far.


• Propose plausible solutions: if we are going to spend the time cataloging challenges, let's also spend the time and effort to catalog solutions. This is part of being constructive.


• Be prepared to support those solutions: armchair coaches are a dime a dozen and very few of us have the necessary skill and background to play the role of a professional critic: someone who is deeply knowledgeable about but not a direct participant in the field. So if we talk about a problem and propose a solution, remember that we are driven by doing more than talking. If we can't strike out and breath life into the solution ourselves, be the first to support those who can. This moves us from being disruptive because of problems to supportive of solutions.

Personally, I feel that if some of the above had been applied to each of the recent "negative" entires, they'd feel a lot more motivational, constructive and accurate. As a result, I'd expect to see more people charging into the solutions. If we really want to see something improve we need to offer a realistic assessment, a possible starting point and some inspiration so others can find their legs.

Read More

krunner atop redux

In the comments section on my last blog entry about KRunner finding a new home at the top of the screen there were a few common comments, questions and concerns. I figured I'd answer them today in a place that might be easier to notice or find than buried in the dozens of comments on the last entry. :)

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.

Read More