We are really glad to release the first officially stable version of our new Screen Management tool that allows you to configure screens such TV, Projectors or Monitors magically just by plugging them while keeping an interface for those users that want or need a more custom configuration.
For those who haven't read the previous announcements, here are the most important features of KScreen:
The System Settings module:
The KDED (magic) Module:
We are already planning the 1.1 but more of that in the next blog post.
A few days back I attended the first freedesktop summit/sprint where a few hackers from different free desktops met with the objective of working together. We were people from Razord-qt, GNOME, Unity and of course KDE.
Even though we did not had the chance to discuss all the topics I was specially interested in like Notifications or Session Inhibition I did had the chance to get involved in other topics that are equally interesting like the shared Desktop Files cache or the "Trash size cache" that will enable a cross desktop way of caching the size of the Trash folder getting better performance across desktops.
The social part of these kind of events is important as well, even though I already knew Ryan and David a week of working together makes the collaboration more smooth, and of course I also met new people as well like Lars, or Jeft.
I'm quite happy to have pushed together with Ryan this event, we definitively moved forward the collaboration between desktops and even though freedesktop is still far from being perfect I do believe we did a step into the right direction.
Can't wait for the next Fd.o Summit.
After a few more weeks of hard work in KScreen we are glad to announce the release of our first release candidate. We decided to jump directly from alpha1 to RC because of all the great feedback we have received and the surprisingly small list of reported bugs
We'll probably do another RC release to test some of the code that is not yet in this version, like supporting the restoration of manually added resolutions (something only needed for broken monitors).
From now on we will be maintaining only one release instead of 4. We are going to focus on 1.3 and try to fix all remaining bugs, then we will work on implementing some of the reported wishes and release 1.4. Once that happens we will only maintain 1.4.
Since BlueDevil was released we have been updating all stable versions, which means:
- 1.0 (currently at 1.0.5)
- 1.1 (currently at 1.1.5)
- 1.2 (currently at 1.2.4)
- 1.3 (about to release 1.3.1)
This has been possible because the code base did not change much between releases so we fixed the bugs in the oldest version and then forwarded the fix to all the other releases, this was the easy part.
Before each release we like to do some intense testing to make sure that none of the basic functionality has been broken. In the hardware world quality is extremely important, we do not want to leave the user without a mouse, connectivity or an usable screen just because we are lazy or we don't feel like doing QA.
In the case of BlueDevil we test most of this before each release (independently of what code has been modified): http://community.kde.org/Solid/Projects/BlueDevil/Tests
This means that even if the "Send File" functionality was NOT modified in a new release, we test it just in case something broke.
In the list there are more or less 60 items, lets say it takes 1 minute per item to test it (it takes more) that means that it will take roughly an hour to test an entire release. Now multiply this per 4 which is the number of releases we have been doing and you will get 4 hours we invest on QA.
Besides the work we do before each release there is a constant effort of bug triaging that becomes way more difficult when you support a variety of versions since it makes you have to switch to a given version to try to reproduce and fix a bug you can't reproduce with the version you are using.
If it is that much trouble, why have you been doing it?
In one word: distributions. Each distribution has a different time table, each distribution has a different minor release policy, each distribution is a different world. At the time we started doing this, Bluetooth in KDE was a mess so the highest priority was to have a good experience in all distributions. It should not matter which Bluedevlil version they were using.
Nowadays the situation has changed, we work quite well in all published versions so if a distribution does not upgrade (for whatever reason) the user won't die.
So, now what?
From now on we are going to maintain only one version, and we are not going to support (or give support) to any other. This means that if a bug is reported with an old version the first thing we are going to ask is to upgrade and test again (if the part that is supposedly broken has been updated).
We are going to release 1.3.1 soon, and possibly another minor release for 1.3 if we have any bugs to fix. Then we will focus on implementing some of the wishes we have been ignoring for years (sorry for that :/) and release 1.4. Once that happens 1.3 will be automatically deprecated and only 1.4 will be supported.
I find it quite sad that after all this years going the extra mile so distributions can have a good Bluetooth experience, nobody stepped up to maintain stable releases. I guess this means that we are doing the right thing after all.
So, if your distribution is not shipping the latest BlueDevil version or it is not upgrading to it ask them to do so!
If after this blog post somebody feels like taking the job of maintaining the stable releases please, email@example.com is your list !
One of the points we had left to implement before we can consider KScreen a replacement for the current screen management was support fo XRandR 1.1.
The XRandR1.1 extension dates from 100B.C and it only knows about one screen on which you can change: size, refresh and rotation. Luckily all modern drivers implement at least XRandR 1.2 (which know about multiple screens) so you may be wondering why do we bother to support such an old thing?
It turns out that virtualization software usually only support XRandR1.1 and some other tools like Xvnc or Xephyr do as well, so the only way of ensuring that we look good when executed in those software is by implementing support for this old api.
Can you imagine what impression will a potential user get if the first thing we do while executed in a Virtualbox is crashing? not good for sure.
So, we are a step closer to consider ourselves complete :)