Huzzah, time to use another Ultravox song title in a blog post. What’s that you say? Mid-80s music references indicate a midlife crisis? Right. But for the first time in my life I’m in Austria for non-skiing activities, and I’ll be doing a little workshop today on Free Software licensing, copyright assignment, business alignment and whatever else I can cram into a few hours and which the participants are interested in. Afterwards, I’m looking forward to meeting some of the Austrian Fellows of FSFE and - who knows - gazing out over the Danube.

This is something that has been on my todo list for a while now, so I figured I would crowdsource it…

In october, I acquired a Netgear WGR614v9 Wireless G router as an emergency router for ABLEconf 2009’s foss game day. It got the job done, but after that was basically useless because I had a much nicer (Busybox/Linux-based) D-link DIR615 Wireless N router. I spent quite a while trying to get the pesky netgear to properly act as an access point to bridge the computers that I have upstairs with the d link downstairsto no real avail — the only real useful guide, is NetGear’s knowledge base, which doesn’t address the creation of a wireless bridge, only a wired one (which I don’t see the point of but… )….

At the fedora marketing fad, I acquired some really cool hardware to try to play with. Unfortunately the device isn’t wireless enabled. Because of the way my network is laid out, everything in the upstairs of my house is on a wireless connection, including my parents’ desktop. So, this device cannot be used with my network architecture as it is.

I think I also have a Linksys WRT54Gv5 that could be used in place of the NetGear, but that is, at the moment, a fun looking brick, so I’d have to resuscitate it.

Any help/howtos is much appreciated.

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

Two days ago the KDE Plasma community announced that they are providing a live image of the Plasma Netbook Reference Platform. They provide this image to make it easy for all interested developers, users, journalists and geeks to check it out, work with, talk about and and improve it. The reference image is the result of an KDE effort utilizing the openSUSE Buildservice and it’s based on the openSUSE distribution.

What does that mean for us the openSUSE community? First of all it makes us very happy and proud. And we think it proves once again that the openSUSE projects’ distribution and its tools have the level where they stand the production pressure which comes with this kind of use cases. The Plasma Netbook Reference Edition is a lot of code to build and has many potential contributors, testers and users. Enabling people to fullfil these jobs can not be done with some script found lying around on the internet. It requires a high level of experience, professionality and stability in development and operation of the toolchain. We always have these factors in mind and many hands and brains produce high quality products reproduceably. We have the build engine, the collaboration tools, notification systems, download infrastructure and the distribution on this level. For the KDE Plasma Netbook Reference Edition we can provide the tools to build the packages and the distribution image plus the linux distribution neccessary to test the interactions between the UI and the rest of the hardware on a netbook system. That way people can experience a whole system, which is way more useful than testing the UI in isolation.

But what is most important, many people in the community are around who wholeheartedly work on achieving these great results while having fun. Again, we are proud that the team selected our distribution as a base and our tools to work with. Thank you guys for your trust. It is a great move for all, the users, KDE and openSUSE.

The Qt 4.7 Tech Preview has been released a while ago, and we’ve gotten a lot of requests to package it for the N900.

Read on if you want to live on the bleeding edge

Amarok 2.3.0 has just been released but the Amarok team is already working hard on the next release. Shortly after mainline opened for feature commits I pushed a feature that will hopefully result in the next Amarok release being based on user feedback even more than 2.3.0: LikeBack integration.

What is LikeBack?

Short answer: a client-server system for gathering context-related, anonymous and immediate user feedback.

Long answer: described in a blog post by Valerio Pilo, KMess developer.

Pics worth more than 1K words (hint: the icons in the top right corner):

As I’ve read, LikeBack was originally developed for BasKet Note Pads and ported to KDE4 by KMess developers.

