German Wikipedia now has a proper KDE article. Yours too?

Today I’m plagued by headache and somehow I had the weird idea that rewriting KDE’s German Wikipedia articles helps me distracting from the pain. Even weirder: it worked (up until I finished – now my head hurts again).

Well… I’m sure you’ve heard of KDE’s rebranding. Whatever you may think about it, it’s not going away for the foreseeable future. That said, often people (incl. KDE-affine distributors like Mandriva) still refer to SC4 as KDE4 and fail to understand that “KDE” is now the organization and I partially blame Wikipedia for it. Or KDE’s inability to prepare modifications for the main KDE articles for various languages in time for the rebranding announcement, to be more precise – I guess due being overworked.

Better late than never: I’ve split the main KDE article in two: KDE now only refers to the organization. K Desktop Environment is a new article that only covers the old releases 1–3. I reorganized and extended the remaining info in KDE. A separate article for SC4 already existed for quite some time, so no need for me to fiddle with it today.

So why did I write this blog post? To tell the world how great I am? Yes!
Just kidding.
Despite my main motivation to get distracted from my headache longer, I hope to have encouraged you to check your language’s Wikipedia article(s) if they need to be reworked as well and to rework them if necessary.

EDIT: For reference, I think linking to the English articles as well might be helpful.

• KDE: Describes the organization and links to individual releases. Articles about the organization should give an overview about the project as a whole and the also explain KDE e.V.
  The KDE navigation at the bottom is nice, even though I doubt that individual articles for components like “KDEBase” are needed. IMO that causes only unnecessary  fragmentation and higher workload for maintainability. To counter that, I already merged all articles related to KDE’s PIM apps into Kontact a while ago.
• KDE 1, KDE 2, KDE 3: English Wikipedia has individual articles for all major releases. Given the length of the KDE 2 and 3 articles, that was a good decision.
  You should check the length of already existing info about KDE 1–3 and ask yourself if you’re willing to write full-length articles about each major release. For German I think a single “K Desktop Environment” (1–3) article serves better.
• KDE Software Compilation 4: Call the sub-chapters for 4.0–4.3 simply “KDE” and from 4.4 onward as “KDE SC”.

The English and German Wikipedia articles have a good selection of references. I should be easier to simply look there instead of doing all the research on your own.

Plasma-Netbook Mockup

The following blog post is mainly targeted at plasma-devel subsribers and I expect possible discussion to take place there. I just published it here, because I needed an easy way to host images and then I thought I could also post the entire text here for a broader audience to see.

While my task within KDE is mainly to translate K3b, I see myself as a usability geek as well. So while cycling through parks in my hometown and enjoying the spring weather, I thought about improving the netbook experience. And while I continued to think about it Plasma applets I already know exist and how they could be incorporated and refined. I also remembered using classic Mac OS which featured a pointer-based GUI that was targeted at screens that have roughly the same proportions as today’s netbooks.

I have to add that I don’t know how in what shape Plasma Netbook in current trunk is, so my suggestions may even already be obsolete. I also lack any talent to code, so obviously I’m hoping for an actual programmer to pick up my ideas.

So, enough introduction talk. Let’s get started.
First, here is a screenshot of Plasma Netbook from SC 4.4 showing the "Search and Launch" page:

Plasma Netbook how it looks today

Page One displays various Plasma applets in an aligned way. So overall I think this screenshot is pretty self explanatory. One aspect is worth pointing out: How task switching currently works. You click on the Running Apps "button" and get an Exposé view of all open windows.
This IMHO has some drawbacks. A.) it requires compositing (not available to everyone) and B.) totally breaks down if many windows are open.

Well, classic Mac OS had a simple drop-down list of running apps. Hardly fancy, but worked really well, so this is what I came up with:

Plasma Netbook mockup: No active app

I moved clock and tray to the far right where IMO it’s expected by many users anyway. "Show all windows" triggers the Exposé effect, so no functionality is lost. The menu could also be assigned to a keyboard shortcut.

When an application runs, the top bar changes:

Plasma Netbook mockup: App active

On the left side is still the app switcher, but now also featuring the options to hide or quit the app (Quit and Show All maybe should switch positions). The button title switches to the app name to indicate what’s running.
The pages bar is changed to the app’s menu bar. Plasma Netbook works in a similar fashion already, but by simply launching apps in full screen and hiding the window decoration. My proposal should look better esp. if smoothly transitioned from pages bar to menu bar (eg. using a slide effect).
A similar menu bar is already implemented by Bespin’s XBar applet. Another approach seems to be in development.

On the far left side, window control buttons move clock and tray. I figured that in this case it’s more important to keep users’ muscle memory for window operations intact rather than tray interaction.
The window controls are what we are all used to:
Minimize/Hide — Unmaximize — Close.
It can be argued that netbook users should run their application always in full screen anyway, but this would effectively kill the usage of multi-window apps. I also saw several people connect bigger screens at home to their netbooks. An unmaximized window can more easily be moved to the other screen. That feature is also already developed.

Any comments (praise, insults, volunteering coders) should be send to plasma-devel.

=-=-=-=-=
Powered by Blogilo

Konqueror doesn’t pass Acid2 (occasionally)

Five years ago it was announced that Konqueror is the second browser of all to pass Acid2.
Just for fun I thought to check how KHTML is doing these days and ran Acid 2 and 3 with it. Well… how times change…

rekonq (QtWebKit) and Konqueror (KHTML) – each in its latest version.

Interestingly enough, the red nose bug is triggered by running Acid3 before. The rendering glitches next to the eyes only appear when you enter http://acid2.acidtests.org/#top directly into the URL bar. If you instead first browse to http://acid2.acidtests.org/ and then click to take the test, that glitch doesn’t exist. Running Acid3 before doesn’t seem to affect the eye bug.

Even weirder, as mentioned in the year old bug report, if you try to run Acid3 again after running it once, the test doesn’t even start.

So, in case any KHTML dev reads Planet KDE, I suggest that you take a look at the bug report and investigate why one website (in this case Acid3) affects how another site renders.

=-=-=-=-=
Powered by Blogilo

Very rough plans for K3b 2.1

Michał (the lead K3b developer) is busy preparing K3b 2.0 for release. However we have some rough plans how to proceed after that release. I’d like to share them with you.

Keep in mind that Michał is currently pretty much the only developer (I’m just a translator who occasionally lends a hand on janitorial work if within my capabilities), so in the end it depends on the amount of time and work he can put into K3b whether it even happens like this.

• Support of KDE Plasma’s global progress bar and removal of K3b’s own progress OSD.
  This is not a crucial feature for 2.0 and according to Michał actually requires a higher amount of work one might think.
• Support for writing Flash Drive images.
  With CD drive-less netbooks on the rise and the announcement of KDE’s Plasma Netbook Reference Platform, K3b 2.1 may support USB Flash Drives as target medium. So instead of cryptic dd if=Plasma-Netbook-Reference.i686-0.1.0-*.raw of=/dev/sdX commands, hopefully 2.1 will do the same with two mouse clicks.
• Spanning data projects over more than one disk.
  Let’s say you’d like to record 7GB of data. Then you’ll be prompted to insert either a Dual Layer DVD or two regular DVDs.
• DVD subtitle grabbing.
  Title basically says it all.
• Somewhat fixed release cycle.
  Three of the most used Linux distributions (Fedora, Kubuntu, and Mandriva) have a fixed 6-months release cycle with releases every spring and fall. To reduce the amount of incoming bug reports for “old” K3b versions, we hope to release new versions in time before those distributions’ feature freeze. Maybe (only maybe) releases will happen more often than that, but don’t expect a brand new K3b version three weeks after a Fedora/Kubuntu/Mandriva release.
  And maybe (again: only maybe) K3b 2.1 will be released along with KDE SC 4.5, because of the already mentioned Netbook Reference Platform that should have its first stable release with SC 4.5.

That’s it for now from K3b. And now I’d like to advertise one of my favorite bands: Van Canto

