Monday saw the release of version 1.2.0 of Homerun, now a collection of launcher interfaces for Plasma Workspaces, powered by a common foundation. If you're already familiar with, or even a happy user of Homerun this description of it might make you raise an eyebrow, so let's take a look at what's new in this version.
The main addition in Homerun 1.2.0 is a second interface built atop Homerun's collection of data sources, the Homerun Kicker launcher menu shown above. Unlike the first Homerun interface, which is designed for use on the full screen or desktop background and meant to be both mouse- and finger-friendly (you can check it out here if you're new to Homerun or just need a memory boost), Homerun Kicker is a more traditional launcher menu design optimized for efficient use by mouse or touchscreen when placed on a panel.
The use of traditional, cascading popup menus is complemented by a sidebar strip in which application favorites and items related to power and session handling may be placed. Both types of items can be added, removed and reordered at will via mouse and menus, much like in the bigger, older brother.
It also has search, which - also a previously known Homerun feature - mines several different sources of data for your query. Unlike in the larger interface, however, results in Homerun Kicker are shown in dynamically created columns, one for each source:
Mmmmm. All that data.
Homerun Kicker looks and should feel simple, but has a bunch of fairly neat things going on under the hood to achieve that goal. Optimization for efficient mouse use starts with the chosen layout, but doesn't end there: The handling of mouse input is smart enough to, for example, treat a diagonal move into a sub-menu differently from vertical movement, to avoid accidentally switching to a different category when only briefly grazing menu items. The result is a menu that hopefully feels solid, dependable and hassle-free.
Keyboard aficionados have no need to feel to feel left out, either: Arrow keys and other keyboard commands work as you'd expect from a menu. Upon opening Homerun Kicker keyboard input focus is placed on the search field, so the search-and-hit-return workflow familiar to Homerun users is supported here as well.
Another feature worth mentioning is support for setting a custom image as the launcher button. The image can be non-square, enabling greater visual variety and a wider mouse click target.
With both Homerun interfaces built on the same underlying framework, several of the new things in this release pop up in both of them. Acute eyes may have already spotted a "Recent Applications" entry in the first Homerun Kicker screenshot - this is backed by a new Homerun source that can of course also be placed on tabs in the screen-spanning Homerun interface. The same goes for "Power / Session"; having a combined listing of buttons many users mentally group together had been a popular user wish in the past.
The original Homerun interface is most often used as a fullscreen launcher, but thanks to the versatility of the Plasma Workspaces architecture can also be placed on the desktop background, where it is very useful in a tablet or hybrid laptop setting. Some users felt the Plasma Desktop Toolbox getting in their way in this usage mode. It's now hidden by default, but can be toggled on and off from the configuration menu.
There's also the usual collection of minor behavior improvements and bug fixes. One particularly nasty bug could lead to the wrong apps being launched when using the "All Installed Applications" source with a particular combination of sidebar filtering and a search query - that's fixed now.
Homerun Kicker is included here as a first version that lacks some of the greater power known from its big brother. In particular, there's no graphical way to change the list and ordering of Homerun sources in the menu yet (though there's one big knob to disable the integration of non-apps data into search results if you don't want it). This is one obvious avenue for future versions to explore.
Those future versions may already be powered by Plasma Next by then - porting to Plasma Next (and therefore Qt 5 and Qt Quick 2) is on the immediate todo as well. The Plasma 1 version will continue to be supported with improvements and fixes until that transition is complete, however.
Some of the work put into Homerun Kicker and the experience gathered with it may also benefit the Plasma Next effort down the road. First reactions from the development period and the users of distributions that have already included Homerun Kicker in their default configuration indicate there's definitely an audience for a traditional menu option that integrates nicely with workspace theming, unlike the classic launcher menu widget currently bundled with Plasma Desktop. Replacing that widget with a derivative of the work accomplished here is one option that's being discussed at the moment.
Welp, that's it! Go grab the tarball or poke your favorite distro for an updated package. After checking out the goods consider providing your feedback. There's a #kde-homerun IRC channel on freenode you can stop by, and of course bugs as well as wishes can be reported at KDE Bugzilla.
looking realy good way beter that what I imagined it would.
Sho rocks again :)
Praise from the master!
Praise from the master! Thanks! :)
Eike, this is really great work. When I started reading the blog entry, and saw the kicker, I immediately thought that you abandoned the original homerunner applet. Fortunately it is not the case. :)
Now I use both homerunner and its kicker on different configurations and they both fit my workflows. Kudos! But as far as I can see there seem to be a small problem with kicker: Some tranlations does not load automatically ("Power / Session" (and its sub-items), "Recent Applications" and configuration dialog translation). The do load, but only if and after I add the homerunner (the full screen one) applet to my desktop or panel, too. Could this be intentional, or a bug?
Keep up the good work.
It's definitely not
It's definitely not intentional. I also can't reproduce it here for now, but I'll look into it more. Control over gettext translation catalog use in pure-QML applets is a bit sketchy unfortunately, and the Homerun i18n situation is a bit complex due a mix of implementation strategies for various components (a pure-QML applet, a C++ applet, a C++ standalone application, a pure-QML desktop containment, ...).
Eike, I forgot to give information about the translation file: I tested it with the Turkish (tr) translation,
Thanks! If you run "plasma
Thanks! If you run "plasma-windowed org.kde.homerun-kicker" or perhaps "KDELANG=tr plasma-windowed org.kde.homerun-kicker" from a terminal, do you see the same problem in that instance?
Yes, unfortunately, I do.
Yes, unfortunately, I do.
In case that I was doing something wrong, I also translated the empty strings in .po file with Lokalize, and recompiled, but the behaviour was the same. "Missing" translated strings seem to get initialized only when I run the main homerunner applet once and then adding the kicker to the panel or the desktop.
I will open a bug report and post the link here.
Do you have the Turkish KDE
Do you have the Turkish KDE translation pack installed?
I've just now noticed that:
KDE_LANG=tr plasma-windows org.kde.homerun-kicker
... didn't load translations here either, until I installed Fedora's kde-l10n-Turkish package. Then it worked. I previously tested with KDE_LANG=de, and already had the German language pack installed. Note that of course Homerun's translations are actually shipped with Homerun, and some of the translations that don't get loaded without the language pack are definitely specific to Homerun, so this isn't a case of the language pack covering for things. Rather this behavior must have its source elsewhere, somewhere below the applet - something's deciding not to do i18n when the kdelibs catalog is missing. It's possible adding the other applet causes the situation to change in some way as far as the loaded catalogs are concerned, I haven't fully investigated this yet.
As for "Power / Session" specifically, I've taken a look at the Turkish translation file and that string unfortunately isn't translated to that language (there's a translation but it's marked with the "fuzzy" attribute, i.e. it's not verified by a translator and doesn't get included at build time). But the above pattern applies to e.g. the items in that submenu, and "Recent Documents" and others - and when I change the translation file to mark "Power / Session" non-fuzzy, also to that string.
Bottom line: I'd double-check that you have the Turkish KDE language pack installed, and hopefully the next point release will include a more complete Turkish translation for you.
Here is the link to the bug report, I hope it will help.
Thanks, let's continue over
Thanks, let's continue over there then.