2014/01/28

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.

Display overclocking with XRandr

As the trends shift and more enthusiast class users start considering Linux, it is important you supply them with the tools to do all the push-it-to-the-limit overtuning effects they had available under Windows.

Monitor overclocking isn't a well documented art, especially since it can literally break the display, in a way reminiscent of 90's AMD processors literally melting their sockets. This isn't the coddled down overclocking of todays desktops, where pushing things too far just results in an unexpected reboot and need to tweak expectations lower. Try setting your monitors refresh rate to twice or more what it is rated and have fun with a dead panel.

That doesn't mean you can't overclock soundly. Trying to double your refresh rate is like trying to run an i7 at 6ghz with the stock cooler. Instead, look for incremental increases in performance like any other overclock, and hold it back from the literal edge of stability a bit so your screen lasts longer than a month.

Under Windows, as usual, the sizable install base has produced graphical tools to set refresh rates. And yet again, Linux proves its technological superiority by not requiring any such tool, xrandr has all the facilities you need to create custom display modes.

So yeah, we are using the cli here, but this is one situation I'll defend this usage - one, it requires you to know what the hell you are doing, and two it is integrated right into the display manager itself and is literally a few bash lines, and if you get a stable OC you can just add it to your xprofile or autostart scripts. In this example I'm taking a 60hz screen to 65 - start here, at the least (or on a 30hz panel at like 33), and increment up until you start seeing graphical errors or glitches. Good tests for graphical errors are fast paced rapid scene changes in 3d games, plus some repetitious pattern (to gauge burn-in), plus anything that rapidly fluctuates the subpixels color intensity, I just use a gif of rapid color flicker at 48 fps.

First, we use the cvt, provided by xorg, which stands for coordinated video timings from VESA. It generates the modelines for our desired new display profile.

cvt 1920 1080 65

Modeline "1920x1080_65.00"  188.00  1920 2048 2248 2576  1080 1083 1088 1124 -hsync +vsync

We get back this Modeline, which we will add to xrandr - note changing the quoted part just changes what we name this mode, so you can name it "oc" or "65" and be fine, since xrandr by default populates modes by resolution (ie, 1920x1080).

xrandr --newmode "1920x1080_65.00" 188.00 1920 2048 2248 2576 1080 1083 1088 1124 -hsync +vsync

So now we have a registered mode, we need to add it as a valid mode to our specific screen - running xrandr without arguments prints the state of all the display outs, find your choice screen and replace HDMI1 here with whatever it got named.

xrandr --verbose --addmode HDMI1 "1920x1080_65.00"

Then you need to actually set the mode. If after running this you see obvious glitches, revert quickly before your display is damaged. Good news is that on many panels, going ludicrously out of refresh bounds will just get you out of range errors on the display or in your xorg log (ie, my Asus IPS pannel probably is only rated for hdmi 1.2, so it can't go beyond 75hz refresh).

xrandr --output HDMI1 --mode "1920x1080_65.00"

If you encounter errors, remember you will probably need to specify the rate as well for your default modes, since most panels present multiple refresh rates and omitting may not pick the highest assumed rate.

xrandr --output HDMI1 --mode 1920x1080 --rate 60

But if it works, congratulations, you overclocked your monitor. You will have to add all the xrandr lines into an init script to run every boot, since it is a non-standard mode. I'm definitely going to be prioritizing good OC displays in the future, you can save some buck on that 120hz premium. I'd love to get an early 4k display that can support getting an OC to 90hz, since Displayport 1.3 can easily handle that.

2014/01/12

AUR Packages that should really end up in official repos!

What a strange blog topic, but something I'd like to document since I really think the only failing of Arch is the rate of official adoption of aur packages.

As a preface, I won't mention anything proprietary, because most of those packages can only be in the AUR due to the legality of distribution. Also, why would the Arch support infrastructure bear the burden of distributing other peoples proprietary blob? Though they do have some proprietary software in their repos, such as Steam and Flash, I'm not going to harp on anyone for not serving up server space for other peoples binaries.

First group - games. Plenty of games and game engines are already in community, so any foss game engine has no excuse (assuming it isn't brand new) for not getting adopted.

  • darkplaces (quake engine)
  • eduke32 + eduke32-dukeplus (duke3d engine)
  • freedoom (entirely free game assets for doom!)
  • gzdoom (doom engine)
  • hexen2 (hammer of thyrion)
  • openarena (foss quake 3 fork)
  • zandronum (foss doom engine with multiplayer)
And the second group is a plethora of KDE and qt apps and documentation that all seem to have 100+ votes but are still not in the main repos:
  • kcm-ufw
  • kcmsystemd
  • kde-thumbnailer-epub
  • kdeartwork-sounds
  • kdeplasma-applets-networkmanagement
  • kdeplasma-applets-starfield-wallpaper
  • kdeplasma-applets-veromix
  • skanlite
  • qt5-examples
  • qt5-jsbackend
I would say that a lot of these aformentioned packages all include a lot of data files like models, textures, and sounds that would take up huge amounts of server space - and I'd completely understand not including that in the main repos, if it was not for the fact games like 0 A.D. and Xonotic have their data hosted in official repos.

I also get a lot of the second set of packages I mention require the input of the original authors who may be MIA. That would explain a lot of it. And maybe some of the first group just outright said no to official Arch packaging, who knows.

I just think moving forward Arch will need to consider ramping up the process of pulling the most popular and longest running AUR packages that aren't proprietary into offical repos. My impression is that it doesn't happen nearly enough, and that can lead to overdependence on the aur when pacman and its repository system works so well. Being constrained to pkgbuilding everything you use isn't the right answer, but neither is a laissez faire avenue to getting anything into official repos on a whim.