![]() |
|||||||||||
|
![]() Hideous GTK themes in KDE4 sessions.For some time, GTK apps running inside my KDE4 session would not pick up their theme properly, making them look hideous in their default theme. I'm using a small wrapper script (/usr/local/bin/startkde4) to get my KDE4 desktop up and running. Since I've put the "unset GTK2*" line into the script, GTK apps pick their theme again: #!/bin/sh export LD_LIBRARY_PATH=/home/kdedev/kde/lib export KDEDIR=/home/kdedev/kde export PATH=$KDEDIR/bin/:$PATH export KDEHOME=~/.kde4 unset GTK2_RC_FILES . /home/kdedev/kde/bin/startkdeIf you're still living under the "I use a GTK1 app" stone, put another line for GTK(1) apps in there. Hope this tip keeps someone from tearing out hair. :) [ Thu, 08 May 2008 12:58:09 +0200 ] permanent link ![]() Non-linear animations in KWin.
Some time ago I've done a proof-of-concept how one can make KWin's compositing effects
use non-linear timelines. Before that, a KWin animation would feel a bit static. Think
of minimising a window. It would abruptly start moving at a constant speed and stop at
some point in the same, abrupt way. Now we have a wonderful class in Qt, called QTimeLine
that provides some additional curveshapes, making it easier to show accelerated or slowing
down movements. After some discussions on the KWin mailinglist, I've implemented a smallish
wrapper class around QTimeLine that is tailored towards the needs of KWin's effects. I've also made windows become translucent as they are being minimised, making it look a bit fancier. Hacking on KWin is actually a lot of fun. You can do a lot with very little, the code in most of the effects is (at least partly) easy to understand and modify, and the results are very visible, which I think is a good motivator. [ Mon, 21 Apr 2008 15:03:42 +0200 ] permanent link ![]() We broke Plasma.
After Alexis has torn Plasma into pieces yesterday, some brave individuals svn up'ed, rebuild kdebase and started putting the pieces backtogether. There are huge amounts of fallout right now, but we're getting closer to having some basic applets back. Currently digiclock, battery, kickoff kind of work (modulo some layout problems in the panel), taskbar at least compiles after some frenzy porting over the last hour. All this feels like a fast-track through the last year-and-a-half through Plasma development. I can remember very well when we first saw a panel and rudimentary clock appearing, the same happened today with much "ooooh" and "aaah" ... :-) But Why? you might ask yourself, it started to look polished and now it's broken again. Well, Plasma in KDE 4.0 was based on Qt 4.3. Qt 4.3 lacked the widgets-on-canvas support Qt 4.4 has. That means that layout managers and widgets had to be written from scratch for 4.0. Now KDE's trunk/ requires Qt 4.4, including the widgets-on-canvas (WoC) support, we're able to use QWidgets, and maybe more important Qt's layoutmanagers in Plasma applets and containments such as the panel. So we were able to remove large parts of code in favour of using Qt's functionality -- less maintainence burden, less bugs, less memory consumption and all that included. And while that fixing of the WoC fallout happens, the next round of breakage is on the horizon: Kevin, Richard and Aaron and The WhiteBoard have gone through all the classes in libplasma in order to polish that, remove braindeadness and a couple WTF's in the code. The plasma API should become much more intuitive, easy to use and future-proof. The downside being another round of breakage and fixing all over the codebase. We expect the results of the API review to hit trunk/ later this week -- including the breakage it introduces. After that, we hope that libplasma is stable enough to have it move over to kdelibs, currently that's planned for the 4.2 timeframe. I've put the results of the API review online. As to the "Which face does this SVN account belong to?", that'll come later. Besides a working desktop, one needs something to look forward to. :P So if you've compiled trunk/ after yesterday and wondered what happened and why someone visually bombed it back into the stone-age (last year ;-)), now you know why :-) If you want to help fixing up things, update trunk/, join #plasma on freenode like others do and fix obvious breakage. It's not necessarily hard, but there's quite some code crunching involved. Do tell others on IRC what you're fixing so duplicate work is prevented. Looking at the current flurry of patches gives you a good idea what to replace with what. Of course this is all done during Tokamak, the Plasma sprint in Milano where we're hacking on your favourite desktopshell since last Friday. More exciting stuff has happened, but more about that later, and of course in other Plasma hackers' blogs. Suffice it to say, we're mightly productive and very cool things are on the road ahead.[ Mon, 14 Apr 2008 22:08:34 +0200 ] permanent link ![]() fkefer is out of laptop.
So after we worked on priorities thanks to our awesome Celeste, Franz Keferböck showed us his version of priorities. He visited us down here in Milano at the Tokamak Plasma Sprint, bringing Stevie, his girlfriend, a case of fine Austrian beer, but unfortunately he forgot his laptop at home. Now that's what I call priorities. :-) [ Sun, 13 Apr 2008 03:37:14 +0200 ] permanent link ![]() Lies, damn lies, ... .... and statistics. Last week, I took a python script that I had written some time ago for CodeYard, modified it a bit and analysed some recent KDE subversion logs. I've taken a look at the number of commits in the KDE 4.0 branch, and a bit in trunk/. I've also compared number of authors and commits to the KDE and GNOME Subversion repositories since 2004. I'm discussing my findings below. Of course, being Free Software, research and all, I've put up the script and data so you can run with it and create your own reality.
KDE and GNOME Compared
KDE 4.0 Branch
[ Thu, 10 Apr 2008 18:33:09 +0200 ] permanent link ![]() A KDE Office.
[ Fri, 04 Apr 2008 13:37:48 +0100 ] permanent link ![]() All ur ChangeLog r belong to us.We (marketing / promo hat on) are right now trying to write the announcement for KDE 4.0.3, which will be released on April 2nd, a bit more than a week from now. Let's have a look at how this actually works, and zoom in on the bugfix / translation updates that 4.0.x releases are. The announcement is usually written by a subset of the Marketing Team, coordination takes place on the kde-promo mailinglist. On this list, people that are willing and able to write about KDE hang out. Those people are collecting information about those releases. For a big thing such as KDE 4.0, this is relatively easy, there's more than enough to talk about. For an update release (such as next week's) we're mostly relying on the changelog as raw material. We try to form an impression of what's happened in branch in that period, and munge that into something which is readable for human beings and provides a high-level summary for those that won't dive into details. Then, the original announcement version is written and ASAP (though usually too late) sent to the translation teams so we have a multi-language announcement ready on release day. The trade-off here is: Writing the announcement earlier, the changelog will be incomplete, but the translation teams get more time, so we end up having more and better translations on release day. Writing the announcement later, there's more in the changelog (although unfortunately not much more :/) but the translation teams have too little time, so we lack translations. Having a more complete changelog available earlier is the solution to this problem. So we need help from developers. Kudos at this point go out to the KHTML and Okular teams, who, from the top of my head, usually have done their changelog homework well. For the lazy ones among us (most, assumably), here's what you do (assuming you use svn+ssh, https users will what to change):svn co svn+ssh://svn.kde.org/home/kde/trunk/www/sites/www/announcements/changelogs kwrite changelogs/changelog_branch_4_0.xmlScroll down to a line that looks like xsltproc --stringparam outputversion "4.0.3" -o changelog4_0_2to4_0_3.php changelog.xsl changelog_branch_4_0.xml I think this ignoring of the changelog is a display of a culture that we see quite often within KDE. A culture that is very humble and fully concentrates on getting work done. Only in this case, it causes problems for others that also want to get their work (informing about KDE) done. So if you changed something in the KDE 4.0 branch between 27th of February and 26th March (this coming Wednesday) please support the Marketing Team's work by adding your change to the changelog. Remember, if a change is worth backporting, it's worth putting in the changelog. The more entries there are in the changelog, the more choice the Marketing Team has to streamline the message. Of course, also the 'raw' changelog will be available to the users, usually linked from the announcement on www.kde.org and multiple other sites reporting about KDE 4.0.3. Users will look for their pet issue being addressed. The Marketing Team does an awesome job in communicating what's happening (who doesn't love reading the Commit-Digest for example?), but they can't do that on their own. Please spend those 5 minutes and help your fellow gearhead. [ Mon, 24 Mar 2008 23:02:11 +0100 ] permanent link ![]() A pink desktop.
[ Wed, 19 Mar 2008 19:52:10 +0100 ] permanent link ![]() Plasma's panel is now resizable, interviewed.
[ Fri, 01 Feb 2008 21:15:48 +0100 ] permanent link ![]() Newsflash: Plasma hackers assaulted by dangerous croc.
[ Mon, 21 Jan 2008 00:59:08 +0100 ] permanent link ![]() Release Schedule bits and Planned Features for KDE 4.1.Earlier today, the KDE Release Team came up with a rough release schedule. This schedule is actually two-fold. Bugfix releases will come out every month, at least for the next half year. The next real feature release will be KDE 4.1 in July 2008. Furthermore, KDE will be releasing a new feature version every 6 months, so KDE 4.2 will be there in January 2009, 4.3 in July 2009, and so on. We hope that this way, we make it easier for both KDE people and distributors / OSVs to plan. Plasma might see an intermittent release in the meantime, which is made quite easy with our improved infrastructure, so early adopting users won't need to wait until July for some sorely missing features (resizing, moving panel, anyone?!). So what's in the pipeline for KDE 4.1? Let's see:
[ Sat, 19 Jan 2008 09:58:26 +0100 ] permanent link ![]() KDE and the Linux Kernel.Just returned from a break-out session with some kernel developers who are here at Google where we discussed a couple of things that can be improved in the current Linux kernel for a better user experience. We, that is a group of KDE people from different areas, among which aseigo, Dirk, Thiago, Will, Zack -- in randomly alphabetical order. Kernel people in this session include Natalie Protasevich, Andrew Morton, Daniel Phillips and Gary Greene. Issues that have been discussed are limitations in inotify where we'd like to be able to watch more files at once for changes, the most notable use case being desktop search and indexing. Another interesting issue we're facing is bad guessing when trying to keep interesting things (such as a maildir with lots and lots of small files in cache) when dealing with large I/O. This is actually something we can improve ourselves by using fadvise to tell the kernel what makes sense -- the kernel cannot reasonably be expected to know the purpose and usage of data, so we need to tell it somehow. Of course, my pet-peeve and the ever-interesting issue of suspend is another big issue with the Linux kernel we currently have. While it is on the radar of the kernel devs, we made sure that they know how important that is to us. In my opinion, the solution to this is two-fold. As it's mostly drivers that are responsible for the rather bad user experience currently, drivers need to be improved. Open drivers can obviously be fixed much easier for the kernel developers, but it also helps if large companies can kick each other when they're screwing up suspend and hibernate. Most important outcome of this meeting has probably been the opening of communication channels. Andrew told us that the best way to get our issues addressed is filing bugs (as emails), voting for them to justify resources put into them. Andrew also told us that sending such a bugreport from a @kde.org email address will prioritise it, which is I think important to know for us. Kernel people really want to help us, getting them the information they need will make it easier to fix problems we face when using the Linux kernel. Such a bugreport ideally includes a testcase (code!) which shows the problem. Needless to say that I'm very happy we got the chance to exchange. Thanks everybody involved! Also, I should probably pass on Daniel's "Thank you for creating KDE!" to you all.[ Sat, 19 Jan 2008 01:54:46 +0100 ] permanent link ![]() Be free.
[ Fri, 11 Jan 2008 20:14:18 +0100 ] permanent link ![]() Looking back.
More than 2 and a half years ago a historical meeting took place in Berlin - APPEAL. From the Dot story: "The scope was broad and incuded artwork, human interface guidelines, Tenor (a contextual linkage engine), alterntives to traditional file managers and groupware applications." Reading back, there is a striking similarity with core concepts of KDE4. Most of those items are reality in KDE 4.0. Others are close to done and will surface wthin the next releases. In Malaga (my first aKademy, still being a student), this atmosphere of doing something big became more evident. There, I worked with Jan and Ellen (Relevantive & OpenUsability) on a usability review of Guidance. To me, this showed the great potential and how to merge the processes around software development ad usability engineering and get something really nice out of it. I also remember a presentation given by three artists, the Oxygen team. Ken, Nuno and David presented their first bits of work to the community. They discussed concepts behind the Oxygen icon set (it was still merely an icon set, back then) and even showed a first, very early pre-alpha version of some icons. At the same aKademy, we started setting up the Marketing Working Group, with its primary mission coherent messaging around KDE, based on Guerilla Marketing and scientific strategical analyses. For me, this was the start of the KDE 4 vision. Tomorrow we will flip the switch to make this vision reality. And next week we'll present it to the world.[ Thu, 10 Jan 2008 15:53:00 +0100 ] permanent link ![]() First-hand KDE news.As some of you know, the KDE Marketing Team has a so-called press channel for some time now. We feel that it's a good idea to make this more well-known to the media, so here's a call for more participants. The press channel is a low-traffic mailinglist we subscribe interested journalists to. The press channel offers first-hand information, and often even scoops to news before we officially publish it. Sometimes, we even put additional material, such as screenshots into the channel for free reuse in your (the journalists') stories. The format of the messages in the press channel is kept very brief. One should be able to judge from the content in less than 20 seconds if it's interesting material. Additional information is provided through links, so it's easy to start doing research for a story. Why am I telling this? There are actually two reasons. One is to make the work of the Marketing Team, that is often going on behind the curtains more transparant. Another reason is to invite more journalists to the party, so we increase coverage on KDE in the media and the community reads more actual and better researched news. We want to make it easy for journalists to cover KDE in the media. So if you're an interested journalists, please get in contact with me via my email (sebas@kde.org) and tell me that you'd like to join the press channel. As motivation, your affiliation is handy information for us. If you know journalists who could take advantage of this, please let them know, or point them at this blog entry.[ Mon, 17 Dec 2007 16:37:31 +0100 ] permanent link ![]() You are press.My previous blogentry caught quite some attention. Within 36 hours, I burnt 90GB of traffic (thanks jorik for bearing with me!), and at first apache choked on the number of incoming request. But that was only a configuration problem, apache needed its maximum number of concurrent connections increased. I blame the web-2.0 buzzword for this. So most of the users were eager to see screenshots of what's going to become KDE 4.0, Aaron's changed to parts of the plasma user interface (panel and krunner theming were updated shortly before) probably helped a bit. Right before my blogentry, we released KDE 4.0 rc1, which didn't have those new looks, and we didn't really bother posting screenshots along with the announcement. So why that? It has everything to do with our current release process. Dirk usually tags the next release on wednesday, then it gets roughly a week of testing, making compile and fixing obviously stupid things you inevitably get when snapshotting an source code repository that's heavily worked on. So it takes about a week to prepare the release and distribute it to the packagers of various distributions to give them some time to build the code. The announcement is usually done the week thereafter on Tuesdays. And in this case, those running KDE trunk have the more recent code when the release that has been tagged one week before is announced. This will probably change once we branch 4.0 and trunk/ becomes KDE 4.1-in-progress. This, however, will also still take some time. It has been shortly discussed in the release team, and most people think that we should not distract ourselves by branching off 4.1 too quickly. So you are press. A lot of KDE's PR comes from people within the community. It's quite natural, given the interesting blogposts on PlanetKDE. We can make it even more popular by reaching out and being more verbose about the cool desktop, apps and libraries we create. I gather that KDE is also read by quite some people who might not be following the traffic on various mailinglists, and it's always beneficial for us if we know better what's going on in other parts of the project. Let's feel encouraged by the amount of people eagerly waiting for information to pop up. Create screenshots of cool things in KDE, explain them shortly and blog it. We can probably also amaze ourselves quite a bit by all those tricks that can be done with our new KDE -- such blogs also make nice additions to the documentation and might also enlighten those people longing for this handy feature to dump their proprietary platform and switch to KDE. My favourite feature this week was the "undo close tab" which konqueror now has. When logging into my KDE 4 desktop, konqueror friendly asked when starting up if it should also restore the previously opened tabs. Sure, do it. Works like a charm! :-) Last week, my favourite feature certainly was Kate's sessions. It's not a new thing, but I never bothered looking at it and considering it. Now, my kate has a couple of sessions that save me the tedious work of opening 5 documents (that often are located in different directories). Now it's two clicks away and I can get to work right away.[ Thu, 29 Nov 2007 18:53:02 +0100 ] permanent link ![]() KDE 4 snapshot screenshots.
[ Wed, 21 Nov 2007 01:05:23 +0100 ] permanent link ![]() Oxygen battery.
[ Mon, 19 Nov 2007 23:45:30 +0100 ] permanent link ![]() clockwork.
[ Thu, 15 Nov 2007 00:25:10 +0100 ] permanent link ![]() Greenwheels.Jeff Bailey writes about carsharing, and it being critical to solving the problem of mass-transit. First, and foremost, I do agree with that. In the Netherlands, while public transport is quite good (if not cheap) and fairly reliable (compared to say, India :-)), the "if it costs me ten minutes more to get there, I'd rather go by car" is quite apparent. That's not to say that people don't go by train, they do. Usually though, trains during rush hours are pretty packed. Getting a 1st class ticket solves that in most cases, it makes the difference between getting a place to sit, and often enables you to do some work on the train. Or take a nap which is hardly possible in an overcrowded train. So there's Greenwheels, a car sharing company that manages to get quite some coverage over the whole country. Taking part in this programme costs between 12.50 EUR and 25 EUR so it is quite cheap not to use the car. Those cars (small Peugeots) are usually near to a train station, making combined journeys easy. In most cities, you also find one within a short footwalk. There's three cars here within 10 minutes walk, one of them just around the corner. I've been using this for more than a year now, and my impressions are really good. If you need a car quickly, it's usually available, but it makes you think twice wether to actually go by car and not by bike. I don't really like driving (worked as a courier for some time after school, so I've seen enough of it) but those shopping visits some time make it useful. I get to use the car once a month, roughly. It doesn't work very well for those cases with lots of idle time, you pay per hour (at least in the evenings and weekends), and longer journeys (couple of hundred km) can become quite expensive. But then, get a train and only do the last mile by car -- that's what trains are bad at. I'm sure it's not an option for everyone, but still good to consider this before you add yet another car to those traffic jams. And having lots of cars in the streets in front of your house doesn't improve the quality of living as well. So for the Dutchies, there's Greenwheels. Now go looking for something similar in your country.[ Thu, 08 Nov 2007 13:20:33 +0100 ] permanent link Weblog Archive
23-11-2007, 18:44 h
© Sebastian Kügler |
||||||||||
|
|||||||||||