The Konversation team has started porting the application to Frameworks 5 earlier this month, getting things to build and run on top of KDE's next-generation libraries.

Here's all the info you should need to help out.

At this stage of porting there are still hundreds of low-hanging fruit (porting away from deprecated APIs, porting to slightly changed APIs, etc.) that don't require extensive knowledge of either the codebase or even the problem space to tackle, so if you were looking to get your feet wet on Frameworks 5 or KDE development in general, consider chipping in!

In fact, one of the major risks associated with any porting is lowering the quality of the application by reducing functionality or just plain breaking things, and of course we'd like to avoid both. So you can even help out by just running the port and logging the things that don't work on KDE's bug tracker (handy link is on the wiki) as tasks for others to jump on.

I'll keep things brief, since I'm inbetween KDevelop windows right now: It's out today, and in my mind it took just about nine months to make it. Nine months, now that's a timescale with some cachet.

Back in September, we had this, as best as memory serves:

• A rough initial ramp-up of the freshly-refactored low-level Plasma libraries on top of Qt 5 / Qt Quick 2.
• And on top of a similarly rough-and-in-motion Frameworks 5.
• A Plasma shell application that could render a basic wallpaper (with no config yet).
• A few "test this library API" widgets.
• Very broken and very empty panels.
• And we were still running this inside the old Plasma Desktop 4, since we didn't have kwin yet, or an actual session.

Since then, we:

• Rewrote about 80% of the core Plasma Desktop components from scratch, with significant improvements in some areas (e.g. the tray and notifications).
• Ported the rest over from 4.x, often with significant cleanup and non-trivial changes.
• Created hundreds of new visual assets from scratch.
• Ported many, many support and system integration bits, such as network management, while continuing to make significant improvements to them.
• Kept contributing fixes and features to Qt 5 in a major way.
• Continued porting and modularizing KDE's libraries, and finally shipped them as Frameworks 5.0.
• Not insignificantly, kept up supporting and releasing KDE 4 in parallel (with a major overhaul of the semantic desktop implementation in 4.13).

Kick-ass. It's been an amazingly productive time in the KDE community lately (not just in Plasma and Frameworks - KF5 porting of apps is going on as well!), and we'll be back in just three months with yet more.

Back to KDevelop.

I just give it back to KDE at least some in return of all i received in all last 10 years.
Please, if you in some ways had KDE improved your day by day , help to fund Randa meetings.

With the KDE SC 4.13 release soon, a few new features made it into Konsole.

Things have been rather quiet in Yakuake land for a while. 2014 is going to shake things up, though, so it's time for a brief look at what's been going on and where things are headed next.

Frameworks 5

Not long ago I pushed an initial port of Yakuake to Frameworks 5, the next generation of KDE's platform libraries, to Yakuake's git repository. The new code lives on a branch called frameworks for now.

Yakuake on Frameworks 5 is functional and free of the use of any deprecated APIs. The port is mostly complete, too, missing just a few more touches to the first run dialog and skin handling. Here's a screenshot:

Ah yup: Looks no different.

Wayland

One of the broader initatives the community is engaged in this year is enabling our workspaces and applications to use Wayland. Yakuake may just have a small role to play in that.

Historically, Yakuake's relationship with window managers has been plenty interesting. It's managed to crash several of the popular ones at one point or another; it's an unusual application with unusual behavior that exercises window manager code differently from more typical apps. More recently, it was perhaps the first non-workspace process to communicate and collaborate tightly with the compositor, asking KWin to perform the slide-in/out animations on its behalf if available.

The latter is a model for things to come. In Wayland, application windows know intentionally little about the environment they exist in, and instead have to petition and rely on the window manager for things like positioning with no recourse. Yakuake on X11 does this legwork by itself; on Wayland, the comm protocol to the window manager will have to be rich enough to allow for equivalent results.

Having Yakuake ported and ready will allow for it to serve as a useful testcase there.

General feature plans

Yakuake's theming system has been showing its age for a while, so I'm looking to implement a replacement for it. The new system will be based on QML, taking some inspiration from KWin's Aurorae decoration engine. The result should allow themes to support anti-aliased edges and shadows, along with much more flexible control over the placement of Yakuake's UI elements. Existing themes will continue to be supported however (by way of new-format theme that knows how to load and display the old ones -- the config UI will list both types transparently in the same list, though).

The other major feature that's been a long time coming is proper support for session restore. This has mostly been held back by missing functionality in the API of the Konsole component that provides Yakuake with terminal emulation. Unfortunately that situation remains unchanged for now, but I'm still hoping to eventually get around to some Konsole hacking to satisfy Yakuake's needs there.

Schedule thoughts