=-=-=-=-=
Powered by Blogilo

Oh dear! Qt incompatibility on the horizon

I’ve read through a lengthy thread in the official Meamo forum (it’s so long, I even forgot how I even got there *g*).

Basically it says: The Symbian Foundation and Nokia with Maemo (now MeeGo) are building two widget sets on top of QGraphicsView – while both are called Direct UI, they are entirely different (I’ll refer to them as SDUI and MDUI from now on).

Symbian Foundation employee Mark Wilcox is the one who seems to see the seriousness the most that it’s totally braindead to have incompatibe widget sets. Ironically MDUI seems to be the portable one. Hopefully the Foundation understands the problem now and throws away SDUI and adopts the MDUI library for Symbian.

Too bad neither project adopted the already shipping QGraphicsView widget set KDE Plasma, but since Plasma was never written with Symbian compatibility in mind, it may be not ideal anyway. If I didn’t miss anything, MDUI already runs natively on desktop Linux (because it’s mostly developed on it) and uses the DE’s theme. If true that’s good news. Even if not source compatible with the Plasma API, MDUI apps could work nicely under the KDE’s workspaces (notably Plasma Mobile).

=-=-=-=-=
Powered by Blogilo

In case you love Amarok 1.4 more than Amarok 2.x

I just stumbled upon it by accident: Clementine, a port of Amarok 1.4 to Qt 4.
Many features of Amarok 1.4 are missing, so don’t expect a full replacement.

Personally, I keep using Juk – probably the most underrated music player.

=-=-=-=-=
Powered by Blogilo

Call for German speaking K3b testers

(English / Deutsch)

Hi there. My name is Markus and I’m currently the maintainer of the German K3b translation (I’m also one of the Kdenlive translators, btw). As this blog post is a call to test the German translation, it’s likely of no interest to anybody who doesn’t speak German, hence I continue to write in German (don’t worry, other upcoming posts will be in English).

Deutsch:

In der letzten Nacht habe ich – hoffe ich zumindest – die letzten Macken in der deutschen Übersetzung von K3b 1.70 ausgemerzt. Um sicher zu gehen, bitte ich Euch, die neusten Sprachpakete zu installieren und zu testen:

1. Installiert die neuste K3b-Version 1.70. openSUSE-Anwender finden sie z.B. im PackMan-Repository, das openSUSE-Anwender so oder so aktiviert haben sollten. Wenn Euer Distributor KDE SC 4.4 anbietet, ist K3b 1.70 sicher auch dabei.
2. Falls gettext bzw. gettext-runtime bei Euch nicht installiert ist (sollte aber eigentlich), auch das installieren.
3. Ladet die folgenden Dateien runter: k3b.po k3bsetup.po libk3b.po libk3bdevice.po
4. Wechselt mit Dolphin in den Ordner mit den Dateien und öffnet Extras -> Konsole .
5. Dort gebt Ihr dann ein:

sudo rm /usr/share/locale/de/LC_MESSAGES/*k3b* sudo msgfmt ./k3b.po -o /usr/share/locale/de/LC_MESSAGES/k3b.mo sudo msgfmt ./k3bsetup.po -o /usr/share/locale/de/LC_MESSAGES/k3bsetup.mo sudo msgfmt ./libk3b.po -o /usr/share/locale/de/LC_MESSAGES/libk3b.mo sudo msgfmt ./libk3bdevice.po -o /usr/share/locale/de/LC_MESSAGES/libk3bdevice.mo

Und das war’s eigentlich auch schon. Gefundene Fehler meldet bitte unter bugs.kde.org. Bei Fehlern in der Übersetzung “i18n” als Fehlerkomponente eingeben und als Summary “Error in German K3b translation” oder so angeben. Dann landet das auch bei mir. Wenn Ihr Fehler im K3b-Programm selbst findet, die nichts mit der Übersetzung zu tun haben, wählt “k3b” als Komponente. Um die kümmert sich dann Michał, der aktuelle K3b-Betreuer.