In Amarok the LikeBack bar is enabled by default only for testing releases i.e. git builds and betas. When the user has a good or bad experience, or gets an idea for a feature, he can click on one of the icons in the top right and submit a message. With LikeBack we gather comments of the types “like” “dislike” and “feature idea”, single and short suggestions, not discussions or bug reports. Bugs are still handled through the usual dialog that takes the user to bugs.kde.org, a system much better suited for bug tracking than LikeBack: this also means that if we receive something like a bug report under the guise of a “dislike” through LikeBack, we will have to consider it invalid.

The feedback we have received so far (several dozen comments in half a week) is quite positive, no insults yet (yay!).

LikeBack is available in Amarok’s git mainline (and in git/nightly builds if your distro provides them) as of a few days ago (*not* in the 2.3.0 release), so feel free to give it a spin and let us know what you think, either through LikeBack or the usual channels.

Hello everyone,

The KDE Brasil community is happy to announce the first official Brazilian KDE meeting – Akademy-BR 2010.

As a consequence of an increasing Brazilian participation in KDE projects related to coding, artwork, translation, and promotion, some efforts have been doing last years in terms of travelling for Qt/KDE talks and courses, supporting new contributors, and leveraging the KDE presence in events like FISL and Latinoware. We’ve seen a number of regional KDE groups appearing in Piauí, Santa Catarina, Rio Grande do Sul, São Paulo, and Minas Gerais, formed by amazing guys who are already doing some contribution to KDE. Previous in-person meetings in FISL and Latinoware, where focus was driven to talks, booths, and user group sessions, have demanded the organization of an official KDE Brazilian meeting devoted to some short talks and basically focused on hacking (that includes artwork/translation/promotion) sessions.

Akademy-BR 2010 will take place in Praia do Forte (Fort Beach), a pleasant and small touristic village near Salvador – Bahia, from 9th to 11th April. We are thirty participants from distinct Brazilian states staying for three days in the Praia do Forte Hostel and doing our best to make KDE contribution more accessible to newbies, to narrow friendships, to make KDE applications rocking, and to plan our expectations for KDE in Brazil during 2010.

I would like to anticipatedly thank KDE e.V. for the financial support, the other Live Blue guys for helping in the arrangements, and Mauricio Piacentini, Helio Chissini, Fernando Boaglio and INdT guys for making Akademy-BR a reality !

That mentioned, it’s just left for me to say:

Within KDE our applications and platforms are divided into “families” (no, idea what the correct branding is for these). In trunk these are: kdeaccessibility, kdeadmin, kdeartwork, kdebase, kdebindings, kdeedu, kdeexamples, kdegames, kdegraphics, kdelibs, kdemultimedia, kdenetwork, kdepim, kdepimlibs, kdeplasma-addons, kdesdk, kdetoys, kdeutils and kdewebdev.

I have now started to to automatically run some of my scripts against each of these on a monthly basis. For now I am only running three scripts. The example output for KDE PIM in February is below:

WhoWhat: You know, the green blobs showing who commited in a given week.

Plots: Produces a plot showing the commits and commiters per day during the month.

Network: Produces a graph showing who has worked with whom. The closer two nodes are together, the more they worked together.

Over the next couple of months I will add further scripts to this automation. In particaular I will add in my scipt for identifying the comminters that projects are reliant on and a new script I am developing which automatically generates a commit digest.

I will only ever be publishing the results for KDEPIM, KDEPIMLIBS and a few other paths in SVN. If you have an interest in getting the results from the other “families” or another path in SVN, please let me know by dropping me an email or leaving a comment to this blog post. All I ask is that, if I send you these images on a monthly basis,  you take the time to publish them publicly somehow. These are all done for the benefit of KDE after all.

Last night the Kraft team was releasing the second beta for Kraft 0.40. A second beta is needed because meanwhile KDE 4.4 was released which comes with the Akonadi based addressbook. That is a big change compared to the old addressbook with a large impact on Kraft. Parts of Krafts addressbook integration had to be rewritten. The Akonadi addressbook interface in the KDE Pimlibs feels like not really being complete yet. With large address books for example, this version of Kraft might show performance gaps.

