random quote: "Nothing ever becomes real until it is experienced."
John Keats
|
|
 Networkmanager in KDE4.
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 :-)
[ Tue, 06 Jan 2009 02:13:16 +0100 ] permanent link  KDE 2008 fly-by.
The beginning of this year in KDE was marked with the tagging and release of
KDE 4.0, followed up by the release event in Mountain View. KDE
4.0 has marked for the KDE community a stable base to build a kick-ass
desktop and applications on. Over the past year, we see this effort paying off.
Applications such as Dolphin, Gwenview and Okular are mature tools, powerful and
userfriendly at the same time, speaking for the KDE4. With KDEnlive and Amarok
2.0 as their first KDE4 version, we see the more complex applications coming up.
On the workspace side, new UI technology has matured, KWin's
compositing and Plasma give you a very smooth ride as well.
The development platform is paying off, it proves to be a very
extensible and future-proof platform, more and more applications are becoming
available on Windows and Mac, KDE on OpenSolaris is getting closer to inclusion
in the distribution, and we've seen KDE already available on FreeBSD. New
applications written in Python have entered KDE, and scripting support for many
applications is becoming available as well, in the form of services in Amarok and
scripted Plasmoids for example.
The development platform appeals to be very attractive to new developers as
well. At the end of 2008, we'll have welcomed 300 new developers in the project.
The current activity in terms of commits to the KDE's SVN, the ongoing bug frenzy
and general polishing of KDE4 desktop and apps is amazing.
On the organisational side, this growth in the KDE
community and the increased attention from both users and the wider Free
Software community, has been balanced out by the launch of the KDE Forum and
UserBase to improve communication across a wider community. The formation of the
Community Working Group has worked out very well and has come far in smoothening
out how we work together. The wide acceptance of the Code of Conduct is another
successful chapter in improving the collaboration.
The opening of the KDE e.V. office in Frankfurt and employment
of Claudia has been an important step,
and are leading to a smoother functioning organisation in many ways. In 2008,
many developer meetings have been supported both financially and organisationally
and two larger conferences have been held in Mountain View and Mechelen,
which scored the record number of attendees.
So what's up next year? Personally, I'm hoping, actually being confident
that in 2009 we see the rise of new technologies such as Akonadi, Decibel,
integrated desktop search and the semantic desktop. I'm looking forward to
seeing KOffice2 becoming available and maturing. Higher level concepts such
as the Social
Desktop will start to be integrated, and a wide variety of new and existing
applications will make their way onto everyone's desktops and mobile devices.
More imminent, there will be the second KDE conference in the Americas on
Jamaica in January, and a smashing Akademy during the Gran Canaria Desktop
Summit in July.
It's been a smashing year, and we're not even done yet.
[ Fri, 19 Dec 2008 03:33:36 +0100 ] permanent link  Dolphin screencast.
I've been playing around with screencasting software for some time. My idea is,
to provide a series of screencasts showing off different aspects of KDE
technology. I've now mostly sorted out the technicalities and concepts, so I
started recording some test screencasts. For the screencasts, I'm using
recordmydesktop. I've chosen blip.tv a one means of distribution. Their web
interface is nice and easy to understand. It offers a flash player, so it makes
the content accessible very easily, but you can also view the Ogg Video version
of the file, so it's equally accessible for those preferring a Free format.
Blip.tv also seems to have a reasonable understanding of licensing. They're
offering several creative commons licenses to choose from. I've chosen a
relatively liberal license so the screencasts are easy to redistribute and use
in other materials. Well, maybe not this first one, as I'm not yet a super hero
in this authoring domain. To make things easier, I've not included sound. This
pilot is about 10 minutes long. I'm using the fine Plasma notes applet to tell
what's going on, although I'm forgetting to scroll in the beginning, and
somewhere towards the end, please bear with me -- I guess that's some sort of
digital stage fright.
So this first screencast walks us through a part of Dolphin's feature set. The
different view modes, zooming functionality, tooltips, the cool selection
mechanism (no ctrl-key!), shows how Dolphin integrates my USB stick and how you
safely remove it, the Capacity indicator, the places, information, folders and
terminal panels and how you can use them to make Dolphin fit your working
habits. It concludes with a run through the configuration dialog. Enjoy!
[ Fri, 28 Nov 2008 04:49:51 +0100 ] permanent link  Re: Making sure we do power management the right way.
So Matthew Garrett
dissects what he thinks powerdevil is doing wrong and gives a couple of point that
in his view, power managemers on the Free Desktop aren't doing right at the moment.
Let's have a look at Matthew's points (I'm paraphrasing here for ease to follow,
hoping I'm not getting his points wrong):
-
"Powersave is the wrong governor". First of all, Matthew
assumes that the setting "powersave" will actually use the powersave cpufreq governor.
Fair enough, the label offers it as powersaving mode. The CPU governor in use
though is not the powersave governor, but the "conservative" governor, which
indeed is an "ondemand" governor, meaning it gives you the
extra needed CPU power when you ask for it. As its name says, it's slightly more
conservative than the ondemand governor when scaling up. Matthew gets this
wrong, but he's probably misled by the label we present to the user.
The "powersave" performance profile does more than just switching the cpufreq governor,
it can also control your display's power consumption (and in the future probably
even disable animations all over the place so you don't loose any of these CPU cycles
for eye-candy).
-
"Thermal management is not the job of a power manager".
True, mostly. Usually, it should be controlled by the BIOS. The default setting
though is usually very conservative / safe. In general, we don't want users to
fiddle with the limits (at what temperature should your CPU cooler start
spinning?). Powerdevil doesn't offer such option, so Matthew will be happy about
this item. (I don't see how Matthew gets to think that powerdevil does poke into
thermal management settings, so I guess Matthews point was more a general one in
the first place.)
-
"Presentation mode". Something the app does indeed. We've
discussed this on the hardware-devel list and came to the same conclusion.
Again, powerdevil doesn't offer an option for presentation mode to the user
because it's "an application behaviour policy" as Matthew tells us. I do
agree. What Matthew is missing here is that PowerDevil manages those policies.
It's in fact the central place to do so in KDE 4.2. Apps will tell powerdevil
that a presentation is running, powerdevil will keep track of all apps
inhibiting certain PM features (screensaver, dimming, suspend, ...), check other
policies (e.g. "lock screen on resume?"). There's no "inhibit suspend" button in
Powerdevil though. Downside is that we have to rely on apps actually setting
this cookie -- which might or might not be more reliable than the user herself.
So it might take some time until this feature in powermanagement on
the Free Desktop works for everybody. (Until that time, you can switch to a
power profile that doesn't suspend / screensave in the first place. All happy. :)
-
"3d takes more energy than 2d". Might be true. From my
measurements, however, facts are: a) KWin with compositing enabled does hardly
spend "a significant proportion of the time on the GPU". (In fact, it sleeps
most of the time.) and b) KWin in compositing mode does hardly need any more
energy than when compositing is off. (Again, results of my measurements, those
might be off. I'd invite Matthew or everybody else to provide additional data
points so we can improve our default setting to optimize its behaviour further.)
Users can of course easily check this themselves. Run powertop with compositing
on, measure your CPU consumption, switch it off (alt+shift+f12), measure again,
compare. In my tests, results have been in the 1% - 'hardly measurable' range.
If that's different on your machine, configure powerdevil to automatically
switch off compositing. If you're findings vary from mine, let me know and we
can further improve powerdevil's set of policies.
Lesson learned: Check your facts before you publically dissect the inner
workings of something that is as complex as powermanagement for a desktop system
and that you're obviously not familiar enough with to judge wether this piece of
software gets it right or not. I'm assuming that Matthew does know *his* stuff
(his general points are pretty much all sensible). Unfortunately his arguments
in the light of powerdevil's actual implementation are all strawmen. I'd have
expected a more thorough analysis from Matthew.
I'd also like to thank Matthew for his input on these matters, and I'm glad
it's not as disheartening or dramatic as he tries to put it. In fact, reading
his blog, I'm now even more confident that we have something that is both, in
its default setting a very sensible system to manage power consumption while
not getting in the way of the user, and also very powerful for all those cases
where machines are just a bit different -- so we're also set to deal with a great
variety of systems and usecases.
[ Sun, 23 Nov 2008 17:15:08 +0100 ] permanent link  Embedded Linux and KOffice.
I'm on the train back home from ELCE (Embedded Linux Conference Europe) now. It was an interesting
conference, not 100%, but quite free software-ish. Met a couple of nice people again: Adriaan (KDE
+ NLUUG), not quite surprisingly, Armijn (NLUUG + gplviolations.org), but also Will
(KDE + Suse) who I've did a bit of networkmanager
hacking with in between the talks, Shane (FSFE, FTF hero), Oliver Gravert (Canonical), Valer
(NLNet) and others. Feels somewhat like home (which I wouldn't have expected from a mobile /
embedded conference in the first place). I gave a talk this morning, which I found quite
interesting myself (that's at least one person). I've talked about how to get KDE on a mobile
device, starting with an explanation of the software stack and how those parts related to platform
independence, moving to technical challenges when turning a desktop system into a mobile system
(covering things like screen resolution and pixel density, input mechanism and the more limited
hardware you usually find on mobile and embedded devices). People seemed interested although the
room was not exactly packed. Also followed talks myself (Will's to begin with, giving me a bit more
insight into Solid's networkmanagement stuff, quite useful if you're hacking on that ;-)). Ow, and
fixed two layout glitches in battery and networkmanager applet, not bad.
Tomorrow, I'll be on the KDE-road again, going to Berlin to attend the KOffice sprint that's held
in the middle of cocktailbars and restaurants (a.k.a. KDAB's office). But why? What do I have to do
at a KOffice sprint? Well, one of the topics there is release promotion of KOffice 2.0, which I
understand is due in the next months. I think KOffice is in a very interesting situation right now,
and it's critical to position it nicely now so it'll have a bright future.
People that know me also might have heard me cursing about OpenOffice. Frankly, I don't see
OpenOffice having a bright future. The codebase seems rather convoluted (about as many lines of
code as the whole of KDE -- including KOffice) and because of its sheer size OOo is basically
unmaintainable. Add to that what looks like a fork by the Novell team decided to publish as Go OOo,
and a development model that's pretty much entirely much based on one vendor (SUN or Novell,
depending on who you ask ;-)), so community involvement is apparently down to a minimum. With
devices becoming smaller and requirements regarding the user interface becoming more central in the
Free Desktop ecosystem, I just don't see OpenOffice providing a sensible answer to that.
Enter KOffice. It's free, it's lightweight, it's cross-platform, its codebase apparently is rather
clean, in short it could very well fit into that mobile "niche" as use cases are more limited on
those devices anyway. So what's needed to get KOffice in shape so that it becomes the serious
contender? Frankly, quite some work still, in my opinion. First, it needs to work, a word
processor, a spreadsheet application and a presentation program are the least I'd expect. so it
makes sense to focus on those apps. Then, support for the most used standards, I know Girish is
already working on getting OpenDocument support to work really well (absolutely critical IMO), but
at some point, we'll also have to look at support for proprietary formats.
That said, I think there's quite the business case for a manufacturer seeking support for office
documents in a certain product. So pitching KOffice to manufacturers in that market makes a lot of
sense.
Then, there's of course the platform-indepence thing looming. KOffice, as many other KDE
application will be available on Windows and Mac OS as well. How does that impact how KOffice sees
and shows itself, and to whom? And how do we do end-user support? We certainly wouldn't like to
burn credits by people that run into simple problems but just aren't able to find a solution to
their problem or support in general (be it community support or commercial support).
Another interesting angle is the "OOo reinvents MS Office so we don't have to angle". KOffice's
current user base is pretty small, so in turn, there are very little people who will complain when
KOffice goes new ways (like Plasma did in KDE4), so I'd expect much less pushback when actually
fixing the "Office UI", making it a sensible interface that's is a pleasure to use instead of
something that drives me nuts the instant it starts (which is not really an instant in fact ;-)).
[ Thu, 06 Nov 2008 18:55:58 +0100
] permanent link  Python Plasmoids.
Simon, our worshippalicous python bindings hacker came by tonight for a bit of hacking (he lives across
the river from here, about 20 minutes by bike on a well OSM-mapped route. I was keen to get the new Python scriptengine Sime has just landed in SVN running so I can play around with Plasmoids written in Python.
The steps to get Python Plasmoids on running on your desktop are (assuming you have KDE from SVN installed): installing python, sip and pyqt into your development environment; building kdebindings, then you can build the plasma scriptengine located in kdebase. There are building instructions on TechBase.
Developing Plasma applets (which is pretty much the only thing you can do with the scriptengine right now, since there aren't any applets written yet -- except for the obligatory clock) is pretty easy from that point. You need to have a .desktop file containing some metadata and you actual script (which can be how ever long you wanted, it lands in contents/code/main.py and other .py's). How you include graphics and more is well documented on TechBase, so I won't repeat that here. To see if the scripting engine works, open the Add Applet... dialogue|Install new widget|...from local file. You should then see the scripting engine listed among the other options. In the future, we can make this part a bit nicer, installing and running and applet could be as easy as dropping it on the Plasma canvas and do the necessary security work. ll the needed information is already contained in the package.
This all is pretty new right now, and there are some rough edges here and there that need to be ironed out, but it basically seems to work at this point and is documented so we Pythonistas can get our hands dirty, with KDE 4.2 hopefully out of the Box.
The really exciting thing in my opionion about this is that with the scripting support, we can deliver full-fledged Plasma applets in Python. As they are scripts, it's easy to deliver them in a platform independant way through webservices such as the OpenDesktop, KDE-Look and others or share them with your friends in other ways (hi JOLIE!).
[ Sat, 25 Oct 2008 01:29:11 +0200 ] permanent link  KDE4 in Linux User, away for a bit.
As we all know, one can never travel enough. In that light, Kim, the supermodel that shares this life with
me announced to me that she'll be kidnapping me for a couple of days starting on Tuesday. We'll not be
going far, just far enough to get away for a bit and recharge the batteries. (Actually we're running
on solar energy and Port wine, but that doesn't make for a common metaphor, so there you go.)
But fear not, I've taken precautions for this scenario, and the guys over at LinuxNewMedia have kindly
helped with that. In the last and the current edition of LinuxUser Magazine, there's a series about
KDE4. It started last month with an article about Plasma that was the first part of a tutorial
I've written. This month's edition features a longer article that explains all the easy 129 steps
you can follow to get to your own Plasmoid. There's an example Plasmoids I've written for that
article, it's called Dr. Ade, courtesy of Adriaan's promotion some time ago. (I'm obviously very proud
of him -- well, maybe it's also the fact that we had this bet running. We've started off with one case
of beer that I would give him. For every week I had to wait for his dissertation to be finished, he
would give me one beer. Ade, you owe me two crates. No, I won't forget that.) But I digress. Next month's
edition will conclude the KDE4 mini series of articles with an interview (again, with yours truly) about
the future of KDE.
Me being
away also means that you won't hear from me in terms of email, chat, blog or one of the other ways we
communicate (did I mention the new KDE Forum?) as for that occasion
I won't be taking my laptop, and I just refuse to write anything longer than a URL on those small
devices that are taking over the lives of us geeks.
By now, you should have understood 3 points from this post: a) Don't expect timely replies to emails
sent to me next week, b) If you plan to sneak anything by my eagle eyes that I wouldn't approve
otherwise, concentrate on getting that done before next Saturday (instead of sending me emails),
c) Go to your next store, buy Linux User magazine and start learning German (if necessary).
[ Mon, 13 Oct 2008 00:58:41 +0200 ] permanent link  Portugal in Fall.
I'm in Portugal right now, visiting Nuno to work on a top-secret commercial project for a couple
of days. I think I've chosen the right time to come here. While the weather is mostly vile back
home in the Netherlands (rain, grey, overall depressing), the sun still shines brightly here in
Regua, in the Douro valley. Can't say that this way of working is a pain. While we're really
productive, having good conversations, complement each other nicely (strategic bits: me,
graphics and beauty department: Nuno), we also find some time to dive into Portugese culture.
Tuesday, we've taken the afternoon off to drive into the Douro valley, the region where all
Port wine comes from. The cropping season is just beginning here, and the vineyards are starting
to change their color from green to shades of yellow, brown and red. With the mountains here, that
makes for beautiful scenery. Also the smell of fermentation is slowly coming up (that same smell
you might know from your last visit of a wine cellar, if you ever did that). It's funny and amazing
at the same time to read the names of the wine houses, most are actually known to me, and then you
see their vineyards...
Some of you, my dear readers, might know that I'm a big fan of Port wine, so I'm also taking this
opportunity to understand a bit better the circumstances of making this great product, the weather
situation, geographical circumstances, but also food that goes along with traditional Portugese
wine culture. Tomorrow, I'll be going back home, and next week, Kim has claimed a couple of days
to visit Leeuwarden and Groningen in the South of the Netherlands, and to spend a bit of quality
time -- we didn't have much time for that lately.
[ Thu, 09 Oct 2008 13:58:10 +0200 ] permanent link  Power management goodness: KDE 4.2 will suck less
... power. As Dario has
already
blogged, we have a great new application in kdebase, scheduled
to be released with KDE 4.2 in january. PowerDevil is actually not an
application in the traditional sense. PowerDevil delivers the infrastructure for
power management in KDE. This means it'll notify you when your battery is
running out, it dims your screen a bit when you're idle to save some battery
life, it switches to a lower power consumption state when you unplug the AC
Adapter, it automatically suspends, hibernates or shuts down when your battery
is (near) empty, that kind of stuff. For a user, it's not a real application,
but much more a service that handles some tasks for you and doesn't get in the
way.
Technically, powerdevil is designed to integrate
with KDE's platform-independant infrastructure. So while the actual tasks are
very close to the hardware's capabilities, powerdevil is not bound to Linux for
example. The code is very portable, thanks to the Solid hardware abstraction.
Naturally, PowerDevil uses knotify to tell the user about anything she needs to
know, fine-grained control about all notifications is available in the System
Settings module.
PowerDevil consists of the following parts:
- A configuration dialogue in System Settings
- A kded module that does the background work
- A KRunner for command-line access to most functions
- A Plasmoid for quick access to some popular functionality
During the last week, I've done some work on the plasmoid corresponding to
powerdevil, and it starts to work nicely. In current KDE's SVN trunk/, you can
click on the battery plasmoid and you'll see the dialogue in the screenshot. The
idea (should be pretty clear, eh) is that you check some details on the battery
status, quickly switch profile (when you want full performance on the road, for
example), or re-adjust your brightness. The button at the bottom opens the
PowerDevil settings module. The plasmoid still needs some polishing, but thanks
to the input from Riccardo, Celeste and others, I think we're pretty close to a
smooth UI. I'd also like to add a "do
not suspend or screensave my system while I'm doing this presentation / watching
this movie" button. We could implement that with a profile in powerdevil (but
that wouldn't cover the screensaver), or -- and I think I prefer that option --
with a "[x] Presentation Mode" checkbox. I figured, we should only prevent the
system from suspending after an idle time. The system should still suspend (/
hibernate / shutdown / ...) at the critical battery level. This critical level
suspend should also go with some kind of count-down dialog, so you still have
the opportunity to '... cancel that damn thing' when you really do not want it
to go away. Well, on the TODO. :)
Thanks to the awesome work of pinda, you can drag the battery's pop-up control
to the desktop and have it sit there as separate applet. There will be a button
in the top-right corner in that case that moves this "extender" back into its
original location (the battery applet's popup). Neat-o.
Wacky detail, as you can see, the popup also shows the battery. I've loaded
another (simplified) instance of the battery applet there, so that's all
animated and shiny. Thanks to the power of plasma's dataengine, all the "getting
data code" is shared between those applets anyway. UI-wise, the battery-in-panel
is actually a subset of the "battery-extender-on-desktop".
I've also done some performance tweaks to the runner (also in kdebase) that lets
you control power management aspects. As we still haven't implemented an easy
way to find out about krunner syntax (I usually check the source code :/),
here's a quick list of things krunner + powerdevil now understand:
- screen brightness 80 to set the brightness of your display
(between 0 and 100)
- suspend for various suspend methods
- power profile to switch to a different profile
- power governor for a list of CPU governors
- power scheme for different schemes (note to self: find out what
the difference between scheme and profile is ;-))
- screen brightness (without number) to turn off and dim the
screen
We should probably collect this knowledge on UserBase ...
In other power management news, we've also come quite far. Various people (among
them Lubos) have done an awesome job making KDE suck less power. I've done some
tests over the last months. Around KDE 4.0, the machine caused 700 - 900 wakeups
per second, idle. Most of that (but not all) was caused by an issue in xine when
using certain functions in phonon. Right now, we're pretty much there. My idle
system is down to around 100 wakeups per second, most of that caused by hardware
(wifi, usb, sata, ...). Something the kernel developers are working on. KDE
(plasma + apps) accounts for 5 wakeups a second, the first KDE app comes in as
10th. To put those numbers in perspective: 100 wakeups per second is already
pretty low. Everything below it is probably highly optimized. Even in
compositing mode, when you're not moving your windows KWin doesn't suck extra
power. Good news for mobile KDE users. :)
[ Fri, 26 Sep 2008 04:04:04 +0200 ] permanent link  We are out of swordfish.
... which, in Greece is served as a main dish. So at a regular dinner, that's after the
second Ouzo, which is both refreshing and the kind of fun that flushes your
java-fried brain pretty thoroughly.
As Ade already blogged we're in Greece, just south of Athens (that's where "50" inside
a red ring on a road sign means "120 km/h is a good average, you have to fiddle with
your navigation system after all at the same time", at least in taxi drivers'
minds, apparently) for a SQO-OSS sprint, but also where the waiter happily shows you
the fish you're planning to have for dinner, and even gives it a name (in my dinner's
case "Papadopoulos") on request. But let's try to keep the "We are out of ..."
titled blogs void of sensible content ... (respect tradition!)
On a totally unrelated note, today's kudos go
to Nuno for providing me with green, yellow and red variations of the Blue Curl
wallpaper (the default KDE 4.1 one) they're in the slideshow plasma rotation wallpaper
plugin and making this world a better place (did I mention that I don't have a real
life? ;-)).
Concluding with today's geek survival tip seems appropriate: If your mouse cursor behaves
in very weird and unpredictable ways, if you see context menues popping up seemingly
randomly and if you just have a really hard time pointing at anything: *do* check your
short's pockets to make sure you didn't tuck your wireless mouse in there. Worked for me.
[ Tue, 09 Sep 2008 23:14:50 +0200 ] permanent link  New Nvidia Beta driver: KDE4 flies, but has stability issues.
Last night Nvidia
released a new beta version of their binary driver. This one
has some new features, where especially a couple of RENDER pathes are now
hardware accelerated. I've installed the driver on my desktop machine on a
rather clean OpenSuse 11 and a 7600GS and
tweaked it
to enable to new feature that aren't on by default in this release (but are
planned to switch on for the real deal). The performance problems I've had with
switching desktop and apps are totally gone and KDE4 is flying like I've never
seen it before. Switching tabs in Firefox
is still slow, Konqi does it swiftly. I've set the following options in my
xorg.conf. My Device section now looks like this:
Section "Device"
Identifier "Device[0]"
Driver "nvidia"
VendorName "NVidia"
BoardName "GeForec 7600GS"
Option "RenderAccel" "true"
Option "AddARGBGLXVisuals" "true"
Option "AllowSHMPixmaps" "0"
EndSection
And the Screens section:
Section "Screen"
Identifier "Screen[0]"
Device "Device[0]"
Monitor "Monitor[0]"
Option "PixmapCacheSize" "20000000"
Option "AllowSHMPixmaps" "0"
SubSection "Display"
Modes "default"
EndSubSection
[...]
EndSection
(AllowSHMPixmap probably only has to go into one of those, but it doesn't seem
to hurt as other issues are more pressing right now. When I resize a konsole window too
quickly, the machine locks up. I'm not sure if this is a driver problem indeed, or a
hardware problem (I've not used the machine much lately, and lockups happened with
earlier versions of that driver as well.)
Something which I find rather strange is that I cannot run nvidia-settings:
ERROR: The control display is undefined;
please run `nvidia-settings --help` for usage information.
So assumably I'm getting only part of the performance improvements. I'm
asked if anybody knows
why, up until now to no avail.
Overall I'm very positive about this release. It finally seems that we can deliver
a really swift KDE4 experience also to those users with insanely fast graphics cards (insanely fast
at least for the graphics features we use in KDE). I'd suggest those that have been suffering
from performance problems (and anyone else using 7xxx or above Nvidia series graphics cards
to try this driver. Don't forget to change your xorg.conf and enable the Gyphcache and
PixmapPlacement hacks. I've also updated the
techbase page with this
information to make it easier to find.
Update: After some fiddling, I've got everything to work. The nvidia-settings
issue was a local config problem, the lockups are only present when I forget to run
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1. I'm a happy camper now. :-)
Update: There's an even newer version of the beta driver available, try
this one
instead of the .68 or .69 version of the driver as it fixes a couple of problems with the beta driver
and it's just more likely to work.
[ Wed, 20 Aug 2008 18:25:21 +0200 ] permanent link  that demo machine...
Wade brought me a new Mini-ITX motherboard for a demo machine we used to have in the boothbox (but which
had one minor issue: No X, not even after lots of driverfoo.).
So I've replaced the VIA Epia board with an Intel Atom one with
integrated 945 graphics chip. KWin's compositing now works nicely on this machine, it's swift and
I see no graphical glitches. The machine has a 1.6 GHz Atom CPU. One problem now is that the slot-in
DVD drive doesn't fit nicely. I can squeeze it in, but as soon as I screw the cover onto the
small desktop case, the DVD doesn't eject the disc anymore, caused by a slightly squeezed top of
the drive. So I'll need to find a way to gain a couple of millimeters of space in that box (or stick
a note under the case that you need to open the case to use optical discs ;-)).
Also left to do is testing multimedia. I might need to install a couple of plugins there, and I didn't
check yet if sound works at all. I'll see if I can bring it to Froscon this coming weekend (depends
if the boothbox will be there, or someone to take it to the KDE office in Frankfurt.
(Drop me a note in that case :).)
Otherwise, we have a nicely working demo machine, with KDE 4.1 and exampla data on it
that should also be easy to maintain for some time. I've installed all the
interesting things from KDE4, so we don't end up with
not finding all kinds of applications and need to install them on slow fairground connections.
Yesterday, I tried to reinstall my desktop machine, a rather nice dualcore with lots of RAM and
fast disks. It's got two 17" displays connected. Lately, Nvidia's drivers have caused me some
headache there, making it just no fun to work on that machine. So I've been mostly using the laptop
lately. I do miss the comfort of a good desk and chair though, so I've hooked up the laptop with one
of the TFTs. I need to try the latest nvidia beta drivers,
a posting on the NVNews board
sounds promising, at least. Can't wait to try ...
People on #suse have been rather helpful in getting me better acquainted with the system. I found
out that's it's apparently quite helpful to people guiding you to tell them in how far you need
guidance ("I'm an advanced linux user, but just don't know the distro very well") helps to avoid
a couple of unnecessary questions ("did you restart X after trying the driver?").
Ereslibre has apparently fixed the Konqueror toolbar issue, I've been seeing for some time, I'm
rebuilding everything as we speak.
[ Wed, 20 Aug 2008 00:50:21 +0200 ] permanent link  Akademy Runners.
On the train back home from Sint Katelijne Waver, I've got the kate session plugin working,
which I wanted to have still during Akademy. I've missed that personal goal by three hours
(or I pinned it down by 20 minutes, depending on how you view it). I had written part of
that plugin earlier in the week
and made it basically usable short before I arrived in Nijmegen. I use kate a lot, and have
several
sessions, as sets of documents that I'm editing often. Now I can just type the name of the
session into KRunner (that ALT+F2 thing) and hit enter to open the session -- so with 5
keystrokes, I can now start hacking on plasma (and pretty much anything else I work on, it
happens to be mostly plain text).
The kate session runner is now in playground. The Runner actually does two things: It
matches document sessions from kate, and also offers kate's sessions as options when you
just type "kate" (screenshot).
This runner will probably go into kate itself, where there's already the session applet
written by Laurent.
The new Browserhistory plugin I had written earlier, currently only searches the immediate
history from Konqi's combobox. I've discusses this with David on the boat, and we might be
able to use the full history if we expose the relevant bits in Konqueror's API and ship this
Runner with Konqueror. Right now, this
runner is in kdeplasma-addons.
On the other hand, for Firefox users it should also be possible to have such a thing. If you want to
add support for Firefox to this plugin (or maybe make it its own one), I'd welcome a patch :)
[ Tue, 19 Aug 2008 01:08:18 +0200 ] permanent link  How to survive Akademy.
- The beer in the small bowls is around 8% - 9%, don't drink more than 20 of those.
- Have a water once in a while (you can drink the tapwater in the university building)
- Get foodtickets before you queue up for sandwiches, saves you a lot of time
- Writing a music manager / player doesn't save you from having mediocre taste in music
- When hung over, don't even try to play ping pong with Seb
- Lunchbreaks feel a lot like the Ministry of silly Talks
- Don't write long blog entries when there's a keynote coming up shortly
- Marble.
By the way, if anyone found my badge after yesterday's piss-off, I'll get you a candybar in return...
[ Sun, 10 Aug 2008 13:56:16 +0200 ] permanent link  Take a peek at Akademy.
Not much time to write long reports right now (attending the Plasma Frenzy talk,
heading off to the social event in a bit), still managed to
get some photos up.
Feel free to use those in your
coverage, if you need special permission or a larger version (I've got them in 12MP
on my box), drop me an email at sebas kde org.
[ Sat, 09 Aug 2008 17:45:26 +0200 ] permanent link  Going wild with KDE 4.1 themes.
Now KDE 4.1 is out, I've played around a bit with different themes. I've installed
the KDE artwork package, and a couple of themes via GetHotNewStuff. KDE's coloring
system has seen quite a lot of love, as has Plasma's theming engine. The results
are quite impressive, as you can see in the screenshots.
First off, a bright setup with full-width, pretty standard panel. The
Plasma theme used here
is Aya, I've made the window background colors a bit lighter, just for more intense
shininess. Those bright colors also go quite well with the "Glassified" color
scheme, but I found it lacking some 'whitespace'. The screenshot shows some
integration bits as well, the context menu offers to install the package using
Ubuntu's gdebinstaller. The GTK+ theme blends in nicely with the colors I've
set up. (Without me even tweaking it).
If you want to go out in black tonight, the Obsidian color scheme is what you
want. The Plasma theme used here is Elegance. I personally don't really like
dark widget themes, although I find it OK in a konsole. There's also a second
panel on the left with some buttons and info, so the whole width of the taskbar
in the bottom panel can be used for applications.
The Norway color scheme combined with the Aya Plasma theme. I've made the panel
shorter, centered and a bit higher. People seem to like it that way as well, though
I don't understand what the fuzz about such panels is. It tends to create dead
corners, and what's better than slapping your mouse bottom-left and typing into
kickoff? The colors are nice and warm, and some utilities such as a calculator,
online dictionary and calendar can be found on the desktop.
The Wonton Soup color scheme is dark, but not quite as dark as Obsidian, it has
a bit more contrast than Obsidian as well, and looks a bit softer.
The wallpapers used here should be available with KDE 4.1 install, some might
be in the kdeartwork module. The tools I've used for
theming the desktop are the Appearance module in System Settings (especially the
color pages). The widget style used in those screenshots is Oxygen, the Plasma
themes vary though. Aya is especially nice and flexible, as it bases its color on
the widget colors you can tweak in System Settings. I still have some garbage in
the systray, unfortunately. It's not that bad all the time, on the upside :)
[ Thu, 31 Jul 2008 16:55:50 +0200 ] permanent link  Thoughts on innovation on the desktop.
While surfing around on Teh Intarwebs, I've read complaints from people that we're doing
something radically new to the user. Some of those users seem to have problems with all
that "radically new" stuff. Honestly, I don't think they have seen anything we *can* do
yet. With KDE 4.1, we have pretty much implemented functionality that was there, made
applications smarter, and polished the looks. Almost all of the work on the UI,
especially in Plasma has been put into recreating functionality from KDE 3.5. What is so
radically new to it? Having a shallow look, both -- KDE3 and KDE 4.1 have quite a
similar interface. Panel with tasks in it, an application starter menu, a simple clock
with a calendar, a virtual desktop switcher and the systray. Just about
everything is in the same place where people using KDE 3 used to find it. And in
4.1, you'll have icon groups on your desktop that work just like kdesktop's
filemanager, only a bit more flexible. Overall nice improvements, but certainly
nothing radically new as a whole. That's probably as far as it can get with
re-creating the traditional desktop. Nobody wants to create an exact copy of KDE
3 at this point anyway. If we would have wanted that, we wouldn't have started
this journey that is KDE4.
Yet nobody wants to take away the traditional desktop from the users. That's why
KDE 4.1 looks like it is. It's a relatively conservative traditional desktop. If
you look at the KDE 4.0.4 implementation of openSuse, it's even very close to
how KDE 3.5 looks like and works. Besides that, you have enough choice to run
any traditional desktop around, wether that'd be KDE3, GNOME, XFCE, or whatever
you like. And in August, we'll release KDE 3.5.10 for those that prefer 3.5.
See, we're nice people, we're not abandoning 3.5. We don't want you to move.
It's completely up to you. KDE 3.5 is rocksolid and works really well in many
aspects. KDE 4 has not reached its full potential yet. You will be able to
decide yourself when it's time to move to KDE4, if ever. And if you happen to
fall in love with KDE4 applications, which is quite possible, they also run just
fine in KDE 3.
Surely the developers do need some room for innovation and trying out new
ideas. It would be strange if we kept adhering to all those traditions and
copied 3.5. And it's why we created KDE 4 in the first place. Two years ago I
talked with a Canadian friend on the phone about KDE 4 and Plasma in particular.
The idea was back then to create a desktop that is backwards compatible with
what people are used to, yet offers new cool stuff that gets you hooked. With
KDE 4.1 we've probably reached this goal. A desktop that's pretty close to 3.5's
functionality.
Regarding those relatively small adjustments we've made to the desktop
shell, one could wonder what some people say when their filemanager and
applications start dealing with information, rather than with data
understanding relationships between information, people, ... and works with
metadata and semantics, rather than a hierarchic filesystems. (that's what
nepomuk might bring us at some point) What about when we start blurring the
lines between the desktop, the network and other devices. Will people start
freaking out then?
A couple of days ago, I read that 166 new SVN accounts have been created in
the last 6 months, that's a lot of new blood. That's 166 people that plan to
contribute to KDE codebase on a regular basis. And those are people that are
obviously attracted by the direction KDE is taking.
So what will KDE 4.2 look like? Judging by what the Plasma team has
accomplished in the last couple of months and the magic crystal ball, we might
see some mighty cool new things. I'm certainly looking forward to integrated
uiserver and Plasma notification applet, the concepts of detachable extenders
and Plasma's ZUI integrated with KWin and generally made more polished.
I'm sure KDE 4.1 will be a blast, and if people still complain that it
doesn't do exactly the same as 3.5, we can probably never get it right for some.
I've personally always found KDE a friendly bunch of people that like creating
cool and free technology together. Let's concentrate on just that. Happy hacking!
Props to Wade for the picture.
[ Wed, 09 Jul 2008 01:44:44 +0200 ] permanent link  Plasma while I'm away.
So without being able to have a look, Plasma is still progressing at an amazing
pace. Last wednesday, before I left to Belgium for
Rock Werchter I mailed Marijn (who
is the student working on Plasma on Small Form Factor (SFF in Ade-language) my N810
so he can look into getting Plasma going on that device. Returning, I see
a blog
of his showing Plasma running on Maemo on the N810. Awesome. I'm looking forward to
trying it and be able improve plasmoids for this formfactor. Being able to see your
own code on a new device is also quite cool, I must say.
Next, as far as I can see, with consent of the release team, we managed to put one
more new feature a lot of people wanted to see into Plasma in trunk/ -- meaning
this will make it into the upcoming KDE 4.1 release. So now you can move applets on
the panel. Yay!
In other Plasma-news, Dong Tiger has been working on support for Google Gadgets
in Plasma, and it's coming along nicely as you can see in the screenshot. A couple
of things still have to be solved, how to install them in the most intuitive way?
The Google Gadgets are using a QWidget subclass that does rendering and input even
redirection (by mean of Widgets-on-Canvas). So, support for many, many more
widgets is coming up and Plasma seems to be becoming The Shell To Rule Them All.
Disclaimer: Support for moving widgets on the panel is going into 4.1.
Support for running Plasma on Maemo will probably not be included with KDE 4.1,
neither will support for Google Gadgets be. (Those disclaimers apparently are
necessary to prevent confusion among those not reading developer blogs carefully
enough.)
[ Mon, 07 Jul 2008 18:44:17 +0200 ] permanent link  Werchter
Just over two hours ago, I returned from Belgium where I was at
one of those (watch out, sucky flash
content with far too long animations) large
European summer rock festivals, together with about 80.000 others. It was a blast.
I've most enjoyed the Chemical Brothers' concert, which was late on Thursday
night, they actually played until after half past three. Their show was quite
"electronic" and very, very "phat", with lots of references to bands such as
Kraftwerk("We are the robots, dum-tutu-dumdum!"). It was also
good to see them not doing too much of their breakbeat numbers in the style of
their early works, but coming up with refreshing new sounds, and using the
stage and its rather nice visual equipment to its full extent. I loved their
"Don't look back" which probably makes for an awesome soundtrack for
Wade's "don't
look back" series of pictures. I don't know how licensing sound for something
like this looks like, though.
Other remarkable
bands I've seen and really enjoyed were Soulwax, Moby, Duffy, R.E.M., Kaiser Chiefs
(who probably won the prize for most drunk act). Radiohead did disappoint me a
little, but I guess that's mostly due to their latest works being more "sofa music"
than something to dance at a festival. So after four days of camping, cherry beer,
music and pretty much void of shower, I'm back home, cleaned, took care of various
pets including my own body and cleaned the house a bit. Now catching up on emails
(which I probably won't manage to finish today, so hang on a bit if I owe you a
message). I'm also updating my local installation from trunk/ right now to see
what you busy bees have been up to.
[ Mon, 07 Jul 2008 17:43:17 +0200 ] permanent link  benchmarking XRender performance, how to file nvidia bugs
Blauzahl asks where to file
bugs we encounter in the nvidia drivers. Last night, after my
previous blogentry
Fredrik told me he disagreed that it's hard to find nvidia engineers
that can help with this kind of performance problems. It seems some hang out in
#xorg-devel, and our planet admin Chris Lee is currently working on the NVidia
Linux team as well. Fredrik pointed me to a benchmark that measures the performance
of various XRender calls. Running it shows that most of the tests are
very fast (1 - 20 milliseconds) or very slow (most between 8 and 16 seconds).
That means lots of operations take 400 times as long as others. On my notebook's
ati x1300 using the fglrx driver, I get results of 20 milliseconds for the 'faster'
operations. Not a single test takes more than 2.5 seconds. So nvidia is faster
, but only for some tests. Overall, ATI performs better in these tests. And then
maybe those operations can be accelerated in the driver. xrenderbenchmark
takes ~13 minutes on my nvidia 7600GS
and 1:45 on my ati x1300, a fairly low-end laptop chip. In order to compile
xrenderbenchmark, first "qmake xrenderbenchmark.pro" (make sure you use Qt4's
qmake). Then run make, and xrenderbenchmark.
So if you encounter those performance problems,
get Zack's
benchmark and provide the data to the nvidia developers. The problems should
be filed as a bug on the product xorg, component "Driver/nVidia (proprietary)" on bugs.freedesktop.org. I've
filed the performance issues here,
along with some my logfiles.
Update: I'm not the first finding out about this.
Nice pictures showing the performance
problems and lots of reports on the
Phoronix forums. All
reporting abominable 2d performance with NVidia graphics cards and drivers.
[ Fri, 27 Jun 2008 06:20:12 +0200 ] permanent link
Weblog Archive
23-11-2007, 18:44 h © Sebastian Kügler
|