Frameworks 5 uptake in distributions has been very promising so far, with several distros (I'm aware of Fedora and Kubuntu, but there are no doubt others) packaging the preview releases soon after they were announced. It's still pre-release software, though, and APIs might still change until the stable release this summer. Until it's out, the repo's master branch will therefore continue to contain the KDE 4 codebase, and there will be another maintenance release cut from it sometime soon.

Development of the new theming system will be targeted at Qt 5 and Frameworks 5, however, due to significant API changes in the new Qt Quick and QML generation. As with the next KDE 4-based release there's currently no firm date for this - Aaron makes a good case for not rushing things - except to say it will be some time this year.

For several years, I used to maintain a collection of clippings showing the KDE workspaces in use in interesting settings - popping up on TV shows, on public terminals in odd locations, in articles on leading scientific endeavours. All sorts of cool cases. More recently I haven't been collecting as diligently anymore, though, for perhaps the best possible reason: It's happening so frequently now that individual examples have lost much of their novelty.

But from time to time it still provides me with a (pleasant) shock to the system to see our software help others push the envelope and create amazing things. The latest example occurred just the other day, while I was watching the making-of documentary for Alfonso Cuarón's impressive film Gravity:

Framestore worked for several years to provide the majority of the film's effects shots, and their London-based offices appear filled to the brim with workstations running KDE Plasma. I think I may have even spotted Yakuake on a panel in there.

Interestingly, Framestore isn't the only London-based VFX house using KDE software. I previously collected a snapshot of Doctor Who VFX provider The Mill using Plasma Desktop in their work as well.

One factor driving this adoption is perhaps the synergy between our and the industry's extensive use of and familiarity with Qt - many high-end 3D modelling and video editing/compositing packages now use Qt for their UI, and often provide PyQt as convenient extensibility solution for in-house dev teams at the studios. The same is true of KDE. But I'd like to think providing a damn nice desktop experience also has something to do with it :).

In the thick of competition, or looking purely at market share data, it's sometimes easy to forget just how much real and compelling use the stuff we make is seeing in absolute terms. And the degree to which our software permeates the foundations that big chunks of our culture get built on top of.

It's nice to reflect on that now and then.

Gravity has been nominated for ten Academy Awards recently, including the Best Visual Effects category. I loved it, and have a feeling it has a pretty good chance.

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.

Homerun Kicker

Tada.

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.

What else is new?

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.

Future plans

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.

Closing notes

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.

With some idle time on my hands due to waiting on an especially long build, I decided to put some time into cleaning up my KDevelop's UI layout today:

Click for original resolution.

