Feed aggregator

I've been running KDE4 desktop since May and I've constantly suffered from poor desktop performance and various graphics card related problems. Now I've solved those problems: I've bought an ATI card. Despite NVidia releasing the new Linux driver and suggesting to tweak several performance-related configuration options, I still decided to go and spend $50 on the new video card. Here is the long story why...

On my NVidia GT8600 KDE4 had several types of performance problems:

1. Slow repainting of windows
When I used KWin as a window manager with disabled compositing (sic!), main windows of KDE4 applications took too much time to repaint themselves upon switching. When I used other window manager (twm for instance :)), the repainting was a lot faster. Measurements showed that KWin suddenly took more than 40% of CPU on window switching. Turning on compositing (aka "desktop effects") greatly improved KWin performance, but compositing was a no-go for me for the reasons I'll explain below.

Status of the problem: could not be solved for me.

2. Slow resizing of windows and plasma applets
That's the problem all people using NVidia cards saw. It was the most severe but NVidia forum's suggestions helped.

I created an autostart script

#!/bin/bash
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

and added 3 more configuration options to the xorg.conf:

Option "PixmapCacheSize" "3000000"
Option "AllowSHMPixmaps" "0"
Option "OnDemandVBlankInterrupts" "True"


This all helped to get reasonable performance. Some people report that for them KDE4 flies with such configuration. For me it did not fly. The performance was just bearable, but KDE3 desktop was simply a lot faster.

Status of the problem: almost solved.

3. Slow desktop effects
KDE4 with desktop effects turned on, remind me of running a heavy video game on integrated graphics card :) Slowness, freezes and so on.

Using the newest driver and all options I told about above solved the problem. Once again, almost solved. Virtual desktop switching effects would still freeze times to times.

In any case, I didn't care much because every time I turned on compositing, scrolling speed in Firefox degraded by an order of magnitude. I have to use Firefox a lot these days because I do web development at work so compositing became a complete "no-go" for me. Therefore I didn't really cared much about it being slow. I could be happy if only KWin hadn't got the problems with slow window repainting (the problem #1).

Status of the problem: almost solved.

4. Slow painting in KDE4 apps
This problem didn't depend on window manager or compositing. It was always visible and the most annoying. It was also quite hard to track down and profile.

One example was a listview widget in akregator with a list of posts. I have hundreds of posts there and listview scrolling was too slow for me. Valgrind said that the text painting was a problem. My laptop with old ATI X1600 card (and open-source driver) rendered the same text a lot faster and scrolling in akregator wasn't an issue at all.

Second example was kate also having problems with painting text (see bug report for details). The painting algorithm in kate part may not be ideal, but my system was supposed to be fast enough to counterbalance that. In reality, painting text with the nvidia driver was just too slow and non-optimal algorithm just merely increased the annoyance.

Status of the problem: I was unable to solve it.

5. Corruption of system tray icons
Almost always icons in system tray were rendered with some weird background consisting from parts of other system tray icons. No driver updates and config options solved this problem

Status of the problem: I was unable to solve it.


Conclusion
After several months of self-torturing I decided that it was enough for me. I went to the local shop and got a cheap ATI Radeon 3450 card for $50. It's inferior to my 8600GT but I don't care much because KDE4 just flies on it. And by "flies" I do mean that it's really really fast. All 5 problems I've listed above are gone now. Period. Finita la commedia :)

It's not like things are all that shiny with an ATI. I miss the brightness setting in the driver (with nvidia you could do something like nvidia-settings -a Brightness=-0.4) and Firefox is still slow with compositing enabled. But in any case my desktop doesn't bother me anymore and I can just enjoy using it.

Update:
If after reading this post you think of selling your NVidia card and buying ATI, please note that proprietary ATI driver has at this moment (October 2008) several problems I know and can confirm:

• video (xv and gl) doesn't work with composite turned on - it flickers
• Xorg may fail to properly shutdown leaving only blank black screen
• scrolling is still slow in Firefox with compositing turned on

