KWinFT packaged for openSUSE, KWin-LowLatency updated

The KWin Fast Track (KWinFT) project was recently announced and I’ve taken the liberty to package it for openSUSE Tumbleweed and Leap 15.2 in my home:KAMiKAZOW:KDE repository:
1-click install
First review: I don’t notice a difference to regular KWin – I guess that’s a good thing for a new project.

I won’t submit the package to the KDE repository after they refused to accept KWin-LowLatency because they don’t want 3rd party packages there. They will just do the same again. If they ever change their minds, I’ll be happy to submit both again.

Speaking of which: I’ve updated KWin-LowLatency to 5.18.4-4.

Working around the Wrong Cursor bug

Every once in a while I need to do a fresh installation (usually because of new hardware) and then I encounter this:

wrong-cursor-demonstration.gif

This is a long-known bug with countless Reddit/Forum/… posts with often the correct answer how to fix it.

So what I decided to do is to make a package that does that semi-automatically:

1-click install

Basically the problem is: When there’s no “default” set in /usr/share/icons/, Plasma or KWin or whatever doesn’t always pick the selected cursor set (happens only under X11, not Wayland) and this package simply installs a default theme that contains no cursor files and merely inherits Breeze.

Here’s the source code if you want to make sure nothing nefarious is going on.

Dolphin-Emu under openSUSE Leap 42.3

EDIT: Thanks to a tip in the comments, Qt 5.6 support is restored for now. Something broke Fedora 27, though. Once Dolphin adopts Qt 5.9-specific features, I’ll proceed as originally mentioned below.

Original post:
A day after I formally announced my game console emulator repository, the Dolphin Emulator guys decided to merge a patch that makes Qt 5.9 mandatory. That means Dolphin is no longer compatible with openSUSE Leap 42.3 which comes with Qt 5.6.

I take pride in myself for having a high-quality product, even if it’s just free video game stuff. Therefore my plan is this instead of simply disabling 42.3 and calling it a day:

I’ll pick the last commit before that patch and build that Dolphin revision. Then I’ll disable the 42.3 target and build the most recent version for the other distributions. That way the last 42.3-compatible binaries stay on the download server until I remove the 42.3 target entirely which will be either when Leap 15.1 gets released or maybe even earlier.

I don’t think the impact will be that big, though. For gaming it’s important anyway to migrate to new base OS anyway because of all the performance improvements that come with new kernel and Mesa versions but for now the 42.3 users are covered.

Video game emulators for Linux

What started as an effort to package Ishiiruka-Dolphin for Linux has grown into a broader project. It grew in silence but I thought it’s time I formally announce it.

My Open Build Service repository ships release versions of:

And it ships regular Git snapshots (for very active projects almost daily) of:

Everything in this repo is 100% legal. Games, firmware, or BIOS dumps are NOT included and will never be (unless someone makes a legal reimplementation of those). Some emulators are still highly experimental (such as Decaf) and don’t even work for anything but simple homebrew stuff.

It’s not always possible but I try to target the current and the last Fedora releases, the current and the last openSUSE Leap releases, as well as openSUSE Tumbleweed. I build for x86-64 only. Some of the packages would also build for CentOS, Mageia, and 32bit x86 but I decided not not enable these build targets to reduce strain on OBS servers – I’d be happy to accept tweaks and fixes, should anyone of you fork a package into your OBS home repo and build it there.

Dolphin/Ishiiruka users might also be interested in this collection of gamepad layout presets: https://gitlab.com/KAMiKAZOW/Dolphin-360-Linux.

UPDATE: Added bsnes.

Adoption of Flatpak vs Snap (2018 edition)

This is an update to my blog post from last year.

Here some facts for context, should anyone read this sometime down the road:

  • Today is 8 June 2018
  • Latest Flatpak:
    0.11.8.1, released today (0.11.8.0 was released yesterday)
    0.10.4 “Stable” released on 14 February 2018 (last old stable was 0.8.9)
  • Latest Snapd:
    2.32.9 released 21 days ago

Because Flatpak comes in two types, regular release (0.11.x) and “Stable” (=LTS, 0.10.x), the latest Stable release counts as well. With Flatpak 0.11.8’s hotfix only released 4 hours ago, it could not have passed the QA of any serious distribution, so 0.11.7 counts as latest for now.

Green means the latest version is in an official repository.
Yellow means that either the latest version is in an add-on repo or the package is in an official repository but with some problems.
Red means either not available at all or in some barely maintained (or even abandoned) add-on repository.

Flatpak Snap
Arch Linux Extra / Latest release AUR only / Latest release
Debian Latest in Stretch Outdated everywhere (even Sid)
Fedora Latest release Outdated and clashing with SELinux
Gentoo Overlay with latest release Overlay outdated
Mageia 0.10.3 Not available
openSUSE Latest in TW / Latest LTS in Leap15 Outdated / In add-on repo only
RHEL/CentOS 0.8.8 Not available
Ubuntu Latest in Bionic Latest in Bionic

