news aggregator

KHotNewstuff2 is going to be using Goya (once it moves out of kdereview and into kdeui on the 19th). So I thought publicly thank Raphael(ereslibre) and Kevin(ervin) for the great work on such a nice framework. I also wanted to let everyone see the new ui a bit and get some feedback.



This is 'khotnewstuff4 plasma-themes.knsrc' Currently the name, one line of description, author, and downloads are visible. I'll try to get rating shown, and a way to see more information about an entry. Also, notice the tooltip shows the complete description for each entry, it can be a bit big at times, not sure what the best way to show that would be, suggestions anyone?

Application Launcher, and Desktop Organizer. With one click of the organize buttons it will send mp3, png, jpg, to the correct folder saving the user time. Only runs on Linux Platforms.

My Amarok Icons in a set! Jan S.

Someone asked me if i could change the "Red Angry Amarok Icon 2**" into a green colour. Here it is! --> Look for my other Amarok Icons Jan S.

I took a picture and tried to modify the pic useing gimp, if anyone is able to enhance this wallpaper please do since im not having much luck with useing gimp for the first time.

A Kubuntu Wallpaper, hope you like it.

KFceu is a much needed front end for FCE Ultra. KFceu will provide you with the all tools to configure FCE Ultra with ease, and to browse your collection faster. Go to my openSUSE Build repository to see all the other distro packages. INFO: The latest version requires KDE4 libs, and developer tools, including CMake. If your using an RPM based distro you can simply try a "rpmbuild -ta kfceu.VERSION.tar.gz" as root, and if everything is set up right it should build an RPM for you.

This KDE theme is basically a declaration of love. I dedicate this work to you, JB, since I was thinking of you while I was working and testing this design in the last few days. I know we're facing a great storm in our relationship, but I want to tell you I don't want this flame to ever fade away. We always shared several common passions. Our souls touched each other long before we ever met. So I thought of representing all those passions under a same colour: the colour of joy, enthusiasm, li...

Today I may have stumbled upon why the people working on scripting for Plasma tend not to grok at first the point and purpose of ScriptEngines or any of the other mechanisms we have put in place for this:

In most cases, the API is defined by the host and the language binding is just a mapping of that API into the runtime environment the code will be run in.

With Plasma it's really the other way around. The language support (not necessarily bindings!) define the API while libplasma simply provides the canvas and management of the components. The language support defines the API, which could be a 1:1 mapping to the libplasma API but really doesn't need to be.

So the language people have been looking at Plasma asking, "So... how do I bind to this API?" and see ScriptEngine which is totally unsuited for that and scratching their head. Meanwhile, I get to explain for the Nth time (where N == number of languages people are working on ;), probably rather clumsily, that binding isn't the point of those classes. =)

Now that I finally understand this difference in perspective, perhaps I'll be able to articulate it more accurately in future.

So Mario Kart Wii came out the other day. Given that every Mario Kart ever has been at least a great game, we picked it up immediately.