For me desktop effects are not important at all, I turn them off. Be aware of the problems listed above if you intend to use X composite extension and desktop effects in KDE4.

Tomorrow most people will be back from the holiday season, time to start again with the biweekly IRC meetings of the openSUSE KDE Team. This time we will look back to last year or rather to the openSUSE 11.1 release shortly before Christmas and the biggest reported problems. And also, despite the schedule discussion not being finished yet, we will start to collect and discuss ideas for openSUSE 11.2.

Do you think that you have significant amount of experience to work as a mentor at KDE forums? Then you should consider joining the team! Read on…

What do mentors do?
Mentors are responsible for conducting Klassroom sessions. For those who aren’t familiar with the KDE Forum klassroom concept, read this post.
You will be conducting a “Kourse” (lesson) at the Klassroom area. The lesson can be something like “Fixing XYZ bugs” or “Documentation kourse for project ABC”. You will guide a team of “students” (who will apply for your kourse beforehand). Your motive will not only be to contribute to KDE but help them learn how to do so.

Why are mentors needed?
With the great success of the klassroom concept, we are looking forward to have more sessions (at higher frequency). For that, we would need more contributors who can undertake and organize sessions. Existing mentors are listed here.

What all would you have to do?
After joining the mentors group, you will have access to the mentor team forums and moderational access to the Klassroom forum. You can start by posting a draft of the kourse you will be conducting, which can be reviewed by other mentors and forum staff. Once ready for shipping, your draft will be announced for public viewing and you can start with the kourse at the Active Kourses area. Your kourse can be based on any of the following:

• Bug fixing and development in general
• Documentation and screencasts
• Any form of KDE artwork
• Translations

At present, you would be handling a small team of 5-6 students, though this limit may go up depending upon the interested candidates and kourse popularity. After joining, you can also optionally have a “Mentor” badge for your username.

How can I apply?
If you are interested to contribute, you can send a PM to neverendingo (requires registration on the forums) or find him on IRC: channel #kde-forum, network freenode.
In case you send a PM, don’t forget to include a short introduction of yourself and your plans (if any) for upcoming kourses.

I work with bugs.kde.org nearly every single day.

Most people who report bugs on it hardly ever visit it, and that's not a bad thing.

Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.

Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.

Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:

• Always include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect.


• If reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps in detail needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems.


• If you are reporting a crash, always include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even more important. However, first consider reading this how-to on creating nice backtraces and get a realy good backtrace for the report.


• Do not upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments.


• If the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question.


• If the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that.


• If you can't reproduce the bug after a while, let us know. That's useful information.


• If we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there.


• Do not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File new reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones.


• Which leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic. ;)


• Whenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... even if the report is closed. So feel free to add comments to reports, someone somewhere will still get a notice of them.


• Fixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer.


• Describe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them.


• You don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't have to come up with a solution.


• I hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report.


• Don't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)


• Don't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. ;) In general, I put far more weight behind how many duplicates a report has than votes.


• When it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything.


• Saying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps.

Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)

Earlier today Dirk sent a message to the release team and KDE core devel mailing lists noting that KDE 4.2 is now branched off of mainline and that the the first RC is being tagged. That means trunk is now what 4.3 will be.

As I've been reminded a few times already today myself, that means we need to backport bugfixes made to trunk that we want to appear in 4.2. The svnbackport script in kdesdk was updated today to backport to the new 4.2 branch and makes the process of backporting your last commit trivial.

The last few weeks leading up to a release are always exciting and nerve wracking for me. There are numerous details that always need to be worked out, though the project is getting better and not leaving things to the last minute. The promo team has been working on release materials since sometime in December, even. Hopefully that reduces the stress levels and burn out rates. =)

In a couple week's time it'll be full throttle on 4.3 ..

Let us start with a screenshot:

The graph itself is not something new, since I just recreated SquirrelFish Extreme comparison (against its predecessors). The focus is actually the tool which was used to generate that bar chart.

For the code and a little explanation, check out what I wrote on Qt Labs on the topic of QtScript-based bar chart.

Apart from being excited about that I still have to fetch a place to sleep on saturday. Having read this promising offer I was wondering if someone wants to join booking a group room?

Posted in KDE, OpenSource   Tagged: FOSDEM, KDE, Room booking   

In this week's KDE Commit-Digest: Plasma panels now support "drag-and-drop unhide". More improvements for scripted Plasmoids. "Weather" Plasmoid moves into kdereview for eventual move to extragear for KDE 4.2. Lots of reworking the "HTML Validator" Konqueror plugin. Start of a "BomberMan"-like game using Kapman as a base. New game themes in Bomber and KTron. Further progress on the rewrite of Kolf. Start of an effort to refactor game modules in KGoldrunner. A KIPI plugin to export photos to Facebook from KDE photo applications. Support for autoselection in the "libksane" image scanning library. Work towards automatically detecting digital cameras in Digikam (using Solid). Support for importing old feeds from the RSS plugin (from version 2.2) in KTorrent. Work on "Kloss" (bindings for the Lua programming language). Start of an iPod plugin for DeviceSync. Final remaining feature implemented in Ark for KDE 4.2. Initial import of KSSH4 to KDE SVN. Read the rest of the Digest here.

Over on planet.gnome.org, Ted Gould blogs about how the current system tray protocol sucks. I've written about the systray recently, but I started writing about how much it sucks 5 years ago. I wrote about it in a number of places, and sent mails to the xdg list.

Of course, I was always busy with one more thing and nobody else really seemed to care. In fact, some told me I was being silly and the current system was just fine. I wonder if those people even remember. =)

In any case, it seems like hell is finally freezing over: we have a system tray widget in 4.2 that is built for multiple backends (and already has a couple) so that we can freely mix and match old with new as a realistic path forward, and people in other projects are talking about doing actual work in the same area too.

Hopefully Ted isn't going to make the same mistake I did, which is to realize the error of our ways then not actually do anything about it for a couple years because there are so many other pressing things to do. ;)

I also hope that in their thinking about these things that as they move to implementation that they keep us (the F/OSS desktop world) information and even share their plans as they go forward. I personally plan on sending something to freedesktop.org once we have something we can show works reasonably.

Yes indeed ... I think the Devil be shaking, and it ain't out of fear.

Hi KDE people that are coming to FOSDEM,


Here are some small adaptations to the hotel reservation.

In the meanwhile I managed to get an option untill 19 januari for Hotel Albert.


For those still in search of a nice hotel, I managed to get a reduction on rooms in a very nice hotel in the center of Brussels. Very positive: the hotel has free wi-fi!

If you make your reservations at this hotel, please do not forget to mention "KDE voor Emile" to obtain these special prices.

Prices for KDE are:
single room 45 EUR
double/twin room 50 EUR
Tripple room 60 EUR
Quadouble room 70 EUR

Breakfast is included in these price.


You can make your reservations by calling the hotel, by e-mail or by means of the reservation form online.

It is a very nice hotel with 2 up to 3 stars.

Since I do not have an option on these rooms, it will be first reservation = first gets. Rooms are limited, there this hotel is situated very central and very popular with tourists.

Hotel information:
Albert

Koninklijke Sint Mariastraat,27
+32.2.217 93 91
info@hotelalbert.be
www.hotelalbert.be

Situated:
Hotel Albert is situated very near Brussels "Kruidentuin or Botanique" (Herb Garden). Acros the streat you'll find a concerts hall "Hallen van Schaarbeek", where in the weekends concerts and cultural events are kept. The hotel is almost next to Nord Station, very near the shopping area, the central station and the Royal Palace. Every room has a shower, toilet, flat screen television, hair dryer, FREE WIFI.
Bus 272 stops in front of the hotel and goes directly to Brussels airport. For other transportation, Brussels Nord station is almost next door.