Flatpak is continuing to go strong. In case of Mageia it graduated from the development Cauldron branch into a proper Mageia release, even though they forgot to package 0.10.4 and only ship 0.10.3, so while more users can no use Flatpak packages, they went from green to yellow because of that update oversight.
openSUSE’s conservative Leap releases also carry Flatpak now, not only their rolling release, so things actually improved while staying green.
Weirdly enough CentOS, while shipping Flatpak and not Snapd, does not even ship the last Old Stable release.

Positive developments for Snap have been that it graduated in Fedora from a totally broken build in a user repository to the main one. There are problems with SELinux (which is enabled by default on Fedora) but I don’t know how serious they are, so I give them the benefit of the doubt and rate it yellow instead of red.

In Arch Linux Snapd got demoted from the Community repo to AUR, however that at least carries the latest release.

In an attempt to increase the adoption rate of Snap, Canonical hired people to package Snapd for competing distributors. To a degree it seems to have paid off because Arch, Fedora, and openSUSE packages at least have some outside contributors, however only the AUR package is not outdated. Even Debian’s Snapd package is no longer the latest release. So while Snapd managed to cut the number of red cells down, the Debian packagers also dropped the ball and now they’ve lost their green table cell.

Just like last year, smaller distributions seem to gravitate more towards Flatpak than Snapd (like OpenMandriva).

So while things changed here and there, IMO Flatpak is still the way to go, especially for those software vendors that target professional users with Flatpak being supported by CentOS/RHEL, Debian, openSUSE Leap, and even the current LTS release of Ubuntu. Snap packages OTOH are only 100% supported by Ubuntu. Even other distributions that carry it do with some downsides.

Qt Web Renderers Greatly Improved in openSUSE Leap 15 and TW

With the upcoming release of Leap 15.0 and current snapshots of Tumbleweed, the rolling release variant, openSUSE users get important updates to both QtWebKit and QtWebEngine.

QtWebKit

QtWebKit was officially abandoned by Qt Company in Qt 5.6. As the name suggests, it is a port of the WebKit engine primarily developed by Apple for Safari. Until recently openSUSE shipped the abandoned version of QtWebKit, however Konstantin Tokarev maintains an independent version of QtWebKit which merges work of the old Qt port with improvements the WebKit-GTK port made, like using CMake instead of QMake. More importantly, this new QtWebKit 5.212 raises the security patchlevel to that of WebKit-GTK 2.12 and also includes some additional backports. While that is hardly state of the art and I would strongly recommend against using a QtWebKit browser to surf the web, it is a huge improvement over shipping an abandoned release.

Shoutouts to Max Lin who brought QtWebKit 5.12 to openSUSE.

There are still good reasons why QtWebKit makes sense in certain controlled environments. WebKit works with more CPU architectures and uses less memory than QtWebEngine.

I have packaged a version of the QupZilla 1.8 web browser for evaluation purposes. You can use it to find and report bugs in QtWebKit but – as I said – I would not recommend using it as daily web browser.

QtWebEngine

QtWebEngine is the official successor of QtWebKit. It is based on the Chromium codebase developed by Google for Chrome. In most cases, it is a very good choice but there is also a downside: Its releases are tied to the rest of Qt 5. This is less of a problem for Tumbleweed which usually gets the latest Qt 5 version anyway but it is a big problem for Leap which as a distribution with long-term support uses the latest LTS version of Qt 5. During the support cycle of a Qt 5 LTS version, updates ship less frequently until only the most crucial bugs are fixed. The previous LTS version, 5.6, was released in March 2016 and did not get a single bugfix release between October 2016 (v5.6.2) and September 2017 (v5.6.3) and there hasn’t been one since. While that may be fine for the rest of Qt 5.6, there have been a bunch of security fixes to the Chromium codebase that users did not get.

This changes now. Following the example of the Fedora KDE team, we now ship the latest QtWebEngine release regardless of the rest of Qt.

This means: Leap 15 has Qt 5.9 LTS and QtWebEngine 5.10.1 and will get QtWebEngine 5.11 and further future versions ASAP.

As an added bonus, we even ship additional security fixes that are not in 5.10.1. This is thanks to the work done in Fedora whose patches we could simply apply without much work on our part. Additional thanks to Fabian Vogt of openSUSE’s KDE team who helped me a lot with some scripting magic required when mixing different Qt and QtWebEngine versions.

Ishiiruka-Dolphin (GameCube/Wii Emulator) for Linux

You may have heard about Dolphin, not our file manager but the GameCube and Wii emulator of the same name. What you may not have heard of is Ishiiruka, a fork of Dolphin that prioritizes performance over emulation accuracy – and clean code if comments by an upstream Dolphin author on Reddit are to be believed.