I’ve only played it in versus mode, both competitively and cooperatively with my wife, in racing and both battle modes, and I can definitely say that this is the least pleased I’ve been with a Mario Kart title ever. I’ve actually thrown the Wiimote (luckily a mattress was in the way) :(

My major gripes? Well, let’s list:

• I’m actually not upset at the Wiimote-as-steering-wheel controls. They take getting used to and I don’t think they’re as precise as normal analog stick controls (I haven’t tried yet however) but as long as you recognize that about 350 degrees full left to full right is the complete range of motion you’ll adapt. Try to push more and you’ll simply confuse the game into steering the wrong way. This is something that could be improved by a stand or something that has a mechanical stop, at least you’d know when you hit the full range of motion. But again, you’ll at least get used to this.
• The first major concern for me (and this is huge) is that they seem to have drastically changed power sliding. In Mario Kart 64 and Mario Kart Double Dash when you power slide you can kind of adjust the direction you slide. They seem to have significantly reduced this in Mario Kart Wii. This significantly ramps up the difficulty. Turn too early and you are pretty much guaranteed to go over an edge or run into the wall. Turn too late and you are pretty much guaranteed to go over an edge or run into a wall. Even if you don’t spill out you’re likely not going to be pointed in the right direction once the turn is done. Probably the safest bet is to never power slide (or leave it in Auto) but then you will slow down a lot through every turn.
• Oh, and when you do run into a wall (and it will be frequent), you are practically guaranteed to lose 2-3 places each time. This would have been OK as a difficulty-enhancer had they not combined it with the penalty on power sliding.
• One thing that I hoped they would fix at some point is the rubber-band logic that allows the CPU to basically completely annihilate you just for doing well in a race. Do too well and all of a sudden you will have disasters rained down upon you as if from on high (and then you will no longer be in the first half of the leaderboard). In previous Mario Karts it would go from happening randomly to conveniently happening on the second or third lap. Now it just seems to happen all the time instead.
• Also cool is when you get hit by an item, and then get hit by a passing kart, and then get hit by another item (or two, you’re already hosed at this point). This happens in every Mario Kart game. But I think I’m already up to about half the number of times that it happened to me in Mario Kart 64 and Double Dash combined.

It’s not all bad news. I watched my wife play one-player and even though she made a lot of mistakes playing through her first time, she rather easily took first in all 4 races she played. Apparently my strategy will have to be trying to stay in 12th the whole time and hoping for good items. In addition the stages are inspired, both for racing and battle modes. I’m going to stay away from online play because that merely leads to me getting my face stepped on by someone I can’t so much as throw my soda at, but it’s nice that it has the option.

I’m going to go try playing it one-player and seeing if I can at least get some entertainment out of it in solo mode. It’s not like I can return it and get my money back. :-/

.. continuing my "I'm feeling ill, so am soaking in a bath" rambling thoughts:

Most of the plasmoids I personally wanted to work into 4.1 are getting punted to 4.2. WoC and a few other things sapped my time. Thankfully others have been working on plasmoids so we'll have some great new stuff there, I just wish I could've been able to play in Plasmoid land more (it strikes me as more fun than the infrastructure issues I deal with ;)

This is one aspect of the 6 month release cycle that I really don't like for Plasma: the punt rate increases. For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things. The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing. What this means is that we spend half the year in non-feature development; over 3 years time a 9 month cycle (with 3 months of stabilization) gives me 20 months of feature dev while 6 months gives me 18 months. That sounds similar enough, but the windows are tiny in the 6 month cycle, meaning more punting which in turn means that many features will be delivered in 12 months time to the user rather than 9.

It's also pretty obvious to me that for other projects, a 4 month cycle is probably even more useful than a 6 month cycle. Web based CMS projects come to mind as a good example where 4 month cycles would be the "Goldilocks" (aka "just right!") cycle.

In fact, I suspect 4 months might the Golidlocks number for Plasma: 2-3 months of features, 1-2 months of stabilization and exercising those new features via plugins. Unfortunately, 6 is not very evenly divisible by 4 ;) so this wouldn't work for the current release cycle.

I know that 6 months is all the craze right now, mostly IMHO for the wrong reasons like "marketing" or "downstream synchronization", but also partly for the right reasons such as quick cycles with a known clock rate for better iterative development patterns. I really dislike the marketing and downstream control issues because the former is complete BS (I want to smack someone with a marketing textbook every time I hear them opine on how six month cycles are better for promo) and the latter is misplaced priorities (accommodating downstream by hobbling upstream is remarkably short sighted). Really it comes down to finding a way to satisfy different sets of priorities.

I spent some time today thinking about what it would mean if mainline Plasma development moved to a git repository outside of KDE's svn, syncing at "known good revision points" back to svn except during KDE feature freeze periods so that we can have development windows that make sense for Plasma without breaking KDE's release cycles. Downstream gets what they want (a tarball every 6 months) and Goldilocks gets what she wants. We could stabilize the Plasma code base wheneverit would make sense for Plasma and downstream can simply get whatever the last "good point" was when a KDE release happens. This effectively decouples release schedules from development schedules, not unlike what the Linux kernel has managed to do.

I don't think this will work if our merge cycle is longer than 6 months however: testers and new developers will likely work against what is in svn and I don't want to require people to have to use another repository just to get at Plasma. So the merge cycle would have to be shorter than 6 months to keep the illusion of "development done in svn".

Perhaps there's another answer, but something needs to shift because one development window size does not fit all. At the same time the road of "hundreds of individual repositories and tarballs released whenever they want" is not really an option either as that'd just be integration hell for everyone.

So there you go: ramblings with no real concrete answers .. yet. =)

I'm not feeling very well today; been having a bit of a hard time sleeping the last few nights and now I think I know why: my stomach was churning most of the day up until mid-afternoon. Feeling better now, but it seems I was probably fighting off some sort of bug. I don't tend to get really ill, I just get dragged down when I catch something. Anyways .. not very exciting nor what you probably care to read about. ;) It did mean that I spent most of the day being unproductive coding-wise; instead I soaked in the bath a bit and thought about various things. Here are some ramblings from that down time thinking.

Part of the 4.2 roadmap for Plasma is already taking shape in my head. Yesterday while talking with Chani and J.P. on irc, I realized something that is pretty obvious in retrospect (hindsight, 20/20, yadda yadda): containments have become the place to do both functionality customization (layouting, toolboxing, applet addition/removal controls ..) as well as background painting. These things are pretty orthogonal, however, and what you really want to do is mix and match between these two sets of functionalities as a developer.