An other option:
It is also possible to book in the hotel where KDE stayed last year. It is situated a little less central, but still has a good connection to public transport.
Prices are more or less in the same rate. http://www.hotelsabina.be/
Also here make sure to use "KDE" in your reservation!

After 2008's Tokamak in Italy, I blogged about scripting and my cracktastic thoughts on it. I mumbled on about ninjas and myspacers and apparently the drugs are still in my system because I still think it's a solid approach to the problem.

Thankfully I was able to convince a couple others of that as well and the widgets API we put into libplasma, which really just wrap plain QWidgets-in-QGraphicsProxyWidgets thereby taking the boredom out of using them and giving a nice scripting-friendly view on them, was one result. The other was the JavaScript AppletScriptEngine in kdebase.

Rich Moore started the work on these and got a fair ways into it. Then he got busy with his day job. Then he got really busy with his day job. We talked about it on IRC a bit, and I said I'd try to help pick up the slack. Chani and I ended up doing the widget API and Rich got some more work done on the script engine. Then Rich got really, really busy and things stagnated. It happens. (Rich, if you're reading this, we can't wait to see back around. =)

Then Chani decided the other week to write a Plasmoid. Something simple. After months of work on the widgets-on-screensaver insanity project I totally understood her desire for something a little less frustrating, a little more immediate and lot more fun.