Although Ishiiruka began as a reaction to remove the Direct3D 9 renderer in the Windows version of Dolphin (which is probably why the Linux community ignored it for the most part), it also began to tackle other performance issues such as “micro stuttering”.

Recently the Git master branch of Ishiiruka shipped compilation fixes for Linux, so I decided to dust off my old dolphin-emu.spec file and give it a try (I’m hardly an expert packager). So after some dabbling I succeeded. For now only Fedora 24, Fedora 25, and openSUSE Tumbleweed are supported. The packages are available from https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

openSUSE Leap requires some workaround because it defaults to GCC 4. I plan to look into it at a later time. Once Tino creates a new Stable branch that incorporates the Linux fixes, I’ll post it under https://software.opensuse.org/package/ishiiruka-dolphin. (Quick update: It is now available on openSUSE Leap. The Stable builds as well. In addition to that, all openSUSE builds now build against shared wxWidgets 3.1 instead of statically linking the included one.)

If anyone of you is interested in Arch, Debian, Ubuntu,… packages (anything supported by OBS), I’ll gladly accept Submit Requests for PKGBUILD etc. files at https://build.opensuse.org/project/show/home:KAMiKAZOW:Emulators.

Get it from https://software.opensuse.org/package/ishiiruka-dolphin and https://software.opensuse.org/package/ishiiruka-dolphin-unstable.

Adoption of Flatpak vs Snap

A recent blog post says that KDE is still undecided on which containerized application format to support. Inspired by a post in a heated discussion on Phoronix I decided to investigate on my own how well various distributions support either format, so here’s a table with the results:

Flatpak Snap
Arch Linux Extra / Latest release Community repo /
Out-of-date
Debian Latest in Stretch Latest in Stretch
Fedora Latest release (F24 and newer) Not in main distro /
COPR outdated (no F25)
Gentoo Overlay with latest release Overlay outdated
Mageia Not available
openSUSE 0.8.0 in Tumbleweed, latest in review Failed and outdated builds in add-on repo only
Ubuntu Latest in Zesty Latest in Zesty

Given these results alone, I’m quite frankly pretty puzzled how the jury could still be out and that’s completely ignoring the centralized nature of Snap. Distributing AppImages via Steam makes more sense than Snap (Steam has the same centralized nature as Snap). Not only does every somewhat mainstream distribution ship Steam in some non-free repo, it would also allow us to distribute applications to Windows and macOS.

Even Snap’s home turf, Ubuntu, supports Flatpak since 16.10. Canonical employee Zygmunt Krynicki (zyga) was tasked to package Snap for various distributions but didn’t touch most packages since about half a year (no idea why). The COPR for Fedora does neither ship the latest Snap release nor does it support the latest Fedora version (F25). Builds in the OBS repo for openSUSE all fail, even though openSUSE also uses AppArmor, which Snap relies on for its security features instead of SELinux. The only distribution outside the Debian/Ubuntu ecosystem that adopted Snap at all in an official repository was Arch and that one does not even ship the latest release – despite Arch’s rolling release nature. Meanwhile Flatpak was adopted by every somewhat major distribution except Gentoo (and even there the 3rd party overlay is more up-to-date than Snap’s). Smaller distributions like Intel’s ClearLinux and Solus also adopted Flatpak (I encourage to read the Solus post for some great insight).

Note: I’m not a developer, so I see myself as an outsider looking in on that topic who just wanted to contribute some stats. Although my current focus is packaging (RPM), I had no closer look at either format other than distribution support for the table above. I also disabled comments in this case, just because I don’t want to fragment discussion further. Head to the original blog post if you want to comment on this topic.

Xbox pads under Fedora 24

After the release of Rocket League beta for Linux, I decided to install Steam under Fedora 24 and try it out.

The Xbox controller driver is not installed by default. Get it via

sudo dnf install kernel-modules-extra

Apparently the SteamOS variant of the xpad driver has some additions the normal kernel driver does not (yet) have.

To install it:

  1. Uninstall kernel-modules-extra (if installed; the upstream driver conflicts with the SteamOS version):
    sudo dnf -y remove kernel-modules-extra
  2. Enable negativo17’s Steam repo:
    sudo dnf config-manager --add-repo=http://negativo17.org/repos/fedora-steam.repo
  3. Install the dkms-xpad driver:
    sudo dnf -y install dkms-xpad kernel-devel
  4. Build the kernel module:
    sudo dkms install -m xpad/4.1

Not sure if I did a sudo modprobe xpad afterwards but now it works. Have fun.

Send Firefox tabs to your phone via KDE Connect

EDIT: This guide no longer works because the Launchy extension is not compatible with recent Firefox versions! Use Plasma Browser Integration instead.