I removed all but the elements I actually ever click on in the main window -- all the rest I usually access via keyboard shortcuts or the menu (which I'm now going to try using via the window deco button). Since working on an IRC client makes you feel at home with text fields at the bottom of windows, I moved those toolbars down below the bottom toolview button and moved the remaining toolbar actions into the left toolview button column (I already use label-less toolbars on the left in some other apps, e.g. Gwenview). All together, this saves a lot of vertical space, which is precious on my widescreen laptop.

I think I'm happy, though I'll have to actually use it for a while to see whether I'm not missing anything. How does your KDevelop look?

One of the many things to look forward to in the impending KDE Plasma 4.11 release is a new version of the default Task Manager applet, which had its front-facing bits rewritten from scratch, along with additional support work and improvements in the underlying library.

The motivation for the rewrite was two-fold: Address many long-standing and gnarly bugs the old applet was suffering from, and to pull the Task Manager forward into the QML era, making it ready to transition to Plasma 2. Visual and interaction changes were to be kept to a minimum for now, focusing on a regression-free port, but a leaner and meaner codebase along with QML's designed-in flexibility should make a much better foundation for future experiments.

Let's take a look at some of the improvements over the old applet :).

Side bar: The art of putting tasks on screen

There's a lot going on here.

Laying out a task manager is complicated business. Task items have preferred minimum and maximum sizes in both dimensions, derived from the current theme and font settings. This size range information factors into calculating when to break into additional rows (or columns), provided the available space and user settings allow for it. Layout also behaves akin to justified text layout, dividing available space between tasks evenly even when wrapping into multiple rows - but not allowing them to grow beyond their preferred maximum size.

The addition of launcher items complicates things further, making it necessary to carefully negotiate the peaceful graphical co-existence of two different types of items with different preferred sizes, throwing the easy assumption that all items are going to be the same out the window.

Layout also doesn't just have its internal concerns to worry about, but some external ones as well: It has to keep track of when it considers the Task Manager to be full (again drawing on the preferred size range information) and communicate that to the machinery that will try to opportunistically group windows to conserve space. It also has to generate useful size hints for the applet, allowing for things like Plasma's auto-growing/shrinking panels to work correctly.

And then all of that has to work well in both horizontal and vertical orientations, with some subtle differences to tune things for both cases.

Layout: A lot better now

Unfortunately, the old applet didn't do so well on mastering the above. Its layout code suffered from many, many bugs, ranging from just making bad placement decisions to getting stuck mid-animation to causing hangs due to infinite loops. Consistency between horizontal and vertical layout wasn't very good, with support for vertical orientation introduced via copious special-casing and being perennially out of sync with the better-maintained horizontal codepaths.

Layout is also involved with reordering tasks by Drag-and-Drop (if sorting is set to "Manual"), and in the old applet, would occasionally compute incorrect indices for the reinsertion of dragged tasks, particularly at the end of rows and when right-to-left locales like Arabic and Hebrew were used. DND across multiple rows was also a bit crashy.

Many of these bugs only surfaced in somewhat unusual configurations, with the general theme being that new layout features had been added without enough attention being paid to how they would interact with all of the permutations allowed by the feature matrix, not just the most common cases. An example would be combining the presence of launchers with multiple rows, illustrated here:

Layout gone bad: Launchers larger than tasks ...

And now it's good.

All of these bugs should hopefully be resolved by the new version's layout engine.

Consistent interactions

Not just layout behaves more consistently across features and configurations now, interacting with the Task Manager does, too. For example, the popup for window groups now supports switching between tasks via the mouse wheel and reordering tasks by dragging (again, provided sorting is set to "Manual"), just as the primary UI does.

Speaking of those group popups: Up until now, they weren't smart enough to adjust their size as windows came and went or window titles changed, and if windows set very long titles for themselves, the resulting popups could sometimes show up with unreasonably large sizes. They're much smarter now, handling these situations properly.

Group popups learned many new tricks.

Visual fixes and polish

Task buttons have frames (depending on your theme, they come in less or more varieties), and those frames aren't purely decorative - they're used to communicate important state like the identity of the active window. The old applet had several bugs in the code handling button frames, sometimes causing it to claim multiple windows as active or forgetting to reset a frame after a task context menu had been used. These kinds of bugs are gone now.

Task buttons also (well, usually - if layout thinks it has enough space for them!) have text labels with nifty-looking shadows behind them - which the old applet sometimes forgot to re-render for text changes, namely when the font settings were changed. Poof, gone as well.

Themes are also generally applied more correctly now, e.g. taking frame margins into account when making decisions on the size of elements inside them.

Playing nice with the rest of the Workspace

The Task Manager is also responsible for communicating task item positions to the window manager, so the window manager can know the destination for the minimize animation of a window. The old applet sometimes dropped the ball on this duty, causing KWin to animate windows minimizing into the center of the screen, or into outdated positions. Once more I'm happy to report the new version should take this obligation a lot more seriously.

Configuration handling

The old applet would occasionally be reluctant to apply changed settings immediately, e.g. toggling the "Force row settings" option wouldn't take effect unless the value for the "Maximum rows" setting was changed at the same time. Its successor suffers from no such compunctions.

Performance

QML is kind to us here, and it's not even the shiny OpenGL-powered Qt 5 version yet. Animations are generally a bit smoother across the board, and specifically the throbber/spinner animation used in place of the icon on task startup notification items sports a much higher frame rate than before.

It may be hard to tell from a still image, but it's spinning a lot more smoothly now.

There's also some bad news (with a side dish of glimmers-of-hope)

Sadly, a few features didn't make it into the new version - yet, at least.

One is the ability to drag tasks from the Task Manager onto the pager, a very nifty way to move windows between virtual desktops. That this wasn't retained is down to a limitation in the components we implemented to teach QML Drag-and-Drop support; I've proposed a patch to address it in Plasma 2 that may even be back-portable to KDE 4, so stay tuned for 4.11.1 possibly addressing this.

The other two are support for manual grouping and uncollapsing groups into an inline representation in the primary UI. Both seem to have relatively few users, partly due to unfriendly interaction design: Figuring out how to actually manually group windows generally took an internet search to learn about the necessary keyboard modifier. That doesn't make the regressions any less regrettable, of course, but on the other hand we will try to bring these back in much improved incarnations in Plasma 2 (or perhaps sooner). It's part of the reason why they didn't make it yet - both features had some fundamentally bad aspects to their current realization, and burdening the new codebase with their complexity was thoroughly unattractive from a cost/gain perspective. We'll do better.

Future plans

The new QML-powered Task Manager is here to stay - this is the codebase we're taking into Plasma 2, delivering on our intentions to make the transition to KDE 5 a more iterative, less disruptive one. The regressions mentioned above imply some open to-dos, and beyond that we'll be investigating new features and ideas, such as allowing apps to do more with the context menus of their launcher and task items.

Meanwhile, the move to Wayland will cause some further work as well, below the visual level this time, adapting the underlying library to KWin becoming the new authoritative source for window data.

I'm hoping you'll enjoy the new 4.11 Task Manager. If you've got any fancy ideas: Throw them my way in the comments!

PS.: A few of the things described here took final form quite late. If you have a problem with the Task Manager in one of the betas or RCs, take the above as an update on what you can expect from the final release.

On my desktop machine, I have always tried to compile "everything". At a time it was easy: about 18 SVN modules listed in kdesvn-buildrc, trunk for everything, done.
Nowadays there are many more git modules - I currently compile 234 modules, with the help of kdesrc-buildrc (I don't have to list all 234 modules, it expands them for me). Still it's a bit difficult to ensure I really have everything...