However, I begin to think that "Chani" means "trickster" in some devious ancient language because she started doing it in JavaScript. Not with the "ninja" engine in playground (sensible, it's still in playground after all) but with the "myspacer" one that had already trundled into kdebase. That was when we got reminded how incomplete it was.

So Chani, Marco and I jumped on the poor beast and over the span of a few days implemented access to DataEngines, Services, context menu actions, configuration settings, layouts, access images shipped with the Plasmoid in its package and more. The foundation we built on (Qt, QScript, the core KDE libs, libplasma and Rich's initial work in the engine) were all solid and so we raced ahead at great pace and now you can do actually useful things with it.

We wrote a few little test applets to poke at the engine with and as tagging approaches within the next 24 hours for RC1 it's actually moderately useful. =) Take this guy for example:



If we remove the debug output and whitespace, it's 27 lines of JavaScript that can control any music player that exports an MPRIS controller interface (thanks to the nowplaying DataEngine). It all starts with:

engine = dataEngine("nowplaying");
watchingPlayer = engine.sources[0];
controller = service("nowplaying", watchingPlayer);


Yep, it just rips right into things, grabbing DataEngines and Services and flinging them around. In C++ we would've written a couple dozen lines of code (class declaration, constructors, etc, etc) and a CMakeLists.txt to get this far. So while the Plasma, KDE and Qt APIs are great, there's entry overhead we can avoid by using higher level langauges in the right places, no doubt about that.

Next it defines three functions: dataUpdate, stop and setProgress. I won't bore you with those, you can see them yourself over on websvn by looking at the whole file. It then makes a simple UI, all sparkly, performant and themed thanks to libplasma and Qt:

layout = new LinearLayout(plasmoid);
layout.setOrientation(QtVertical);

label = new Label();
layout.addItem(label);

stop = new PushButton();
stop.text = "Stop";
layout.addItem(stop);

progress = new Slider();
progress.orientation = QtHorizontal;
layout.addItem(progress);


It then glues stuff together:


stop.clicked.connect(plasmoid.stop);
progress.sliderMoved.connect(plasmoid.setProgress);

controller.associateWidget(stop, "stop");
controller.associateWidget(progress, "progress");

engine.connectSource(watchingPlayer, plasmoid, 500);


Those controller lines are somewhat magical. They connect the widget to aspects of the Service, so when for instance the music stops the Stop button automatically fades out and becomes disabled. Neat.

The last line connects the DataEngine up and the widget "goes live" at that point. When the music player starts playing, the Stop button becomes enabled, the name of the song, artist and time is printed in the label above and the progress slider starts marching along.

Clicking Stop actually stops the player as you'd expect:

plasmoid.stop = function()
{
controller.startOperationCall(controller.operationDescription("stop"));
}

Moving the slider seeks within the song:

plasmoid.setProgress = function(progress)
{
operation = controller.operationDescription("seek");
operation.seconds = progress;
controller.startOperationCall(operation);
}

All pretty simple stuff, and documentation for the entire API exposed in this simplified window into Plasma is on the way.

Installing the Plasmoid itself is a snap: plasmapkg -i script-nowplaying. In it's final form as a zip file (so `zip -r nowplaying.plasmoid *` in the root dir of the plasmoid), `plasmapkg -i nowplaying.plasmoid` suffices or you can install it via the Add Widgets dialog in the Plasma desktop shell. The Plasmoid above becomes a 1.5K file on disk that you can toss about quite easily, including between operating systems with completely different toolchains and hardware architectures.

We have planned out some tools to help you create Plasmoids extremely easily, so there will be no need to know the packaging details at all for instance. These things will only get better.

I'm really impressed with how quickly it came together over the last few days compared to how actually useful it already is. Writing a high quality language runtime is not an easy task. Writing frameworks like Qt, KDE's core libs, Solid, Phonon, Plasma, etc are also not easy tasks. But gluing the results of those two efforts together? Amazingly quick, if a little black magic-y in places.

Thanks go out to everyone whose worked on those hard bits, and especially Rich Moore, Marco and Chani for helping bring this part of the puzzle together.

Where Do We Go From Here?

If you care about non-C++ languages and Plasma, come join us. We've already got a few Ruboids and Pythonistas hanging about on plasma-devel@kde.org and on #plasma writing Plasmoids, but we need more of you. JavaScripters with an itch to scratch should come join us, too. We need to kick the living crap out of these ScriptEngines and torture them in all sorts of ways, just as we have the C++ libplasma over the last year, and create cool things with them in the process. This way we can go from our first-cut ScriptEngines in 4.2 here to kick ass ones in 4.3.

We're willing, in fact desiring, to improve, modify and grow the ScriptEngines in response to usage. It's the best (some might say only) way, really. =)

I'll be announcing the documentation for the Basic JavaScript ScriptEngine when it's ready to go so you can all jump on it. The docs will come pre-4.2.0, so that you should be able to upgrade to KDE 4.2 and start hacking JavaScript with documentation in hand all in the same day without compiling any C++ on your own. Huzzah.

Networkmanager is a daemon that keeps track of lower level bits on computers that have changing network hardware. It's designed to do this dynamically, and exchange information about status with a user interface that acts as configuration UI and policy agent. Networkmanager has gone through a large redesign between the 0.6 and 0.7 version, including the necessary API and DBus interface changes. Not without advantages though. I personally didn't really like networkmanager's behaviour in the past, found it too random, too much getting in the way. Networkmanager 0.7 is better in that regard, it doesn't drop my connection all the time for a start, it stays online while you log out and operates mostly within the bounds of what I deem sane.

One of the projects I've been working on over the last couple of months is the networkmanager plasmoid for KDE4. Will has put the infrastructural bits and pieces that are needed to work with networkmanager 0.7 into place. There is the networkmanager backend for Solid, KDE's library for interaction with hardware, but also all the different configuration interfaces for all kinds of network access.
During development of the networkmanager plasmoid, I've often used the GNOME nm-applet. It does the job quite well and is a reliable interface to networkmanager. Something I find a bit confusing is that it offers two context menues, one on right click and one on left click. I often find myself looking in both until I've found the option I've been looking for. This also has to do with a limitation of the whole systray interface, which seems really outdated when looking at how we usually do these things in Plasma. As a matter of fact, nm-applet uses the GNOME keyring, which reminds me that it would be nice at some point to share this functionality (i.e. have it uses kwallet on KDE and keyring on GNOME). Right now when using nm-applet, I've two password stores that I need to unlock after login. I've also tried some other 'wifi connection' UIs. One, I've seen in Windows was particularly bad. It would ask the user to type in a WEP key (the long versions, often), didn't offer any help doing this, but made it made it harder. You had to fill in the long HEX key twice, and both fields for that were password fields, so you can't even see what you're typing. It was just plain horrible. Quite a bit better is the interface of the iPod Touch (and presumably the iPhone). It does a good job on the input side (especially given that the user doesn't use a keyboard but the touchscreen). It does fall flat on its face technically though. First, support for WPA2 is lacking, that rules out access to the network at the university, and supposedly many others. Then, it often reports that it has established a connection when it merely logged on to the access point, but didn't get an IP yet. Since you can often connect to accesspoints (even encrypted ones) but don't actually get an IP address, that information is often bogus and it can be quite annoying being told you're connected, while you're not. One of my favourite wifi settings UI is the one shipped with Maemo. While it's nothing fancy, it gets the job done reliable and it doesn't confuse me.

