Software Rants 18: Things to do in KDE for 2014

So it has been a year and I'm still a KDE fanboy. Qt is a great toolkit that needs way more adoption, and QML fixes any gripes I had with c++ widgets. I'm still of the opinion a top priority needs to move the entire qt / kde codebase back towards utilizing the STL, but honestly I can't blame anyone involved for not wanting to try to port tens of millions of lines of code to a new language version, especially when that would prompt a lot of architectural changes (smart pointers, atomics, std::thread, lambdas, constexprs).

My biggest issue is always finding something to do that isn't overwhelming. Today I had an idea - I use btrfs, I was going to write a script to automate my snapshots. After a few minutes in bash, I found instructions to write an EOF to sudo, and gaged a bit, then went to Python. And then I'm thinking "why don't I throw a gui on this and make it official"?

My natural tendency is to move sysadmin features into a KCM module, but if I were to do that I would want to use frameworks 5 and write it in qml, which isn't quite mature yet. Principally I'd be writing code I couldn't use myself on my own system, which is a bit of a no-no, since it would be such a short project.

So I want to go over everything I think could help KDE in 2014, in terms of bug fixes and features, assuming current trajectories place a frameworks 5 release around June and the entire KDE ecosystem switching over sometime in early 2015.

• Menu-in-titlebar : Currently, there is a library called appmenu that allows you to put application menus in an icon in the title bar. This is good, but the next iteration is to place the full menu in the title - personally, I'd implement this as an extension of appmenu, so that on sufficiently small windows the menu collapses into the app icon. When the titlebar isn't big enough to filt the whole menu, you have a minimum title size (determined by study, whatever is the minimum set of characters to uniquely identify a window in, say, two standard deviations of all windows) and fill the rest of the bar as much as possible with the menu, from the left to right. If the whole menu fits, the title can either right-align all the time, or center in the remaining space. If the whole menu doesn't fit, you have two arrows on eithe end to scroll the bar, which also works as a flickable and with the mousewheel. If you invoke a menu through keybind, such as the file menu, it would animate the slide to bring it into the frame if it isn't already visible. I would also imagine other controls you could integrate into a titlebar, such as per-window brightness, contrast, volume, pitch, and base.
• Window / display sharing : Miracast is supposed to show up in Mesa this year, but as a technology it is woefully lacking. We should also see Daala released this year - hopefully taking the video codec world by storm. Whenever that happens an evaluation will be needed on open codecs for one that can do streaming with low latency and good compression like h264 streaming seen in Miracast, Shield, OnLive, etc. This technology needs to be standardized beyond KDE, so it can be used as a window share protocol for Wayland for network transport, for use in RDP to help with its bandwidth constraints, and open video conferencing. WebRTC and Jingle are both projects involved in this domain, so whatever matures out of there could be wide-band adopted as window, screen, and livestreaming across the desktop. An intuitive implementation could be a killer feature for years.
• Timeline : Rosa has an implementation of an activity timeline already in release, and should see adoption in the broader ecosystem. A lot of features from Rosa should probably go mainline kde, since they all seem well integrated with Plasma Active and Desktop.
• When I create a new folder, Dolphin shouldn't pop up a dialog, it should make the folder while I enter a name field. This is actually what happens with the qt files dialog.
• Rekonq : I really want to use rekonq. Probably yesterday. The footprint is much lower, it has a super fast rendering engine, and it integrates so well into the desktop. My problems with it all stem from core features of Firefox I just need available, and its its implementation of an addon API to mimic Chromes so it can use all of their apps will be the deal breaker. The other aspect is syncing - it currently only does Chrome bookmarks syncing. If it can act as a Chrome browser for syncing purposes, it would be set.
• Deep screen recording integration : KSnapshot should at least have an option to record to vp8 or ogv with a start / stop record button that is keybindable. Since opengl recording requires injection, dedicated programs suffice, but having one of those as well would be nice. In theory, though, you would want to expand KSnapshot's sharing features to send images to others, and to broadcast live video or send the recorded footage. I'd definitely like to tackle this problem domain this year.
• An active solution to small buttons : Plasma Active has one problem right now, which is that most buttons are too small. I expect that in kf5 the theming engine will be reworked enough to easily specify a scaling factor on all interactables (probably through some deep qt integration), rather than just individual elements, so the desktop can have its traditional metaphor that can elegantly scale down to the mobile form factor with one slider.
• Distributed cloud accounts : It would be infeasible to have a completely free desktop like KDE provide per-user networked accounts with a verbose sharing policy with akonadi, plus all your per-app settings, plus your saved passwords, etc. An alternative solution is to effectively combine bittorrent sync and wallet passphrases - run a daemon that seeds and shares wallet data with the swarm, with a few orders of duplication and information sharing (ie, each account is duped in fractional parts across the whole network, and you can rebuild your own complete network account database, which has that access logged in case someone is trying to brute force you. Plus, every IP could have fail-2-ban on a swarm scale, so anyone trying to brute force  pull all accounts would have their ip ranges blocked quickly for short lockouts but ones that make raiding the entire swarm infeasible. Because if you had this system, you could have a secure share of your passwords, bookmarks, application preferences, you can share files in your kde cache, etc. It would require some kind of usage limit so someone doesn't just dump data into the cloud and overwhelm it, but it should be able to hold at least voice mails and several photos or short video clips.

I'll add to this list as I think of new things, but I hope this is a bright year for the KDE project, and that I can find the time to crank out some of these ideas. First I want to finish the cadeques book and read the kf5 documentation in progress.