Planet KDE

For the last 2½ years I have been working full time as a developer for Magnatune.com. While I have enjoyed this work very much, within the next few months, Magnatune wishes to transition me to a part time position instead.

This means that I will either have to find some more clients for my small one man consultancy business or find something else to do altogether.

So, if anyone is interested in working with a skilled developer with a passion for Free Software and Free Culture and a proven record of making stuff work (whatever unconventional solutions it takes) I am putting myself up for grabs. I am very skilled in C++/Qt/KDE through several years of contributing to Amarok and I can work with pretty much whatever technology is needed to make a given project work (at Magnatune I have done mainly PHP and TCL and in previous jobs I have worked with Java, Perl, Lua, Delphi, C and host of other things)

Alternatively, if anyone out there wants to sponsor a particular feature for Amarok, now would also be a perfect time. I wrote the integrated Magnatune service and the framework behind the services in Amarok 2 (as well as many of the other services as well) so anything that aims to integrate an online source of music I am particularly good at.

If you have any interesting proposals, ideas, questions or just want a full CV, please mail me a nhn@kde.org

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.

Filed under: Amarok, KDE Tagged: Amarok, KDE

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

The Plasma Netbook Reference Platform is a Linux-based software distribution that gives you quick access to the KDE Plasma Netbook experience.

It's designed to be easy to get: If you have a 2 GB (or larger) USB memory stick and a device (laptop, netbook, tablet) that can boot from a USB stick, you are one download, two (copy and paste) commands and a few minutes away from having the latest build of Plasma Netbook up and running.

It's designed to be easy to get involved with: We are using an openSUSE Build Service project that you can not only use and monitor but which you can even modify in your very own "playground". You can share your changes with others easily and even request merges from your work back into the main project.

Why?

Testing Plasma Netbook, demonstrating the possibilities of it to others or even just simply using the latest builds has not been easy or reliable enough. The Plasma Netbook Reference Platform gives us the opportunity to build and deliver a quality example of Plasma Netbook that is constantly kept up to date with development. This will hopefully allow us to:

• 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

We were lacking a tool that could do all of this for us ... until now!

How To Get It and Get Involved

Here are all the resources you need to get started immediately:

• 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

There are three very simple ways we will be measuring the success of the Plasma Netbook Reference Platform

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

This is your chance to dive into the deep end of the pool the easy way, to get a bit closer to Plasma Netbook and the KDE workspace projects using an easy and exciting set of tools. Whether your aim is to evaluate, use or contribute I personally invite you to take the Plasma Netbook Reference Platform for a spin today, track where we go tomorrow and share your feedback and ideas of how Plasma Netbook can be tweaked to perfection.

Here's where you start, we're already there and waiting for you. :)

Thank Yous

Thanks to:

• 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.

Whenever I was working on kicker back in the KDE 3 days, I was quite focused on panels and applets in the panels. It was a pain to test at times because panels can be in any number of positions on screen, they can be hiding (in various ways) or not, etc. Ignoring the repetition involved in testing, however, it was pretty straight forward development.

When moving from Kicker to Plasma I bit off a lot more to chew on, though I didn't immediately realize all the nuances of those decisions.(I probably have more to learn about them still, in fact. :) It wasn't until the 4.0 release was a few months away that the following aspect of it really set in: I was no longer creating one tool (kicker) that Someone Else(tm) would pick up and somehow cram together into a desktop environment, I was now working with a group of people to create a complete and coherent desktop shell that would encompass the run command dialog, the desktop layer, the panels, the window manager, system information ... as a coherent product. Yes, each piece still runs very nicely on its own and nothing is welded together at the seams (kwin, plasma-desktop and krunner all happily run without each other, for example), but they do support the user experience across those boundaries when run together as can be seen in how KWin provides more and more of the windowing effects used by plasma-desktop (such as the slide in and out effects on the panel).