So one of my personal goals is to not make all those mistakes in the interface for networkmanager in KDE4. We're not there yet, but progressing OK. Settings for wired and wireless start to work, as in "at least three persons on this Planet have ever been able to connect to a wireless network using it". It has UI glitches, it's not nicely streamlined for workflows we have in mind, the configuration interfaces are no beauty yet, and it has bugs, lots of it. It is in no way near release quality yet, more like an early Alpha. We're trying to have a first working version out within the next couple of months, hopefully in time for the distros that ship in spring. So the applet won't ship with KDE 4.2 we're planning to release it individually so you (or your distro) can grab it in the meantime. We're looking at putting it into KDE 4.3 then.
If you're interested in hacking on it or just trying it, the current code can be checked out from playground. For this to work, you need to have the libsolid code from kdebase/workspace/solid installed. There are actually two networkmanager plugins, one is for networkmanager 0.6, one for 0.7. The latter one is the one we're relying on. Yesterday, coolo started committing patches to the networkmanager plasmoid, scratching an itch. That's pretty cool given that he's one of KDE's oldtimers. A true honour to share code with :-)

well, the first day of a new semester is over. it’s been a fairly good day. the burnaby campus was closed (even though buses were running) but the surrey one was open, and all my courses are there. the first course was cancelled anyways because the teacher didn’t think he could make it. :)

I got my upass, sold an old textbook, managed to get into the bookstore at a time when it actually had no line and buy one of my textbooks, and discovered I’ve got a friend in each of my classes. macm 316 looks like it’s going to be annoying (the teacher has a thick accent and mumbles), but cmpt 383 will probably be quite interesting.

how much time I’ll have for KDE this semester remains to be seen, but I *am* going to campkde, and there’s another tokamak soon (oh god I hope I can keep up with my courses with all this travel) so if all else fails I’ll have a chance to hack then. :) aseigo and notmart’s work on the qtscript bindings seems to be going quite well, so this week I think I’ll try to focus on getting ahead in class wherever possible and preparing for my courses. of course, having said that I’ll probably get distracted by shiny code anyways ;P

      

More KDE 4.2 Release Parties

• When: Friday January 30, 19:00
• Where: Piratz Tavern, Silver Spring MD (map)
  • Metro accessible, Parking available, Family friendly
• Contact: Celeste Lyn Paul

 

New year means some snow and cold noses here in Warsaw, and a new job to me, this time in the mobile industry, what has rather diversified my day, and that's good. Happy 2009 to you, to your friends and family.

But I am on the KDE board too, it's not going to change. What's recently time-consuming for me is refactoring of the Native Kexi Forms. The most serious and anticipated decision is dropping the (implemented in 2004..2005) idea of the forms component reusable at a rich API level for other applications. The idea has introduced too man layers after months of development, too many to have things maintainable, with just proof-of-concept KFormDesigner being the only app using the framework except Kexi.