While being over that, the Kraft setup assistant got another change compared to beta 1. It now additionally asks the user to mark his own address which is stored and used in the document generation. That helps to ease the configuration even more for new users.

I would really appreciate some testing of the beta version if you are interested in this kind of software. Please report bugs back to the Kraft user mailinglist.

A source package can be downloaded from the Sourceforge project page. Binary packages for recent openSUSE distros with upgraded KDE to version 4.4 are available from the Kraft Beta repository from the Buildservice. I can not provide (K)Ubuntu packages this time unfortunately because there are no KDE 4.4 packages for (K)Ubuntu in the Buildservice yet.

I’m in a train, listening to old Metallica on an iPod while reading government documents about software procurement. Was this ever a career choice my ninth grade teachers gave me?

It’s a time of change for me in Lent, as the MOMC is going back to work as a manager and organizer for an NGO that promotes mathematics to schoolkids — that means I’ll probably blog a little more about elementary schools and maths here. But when she’s working, that means I need to shift my schedule a bit to bring kids to school and swimming lessons. Fewer late nights for hacking, which means it will just have to move into the day.

Meeting

Last week Espen already reported that a group of trolls were attending the Bossa’10 Conference in Manaus. It was a great conference with lots of great people attending and interesting presentations.
What is especially good about this conference is that the focus is on networking. It is always good when you get to meet people you have only been talking to and working with on-line (A shout out to Bruno Abinader, who has been working with me on itemviews-ng; it was great to finally meet you in real life!).

by ThiagoMartins on flickr

Working

Even though it is great to meet new people and hang out by the pool (don’t tell my boss), I was really in Manaus to present my ideas for The Future Of Qt Widgets. I talked about the direction in which the Qt widgets are being developed. It’s all about making life easy for both designers and programmers, using the Qt Declarative UI technology.

mbm working

Having Fun

The conference is over, but I am not ready to leave Brazil just yet. I will be spending the week in Recife with the guys at INdT. It is a blast working with them; they’re a smart bunch of developers and great fun to be around! And then there’s the beach… It’s tough being a Troll in Brazil, I tell you! Did I mention we’re hiring?

Pontal de Maracaípe

Apparently, with my original posting here, I stepped on several people's toes. I'm sorry for that, and for this reason, I've simply removed this content (and also because - as some of you pointed out - some of the things I mentioned were not Plasma's fault, but workarounds or bugs in other areas, although to me as a user they appeared on Plasma).

On the other hand, my frustration with KDE is growing... I find my self more and more replacing KDE applications with GNOME applications, simply because the KDE application does not fulfill my needs or is buggy, while the GNOME application provides the fundamentals that I need.
When KDE 4.0 came out, I accepted the excuse that some things simply needed the time to be ironed out. However, now at KDE 4.4, my biggest problems are still there:

• Printing in Konqueror is just not working so I have to use Firefox (and yes, I posted messages to bug reports),
• KDE's printer dialog does not seem to remember any settings, and it also messes up CUPS in other applications
• VPN does not work in knetworkmanager so I have to use nm-applet (and knm does not display the list of available networks),
• Booklet printing is missing altogether so I have to use Acroread to print my students' seminar works and other papers,
• printing landscape slides 2-up doesn't work in Okular so I have to use Acroread to print handouts for the students,
• KMail regularly decides to eat my inbox or my calendar,
• My bluetooth headset is working only with gnome-bluetooth and gnome-volume-control-applet
• etc.