Every time I press the volume up/down key on my keyboard and see the Plasma themed OSD I get that "oh yeah!" shiver; it's a very small and perhaps even inconsequential thing in and of itself, but it reminds me of what we're doing in the bigger scheme of things. :)

This hasn't been exclusively about KDE software on the desktop, however: a primary Plasma design goal is to be able to create any number of "primary user interfaces" with it and have them all be equally consistent and harmonious. Plasma Desktop was the first such asset we worked on, and in the process of making it we have brought various improvements to the desktop experience (and continue to add to them), but we have also created new kinds of primary UI shells. Netbook was the first "not a desktop" primary UI we made, and now mobile is coming along nicely. (Plasma Media Center is finding some new wind in its sails, giving me hope that it will see the light of my laptop screen eventually too. :)

This approach of creating multiple shells from a shared technology base, each of which is a "whole product" and unique from each other in terms of interaction concepts, has raised new new challenges for us. In years past I could just run Kicker (for example) on its own and ignore everything else that was going on during development and testing and never miss out on any useful information. Today, working effectively on (or with) Plasma Netbook, which has its own primary UI (plasma-netbook) as well as significant tweaks to the window manager and other tools, means running Plasma Netbook in its entirety. Only then can I really test it, understand it and appreciate it. We expect it to get even more tricky with other Plasma Workspaces that are being worked on such as Plasma Mobile.

This really came to a head for us a serious blocker as we find ourselves needing to be able to demonstrate, in context, what we're doing 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.

Every challenge is an opportunity, and so it has become apparent to those of us most deeply involved that we could really use an "interactive reference platform" that can be used to show "this is what we mean when we say Plasma $SHELL_TYPE, and here's how you can quickly get your hands dirty with it". The technology preview that the Kubuntu community put together was really helpful in this regard, and we have decided to go even further with this approach and try to produce something even more collaborative, that can keep you even closer to the leading edge of development and which is even easier to get, to try out and to modify.

So it was that at Tokamak 4 the Plasma Netbook Reference Platform was born. With all the explanatory bits out of the way, the next blog entry will focus on what that is and how you can get it (and get involved) right now!

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.

“An honest answer is like a kiss on the lips.” Prov. 24:26 (NIV).

About 6 weeks ago I wrote a blog about the state of decision making in the KDE community. I stated that generally speaking we are not heavily influenced by any single entity, something many of us cherish. Because of rising corporate interest in open source over the next years this situation might or might not change - it depends entirely on how we approach the challenges before us.

I realize the previous post did NOT have enough pretty pictures and easy bullet points - I will try to do better this time.

IndependenceLet me start by trying to expand a bit on the decision making itself. What does it mean to be independent? Not that commercial parties have no say or influence at all - after all, they contribute in various ways. A problem emerges when for example volunteers feel they're being left out due to the large contributions of full-time corporate workers. This was once described by Till Adam (from KDAB) as the freight train effect. This is problematic for both the volunteers (who might walk away) and the company. Companies often work project-based and need the community to solidify and maintain their contributions.

So the question I see when it comes to independence is NOT: "How do we prevent companies from having any influence at all". The question is: "How do we preserve a balance between company and volunteer input to preserve the long-term health of the community".
ChoicesLast blog I concluded we're facing a choice between:

• 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

The first. Yes, I actually added this one, as there is always the option to do nothing. What will happen if we just go on like we're doing right now? Considering the increasing interest of commercial parties in KDE technology, I guess we'd get more corporate contributors. Larger ones, too, which hire many people in the community to work on certain things. Our technology will spread more and more, and will appear on cool devices. Some companies might try and get their stuff upstream, others might not. But. Corporate influence can be at odds with community ideas (money can do that) which may very well lead to loss of passion for an development area or product some company took over. Things might go downhill from there. At some point, we *might* find us in a situation where our general direction is decided upon by an 'advising' or 'consulting' Board with companies like Nokia, Intel, Novell and other major corporations. We will probably be spending a lot of money on a CEO or a similar function, and choices are made top-down. Some developers will have no problem with this and continue hacking on cool things - it's all (L)GPL, after all. Others might dislike what has happened and will leave.

