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.

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.

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/

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+

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.

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.

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.

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?

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:

A while ago I was wondering about MeeGo. In every article about MeeGo it’s being told how it’s a project of both Nokia and Intel.

But then I had a look at MeeGo source codes. Strangely, apart from Qt itself, I could not find any Nokia code at all. I thought that at least the Handset UX must obviously be a Nokia product. After all, Nokia plans to ship their first MeeGo phone in the coming months.
Well, MeeGo’s Handset developer group has not a single Nokia member. All but two have Intel mail addresses and the two don’t have a @nokia.com address either.
Wherever I look, I can only find Intel code.

The only area where I could find actual Nokia involvement was the semi-official N900 port. The table on that page contains some Nokia-related names and the page also talks about “closed components” only Nokia has access to.
Is it actually true that Nokia’s only involvement with open source MeeGo-specific code is to port Intel’s open source code to the N900 via “closed components”?
Then I thought that Nokia will probably develop a closed source user interface for their upcoming MeeGo devices, similar to the WeTab. However that would contradict page 4 of Nokia’s Software Strategy White Paper.

Anybody got a clue what’s going on? My elite web searching skillz left me as puzzled as before…

EDIT: Nokia develops MeeGo Touch Framework. That’s still no front-end application that I had hoped to find, though.

So digg.com has been completely redesigned and KDE now has an account, too.

http://digg.com/KDE will automatically publish KDE.News stories and Planet KDE posts.

Let’s see how/if that works.

[EDIT] It works! \o/
So in case you don’t use Akregator (shame on you!), you can now also follow KDE in digg to get Planet KDE posts. KDE.News stories will take a bit longer but they’ll come.

Now don’t forget to digg (=vote up) your posts.

While FF is nicely extensible, it got more and more on my nerves with its slow JavaScript execution, bad KDE Workspace integration (even with SUSE’s KDE extension for FF), etc.

Getting FF’s bookmarks into Rekonq took some manual steps, but overall went smooth:

1. Export FF’s bookmarks with its bookmark manager as HTML file.
2. Close Rekonq/Konqueror, run keditbookmarks and import the HTML file.
3. Let keditbookmarks fetch all favicons (select all and then right-click).
4. Define your FF bookmark bar folder als KDE bookmark bar folder.
5. Close keditbookmarks and launch Rekonq again.

A few glitches came up pretty soon: All text fields were off, weird crashes on Facebook, and no spell check in text fields.
The first two glitches have already been fixed in Qt. So I added openSUSE’s pre-release Qt 4.7 repo and upgraded all Qt components. So far I don’t see any problems despite its pre-release status (it even fixed the flickering with apps using dbus-menu in the systray).

Spell check is indeed missing but luckily after Qt 4.7 the QtWebKit team will release new QtWebKit versions independently from Qt. So getting spell check after WK Bug 42100 has been fixed, we don’t need to wait all the time for a new Qt release.

Currently Rekonq has no extension support. It’s in development, though, and AdBlock support is built-in anyway (not that I care about a Web Inspector but that one is built-in as well).

A small but irritating quirk is the too high bookmark bar in Rekonq. Favicons are 16✕16 pixels but Rekonq stretches them. I circumvented the problem by manually defining higher resolution icons in keditbookmarks. Now my bookmark bar looks very pretty with those high-res icons.

Yeah, I listed a few quirks but considering the big picture and how much FF sucks (performance-wise) these days, the benefits outweigh the quirks. Maybe if Mozilla Corp. reconsiders and officially releases a Firefox 4 variant built on the Qt port which Nokia has done for MeeGo Handset and follows the KDE HIGs (eg. no "Preferences" in the "Edit" menu), I may switch back. But since that scenario is unlikely, I stay with Rekonq for the foreseeable future.

Get the source code tarball from here (be sure the file is 11.7MB in size – in my first test download SourceForge aborted after 4MB).

The following bugs have been fixed since 2.0.0:

• Freeze on ripping Audio CD using external encoder to MP3 or FLAC (236466)
• Drag and drop from Dolphin doesn’t work (242745)
• Symbolic links are not added to a project when a folder is added recursively (243555)
• Install app icons to hicolor so that they are visible in non KDE WMs (BNC619731)
• Overburn doesn’t work (241534)
• Data part of mixed CD is not written – searching for previous session doesn’t work (246798)
• Fixed the speed comparision and formatting when cdrecord changes the writing speed automatically (246262, 243482)
• Track pointer seg fault (247588)

If there anything wrong with this tarball, please comment here. If you have usual bug reports, please file them at bugs.kde.org.

Apart from the both usual suspects Michał and Sebastian, this release contains fixes by Nicolas Lécureuil (Mandriva) and Will Stephenson (SUSE). Thanks to both!

No idea whether The Board ever enters mainline GNOME 3.x, but it’s great to see that our concept (which is in itself also an evolution of Konfabulator etc.) gains followers from outside our immediate community. This gives us a fresh set of eyes with respect to usability decisions.

Hopefully in the future Plasmoids can be used within The Board and The Board applets in Plasma.

To make it clear: The proposal is not about forbidding people to use those decorations. The current idea is to move them to the “KDE Artwork” module where they are still available to all SC users if they choose to install that package.

I’ve posted a poll to find out which of our shipped decorations are even used.
You can find the poll in our awesome KDE Forums.

The development is done by Nikhil Marathe. He’s implementing Chrome’s extension API which is luckily based on HTML, JavaScript and other web standards which makes it easier to adopt than Mozilla’s current XUL-based model (which is being deprecated my Mozilla in favor of Jetpack in Firefox 4.0 anyway).