Since 2005 things have changed, Qt Designer gained its own reusable libraries. Before someone asks - we don't use them in Kexi Forms not just because that would affect the licensing (LGPL) or because of backward compatibility required by the current Forms' XML format (which is ~95% the same as Designer's but the 5% makes the difference). My point (or read it as feelings) is that while there would be no technical overhead in reusing Qt Designer, we would have overhead counted in man-months.

The first step, mostly finished now was to remove Qt3 Support dependencies. A bit late? True, but not too late. The code using the meta objects and properties is too fragile to receive massive changes in one go. Unlike KoProperty that received rather massive rewrite to Qt4's model/view API (I am not 100% happy with the results yet ) since last summer, Forms are more complex and I am employing strategy of incremental improvements for them. But after all, did I mention that continuous advances in many other parts of KOffice (if not just entire KDE 4) work as true motivation?

Yet another beta for Eigen 2!

Yesterday I released a beta4 but so many issues got fixed since that it's worth making this new beta. I'm starting to be really confident about this being used to build and package KDE 4.2 and KOffice 2.0, not only on Linux but also on Windows and Mac OSX. Just today we've been fixing a Mac OSX issue, several Windows issues, and a couple more generic problems. It's really good to have many users and I must say that in Eigen we're rather spoiled, our users are very active in helping tracking the bugs down -- probably that's the upside of a project being technical in nature.

The API should be 100% stable now -- except of course for the parts of Eigen that we're calling experimental. For the 2.0 release we'll just remove the deprecated stuff (so check your warnings NOW!).

In other news, the forum is very active already so I'm optimistic that we'll reach pretty soon the point where users start helping each other -- something I'm eagerly looking forward to! Like I expected, we're seeing a new group of users on this forum whom we didn't see on the mailing list. So it's great to reach new people. On the other hand there's the risk of balkanization if instead of one we get two disjoint Eigen communities -- that would be pretty bad! We'll see.

It happens again and again that developers complain about cmake being too slow when compiling after a quick change. The solution is to use

• make $target/fast
• make install/fast

This way, cmake skips the dependency checking. As example, whenever I change code in kdelibs/kate, I type make katepart/fast and make install/fast.

So, if you are following the kde-cvs-announce mailing list, you have seen this message about tomorrow’s changes that are bound to hit the SVN.

In a nutshell, when KDE 4.2.x is concerned, this means a couple of things:

• 4.2 is moving away from the trunk, and starts its life in its own branch.
• 4.2 is entering the last stage before tagging it as /final/

While this is great news for 4.2, it is even better for 4.3. This means that the SVN trunk is now exiting the /feature freeze/ state. This is a great thing for developers because the development becomes fun again (squashing bugs can not be labeled as fun), great for PlanetKDE readers since you’ll get real news from now on, and great for feature junkies for obvious reasons.

Lancelot 1.5

Lancelot’s version that will be branched tomorrow is the final 1.5. Compared to the one in beta 2 (1.4.9), it has a couple of bugs (that you haven’t noticed, if bugs.kde.org is to be consulted) fixed and is ready for prime-time.

Now the development of your suggestions can begin!

(image copyright by Wade Olson)


Anyone else noticed the extreme amount of hate & trolling against KDE lately, and especially against KDE 4? I have a special message for you trolls:

You're fucking idiots.


For your consideration:


1) they ignore you

2) they laugh at you

3) they fight you

4) YOU WIN.


(we're at stage 3 now)

(image copyright by Wade Olson)


Anyone else noticed the extreme amount of hate & trolling against KDE lately, and especially against KDE 4? I have a special message for you trolls:

You're fucking idiots.


For your consideration:


1) they ignore you

2) they laugh at you

3) they fight you

4) YOU WIN.


(we're at stage 3 now)