The second option will keep things in our community more as they are now (though we might even want to chase away some companies working with us as they're very influencial in some areas already). We will probably stay on the fringes, with a small marketshare - but we'll have fun. We can continue to invent and work on innovative technology but I reckon without help of big companies and working with them finances will get a bit tighter than they currently are (less coding sprints?) and we will fall behind in some 'corporate feature' areas volunteers don't like to work on.

And the third option - if we decide to go in that direction, we'd need to be consious of our values and freedom and protect them. We will need to know how it came to be that the KDE community, while one of the largest Free Software communities in the world, still makes decisions by itself and is not dominated by (and depending on!) a single entity or just a few. This will help us expand on our ecosystem of different organisations and volunteers working together. Currently, we get input from a variety of sources, be it independent volunteers, universities, companies or NGO's. Diversity is the keyword here - and we will get more of that. I will expand on this third option a bit further.
What's keeping us FreeSo what contributes to an diverse and open development process? Below a list of things which I think have kept us 'sane'.
1. Strong focus on technology and cool things.Most decisions are made on technical grounds or because users are asking for certain features. In companies, decisions on what is needed in the code are often made by non-developers - managers, committees, marketing people. I'm proud to say I don't have any say in development at all ;-) Generally speaking, companies working with us have had to adopt to this way of thinking, similar to how decision making works in the linux kernel development community: technical merits and arguments, not 'my manager said so'.
2. Flat organization, little hierarchy.We don't have much if any hierarchy and the different teams are mostly independend. This ensures that no one individual, foundation, or corporation can dictate the future direction of KDE development as a whole. As a result the project can grow more organically, and innovate more easily as well.
3. having a diverse ecosystem.Having 2 or 3 large companies hiring most developers contains a risk for the independent decision making process by the community. If a much larger variety of organisations (both for- and non-profit entities) contribute in a variety of ways, the opportunity for each to push a certain agenda is much smaller.
4. The role of KDE e.V. is strictly supportive.Companies have no business controlling KDE e.V. - it wouldn't help them as e.V. is not involved with development decisions, only supports us all in doing whatever we want. If we all wanted to move into the beautiful world of bowling, e.V. would probably continue to support us. We might have to vote for a new president, however.
5. Regular developer meetings.Our regular meetings don't just help development, they also create stronger bonds between developers. Not only among the volunteers but also with non-volunteer developers. This mitigates the effect of 'the freight train': corporate developers are often sitting in one room and thus have a tendency to start discussing things there and make decisions, instead of doing so with the wider community over the web.
6. Meetings are funded by KDE e.V.Funding by KDE e.V. instead of specific sponsors per meeting allows more independence of corporate sponsors when it comes to goal setting and justifying the results.
7. Having had to deal with Qt licensing.The Qt licensing issues early on in the KDE history have made the community consious of corporate influence and Freedom in general. We've set up a Free Qt Foundation dealing with this and receive and discuss regular reports about the status. And of course there's our legal dude in the e.V. (ade), who is rumored to sneek into your room at night and steal your underwear if you allow wrongly licensed code into your app.
ConclusionI think the community, that is all of you reading this - developer or not, should stop for a second and think about what we want. Personally, I would love to bring our 'Be Free' to every device out there - but I would prefer to do it in a way where we don't loose ourselves. This community is big fun. It is open, it is free, everyone can be a part of it and make a difference. Decisions are made by us, talking and doing. And for that, we might have to put some safeguards in place.

I would love comments on the above, input on other factors I missed and practical tips. Next time I will try, with help and inut from others, to make a list of what we can/should do to remain Free.