Kudos to Nikhil for his awesome work!

In related news, from what I’ve read rekonq 0.5 is shaping up nicely. According to the roadmap all targeted features are done which hopefully means that the release target in June is hit.
Rekonq will (at least if nothing unexpected happens) also become the default browser of Kubuntu 10.10. It’s already default in nice Arch-based distro Chakra.
Now only Fedora 14 KDE and openSUSE 12.0 need to follow.

Then one day Google shows up and releases the sources to a codec that’s merely a derivate of the patented MPEG-4 AVC Baseline codec. Suddenly all hell breaks loose, Mozilla immediately supports the new (possibly patented) codec.

This raises various questions:

1. Why does Mozilla refuse to use Dirac since years but adopts WebM / VP8 immediately?
2. Why did Mozilla refuse to adopt the Matroska container until Google blessed it?
3. Why is Google’s word on VP8′s patent situation just being taken as truth without an independent patent review?
   (After all, Android is covered by patents from Microsoft and possibly Apple’s as well.)

I suspect that since Mozilla (and Opera as well) gets many million dollars per year from Google for being the default search provider, questions about WebM are not asked. I think Mozilla mainly wants to please its pimp main sponsor to get the money.

Luckily KDE is not part of the discussion (I merely state my opinion as an individual). Konqueror simply uses Phonon to play back HTML5 videos, hence the video can be in whatever format as long as a compatible Phonon back-end is used – WebM, Dirac, AVC,…

Haiku is a FOSS operating system inspired by BeOS. It’s not very useful as of yet, but it shows good progress. Haiku is also proof that C++ can work in the kernel.

Haiku (and BeOS) is noteworthy in a KDE context simply because pretty much all some of what Nepomuk tries to achieve, BeOS already did 10 or more years ago.

Among other things, new features compared to include a WebKit browser, WLAN support, and internationalization support.

And now fire VirtualBox up and give Haiku a spin.

There are two blocker bugs:

One related to DVD-DL burning (https://bugs.kde.org/show_bug.cgi?id=234033) and one to Blu-ray burning (https://bugs.kde.org/show_bug.cgi?id=236069).

The main problem is that Michał, the main developer, does not (yet) have a Blu-ray recorder to work on the a fix himself. He sent out letters to drive manufacturers to see whether they can sponsor one. No reply as of yet.

And the DVD-DL bug cannot be verified by either Michał or Sebastian.

So if you can help with either bug (eg. sponsoring a recorder, contributing code, testing), leave comment in the appropriate bug report or send Michał an e-mail (his address is also in the bug reports).

And now the note to distributors:
All KDE Platform 4-based releases were preview releases (Alpha, Beta, RC) of 2.0. This means unless a new pre-release added a dependency that you can’t meet (IIRC it only affects the switch from sudo to KAuth that was done relatively late and AFAIK also requires SC 4.4), you really should package newer K3b releases as official updates – especially as there is a full feature and string freeze in place since the first RC (when you shipped pre-releases of Firefox 3.0 and Thunderbird 3.0 you had no problems doing the same).
The K3b team is very very small. And while I try to get some of the work load off Michał’s back (like blogging about status updates), incoming reports for bugs that are already fixed, but you don’t package newer versions, increase the load in an unnecessary way.

Thanks for reading and since I like promoting bands who are not known around the world, here’s one song from an awesome Romanian music group (and the vid’s funny, too): Șuie Paparude – Armada verbală

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

After many website transitions, much info on KDE.org got kinda lost. For example, there seems no longer to be a proper announcement of KDE 1.1. The KDE website doesn’t have it. Can’t find it in the mailing list archives of kde-announce@kde.org either. There are only two places where I could find when 1.1 was released: The Way Back service of Archive.org and a backup of the news archives of KDE’s previous website in SVN. After I found the exact date, I took the liberty to at very least add the date to the KDE 1.1 changelog which is still linked from KDE’s announcements page (the KDE 1.x changelogs had white text on white background — there as well I took the liberty to modify the files).

That brings me to an earlier problem: When was KDE Beta 1 released? After much digging I found out, that pretty much all old announcements (except for KDE 1.1 and KOffice 1.0) still reside in KDE’s SVN and those can even be accessed via web browser. http://kde.org/announcements/beta1announce.php works, but it’s not linked from the announce page either along with most other announcements that old.

Next problem: Some dude uploaded a screenshot of KDE 1.1 to Wikimedia Commons and labeled it KDE 1.0. Wow, great. When I looked for real KDE 1.0 screenshots, the whole internet seemed to use exactly the same image. The Way Back service wasn’t of any use either. No backups of KDE.org of that time in their archives. Screenshot of KDE Beta 3, yes. Screenshots of 1.1, too. After many searches I found an image on a Spanish blog that should be KDE 1.0. Needless to say that I replaced the wrong image with this one and re-uploaded the wrong image again as 1.1.

Now KDE 1.x is in good shape in German Wikipedia. I don’t know what I do next: Update the chapter about KDE 2.x or extend the English KDE 1 article…
I wouldn’t mind if one of you extended the English article. All references are in English, so using the German article as base should be possble even if you don’t speak English.

Btw, during my research I found – in retrospect funny – articles which I’d like to share with you:

ArsTechnica reviews SuSE Linux 6.0 with KDE 1.0
ArsTechnica reviews KDE 1.1
LinuxToday’s outlook to KDE 2.0

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

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.

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

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

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

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

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

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

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.