(And just for the record, for most of these problems I either filed bug reports or talked to the maintainers on IRC, who told me mostly, that it's not their application to blame, but some underlying framework and I could do nothing about it...)

A software license lets you do something that you otherwise would not be allowed to do, given the limited permissions granted by Copyright law. That is, it changes the “all rights reserved” into “some permissions granted and all other rights reserved.” Which permissions those are depends on the license; which exceptions to “all rights” exist depends on the jurisdiction under which you’re operating (e.g. while “Fair Use” is something you can do in the United States, that concept doesn’t exist everywhere).

There’s lots of software licenses. There’s even lots of Free Software licenses. The Free Software licenses all grant you permission to do at least four things: use, study, modify and share. Sometimes they allow more. The BSD license allows proprietization. The Apache license allows the use of patents embodied in the software (important in jurisdictions with patents). The GNU General Public License allows you to format shift (e.g. you may publish a GPL licensed program as a T-shirt).

The flip side of permissions is that of conditions: often the permissions are granted provided that you do something else. For instance that you pay for the permission (a proprietary, commercial license would require that). Or that you give the source code of the program to recipients of the binary (as the GPLv2 says). Or that you send your modifications to the original author if you distribute the code in modified form.

The conditions may also include a condition that the same license applies to derivative works. The GPLv2 has such a condition. The EUPL has such a license (plus an escape clause). The CDDL has one. This kind of condition creates an “species” around a single license of like-licensed software. Such a species has software individuals that can be freely combined and modified and shared, since it all falls under the same license.

This kind of condition also creates a division, one between species, because you can’t “breed” between species. The conditions of licenses of two different species cannot be satisfied simultaneously, so you can’t do it. As a consequence, we see that the same functionality is developed multiple times under different licenses. Some might call that wasteful. It’s out in the open, though, and reimplementation only needs to happen once for each species, so the waste of effort is limited. Who knows how much sloth and useless duplication occurs behind closed doors? In any case, we find that a license with conditions creates its own species and that most software combination works within that species.

So-called “permissive” licenses can cross the species divisions, simply because they do not have any conditions that prevent them from being integrated into another species.

If you’re a software developer who is combining pieces of software which are under different licenses, you need to be aware of the species differences. Indeed, sorting out which code can be combined with which can be a considerable effort. The FSF lists dozens of Free Software licenses and whether they’re compatible with the GPLv2 and the GPLv3 — and even the GPLv2 and GPLv3 are different species.

So we have two problems with having lots of species: that of duplication of implementation effort (yes, I too have had to ignore an available Free Software component that did what I needed and had to re-implement it badly because of license incompatibility) and of effort involved in checking for compatibility.

The underlying problem — that of having many license species — is what we call license proliferation: there’s lots of licenses, and more show up all the time. Black Duck software identifies some 1200 of them. The OSI has 60-odd licenses. That’s a lot of extra effort.

So when people ask the FSFE about software licenses, in particular about creating a license with new conditions or that varies an existing one, we say “don’t do it.”

That bears repeating:

Do not write a new (Free) software license. Just don’t. Really. Pick an existing license that does what you need. And if there isn’t one, then what you want is probably not a good idea.

I’m aware that’s an argument from authority. That’s not always a good kind of argument to use. However, you need to be aware that in creating a new species (by creating a new license) you’re committing yourself to the whole rigamarole of re-implementation, and excluding people from outside the species.

Now, as with almost every rule (except rule 34), sometimes the rule is just a guideline. People who know what they’re doing can bend the rules.

There can be really good reasons to bend the rules. For instance, new dangers show up that threaten the Free Software ecosystem. These dangers may be a reason to introduce a new license to counter them — patents, for instance. Who would have though, too, of valuable trademarks in Free Software? They’re explicitly mentioned in the more modern licenses. A simple permissive license that disclaims warranty might not be sufficient if regulatory frameworks change. And in some areas of business, existing regulations might require things of a software license that the existing ones do not provide.

So there can be good reasons to change. And in spite of my position that license proliferation is bad, I’m going to applaud the Mozilla Foundation for choosing to look into updating the MPL (coverage from the Register here).

The MPL is a file-based license, not a work-based license, so it creates species in a different way. Clause 6.2 of the existing MPL allows a transparent upgrade procedure, so I think the proliferation aspect of this license update doesn’t need to be stressed. They’re doing the right thing. The content of the license change isn’t firmly fixed yet: Mozilla is still in the comment phase. Results are expected later in 2010. I’m looking forward to meeting some of the people driving the process in Mozilla next month, for a chat over a glass of wine as to which bits of compatibility are the most important.

So here’s to licenses; let a thousand choices bloom.

PS. Ideally, I think that each license would make a clear statement about what it means in each of the essential areas of licensing. Unfortunately, those “essential areas” have changed over the years, so many do not do so. I hope for a clear new world where we have a small collection of modern licenses (say, Apache v2, GPLv3, MPLv2 and a new permissive license) that define the main species of Free Software.

PPS. Although I think that this applies to every blog post, I think I should add explicitly here: this post does not reflect an official FSFE position on the Mozilla license.

I was lucky enough to attend the Bossa conference ‘10 in Manaus where i was presenting Plasma-Mobile. I did a previous post about it so this one will be short, it just to show that the work is progressing well, look at it running on the N900 with decent performance :

Plasma Mobile is based on Qt, KDE technologies and QML.

On the heels of my wish for a C++ version of printer-applet, Dantti announced just such a project. He invited me to contribute, so I did.

Since print-manager is a from-scratch project, it needed a tray icon daemon. Well, it sorta had a stub based on KPackageKit’s tray icon daemon, but nothing really functional. A few weeks ago I ported the stub to KStatusNotifierItem and left it in an uninstallable, never-tested state. (This was because at the time I was not hacking in a place where I could print things) Today I fiddled around with library names and .desktop files until the KDED module loaded. The result? Every 5 seconds I’d get a new printer icon!

So today I cleaned up the code. I got it to the point where it pretty much has feature parity with the applet included in KDE 4.4. In fact, it’s a bit more, nifty, even; it now tells you the name of the printer currently printing as well as the name of the document it is printing.

Neat!

Things work mostly as before. As long as your jobs are consolidated to a single printer, clicking the icon will load up the queue for that printer. But since print-manager currently can only show the queue for one printer at a time, if the active jobs are spread across multiple printers, clicking the tray icon will make a context menu with all the printers pop up, and clicking these menu entries will open up the print queue for that printer. I should note that I’ve not actually tested this, for the lack of two printers.

I am wondering, though; is the amount of documents in queue important enough to include in a third line in the tooltip? I could see how it might, and it should be easy enough to do so.

The last thing on the todo list is to fix a pretty nasty bug. Since this tray icon is spawned by the KDE Daemon (KDED), the “quit” action automagically added to the icon’s context menu will quit the whole of KDED, bringing down services such as PowerDevil, KHotkeys and so forth. I’m at a loss on how to get around this. Setting a custom context menu won’t work, as the setContextMenu() function of KStatusNotifierItem just adds your custom Menu to the preexisting menu that comes by default. Any bright ideas would be welcome here.

So, perhaps not the most exciting blog post on Earth, seeing as I’m just replacing already-existing functionality, but hopefully a few of the new features are a bit interesting. It’s certainly been quite interesting to code.

Today we are entering yet another string-freeze. That's 2 weeks before we release version 3.97 of KMyMoney, our third beta and hopefully our last before releasing a release candidate.

Today, as Aaron and Frederik said, we just launched a really cool thing: periodically updated images of a reference distribution for KDE Plasma Netbook. It's done with the openSUSE build service and is based on opensuse; however it's quite customized with our artwork and settings, so the general feeling of the distribution is exactly what the name suggests: a reference.

It is (or, will be since we're at very early stages of development) how we envision a complete system that boots straight into the Plasma netbook shell, and to be also a way to quickly test the really really bleeding edge development version without messing up your own system ;)

It is also very easy to customize the build on the openSUSE build service to make your own branch, so remixes and sperimentations of new ideas is really welcome :)

Here you can find the usb stick image, and here some useful documentation on Techbase.

I haven’t yet blogged about Tokamak 4 yet.
Well, it’s only 2.5 weeks after the event. I can finally tell you about one of the projects I worked on
Aaron already blogged about the general idea and goes into more technical detail in a second post.

The Plasma team would like to have a reference demo that can easily be updated and show off the new hot that Plasma Netbook is.

Since we were hosted by our friends from openSUSE, we thought about making use of their great tools. So I sat down in order to build a USB-Stick image (we also plan on having a CD ISO later on) using openSUSE buildservice.

I had the joy of poking Adrian and Will whenever I had a question, so getting started was quite easy. With their help I overcame an old (irrational?) fear of RPMs and created a package to contain config files that let you log in to the Netbook shell rather than the normal Plasma Desktop on first start.
The USB stick raw image can be found here, but I rather recommend to start with a bit of Documentation on Techbase

Now we’re all excited to get feedback on the Plasma Netbook Reference!
Please keep in mind that this is the very first iteration of this project. Now is the time for early testing feedback and to get involved. How about joining our super-secret IRC channel on freenode (#plasma-netbook, but don’t tell anyone)?

We plan regular updates for this project (using the factory repository we can update the KDE components to very recent versions) and will use this to get feedback on design decisions (Marco, “Mr. Netbook-Plasma” himself will thank you for your considerate feedback). Now is a great time to get involved with this exciting project. There are lots of low hanging fruits to be picked For example carefully examining the list of packages that we put on the image, optimizing the default configuration and many other things. No coding skills are required.

The Amarok team is always at work, aiming with every release to deliver the best music player on earth and beyond. For some it may be just great fun, for others it may be a sacred calling, but for all of us a release cycle is a journey with its ups and downs, that comes to an end with a release. Each release is a time when we unleash our brainchild into the wild, and take a moment to just feel proud about what we have achieved.

This is such a moment.

Today I’m happy to announce the immediate availability of Amarok 2.3.0 “Clear Light”, which brings countless improvements and fixes over Amarok 2.2.2, and lots of new features. This release is the result of extensive user feedback, and it contains many patches submitted by members of the greater Amarok and KDE community. Check out the release announcement and please digg it.

That might seem a bit of a silly question, but it’s one that has kinda come up for discussion a bit recently as we’ve, quite unusually, decided to turn away a few articles about application development and maintenance releases.

Guidelines for application release articles

The result of that discussion is in the advice on the Dot article submission page and set out in the guidelines on the wiki. Since not everyone visits every page on the wiki all the time, here’s the most pertinent part of that guidance:

We cover, as much as possible, all feature releases of anything but very rarely development/maintenance releases except:

• The software compilation (devel and maintenance)
• First new platform ports (devel)
• Really exciting new features (devel)
• Significant new application (devel)
• “Maintenance” releases which DO include new features (e.g. Amarok, sometimes)

Of course, we take many other articles other than application release announcements and the general guidance on the Dot submission page covers them.

Is this a change in policy?

Possibly. In the past this hasn’t really been well defined, resulting in some inconsistency – for example turning down articles about beta releases of an application for which we’ve previously reported beta release. It’s more a case of defining a policy rather than changing an existing one.

Why?

It comes back to the question of who the Dot is for. It really serves two main audiences:

1. Contributors to and users of KDE software
2. The wider tech press (a lot of Dot stories get picked up elsewhere)

Group 1 covers a range from casual users to early adopters, beta testers and developers. Some of these (early adopters to developers) are going to be interested in development releases. However, most of these probably also read the planet and/or the relevant mailing lists.

Group 2 generally don’t report on development or maintenance releases for individual applications (with certain exceptions)

So, group 1 probably don’t need development releases on the Dot to know about them; group 2 probably don’t really care.

Proper maintenance releases without new features should go largely unnoticed by users – so they don’t really need to know about them until they appear as distro updates.

Exceptions

With regard to development releases, there can be more general interest in particular cases. First, the software compilation is bigger news because it is a lot of stuff (and lots of new features). Second, first development ports to Platform 4 are more interesting since some people are really wanting those (e.g. K3B and Kaffeine).

With regard to maintenance releases, the exceptions are when some horrific bug is fixed or, again, the software compilation where there are going to be a lot of bugfixes.

We’re unlikely to want to carry articles where the interesting point is that it is a new development or bugfix release, but where there is an interesting story and the release is incidental (such as in the examples above) then of course it could be interesting to carry it.

Summary

Hopefully that helps explain the new guidelines and putting this on the Planet makes a few more people aware than having it on the Dot submission page or the wiki alone. Comments and questions are welcome and if you’re not sure about an article idea you can always send an email to dot-editors@kde.org asking for our opinion before you spend time writing something.

What It Is

Why?

• test Plasma Netbook easily and reliably


• provide system integrators a reference to evaluate Plasma Netbook with, to compare their own Plasma Netbook offerings with and to work with us on improvements that they need/want to deliver to their audiences/markets


• support the growing Plasma Netbook user base in being able to easily get involved with testing, improving and demonstrating interesting, useful and fun modifications both to the upstream Plasma project as well as to other Plasma Netbook users

How To Get It and Get Involved

• The project page on the KDE Community wiki
: this has all the step by step instructions and information you need to get involved as a user, an evaluator and/or a contributor.

• The OBS project page: the work is coordinated and happens here.


• #plasma-netbook on irc.freenode.net: real time communication with the developers


• plasma-devel at kde.org: development discussion via email

How We Will Measure Success

1. Is Plasma Netbook improving in quality?


2. Is it more evident to our user and distributor audiences what Plasma Netbook can look and perform like?


3. Are more people using and contributing interesting improvements to Plasma Netbook?

A Personal Invitation

Thank Yous

• openSUSE and Novell for hosting Tokamak 4 which is where this concept was finally able to come together, for their patient and extensive demonstration of the very cool OBS tools, and for helping us set up the OBS project itself.


• Marco Martin for being an amazing steward to the Plasma Netbook project.


• Qt Development Framework's support of both Marco and my own efforts.


• Every single Plasma Netbook user: you are who we do this for.

• ourselves, so we can do more testing and define the development direction more effectively.


• existing and potential KDE distributors, so they can get an idea of what we're aiming for, what the bar for "success" is and whether or not they'd like to use it in new products they are creating.


• the tribe of users who circle the KDE community most closely, so they can quickly and easily try things out, know what's available (and why) and get more deeply involved with testing and feedback if they wish to.

Some people were poking me about the new printer-manager status, and I think there’s no better place than here to show it’s progress. Last post lot’s of you loved and hated the queue user interface so I end up changing it a bit.

As you know time is the problem always, so when I have I few I try to work on what’s needing, as the print-queue is basically done I worked on the System Settings module to make it work, and it already does some goodies, it can set your default printer, and share it if sharing on the server is enabled (besides showing a few of it’s description and status). Now that I got this working adding some more stuff isn’t _that_ hard… Hope you enjoy the screen shot.

Independence

Choices

• not caring about our independence


• restricting influence of other parties by not working with them, or only to a very limited extend


• figuring out why we're still our own masters and making good use of that knowledge

What's keeping us Free

1. Strong focus on technology and cool things.

2. Flat organization, little hierarchy.

3. having a diverse ecosystem.

4. The role of KDE e.V. is strictly supportive.

5. Regular developer meetings.

6. Meetings are funded by KDE e.V.

7. Having had to deal with Qt licensing.

Conclusion

The treat

This week of the sponsored Krita developer was a little shorter. On Monday I traveled back from Holland to Slovakia. I was at the Krita Hackfest 2010. We worked there quite hard so we decided to take a break for me for 2 days. So I started to work on Thursday and finished on Friday.

As I wrote in my previous blog post, I started to work on the smudge brush, because according the bug report it was horribly slow. Although I wrote many brush engines, this one is not mine. But I have many experiences with brush engines so I hoped to use them.

Thanks to the consultations with Cyrille Berger,author of this brush engine, I managed to speed up the smudge. I removed some unnecessary memory device and then I had to write famous custom bitBlt function which takes selections saved in different memory class into account. The performance bottleneck was transformation of our paint device into selection.

We introduced fixed paint device longer time ago which should speed up the composition of the brush masks because it is lightweight memory device, but in the smudge it introduced some workarounds which slowed down the performance. I removed that workarounds but it was complicated, that’s why nobody did it before. I ported some of my paintops to use the fixed paint device because according our benchmarks it is really faster.

Here is the table with the performance times of smudge in our KisStrokeBenchmark, where the brush engine draws the big stroke:

1. 7,519 msec per iteration (total: 7519, iterations: 1)
2. 5,275 msec per iteration (total: 5275, iterations: 1)
3. 1,202 msec per iteration (total: 1202, iterations: 1)
4. 653 msec per iteration (total: 653, iterations: 1)

You can see, that the speedup factor is almost twelve. The table consists of the iterations when optimizing. From initial time to the final optimization.

On Friday I was done so I started to work on a vectorization of the compositing operations. Sounds cool, nah? First I wrote benchmarks for our composite operations and now I will continue to write example code which will use the vectorization in gcc4.x. Here is what I’m going to study and use. The point is to speedup the composition of course.

A couple of days ago Frank released the first beta of ownCloud and I've been playing with it almost continually since then. For those who haven't read Franks blog entry (which is well worth reading) ownCloud is a set of server scripts for personal storage (among other things) and hopes to implement an open source cloud for everybody to take advantage of. If that doesn't make sense, wait for the screenshots :-) New features are planned (and you can see exactly what those features are at ownCloud.org.)

Now for the fun part: First, keep in mind this major caveat: This is software that has not been released, is not feature complete or bug free or ready at all for general use. But isn't it fun to see what the future might hold?

I installed ownCloud on my server at home, put some files in it and then accessed it from as many computers as possible. On linux:

That's my ownCloud server, mounted via WebDAV and being used to store and access files. That alone was pretty cool in my book.

Next I went to a nearby mac and tried to see how difficult it was to access it from there. The answer: not very. Here's another screenshot:

It appears just like any other file system, to the point where I tested out setting iTunes to use it as my media library. It worked, albeit with a few kinks. The last screenshot I have for today is one of just the basic web interface

That's it for today but I hope to be back soon with another entry showing off some other features of ownCloud. If it looks like something you're interested in helping with, the code is available on gitorious, there's a mailing list here and at least a few people have already jumped in with patches.

Good night!

Mostly as a reminder to myself, here’s how to show remaining battery time in the Battery Monitor widget shipped with KDE Software Compilation >= 4.3:

Remaining time in the Battery Monitor

1. Right click on the battery and choose “Battery Monitor Settings”
2. Enable “Show charge information” and click on “OK”
3. Quit plasma-desktop with the command
   

   kquitapp plasma-desktop

4. Open ~/.kde4/share/config/plasma-desktop-appletsrc in your favorite text editor (some distributions use other paths, for example ~/.kde/...)
5. Search for the term
   

   showBatteryString=true

   and add the following line directly below it:

   showRemainingTime=true

6. Start plasma-desktop again
   

   plasma-desktop

You may disable “Show charge information” now if you want.

Credits to Sebastian Kügler for posting the instructions on the plasma-devel mailing list. I’ll try to also add them to Userbase when I have some more free time.

Note that I do not want a flame war here about if this should be the default setting/configurable in the GUI – it’s been discussed before, and complaining here won’t make any difference.

Enjoy!