There will be some odd ducklings that do everything themself: a MacOS X style dock, for instance, would want to control both the background painting as well as the layouting and applet selection. Fair enough.

But many will want to have a given style of functionality, but use the same background painting that exists elsewhere. Or vice versa.

So in 4.2 I'm going to explore adding some add-on functionality for containments: backgrounds and context menus. The latter was already planned, but the backgrounds as separate add-ons is a new idea driven by the understanding that to avoid lots of duplicated code we really need to have a way to share background painting.

This won't affect the "any applet can be a containment" situation at all, nor will it force containments to use these new add on categories. The containmnet will remain in full control, this will just provide a painless way to access work done by others.

Additionally, I'll need to go back and do some KConfig hacking again for 4.2. In particular, besides doing the API review for KConfigBackend so that we can confidently export that interface for 3rd party use in plugins, I need to make KConfigSkeleton aware of KConfigBase so that we can use KConfigGroup with it. Plasma uses KConfigGroup extensively in its config system, but KConfigSkeleton is unaware of it. This is due to KConfigSkeleton coming about before KConfigBase was really interesting or useful to write against; it was more a "behind the scenes class" versus the useful base class it is now. The problem for Plasma here is that this means we can't use KConfigSkeleton really anywhere, which sucks since it's a very convenient way to both define and document configuration systems. It also makes driving the configuration user interface simple (e.g. one line of code). We already have support for plasmoids from packages (e.g. scripted plasmoids) to have code-less configurations, but it doesn't actually work when it comes time to save the config due to this issue. It's too late for 4.1, so this gets moved to 4.2.

(edit: i completely forgot the following in the first run at this.. doh!)

4.2 will also be when we go for concrete binary compat, move libplasma into a libs module (perhaps even kdelibs?) and either split out the Package classes into KNewStuff2 or make KNewStuff2 use libplasma.

At least we'll have a happy Plasma for 4.1.

A Very Difficult Moment I ------------------------- KEYWORDS: Abstract, Light Made entirely with The Gimp I hope you enjoy

Install: Just unpack it to "/home/username/.superkaramba/KClock/styles" and then select it in KClock settings.

So before I went underway our car had developed a trouble causing the Check Engine light to come in continuously. No abnormal sounds but being nuclear-trained has taught me not to live with “locked-in” alarms or warnings. I wasn’t able to troubleshoot it in the limited time I had before deploying so I asked my wife to make sure it got investigated when she had free time.

She took the car to the dealership. She actually had to make two trips; apparently there were two separate faults that would have caused the light to come in by this time. Nothing mechanical luckily, but apparently at some point while the dealership was troubleshooting the issue they had to unhook the battery. Doing this activated the anti-theft feature of my radio; it would not play music unless I typed in the anti-theft code. This code was included on a card which I was supposed to remove from the car and keep in a safe place. Needless to say, I had removed it from the car, and it is still in some safe place, nowhere to be found.

So my car radio has been silent for about a month and a half now. I finally got the time to really dig into this issue since the dealership apparently is completely unable to figure out what the unlock code should be. A little browsing on the Internet and apparently many people have had the same issue, and the unlock codes are few enough to list in one paragraph.

So I went and wrote them down and typed them in one by one. After about a dozen tries the radio started working again. Yay! I will record the code in my KWallet this time; it is the only thing which I reliably can count on being there. In case anyone else develops this issue with a Chevy Aveo, I found these posts helpful: automotive forums and Yahoo! Answers.

Ok, after roughly one week out in the countryside again I came home yesterday and today I started my efforts again to bring KDE to compile with the brand new mingw-gcc 4.3 alpha version. Even though it has been feared that mingw-gcc might lag even further behind, the new maintainer Aaron William LaFramboise brought out a rather new release. As Aaron is a GSoC-student as I am, we can work together even better.
But now towards the facts that might interest the KDE on Windows Community:
I could build Qt with two patches and I had to disable webkit.
This first patch was due to a missing extern declaration in one sourcefile, the second one was a bit strange since it required using uint instead of quint32. The errors with webkit were not easily solveable so I will investigate them further especially as strigi fails on a similar error too. Currently I think that this is a more a mingw error but I might be wrong in the end.

To give you a more general outline:
I plan to work on mingw4 from time to time so that I will have a running KDE from mingw4 by the time KDE 4.1 gets released. KDE 4.2 should be buildable with mingw4 too and probably for KDE 4.3 we will switch completely away from mingw 3.*.

Right now I will start my GSoC project on marble so most of my time will be coding again.

So long for now, new posts will probably come in more regularly.


(*) 'One step beyond' is a song by the british ska formation Madness and just came to my mind after I got Qt building.