Why Do They Say Android Phones Run Linux?

Hello World!

Long time no code - exams underway, my apologies to the Plasma Team for the silence. I prefer to stay away from IRC since that gets me engaged into work real easy - I *love* the stuff we're working on :) Next week should be it and back to full-time hacking!

Now one of the courses I've been doing is Android Programming. In order to test the school task software I write in a native environment, I got a real Android PDA (ZTE V985, equal to HTC 1X / LG 4x, if I recall correctly, it is built on a quad core Tegra chip). Well, the hardware is awesome to say the least, especially the high resolution display, however I'd like to elaborate on the software part of the device in this post. So, this thing runs Android, which, from what I understand, is used to refer both to an OS and a set of API's to code against. OK, cool, it runs Linux, sounds awesome. I've been using Linux for years on the desktop (ever since father made me get familiar with it, RedHat 3.0 back then IIRC) and love it, especially the control it gives to the user (as in the PC operator, regardless of the admin privilege level). If you asked we for 1 distinctive feature of Linux that sets it apart form another OS'es, I would for sure say "control".

Then I started to tinker with the box. On a long journey back home from the Uni I decided to check some email, and launched the GMail built-in application. First blow: it logged in automatically, no password required. Where the heck did it manage to sneak peek my password and login from? Ah, yeah, right, I had logged into the application store to install some city navigation software. OK, why don't you ask me if I want to share the password with another application? Not to say that this kind of behavior may teach the kids to care less for the security of their PC's and data (why, it's my phone / PC / $box, why place passes all around the OS?) I admit, this is not the OS' fault, it's Google security policy.

(To be fair: the pass is not stored neither in a shadow nor encrypted, an "authentication token" is used instead.)

So, what was the second blow like? I wanted to remove that application for goodness sake. Not possible!

Of course, there is no package manager, at least in the default distribution. OK, there are Linux'es that lack a package manager IIRC, using a bundle system instead. But the thing won't let me erase an application! That is, not even a library, or a userspace service / component (which I'd understand, but of course not welcome). Nope, you have to "root" it, and that voids the warranty. Third blow! No root access? Voiding the warranty by obtaining that? Nice, that's Linux at its finest.

OK, some of you may say that this is how the HW vendors exploit poor Google and their art. Heh, that's what licenses are for! State it explicitly - no freaking removal of control, or you don't get our code. Simple as that. Examples? IIC (L)GPLv3 (not sure it it's the L or the simple one or maybe both) contains a paragraph forbidding the locking of devices running that code, called "tivoization". (OK, I'm not a lawyer, but that's what Linux Format claim, and I trust them on those matters).

Do not call it Linux if it is locked and its license allows locking! Call it Lockix or Blockix or whatever your "product managers" come up with. Do not fool people please!

Disclaimer: this is my personal opinion and it does not express the opinion of the KDE team, nor is related in any manner. All the responsibility for spreading any flames or such is mine and only mine.

Merry Christmas and decent bug reports to everyone!

Merry Christmas to all the KDE devs and users!

Yesterday I finally fixed an often reported crash (bug #299077). Fact is, I'm still celebrating this achievement since that used to be a really mysterious crash. With this post, I would like to thank the user "wodencafe" who provided the bit of detail that made it possible to fix the crash.

Now I know this crash was very trivial. Basically, since plasma-desktop is a process, and applets are merely c++ objects in memory that get created and deleted over time, a leaked instance of dynamically allocated variable in one of the applets may remain in the plasma-desktop process memory until it is quit (restarted). In this case, it was an item view, whose parent was never deleted properly. What made things worse is that the model that view was using got deleted properly on applet removal. So, this leaked itemview kept receiving signals on plasma theme change, and then tried to dereference the (already-invalid) model pointer. Voila!

Moral of the story: a good bug report is one of the best things we could wish to a fellow programmer. The key bit of information, in this case, was that you had to remove the applet from the panel to trigger the leaked item view state.

Also, I'd like to thank dfaure for teaching me to use the debugger any time I have questions about the program. Sound simple, but still :)

While I am at it,  I'd like to ask the C++ experts (hope that the Qt devs read the Planet and this blog post): is it 100% safe to assume that calling the delete operator on a 0 pointer will not crash on any platform / compiler / libc implementation? Or is it, in the general sense, not quite guaranteed? Thank you!

Selection Marker in the FolderView Applet

Hello fellow kde devs & users!

There is an active discussion going on around this bug:

Bug #268641

The problem in question is adding an option to disable the "+" overlay button in the FolderView applet, in analogy with the existing "Click to view folders" option.

So, to really get the option in, we need to demonstrate that this option is valuable to a solid part of the KDE user community. To do this, I've created this poll here:

The forums.kde.org poll

Opinions welcome!

Disclaimer: This post is not intended to create any kind of holywar, flame or FUD. It is intended to explore the opinions of the user base and to raise awareness of the issue. Thank you for understanding the rationale behind this post and treating it constructively.

NFS FolderView Bug

Hello fellow KDE devs and users!

Once again I am asking you to report on a bug which is not reproducible for me.

Here it is:

https://bugs.kde.org/show_bug.cgi?id=265774

Basically, folderview lays the icons out in a random order (though automatically, on a grid and sequentially) on plasma restart if the icons had been previously put in custom positions (dragged around with the mouse.)

I would like those of you who have ever experienced this bug to check out the trunk and see if the bug persists. I have just made a commit fixing a potential race condition that could lead to the manifestation of this bug, but this is, of course, just a guess. Also, any additional information is welcome.

Please, comment directly at the bugs.kde.org bug page listed above.

Thank you in advance!

KDE 4.8.1 available in Fedora

Hello fellow KDE devs and users!

I'm glad to tell you that the 4.8.1 update is available in Fedora in fedora-kde48 and kde-testing. Check out the amazing KDEPIM and folderview bugfixes, and probably a ton of other nice stuff!

Also, the hardcore desktop tweakers out there will appreciate one kdelibs / workspace / folderview fix I did for 4.8.1. Namely, I introduced a new KGlobalSettings category, SETTINGS_STYLE, and patched kcmstyle to emit a KGlobalSettings::settingsChanged notification with this category when the Graphic Effects level in the Fine Tuning tab is changed. Then, I patched FolderView to take advantage of that functionality, so now the hover-enter / hover-leave icon frame animation will only be enabled for the "low-low" and "high-low" (the topmost two) effect levels. I welcome those of you who use animations in your apps to take advantage of this change as well and consider disabling some or all of those animations at a certain graphic effects level. FolderView, for example, disables animations at NoEffects and GradientEffects and enables them at the higher levels.

Unfortunately, I forgot to backport the kde-workspace (kcmstyle) part of the fix to 4.8.1, and done that only a few hours ago (the original fix I did it mid-February). However, in Fedora, the fix will be available in 4.8.1-2. The other distros will probably push it as part of 4.8.2 when it is released.

Feedback for 4.8.1 in fedora-kde48 / kde-testing welcome! (of course, you should be reporting it to the RH tracker, I can only notify you about the updates)

Have you ever experienced this bug?

Hello fellow KDE devs and users!

Community help is needed with a difficult to reproduce bug.

The bug looks like this:if your desktop is set to FolderView (right click->View->Layout->Folder View->Apply), on plasma-desktop restart or KDE login, you are presented with an empty desktop and a scrollbar on the left, even if there are files in the directory displayed by the folderview containment. Scrolling to the very bottom does not reveal the icons. Setting the desktop to Desktop and then back to FolderView remedies the problem, but on the next KDE login, you may well experience the bug again.

The relevant bugs.kde.org entry:

https://bugs.kde.org/show_bug.cgi?id=294795

I'd like to know if you have experienced this bug, under which KDE version, and any other steps to reproduce the bug.

Please add comments directly to that Bugzilla entry to avoid duplication and lost data. Thank you in advance!

FolderView Fixes Part I

Hello fellow KDE devs and users!

Let me present myself. I'm a 3rd year student doing a course in IT and a long time KDE user and RedHat fan. I've been with KDE ever since I got my first computer some 5 years ago, that is, KDE 3.5 on SUSE then some Fedora Core, probably 7, and was one of the first users to install KDE 4.0 on their production system - the source was the famous Fedora 9 KDE 4.0 Live CD. I still remember that early morning in spring when I got up to install F9 (or was it FC9?) onto the computer. Since then I've been with Fedora and KDE 4.


I think I had even used Gnome with FC8 for some time. The wallpaper that changed its color tint during the day, just like the Google Phatasea theme (the best one - why did you kill it, Google?), was the best thing I've even seen in Linux. Maybe I need to try to reproduce that with the modern Plasma wallpaper technology.. sadly, they dropped it with FC9, I think.

At the end of January 2012, I got a sponsorship from Blue Systems GmbH (blue-systems.com) and started working on the FolderView Plasma applet. The FolderView applet allows you to place a folder on the desktop for quick access when used as an applet, but most importantly, it allows you to use the desktop the conventional Windows way - that is, as an icon store. The former is pretty useful when working on a certain task to have the necessary files handy, whereas the latter is absolutely crucial for those distros that want to embrace a more traditional desktop paradigm, for example, in order to aid Windows users in their migration to the Linux OS, or to create a KDE3 feel. Either way, it is really important to have this Plasma component as polished as possible - it is the first thing the user see on login, and if they come from Windows, FolderView may well be the first Linux desktop component they see in their entire life.

Now you may be surprised here, but it has a lot of bugs!

Well, used to.

I'm glad to tell you that more than half of the FolderView bugs have been fixed by now. What remains is mostly containment and multi-screen bugs, and those will have been fixed for 4.8.1.

Here goes the list of the fixes with comments where appropriate:

• (#268641) Automatically enable / disable selection marker - if KDE is set to double-click, no need for the "+" sign
• (no bug #) If KDE is set to double-click, shrink the icons only once on double-clicking them
• (no bug #) On double-clicking an icon with KDE set to double-click, repaint the icon after shrink (icons used to stick) - debugged by me, final patch and commit by aseigo
• (#291140) Some configuration related problems where the FolderView would not apply settings on the fly when used as a containment - aseigo had broken that, I made him fix the thing back ;)
• (no bug #) Account for the SVG margins in IconView::itemSize() - when the text width is used to calculate the item frame width, this is noticeable
• (no bug #) kdelibs/plasma/widgets/iconwidget.cpp - same as (2), but for the Icon widget
• (#247144) Fix the 1px offset in air/widgets/viewitem.svgz - now that was one hell of a bug!
  I spent 1.5 days looking for the source of the issue. I quickly narrowed it down to the wrong size of the "normal-right-border" element in viewitem.svgz (the frame you see around the FolderView icons), which was 9px wide as opposed to all the other border elements (8px). Now what? Marco Martin found out that the PNG of the shadow for that element was incorrect and 9px wide instead of the required 8px. And I was digging through the source of the Plasma::FrameSvg class. All I needed was in fact to get an SVG expert  to have a close look at viewitem.svgz. Thank you a lot Marco!
• (#211002) Make the popup view inherit the parent IconView sorting & filtering settings
• similar to #211002 Make the popup view inherit the parent icon view selection marker settings
• (#290694) (Part I) Correctly handle Plasma theme change - thanks goes to Marco again, he noticed there was a slot name collision when I pointed him to the relevant slot in the FolderView class, though Marco still insists it's my bugfix ;). When the applet is on the desktop, the outer frame will be immediately repainted on Plasma theme change, just as it should be
• (no bug #) Apply icon flow settings in configChanged() - icon flow settings will be applied when you click "Apply", as they should be
• (no bug #) Read icon size settings in FolderView::init() - don't lose the custom icon size settings between plasma restarts
• (#261207) Apply custom text line count setting in the list view - this, used with a small icon size and a slim plasma theme, can save quite some vertical space in the list view
• (#290694) (Part II) Relayout the items using the updated grid and item size - on Plasma theme change, the SVG margins change, and so should the positions of the items in the icon and list views
• Fix item sorting - fix sorting by size and type, introduce a three-level fall-back for sorting by name, sort folders by child items count when sorting by size. Thanks goes to Peter Penz for the three-level file name sorting fall-back code!
• (no bug #) Enable  on-hover item animation only for a certain level of graphics effects (Low CPU == effect off)
  This introduced a new KGlobalSettings category, SETTINGS_STYLE, which is currently only used when the graphic effects level changes - you're welcome to notify about style configuration changes using this category.
• (#244557) Fix icon scaling when the FolderView applet is in panel - behave similar to the Trash applet when in panel

This is of course not all what needs to be done, but it at least makes FolderView usable. Bug #268641 needs further fixing as I occasionally learnt yesterday - with some icon sizes, the marker occludes the icon partially (at 22px) or even completely (at 16px). There are some visual glitches remaining, and of course a lot of features to implement.

Now for the time frames. The fixes listed above will all be available in 4.8.1, along with some yet to be done bug fixes. There is one 4.9 feature currently, the ability to sort icons ascending or descending when FolderView is used as a containment.

I also need to tell you about one important bit of polish that depends on a fix in Qt. Namely, if you drag some icons around in FolderView, you will see some  ugly artefacts. I've created a review request in Gerrit, the Qt code review system, but the Trolls refuse to accept the patch until I do a similar fix for Qt5. Now drag and drop in Qt5 is broken, as in, the drag pixmap is not displayed at all! And the Trolls want me to fix all the drag'n'drop code in Qt5, after which they will gladly accept my Qt4 patch. Well, as they say, you fight fire with fire! I've talked to Jonathan Riddell of KUbuntu fame, and he promised to post the patch to the kde-packagers mailing list. This means that the patch will be applied by the distros on the next Qt release. Take it, trolls! :) (no offence here - but I need to get the applet fixed, Qt5 is a mirage at the moment and will remain a mirage until two or more major KDE releases)

What I've done is more than half of the job. The other part will have been done before the 4.8.1 tagging. I encourage you to check out and build kde-baseapps master and have a look at the improved FolderView applet!

Best regards,

Ignat Semenov