Even though I criticized Mozilla in the past on my blog, in the end I always returned to Firefox as my main browser, as it the most customizable browser while also (nowadays) very fast and stable.

Today I want to talk about how to marry to KDE Connect, one of the most awesome pieces of technology to come from KDE in recent years.

Everybody who once used KDE Connect is immediately hooked to it. Some say it even was the inspiration for Apple’s Continuity feature.

KDE Connect works both ways but the user interface mostly just exposes sending stuff from your phone to your PC which has been an annoyance for me.
Luckily it is solved now. Today I’ve read about indicator-kdeconnect by Viko Adi Rahmawan (EDIT: Looks like the project was abandoned. Bajoja forked the project and applied a few fixes recently. You can find it at https://github.com/Bajoja/indicator-kdeconnect).
indicator-kdeconnect is mostly a port of KDE Connect to desktops that use App Indicators, such as Ubuntu Unity. However it also comes with a very handy tool called kdeconnect-send that allows you to do just what I was missing: Send links and files from the PC to the phone.

Sending files is IMO not that important as KDE Connect allows to browse the phone’s file system (at least when the phone is running Android 4.4) but sending the current tab to read it on the go is where the fun is.

To do that you obviously first have to install KDE Connect on both your PC and Android device and then pair your devices.

Then install indicator-kdeconnect. For (K)Ubuntu the necessary steps are outlined here. I packaged the tool for Fedora myself, available here.

The third step is installing Launchy for Firefox.

The fourth and final step is to manually edit launchy.xml. Details how to do that are outlined in Launchy’s Preferences window.
The code you have to add to Launchy is:

<?xml version="1.0" encoding="UTF-8"?>
<configurations xmlns="http://launchy.mozdev.org/configurations">
<application>
<label>KDE Connect</label>
<type>1</type>
<command>/usr/bin/kdeconnect-send</command>
</application>
</configurations>

After you restarted Firefox you should have this button:
Launchy

On Android it then looks like this in the notification drawer:
Screenshot_2014-11-22-01-21-28

Have fun!

PS: I didn’t yet investigate why it’s not building under openSUSE. I send the spec file upstream. If you have a fix, please sent it upstream as well. Also no (Build)Requirements for Mageia are currently in the file. Again: If you have Mageia and want to make this tool available there as well, please send your additions directly upstream.

Very short 4.8 first look (from a user’s perspective)

The release candidates of the 4.8 generation are out since a few days and now also openSUSE packages are available in the KDE Unstable repository.

Release candidates by KDE are usually very solid with incomplete translations as biggest drawback but since translating is usually done during RC phase, it’s to be expected.

Plasma Desktop

I’m not a friend of bright desktop themes which is why I always change the Plasma theme from Air to something else on the first day and never see Air again until I do a fresh install for whatver reason. So I can’t comment if the Air theme itself has changed. What I noticed when I switched to Air out of curiosity was the giant size of the clock:


This is in Air alone. In the dark Oxygen theme the clock looks not like someone screaming at me that my eyes are bad. 😉

Possible theme changes aside, from an end-user point of view, the desktop hasn’t changed.  The device notifier uses new technology inside but it looks and behaves just like the old one.

There is a slight graphical glitch in Plasma Network Management but openSUSE has some random (likely untested) git checkout of that in its Unstable repository, so I’m not sure if that’s a Plasma Desktop bug or a PNM bug.

A small but nice change in the Oxygen window decoration is that the X button now glows red when hovering it. IMO that improves usability quite a bit:

Dolphin

A big user-visible change is Dolphin 2.0. As Peter explained last August, 2.0’s file directory code is a complete rewrite and it shows immediately. Dolphin 2.0’s workflow hasn’t changed, so there’s no need to re-adjust, but what’s there is a whole new level of polish:

As you can see in that YouTube video (WebM version available), all operations that require icons to be re-sorted have a fluid animation (lags in that video are due the recording process – it’s 100% fluid on my low-end laptop). Directory reading speed is also much better now.

I encountered three small bugs, though. I’m not sure if I’m the exeption or if those bugs are the rule with the new version:

Bug 264434 Dolphin doesn’t remember the columns widths in details view

Bug 281598 Geometry issues when increasing width of information panel (not exactly my problem but Peter closed my Bug 289851 as dupe)

Bug 289850 Size column uses KiB only
Other than those minor bugs, the experience is great!

Kontact

With 4.8 I also bit the bullet and switched to Kontact 4.8. I kept using Kontact 4.4 under KR 4.7 because of its bad reputation. My personal mail accounts – thanks to mailing lists I subscribed to – contain several tens of thousands e-mails. So any migration naturally takes its time.

Overall the experience with Kontact 4.8 is OK. From what I see the biggest problems aren’t actually problems with the programs itself but bad communication by the applications.
I also use Thunderbird for my work-related e-mail because I like to keep work and private mails separate. So I can actually compare both.
Kontact just like Thunderbird index mails for quick search. With as many mails as I have, both TB and Kontact take their time but here the bad communication comes into play:
TB says in its status bar in an unobtrusive manner that it indexes the mails. Kontact says nothing. It sits there, some Akonadi process eats roughly 30% CPU power and no common user knows what’s going on.

So there the problem is that Kontact does not talk at all. In another case Kontact talks too much. When I put my laptop in standby and later wake it  up, I get a notification for each mail account that the resource is broken and that the account if offline because of that.
No, nothing is broken. Standby simply caused the internet connection to be severed.
In another case – when I manually flag a mail as spam – I get the notification that the mail can’t be moved, even though it was successfully moved to the Trash folder at the same time.

So what would common users think? Probably something like this: “Kontact causes high workload and admits it’s broken all the time.”

Another problem is the result of an actual bugfix. KMail 1.x could only handle one operation at the time. This occasionally caused the GUI to freeze. The Akonadi back-end still can only do one operation at the time but now the GUI is responsive. So KMail2 downloaded 7,000 mails from one IMAP account and I could still use the application. So I went to another account (already synced) and wanted to read a mail just to get a “Retrieving folder contents” message for the time it synced the other account. Well, at least KMail told me what was going on.

Luckily such large-scale syncs are a one-time thing. After setting Kontact 4.8 up initially, the experience is smooth. In fact I find it smoother than Kontact 4.4. The GUI freezing fix may cause irritation during large-scale syncs but on a daily basis it’s way better. Bug 193514 has also been fixed. Those two have been two of the most hated bugs in KDE history.
I can’t tell how Kontact 4.6 and 4.7 have been but 4.8 is a solid improvement over 4.4. And no, Thunderbird is not better. It has better notifications but that’s it.

That’s it for now. I didn’t notice other changes so far but from what I gathered from blogs, most changes are under the hood anyway. So you may or may not benefit from them.

Forking the FSF – RMS and Steve Jobs

If you’ve read the blogosphere around GNU (Planet GNOME etc.) you’ve probably heard that some people are really upset about a comment by Richard M. Stallman about Steve Jobs’ death. RMS wrote “Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died” and continued with a requoted phrase said about a corrupt mayor: “I’m not glad he’s dead, but I’m glad he’s gone.”

I’m not sure forking the FSF would solve any problems. Despite what RMS sometimes says, the FSF is broken in its foundations. From the very focused goal to build a completely free operating system called GNU the FSF transformed to ‘everything that vaguely adheres to our standards can call itself a GNU project and we’ll throw an occasional political manifesto on top of it all’.

The FSF doesn’t need a fork. Newer organizations already took over FSF’s former responsibilities: ‘Software Freedom Law Center’ does the majority of legal work. Linux provides the kernel and KDE and GNOME (officially still a GNU project but de facto without relation) provide the userspace tools.

As for RMS himself: I don’t think his political ideals are wrong or go too far. As even Apple itself once said: “people who are crazy enough to think they can change the world, are the ones who do”.
We shouldn’t compromise our ideals of Free Software or – in broader terms – free knowledge for everybody but IMO we don’t RMS any longer because we have more than just him now. People like SFLC’s Eben Moglen reflect more about what they are about to say.
IMO arguments for free software/knowledge weigh more when there is no crazy talk mixed in. It’s a plain fact that while Apple is hardly perfect from our perspective, Steve Jobs made Apple way more open than Apple under John Sculley, Michael Spindler, and Gil Amelio. Everything was proprietary. After Apple bought NeXT and effectively NeXT took over Apple’s operations, suddenly we had an Apple that contributes to GCC, releases its new NeXTStep-derived operating system’s core (Darwin) under a LGPL-like license, creates WebKit, maintains CUPS, and is the main driver of LLVM.

So to get back to the first paragraph: I’m glad we had Steve Jobs. Not only did his decisions result in improvements of FOSS itself, he helped to break the dominance of Windows and let people accept that there are alternatives that not only work as well as Windows but even surpass it.

Get the branding: Unofficial KDE abbreviations list

Sometime last year I expressed my thoughts on the kde-promo mailing list that one of the reasons for lacking support of the KDE rebranding initiative from 2009 was the lack of official abbreviations – after all, “KDE 4.7” is easier to write than “KDE Plasma Desktop 4.7”. I got no responses but for the last months I didn’t really care a lot.

After yesterday’s announcement of KDE Frameworks 5.0 I’ve seen talk about “KDE 5.0” on several web sites. But as anyone into KDE knows, there is no KDE5. Reading the mailing lists and other Planet KDE posts, it seems to me that the Plasma Workspaces won’t necessarily jump to the next major version once Frameworks 5.0 are released.

So here’s the list of abbreviations that I personally use since a while and also saw a few others use as well:

  • KPW – KDE Plasma Workspaces: All shells developed by KDE.
  • KPD – KDE Plasma Desktop: The shell by KDE for desktop computers.
  • KPN – KDE Plasma Netbook: The netbook shell.
  • KF5 – KDE Frameworks 5: Successor of KDE Platform and kdelibs.
  • KApps: KDE Applications: Applications written by KDE.
  • KR: KDE Release: Coordinated release of several KDE modules twice per year. Formerly called Software Compilation (KSC/SC4) or K Desktop Environment. (KR is probably the most common abbreviation as openSUSE uses that since quite some time to refer to its own release repositories.)

So that’s it. Remember: That list is in no way officially endorsed by KDE Promo, KDE e.V., or anyone else.
As with all 3-letter abbreviations: Conflicting meanings exist – be it Kathy’s Patch Works, or a Netherlands telecommunications provider. So use them only if the context is clear.

WTH?!? I need to use AdBlock on AdBlock?

After my last blog post I promised myself to concentrate more on KDE again but this blows my mind:
My AdBlock Plus extension for Firefox was updated recently. Today I opened its context menu and found a huge “Recommend us on Facebook” button in the menu.

WTF?!?

Luckily Firefox’ GUI is itself rendered with FF’s own rendering engine which means that AdBlock Plus can block parts of the GUI.
A quick look into ABP’s forums turned out to have a solution already: Just subscribe to the “Antisocial” list on http://adversity.uk.to/

Short Review of GNOME Shell

It feels a bit weird to be part of KDE land and be a bit of the conservative guy these days. We had our first Plasma Desktop release three years ago and the first fully user-targeted 4.2 release two years ago. Since then things improved on a steady but not revolutionary pace. Well, that’s not entirely true for our back-ends as I feel that eg. QML is a very revolutionary move for developers but the desktop experience from a user’s POV stayed largely the same.

As I have an open mind, I of course gave GNOME and lately GNOME Shell a try and today I upgraded my GNOME installation to 3.0 beta 2.

Startup

What I noticed immediately was the lack of a splash screen. Since I upgraded from an older release and the settings were kept, I stared at a entirely black screen for a few seconds because in the meantime I deleted the wallpaper I had selected before. I honestly didn’t know at that time what if anything went wrong. While some say progress bars are evil from a usability standpoint, I at least like it when something is moving to ensure me that nothing is hanging. With clean settings you stare at blue stripes for a while but you still can’t be 100% sure anything is loading at all. I find our smoothly fading Plasma splash screen way better.

Launching Applications

Starting applications is a bit weird. First you have to open the Activities screen (so far OK). Then you can either run them from the Dock-like bar on the left side which in my case only held Firefox and Nautilus or (and this is the weird part) switch from the current ‘Windows’ view to the ‘Applications’ view. Initially I didn’t even understand that the two Windows and Applications “buttons” are clickable. They follow no convention known to me to indicate that they are clickable instead of being mere titles of some sort.

And even if they indicated that: As the default ‘Windows’ view shows a Exposé-like view of all open windows (in the current Activity), I’d expect the ‘Applications’ view to show all running applications regardless how many windows are open. (Yeah, I know. Knowing about applications and which windows they spawn is considered geeky these days.)

Alt-F2 also works but it’s a simple command prompt. IMO the Shell crew should adopt something akin to our Runner for a future release.

Maximize and Minimize

There is quite a big fuss going on about the decision to drop Maximize and Minimize buttons by default. I don’t think it’s much of an issue. The new concept behind GNOME Shell is clear: Less window management but instead Activities management.

Switching between maximized and windowed state all the time seems so 1990s to me. These days you either have a rather high resolution screen with which running maximized windows makes no sense at all or you have a portable device like a netbook or small laptop where windows should open maximized by default anyway. Windows nevertheless can still be maximized or windowed by double-clicking the title bar or via Aero Snap-like gestures (dragging the window to the top of the screen – other Aero Snap gestures are also available).

The missing Minimize button is another story. While it’s clear that Minimize is no longer needed, provided that good activity management is in place, it currently is not.

Neither do new windows spawn in new Activities by default (which IMO would make sense given the paradigm), nor is moving windows between Activities easily accessible just as the Activity switcher is not.

Better Activity accessibility is something likely to be in line for 3.2 in fall.

The Little Things

It’s little but I fell in love with it: The way startup feedback of applications work. Here in KDE land we have the jumping cursor which I also love. In GNOME Shell a roundish progress writes the title of the application into the task bar.

One aspect I found a but weird was Firefox: For some reason under GNOME Shell placing the mouse cursor somewhere inside the Firefox window makes it completely change its appearance. In FF the cursor is back with white outline while outside of FF it has inverted colours. WTF? It can’t be Firefox’ fault because under Plasma the cursor doesn’t change to something completely different.

A rather big usability fuckup is the introduction of a new switch widget to replace checkboxes. I have the same on my touchscreen phone where they work because I have to use my thick fingers to activate options but on cursor-driven GUIs they just look clumsy.

The “Is that a clickable button?” question also hit me when fiddling in GNOME Control Center. The “Back to All Settings” button doesn’t look like a button at all.

The title bars of windows are a bit too big. I don’t mind them to be bigger than before (after all the average screen resolution increased) but in 3.0 it’s a bit too much.

Conclusion

The most important question is: Is it good? And yes, it is. There are quirks here and there but it’s just a dot-0 release. In time they’ll be ironed out. I’m sure.

Is GNOME Shell something to imitate for Plasma? No. Like often there is no objectively right way to approach users. There are a few concepts that can be adapted however. The application startup notification may be worth trying out adopting in an alternative task bar Plasma widget but my guess it that it won’t look good in a cramped task bar.

Shell’s Acitvity approach is IMO also no something that works well with the existing Plasma Desktop but I think something along Shell’s lines would work well for Plasma Netbook and Plasma Mobile.

Will I switch? No, definitely not. GNOME Shell is good but from my point of view it’s also fundamentally flawed.

  1. Shell is a plugin to the Mutter window manager. Crashing the window manager means crashing everything. While typing this review I switched back and forth from my other session and at some point I had just a back screen with a mouse cursor and locked input – meaning I couldn’t even switch back to my main session running Plasma. I had to forcefully turn off my PC (luckily Blogilo saves automatically every few minutes).
    Not only that but being a window manager plugin also means I can’t choose to use a different WM with Shell. KWin allows me to on the fly turn off compositing. It’s nice because my GPU is too old to handle compositing and GPU-accelerated HD video decoding at the same time. Mutter does not and KWin can’t be used with Shell.
  2. It’s still GNOME. By default GNOME shows only a handful of options in GUIs. GNOME has many hidden settings but it’s my opinion that settings should be organized well instead of being hidden. While it’s true that our own past releases tended to have options simply thrown together, we changed our approach since 4.0 and the results are great, usable, configurable but not crippled applications like Gwenview, Dolphin, Marble, etc.
    In GNOME 3.0 I couldn’t even find a way to change Shell, Mutter, and GTK themes. Maybe I am missing some pref pane package but so far it looks like everything moved into hidden settings.

Rating: B+

Did you read Planet GNOME lately?

Planet GNOME is a good read lately. After Canonical found it to be a great idea to take 75% of revenue away from GNOME Foundation for an application Canonical didn’t even develop, discussions about older experiences of Canonical’s “interaction” with the GNOME community.

It basically goes on like this: Mark Shuttleworth blames GNOME for allegedly being close-minded for not adopting app indicators and GNOME people are arguing that the rejection was solely based on bad timing (feature freeze too close) and disagreement about the implementation on a purely technological level.

Whatever the truth is (read the posts and decide yourself), the aspect I find most amusing is the irony that Shuttleworth on one hand portrays himself as a victim of GNOME’s alleged high entry barrier for contributions and on the other hand requires contributors to Canonical projects (incl. the indicator library) to assign all copyrights to Canonical and rejects patches because Ubuntu is not a democracy and all design decisions are made solely by Canonical.
Either Shuttleworth is a great comedian or he really does not get the disconnection between his acts and what he preaches.

Nokia’s risk with Microsoft and the “Mobile computer” loophole

You heard by now that Nokia chose to use Windows Phone 7 as main smartphone OS.

I certainly won’t buy any WP phone ever. I’d rather buy some Android phone as long as it doesn’t depend on Windows (like Samsung’s AFAIK do).

As you may recall, Palm went a similar route before: PalmSource developed PalmOS 6 based on many technologies from BeOS. They had a superior OS but Palm never used it in any devices. Instead they sticked with PalmOS 5: Outdated technology but binary compatible to existing applications.
As PalmOS 5 was gradually replaced with Symbian as dominant OS, Palm partnered with Microsoft and shipped Windows Mobile on its devices. In the short term it helped Palm gain back some market share. In the meantime PalmSource was bought by ACCESS and Palm worked on webOS.
webOS seems to be a very nice OS but clinging to PalmOS 5 first and later partnering with Microsoft distracted Palm. The result: webOS came too late. Palm was bought by HP.

Change some nouns above and you’ll pretty much get Nokia’s recent history.

However, Nokia at least was wise enough to have two loopholes: The first is that Qt stays for lower end phones which means Nokia won’t stop developing it. The second is – and that one seems underrepresented in the news coverage – Nokia still plans to develop MeeGo “computers”.
You may not know it but by Nokia’s official terminology the Maemo-based N900 is not a smartphone. It’s not a phone at all. It’s a “mobile computer” that happens to be usable as phone.

If Nokia continues those “mobile computers”, the situation is not so grim. However if Nokia really bets on MS – and history showed us that doing that is a safe bet for doom – I’ll say Lenovo will buy them.

Quick look at Firefox 4 for Qt4

A while ago I blogged that I left Firefox for Rekonq. Sadly that didn’t last long because Flash keeps causing crashes.

So for a while I used Konqueror in KHTML mode. While Flash didn’t crash there, it did other weird stuff such as painting over the toolbar when during scrolling.

So I tried Chromium… gosh, that GUI is really unbearable when using under a KDE environment.

Then I went back to Firefox but being so fed up with FF3, I tried FF4. To my surprise at least its performance was immensely improved. The GUI however was not. Well, at least I could restore most functionality (status bar via an extension, real stop/reload button via rearranging). Thanks to SUSE’s KMozillaHelper application I also have some Plasma Workspace integration but FF3 had that as well, so no news there.

When I’ve read yesterday that a Qt version of Firefox is now available, I decided to try it. After all, the screenshots on that website didn’t look so bad, right?

Well, time to put them into a KDE perspective:


Default window after first launch.


Accessing a menu (context menus don’t work at all, bzw)


Firefox-Qt’s Open/Save window

There you have it: Don’t bee too exited, yet. FF-Qt still has a long way to go.

EDIT:
I just made the mistake to scroll in one web site. Half the page turned white.

So Canonical ported Unity to Qt…

In case you haven’t heard already: Canonical ported Unity to Qt.
So far it’s only advertised as option for people without 3D drivers (like the EFL port of UNR before Unity) and no plan to make this default at some point has been announced.

To me it seems very weird, though. All that replacing and porting over and over again (UNR port to EFL, later a rewrite of UNR as Unity for Clutter/Mutter, then porting Unity from Vala/Mutter to C++/Compiz and now from Clutter to Qt with whatever window manager) makes me wonder if there are people in charge at Canonical who don’t change their mind every few months…

From a KDE perspective the increased adoption of Qt is certainly a plus but OTOH losing (or at least cutting down) Aurélien Gâteau’s paid work on KDE software is sad (he’s now part of the Unity porting team). He already announced his plans to work more on KDE software in his free time, so we won’t lose him as a community member but I fear his Unity work will go to waste in a similar way as EFL UNR just because some manager decides that everything has to be ported to Moonlight/Java/FLTK/Android/… six months from now……

What do you think is the overall picture? Will Unity-Qt help KDE due increased Qt adoption or will the work force transfer hurt KDE? Or will nothing change for us at all?

What’s Nokia doing in MeeGo?

EDIT 2: Damn, I’m so dump. I had the answers already but I totally forgot about them. I posted something similar to this blog post in the comments section of that article but being a bit ill (not surprising in November..) I completely forgot about it and never checked back.
Due weird circumstances my websearching brought me back to that article where I found a reply by Nokia’s Quim Gil. He wrote:

The apps included in the MeeGo Handset UX are the top of a complex iceberg. Nokia is contributing heavily to Core OS and Handset UX, from Kernel to MeeGo Touch Framework. The Handset application/services layer in MeeGo products from Nokia will be heavily tied to Ovi and Nokia proprietary apps. It would be quite schizophrenic to also develop the open alternatives. Still you can see Nokia’s involvement in Mozilla, KOffice and essential application back-ends like Kcal or Buteo.

Now we have it: Nokia won’t open source the actual front-ends. The code for the Handset UX front-ends is just meant to be a reference implementation and nothing to ever become a usable product on its own.

Apart from MeeGo Touch Framework (a component I wasn’t really aware of at that time, even though I had heard the name before but it never caught my attention) Nokia is involved with upstream projects for back-end services.
A misconception (likely due my unclear use of words because I’m not a native English speaker) in said comments section was that I accused Nokia to be not involved in FOSS except Qt. That is not what I meant. Both my comment and this blog post were solely about MeeGo-specific projects and not multi-purpose upstream projects like Mozilla where Nokia is developing a Qt port of Firefox Mobile.

With my regained memory about the VisionMobile article, let me say a few words about the comparison of MeeGo Handset and Android. If the MeeGo Handset front-ends stay a mere reference implementation, cheap smartphone manufacturers will more likely opt for Android because even stock Android is a polished product. The development may occur behind closed doors but a complete end to end stack is released with each development cycle.

This however may serve as opportunity for us KDE people. If Plasma Mobile + our apps turn out as polished product bundle, we “only” have to make potential MeeGo adopters aware of it as in “Just take it all for free. You only need to set a branded wallpaper and you’re set. If you do encounter bugs, our development is open – just submit a patch.”

Now that it’s all settled, I can go to bed again. 😉 For reference I keep my original blog post below:

Continue reading “What’s Nokia doing in MeeGo?”