The treatNow a picture as reward for reading through (and thinking about!) all this stuff. This kitty stood behind our back door in our new house meeowing until we let it in. After checking out the room it decided it wanted to sit on my lap (while I was working, grrrr) and I can't say no to cuties so I let it. While finishing this blog it's purring beside me. Aaaw... Any suggestions for a proper name?

Maybe it's just because ownCloud is a new project so there are a lot of basic tasks that still need to be done, but every morning I wake up and there have been some pretty major changes made during the night.
This morning I found a preliminary configuration dialog, much better than setting it by hand, as well as instructions on how to create the databases necessary so now my log is working!
Obligatory screenshot of the configuration dialog:



Here's another shot of the log. At first I thought it only logged when people signed in and out but then downloaded a file and that showed up, too. I think the existence of a read event in the log implies that a write event is coming (or is already there and I haven't found it yet).


For my next entry I think I'll make a screenshot tour of installing ownCloud from scratch. Now that it has a configuration dialog it's a lot easier to get it running. Plus, even if it is still in beta it's already becoming incredibly useful for me. Access to an arbitrary set of files from anywhere changes how I do things. If I know I'm going to want to show somebody something there's almost always a computer handy and this is much more convenient than thumb drives or searching google for that link I like. I'm sure it'll only get easier when sharing is implemented directly within ownCloud.
Until next time!
P.S. Maybe this is getting old but it's always useful for me to see when reading about non-final code: No matter how polished it looks, it's still in beta and, by definition, not ready for production use. As soon as it is ready, I'll be the first to let you know :-)

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!

Hello, I've been very busy with school so I haven't had time to write much, but I have been keeping tabs on the technology world. During my daily news search I ran across this interesting article on the performance across different desktop environments. KDE did not do so well in this test.

http://www.phoronix.com/scan.php?page=article&item=linux_desktop_vitals&num=1

Any thoughts on this?

I’m really pleased to announce that latest version of QJson on master is working on Symbian. You can find the installation instruction here.

Since I’m not a Symbian developer it has been a little hard for me to achieve that. I would like to thank Antti Luoma for his help.

There are also good news for Windows developers: now building QJson under Windows is easier. Checkout the new installation instruction page.

I hope this will help all the Windows developers who want to use QJson.

Today’s the first (of two days) of the “Chemnitzer Linux Info Tage”. Here are some impressions:

This CLT begins

more then one visitor comes

our booth

never without konqi

This week’s heaviest contributions were Antonio’s directional navigation and Benjamin’s scrolling optimization for pages with fixed positioned elements.

• Antonio landed his work for spatial navigation, making it possible to navigate through links and widgets with the cursor keys. The long list of patches also includes layout test coverage, DRT support and a flag in QWebSettings for toggling the feature (18662).
• Holger fixed a bug where non-animated gifs were animated (35955).
• Robert added support for running caret browsing layout tests in the Qt DRT (35593).
• Chang fixed a bug with parsing CSS colors (22150).
• The network state notifier JS API is now enabled when compiling the trunk against Qt 4.7 (35983).
• Support for accelerated compositing is now enabled by default, when using QGraphicsWebView (35866).
• Benjamin implemented an optimization to avoid full frame renderings when scrolling pages with fixed positioned elements. If there are only a few of these elements present, then most of the pixels are still blitted (33150).
• Jesus added a fullscreen mode to QtLauncher (35755).
• Zoltan continues to spread the use of FastMallocBase to increase the coverage of custom allocators (35857, 35855).
• Jedrzej fixed two QtScript issues (35577, 35577).
• Diego fixed a bunch of failing layout tests with access key modifiers (35993).
• Props to Chang and the Szeged developers for keeping up with layout test updates

Note that I’m only listing changes here that actually landed in the trunk. There’s quite a bit more work going on behind the scenes and in bugzilla.

All these changes are also included in this week’s experimental build, for Linux, Mac, Windows, Symbian and Maemo5.