Feed aggregator

The KDE web team is pleased to announce a major redesign of the KDE.org frontpage and buzz.kde.org, just in time for the pending release of our updated Workspace, Application and Development Platform compilation. The redesign is the result of many hours of work by artists, coders, writers and testers. Keep reading to gain some insight into the people and processes behind the retooling.

read more

The second week of our action plan for optimizing Krita was devoted to optimizing painting in Krita. Although there are many great paintops in Krita, digital painters tend to use most of the time the simple default brush engine which we call Pixel Brush. Painters can use GIMP brushes here, the text brush, but the most used brush tip is called Autobrush. You can setup the brush attributes like shape (circle, rectangle) and you can change the ratio to get an ellipse. Then you can change softness by vertical and horizontal fading. If you play with spikes and ratio, you get stars and other funny shapes. The brush has many dynamic attributes thanks Cyrille Berger’s work on concept called sensors. E.g. tablet can control the size by pressure, by tilt or anything you want (e.g. interesting is drawing angle) and it can be tuned by curve.

The algorithm, which computes the brush mask, stamped on the canvas regular as you stroke, is computed by the KisCircleMask::valueAt(). It is a computationally expensive function according valgrind logs we did week ago and many times before. David Revoy, team member of the Durian project, said that using 70px brush on 2500×2500 image was very slow in Krita. So we needed to optimize that.

I started with exploration of the code. I’m not the author of the autobrush, though I did most of the paintops in Krita (10 paintops are mine out of 19, many are experimental). First catch was the interpolation in the brush mask computation. We called valueAt() 4 times per pixel of the brush mask. We found out with Cyrille that the valueAt function used to take integer parameters a long long time ago and double values of the brush mask pixel positions were computed with interpolation. So I decided to remove the interpolation as the function has been capable to take double input long time ago. And the results of the valueAt() are more precise then interpolation. The benefit was great. Painting was 4x faster. Benchmark for random lines with changing size according pressure dropped from 18 seconds to 4 seconds on 4096×4096 image. Check it in the wiki, related table is called Just with performance fix.

From the valgrind logs we noticed that the atan2 function is called too often. “Chickenpump” suggested some cool old school tricks in comments. And so we gave that a try. I used double hashing with QHash in QHash for the 2D function atan2, but that was very slow due to low cache hit ratio and expensive hashing. Then Cyrille posted some links with free code which implemented a fast atan2 with an internal lookup table. So I ported that code to Krita. Cyrille did some magic stuff like computation with fixed precision on library loading time and some little tune ups to speed the fast atan2 computation and we managed to get more speed up around 1.3x faster then without fast atan2 function. There is probably some more room for optimizations as the fast atan2 implementation uses a quite small lookup table. Also I tested some other implementations, but it had problem with precision. It had 3 degrees error. That is too much for us, so I dropped that.

I remembered a quite interesting magic function for fast inverse square root used in Quake III. So I gave it a try as we use inverse square root in valueAt() too. I found out by benchmark that fast inverse square root is slower then directly computing the inverse square root (1/sqrt(x)). It used to be 4 times faster a long time ago. Probably Intel implemented that in processors already. Or the optimization done by compiler was not so effective in case of fast version. Again we dropped that.

Most of the use cases for painting include brush masks which are symmetrical. The algorithm could compute just 1/4 of the mask. Next step was implementing this.

First version used 4 pointers to the memory and compute 1 pixel and copy 3 pixels to the right region. I managed to get another 1.7x speed up (from 3.555 ms to 1.9 ms).

Memory access is very important and can slow down computation. It is like when you use setPixel/pixel method to access pixels in pixel buffer – you supposed to use scanlines, that is faster. Here is some interesting article about it. If you don’t have something to read, here is also nice CPU memory bible.

First version used 4 iterators over image pixels. One computation per pixel. And copy the values.

So I decided to make it little faster just by using two pointers. I compute 1/4 of the mask and copy this part to the NW region. And then I copy the rows in the lower part of the mask in correct order – I mirror it.

Improved version used two iteratiors and memcpy the second half of the brush mask.

I found out on friday evening that it does not work though. Circle masks seems symmetrical from user point of view, but they are not. The brush mask respects sub-pixel precision in Krita, so the edge pixels of the circle are not symmetrical. The sub-pixel precision is visible when you work with big zoom level. I have an idea for computation 1/4 of the brush mask, but I decided to post-pone it.

Other possibilities are still around:

1. mip-mapping : pre-compute various levels of brush mask to buffer and interpolate the masks. We do this for Gimp brush. We would interpolate two computed brush masks instead of computate the single mask. Maybe it could be faster, maybe not. The reason for mipmap in GIMP brush painting we have, was to increase the quality of the scaled brushes as Adrian Page, hacker in the Krita team, wrote me in an email. Mip-mapping would require to split rotation from the mask computation. This can lead to different results regarding of the brush mask. Now we consider the rotation in the mask computation. Then we would rotate un-rotated mask by image processing – rotate image. Some conformation rendering test would be needed. The advantage would be support for rotation of the gimp brushes in Krita.
2. cache the brush mask for mouse users: cache the dab as the mask doesn’t change. This would be nice if we did not compute sub-pixel precision. But we do that, so the cache hits ratio would be very small. It would be usable for 100% zoom, when sub-pixel position is zero. And of course big condition for checking of the parameter changes would be required.
3. Compute the mask with graphics card – use shaders: that would be cool, I have some initial experience with shaders but integration would be harder and probably too experimental for our plan. I’m mentioning this as we discussed this with Sven Langkamp in Oslo and so that it is not forgotten.
4. We will probably do some garbage recycling – memory allocation is slow, we can benefit from recycling memory. It is a matter of discussion on IRC at #krita on freenode. You are welcome to join.

Final time of the computation in benchmark for random lines is 1,449.2 ms. It dropped from 18,576 ms. So the painting was 16xtimes faster.But I revert the 1/4 of the brush mask speed up, so the current speed is 3.555 ms. Painting will be 6xtimes faster. The speed is considered to be usable for big brushes now. I invite you to do check-out of the trunk and try to play with big brushes. 200 px is now very usable on my laptop. What about yours?

I updated my WordPress blog. I dropped the previous classic WordPress theme and selected the default one – lazy developer. I did not like the font in the previous one. I don’t have much time to play with web-designing these days. But at least I customized the default Kubrick theme. I changed the fixed width of the theme to wider values. I did also simple custom header with some random strokes with my paintops in Krita. I hope you will like it. Every image in the blogpost is made in Krita.

For all those in Buenos Aires or its surroundings, we'll be having a meeting to celebrate the release of KDE SC 4.4.

This next Saturday 13th, at 19:00 we'll meet at Dr Mason, a bar known to be friendly to FLOSS people of all nature (it has been home to a couple of Ubuntu release parties). It is located in Araoz 1199, Buenos Aires. Cost is about AR$ 30 for some beer and snacks.

We'll gather to talk about the features of the new releases, upcoming events, and of course, have a beer and socialize. Here you can find more information about it: http://kde.org.ar/node/54

Just in time with the KDE SC 4.4 release, I was able to get out another release of Skulpture, my favorite widget style. The list of fixes is quite long again, partly because Qt 4.6 required some adaptions. The most annoying bug, the Tab key handling in Konversation, has finally been fixed. Two other bugs could cause crashes, so you are advised to update.

Source code and packages for all major distributions are available for download from the kde-look.org site. Note that these packages are not official; you should switch to distribution packages once they are available.

It's been a while since I blogged last. I blame microblogging. So just to introduce myself again, I'm Ian Monroe and I'm an Amarok developer. I live in Iowa, USA. For about a year and a quarter I've been working for Collabora. I believe the rate of hired Qt developers has been growing exponentially at Collabora year-to-year since 07, so it won't be long until we all work for them. ;)

You'll find tons of sample Git workflows in Git docs all over the Internet. We've been using Git in Amarok since July and I've been using it everyday at my work since January so now I have my own Git workflow to add. It assumes you know the basics of Git already and that the project you work on is actively developed by others at the same time.

But first a note on why my commands are longer...

Keep it Explicit

One thing that much of the documentation for Git does is make things 'simple' by using various command shorthands. From helping fellow Amarok devs get used to Git and just from my own experience I've decided that in the longterm using commands that combine several tasks or use default options are confusing. Most of us type at about 50 words per minute causally, there's really no reason to skimp.

An example of this is to use git push origin master:master instead of git push. That tells you exactly where your commit is headed: to the default remote named origin. The master:master says you are pushing from the local branch master to the remote branch named master. I like being explicit with branch names since getting mixed up which one you have checked out is a mistake I've made before.

Importantly it keeps you in control and aware of what you're doing.

A Workflow

So you notice it's time to go make dinner, instead of just leaving the code uncommitted I say its a good idea to go ahead and do a git commit -a before you leave. Writing the commit log is helpful for when you sit back down later. Remember you can always git commit --amend and add to your last commit before pushing.

Okay so next morning, back to hacking. Time to update. It is important to often update to avoid conflicts.git remote updateThis command refreshes all the remote branches. It doesn't touch your checkout. Both 'pull' and 'rebase' let you interact with remote branches directly, but I like to break it up. So now bring in the latest changes to your checkout:git rebase origin/masterThis is mostly why I like to leave all changes committed before I leave, because then the rebase works without you having to remember to git stash or commit when you're updating in the morning before having had any tea.

The advantage of rebase over doing a merge/pull is that it changes the commits you haven't pushed yet by making them patches on top of the latest code. It gives those commits a 'new base.' It's actually how Subversion works all the time, if that makes it easier to understand. This leads to easier to understand linear history, in the unlikely event everyone else in your project also uses rebase.

Okay now you've done more hacking and are ready to push. Repeat the above steps to make sure your code is still up-to-date. If you try to push when its not, Git will notoriously tell you that you are trying to do a non-fast-forward. It sounds scary, but 90% of the time it means you just need to update.git status
git commit -a #or git commit -a --amend if you want to add to a current commit
git remote update
git rebase origin/master
#maybe double check it still compiles after updating
git push origin master:master

Obviously there are other ways to use Git, but this is mine. I hope it has been helpful.

Just one image of a new Lancelot feature:

So, in The Beginning, when I was just a young padawan on the Internet, I had been let into a glorious secret: Emulation (not of IBM System/360 machines, but of more important things like the Super NES). Some branching from there led me to zophar.net, a popular emulation site, and their message boards, and also left me with a fascination with emulation.

The attributes of some of the older systems like the NES and Super NES made it fairly easy to capture their music-producing software, since those systems used separate co-processors to handle music effects. NES music would be stored in the NSF format, and SNES music was handled with the SPC format (named after the audio chip used, the Sony SPC700). There were (and still are) specialized plugins on many systems to play these formats (they emulated only the music chip, not the rest of the system).

I’ve been involved on the periphery of some of these things for the past couple of years. (For instance I had written a KFileMetaInfo plugin for KDE 3, and had helped Chris Lee with adding playback support to GStreamer.

One problem with the previous GStreamer solution (which I’ll call gst-spc) is that the underlying playback library, libopenspc, is written in x86 assembly, and has some crash bugs associated with it as well. As well the code has long been orphaned. I’m not really any good at writing emulation code and although I could learn, it would take far too much time for me to do anything useful.

Luckily for me the state of the art has advanced and last year I was pointed to a library called game-music-emu. This library included a very good SPC emulator written in C++, which had been merged into some popular SNES emulators already. Unfortunately it didn’t really have a great build system (using it involved simply copying it into your existing program) so my initial proposal to port GStreamer to use game-music-emu by simply including the source files with GStreamer was rejected. The GStreamer devs preferred to have an external library which could be used (or not) and I couldn’t blame them since in general good OSS projects avoid copying or forking external code.

So I contacted the game-music-emu author (Blargg) asking about the possibility of adding support for building a library, and ended up with commit access and an invitation to do it myself. Hmm.

So I did, and awhile ago I had made a release of “libgme” 0.5.5, working with Blargg has he got free time. My subsequent patch to GStreamer was accepted and since gst-plugins-bad-0.10.14 it has been possible to use libgme to playback many emulated music file types (not just SNES, but others as well).

With that solved I left the issue, but I recently came back to it since I figured out that even after upgrading to gst-plugins-bad-0.10.17 the other day, that gstreamer playback was not using libgme, but the older libopenspc.

At first I thought it was simply my fault, as I’d still had gst-spc installed from years and years ago. Removing gst-spc and libopenspc (just to be double-sure) left me with no SPC playback features. Running gst-inspect confirmed I did not have any gme decoder. WTF.

I then again thought it was my fault because I had installed libgme to /usr/local instead of /usr. So I dutifully wrapped up libgme in an ebuild and installed it. And still nothing. WTF.

I dug into the Gentoo ebuild for gst-plugins-bad and it seems that for whatever reason not all possible plugins are installed. It seems the new installation method is supposed to be that each individual plugin is supposed to have its own ebuild (i.e. gst-plugins-gme), like how Gentoo has split out other packages like KDE into individual ebuilds. Fair enough.

I write another ebuild, and finally hit paydirt:

The Qt example music player playing SPC files

Obviously this does require that you are using the GStreamer backend for Phonon to have this work, otherwise you can just try it in some other GStreamer-using application. (I’d show it in JuK but I’d have to add SPC support to Taglib first)

If you’re interested in the ebuilds I used you can use this Portage overlay, (SHA-512 sum c0ff9aa5413b0c0b14f7c52d5b3ee887edc4e7bf47182e58c21e9c340d8ff7e9). The overlay may or may not work for you, and I don’t even know if overlays are still the “hip” way to do things in Gentoo, but It Works For Me. ;)

As always, I took some pictures at FOSDEM 2010. Disappointingly I took less than last year: only 55 instead of 132 (and even that is cheating, because that includes a picture *of* me taken by xvello). Still, better than nothing, I guess... In any case, as always at FOSDEM, I had lots of fun, and that's what counts!

You don’t have to use KDE 4. (And I can’t believe I’m actually having to make that part clear) Really people should use whatever makes them most comfortable, productive, fits with their needs better, etc. Just use what you want.

With that said, saying that you do not like desktop effects is not a good reason to avoid KDE 4. I happen to like desktop effects but I’m not using them, even though I’m in a KDE 4 desktop (due to a stupid problem somewhere in the driver toolchain). In fact I know for a fact, given that I recently tested it, that KDE 4 works just fine even in a Composite-less X11. So I forget what propaganda technique it is (straw man argument?) but in short that reason has absolutely nothing to do with KDE 4.

Really your whole rant could have been more concisely expressed without a single reason (as after all, you should be able to use whatever desktop environment you want) and you wouldn’t have people nitpicking your exact reasons that way. ;)

"There's nothing easier" -- you say -- about packaging and deploying SQLite. "Just take the software with default settings and package as a shared lib plus SQLite shell".

It's not that simple.

The SQLite project is developed at impressive speed assuming complexity of the software. It's already part of many operating systems like OS X and Symbian. Linuxes use it somewhat at system level. Browsers use SQLite for storage via HTML 5, earlier via Google Gears.

The fact is that all of the uses we can spot are for a specific cases. For each case slightly different configuration is beneficial. SQLite has two kinds of configurable options: runtime and compile-time. The latter includes configurable limits. SQLite deployment is typical to embedded software, which is efficient but requires developers to be aware the specifics.

Google Gears expected SQLite to have certain features enabled. This is also the case with Kexi or in general any app that uses SQLite for desktop databases. As you can read in the backlog of Kexi development for January, I have switched to system SQLite. I even proposed update to FindSqlite.cmake to make sure minimum version with enough features is in place. That lasted just one day.

Then I have immediately switched back. There were a few subtle and one main reason - security. SQLite provides one nice compile-time option:

SQLITE_SECURE_DELETE This compile-time option causes SQLite to overwrite deleted information with zeros in addition to marking the space as available for reuse. Without this option, deleted data might be recoverable from a database using a binary editor. However, there is a performance penalty for using this option.

I have assumed that we want this flag to be on, so one important workflow in Kexi is more secure. When you delete tables or even just table rows (records) from a database, and send the .kexi file (which is based on SQLite database) to others, you basically expect not to have the deleted information in the file. Unless SQLITE_SECURE_DELETE is enabled, this is not the case. Databases, includeing SQLite, like to just mark the deleted records are deleted without removing the empty space or cleaning up the bytes.

Enabling the feature at the cost efficiency is the current design decision. An alternative to SQLITE_SECURE_DELETE would be to vacuum the database on closing. But what if the application was terminated uncleanly (application or system crash)? And what if user sends the database by email while Kexi is still running? These question do not exist when SQLITE_SECURE_DELETE is on, and that's why I like the flag.

SQLITE_SECURE_DELETE is not always needed however, for example when you share the data through a web server or remote connections. But these use cases are not yet supported by a stable implementation in Kexi.

All in all, the current set of options for Kexi's copy of SQLite is as follows (kexidb/drivers/sqlite/CMakeLists.txt) -- look to just get an idea of possible future features of Kexi and Predicate library (KexiDB 2):

ADD_DEFINITIONS( # sqlite compile-time options, http://sqlite.org/compile.html -DSQLITE_SECURE_DELETE -DSQLITE_ENABLE_COLUMN_METADATA # Some additional APIs that provide convenient access to meta-data # about tables and queries -DSQLITE_ENABLE_FTS3 # Version 3 of the full-text search engine -DSQLITE_ENABLE_FTS3_PARENTHESIS # Modifies the query pattern parser in FTS3 such that it supports # operators AND and NOT (in addition to the usual OR and NEAR) # and also allows query expressions to contain nested parenthesesis. -DSQLITE_ENABLE_MEMORY_MANAGEMENT # Extra logic to SQLite that allows it to release unused memory upon request -DSQLITE_ENABLE_RTREE # Support for the R*Tree index extension -DSQLITE_ENABLE_STAT2 # Additional logic to the ANALYZE command and to the query planner that can help SQLite # to chose a better query plan under certain situations -DSQLITE_ENABLE_UPDATE_DELETE_LIMIT # Optional ORDER BY and LIMIT clause on UPDATE and DELETE statements -DSQLITE_ENABLE_UNLOCK_NOTIFY # Enables the sqlite3_unlock_notify() interface and its associated functionality # (http://sqlite.org/unlock_notify.html) -DSQLITE_SOUNDEX # Enables the soundex() SQL function (http://sqlite.org/lang_corefunc.html#soundex) )

As mentioned in the reviewboard comment even while SQLite is not packable for general use as a shared library, this is by design. Because there are many compile-time switches, so many not-fully compatible versions of SQLite can be found in particular distros.

By having own copy of regularly updated SQLite, whas has been started in 2004, we can also patch SQLite to add some esoteric features, e.g. provide progress information of the .dump operation, so we can have display the progress in the GUI, which is good for large files.

I am also thinking about related proposal: having a copy of SQLite moved from Kexi into some place like kdesupport, with sane build defaults. With the lib name altered to something like libksqlite to avoid clashes with distro-packaged SQLite. Then something like simple FindKSqlite, would be used within KDE.

Do you have any opinions on the matter? Please share it in the comments below.

I finished today the (for me) most missing feature in the KDevelop Php language plugin. It fixes parsing problems that occur when a project is initially parsed and the code makes heavy use of classes together with an autoloader. That means no include() statements for parent classes or static function calls. (Typical when using eg. Zend Framewok)

Previously code completion was broken until you manually forced a reparse, now this reparsing is automatically done once a identifier is not found - the file is added to the parse queue with very low priority - and the base class will be parsed meanwhile - and found correctly in the second pass.

Credits for this should mainly go to Hamish - who implemented that more or less the same way in Java language support.

As KDevelop is currently frozen for Beta8 I couldn't commit yet, until then I created a temporary git repository.

A friendly user has today created a screenshot of the latest Amarok from Git Master. I was rather surprised that it actually looks fairly decent on Windows (had expected worse things), and the user even said it also works pretty well, with the new Phonon-VLC backend.

Anyway, I wanted to share this with you, but please keep in mind: This is a preview of the next Amarok version. Some things (like the new toolbar) are not yet fully finished, so please don't complain about that.


Preview of Amarok 2.3, on Windows

A friendly user has today created a screenshot of the latest Amarok from Git Master. I was rather surprised that it actually looks fairly decent on Windows (had expected worse things), and the user even said it also works pretty well, with the new Phonon-VLC backend.

Anyway, I wanted to share this with you, but please keep in mind: This is a preview of the next Amarok version. Some things (like the new toolbar) are not yet fully finished, so please don't complain about that.


Preview of Amarok 2.3, on Windows

With 2010 we've started to employ identica (then connected to Twitter and Facebook) as an channel for our live changelog at the {power}user level. Here's the dump for the past ~30 days (oh I should have used an XSLT).

• We're replacing serialized QFont attrs with ODF equivalents in Kexi Reports file format; e.g. fo:font-family; it's extension of OpenRPT
• Finally we're still embedding SQLite as many options are not set in distros, e.g. SECURE DELETE should be the default http://bit.ly/amZfJ3

• Kexi switched to using sqlite bundled with the operating system instead of using a fork. The newest stable version is always recommended.
• Sidebars behave now as expected: when collapsed, vertical buttons appear like in Kate. It's now natural to put widgets palette as a sidebar.
• An extra ko dev has taken an interest in the report backend used in kexi (koreport), working to making it usable in kplato, a win allround!
• We have line style combo box in the Property Editor. Today high precision point type also added too. Good for accurate printouts (reports).
• Just ported color selector for the property editor. Now we're defaulting to KDE's Oxygen palette instead of the old school VGA colors.
• Exporting in action! http://www.piggz.co.uk/kexi/kexi-export-1.ogv
• MS Access 2010 drops support for many formats: Paradox <=7, Lotus 1-2-3, Access 1/2. But 64-bit ver not even planned. http://bit.ly/5xZZV7
• Is zoomable table view reasonable idea for you? http://bit.ly/8AWp6c Added as todo just yesterday for Kexi 2.6 http://bit.ly/64C4jb
• MS discovered SVG? http://bit.ly/76lrNr Kexi just switched to svg ns for XML tags in Kexi Reports format-took 2 hours! http://bit.ly/6uD7dy
• All the most ugly painting glitches now fixed in Kexi Table View. So time-consuming but pays-off...
• Some rendering issues in the Table View widget fixed now. Looks like the Table View will stay Qt3-based until Kexi 2.3 - porting takes time.

Just a reminder to everyone from KDE Community (or others interested in or work), who will be around Ljubljana, Slovenia on February 9. Encouraged by the big success of the KDE party last year, and a lot of exciting new features in KDE SC 4.3 and 4.4, we’ve decided to organize another KDE release party this year. It will start at 18:00 local time and you’ll be able to hear about some of the cool new developments that have happend in the KDE land since the last party. So don’t miss this get-together and put this party on your calendars. If you are comming, please add yourself on the list on the KDE SC 4.4 Release parties Wiki and/or party page on Facebook. Invite your friends too. Don’t worry if you are not around Ljubljana on that day and time, we’ll most probably have a live streaming video during presentations (check this blog, or previously mentioned wiki/Facebook page, later for more info). In case you are even further away from Ljubljana (or don’t understand Slovenian) there are 26 other parties in 15 different countries around the world. Get ready to party!

• Hello Planet KDE, hello RubyCorner
• Simple Ruby Plasmoid
  • Test It
  • Understand It

Hello Planet KDE, hello RubyCorner

After some blog posts on my old blog about KDE programming with Ruby I decided to bring the content a little bit more to the people. Here I am.

Two days before yesterday I got a mail concerning a problem related to creating plasmoids with Ruby. I never had the wish to create my own plasmoid. I thought it would be difficult, but while getting a closer look, I’ve noticed how easy it is - in the case of using Ruby.

Simple Ruby Plasmoid

This example is a modified version from the one in the KDE techbase wiki.

The plasmoid sends the content of a QLineEdit to the clipboard when pressing the QPushButton or pressing the enter key and clears the QLineEdit afterwards.

Test It

If you want to try it yourself, you just have to extract simple_ruby_plasmoid_clipboard.tar.gz, change the directory to ruby-test-applet and start the plasmoid in a special viewer with plasmoidviewer.

You have to install the Ruby KDE bindings package (on opensuse it is called ruby-kde4), but on a lot of KDE4 systems this should be installed already.

Understand It

First you need the right directory tree for your plasmoid. It should be look like this:

ruby-test-applet/ |-- contents | `-- code | `-- main.rb `-- metadata.desktop

You need at least two files. The first one is main.rb, that contains your program code.

When accessing KDE libs from Ruby you write nearly the same code as you would write in C++.

A short example in C++:

setMinimumSize( 150, 150 ) Plasma::LineEdit line_edit( parent )

The same using Ruby:

set_minimum_size 150, 150 # or setMinimumSize 150, 150 # or self.minimum_size = 150, 150 line_edit Plasma::LineEdit.new self

Member variables begins with an @ sign. There are different aliases for KDE and Qt methods. You can omit brackets in a lot of cases. You don’t need any header files. You don’t need to compile.

require 'plasma_applet' module RubyTestApplet class Main < PlasmaScripting::Applet slots :addText def init set_minimum_size 150, 150 @layout = Qt::GraphicsLinearLayout.new Qt::Vertical, self self.layout = @layout @label = Plasma::Label.new self @label.text = 'This plasmoid will copy the text you enter below to the clipboard.' @layout.add_item @label @line_edit = Plasma::LineEdit.new self begin @line_edit.clear_button_shown = true # not supported in early plasma versions rescue nil # but that doesn't matter end @layout.add_item @line_edit @button = Plasma::PushButton.new self @button.text = 'Copy to clipboard' @layout.add_item @button Qt::Object.connect( @button, SIGNAL(:clicked), self, SLOT(:addText) ) Qt::Object.connect( @line_edit, SIGNAL(:returnPressed), self, SLOT(:addText) ) end def addText Qt::Application.clipboard.text = @line_edit.text @line_edit.text = "" end end end # kate: remove_trailing_space on; replace-trailing-space-save on; indent-width 2; indent-mode ruby;

The second file you need is the metadata.desktop containing all the meta data. ;)

[Desktop Entry] Name=Simple Ruby applet Comment=This is a simple applet written in Ruby Icon=chronometer Type=Service ServiceTypes=Plasma/Applet X-Plasma-API=ruby-script X-Plasma-MainScript=code/main.rb X-KDE-PluginInfo-Author=Me X-KDE-PluginInfo-Email=me@example.com X-KDE-PluginInfo-Name=ruby-test X-KDE-PluginInfo-Version=0.1 X-KDE-PluginInfo-Website=http://plasma.kde.org/ X-KDE-PluginInfo-Category=Examples X-KDE-PluginInfo-Depends= X-KDE-PluginInfo-License=GPL X-KDE-PluginInfo-EnabledByDefault=true

What do you think? So easy, isn’t it? If you have ever played a little bit with Ruby and Qt or KDE you should know enough to create your own plasmoid within a quarter of an hour!

Warning: rant follows.

So today at the ‘release party’ in Toronto (I use this term in the loosest possible sense), certain KDE developers decided to have a go at me for my refusal to use KDE 4 in favour of KDE 3. Admittedly one of them was particularly drunk after only a couple of pints, so I won’t take his input too seriously, but it did raise some concerns with the mentality I’m now (more often) seeing within the KDE community that I never used to see.

For me, KDE always stood for being free to do whatever you want. Surely that’s the philosophy of free software as a whole? If I want to use my machine to herd cats in my garden whilst terrorising them with a giant torch? Sure [0]. If I want to make my desktop look like other, well down, proprietary desktop environments - why not? You get my point.

However, today my objections to KDE 4 were met with an unbelievable barrier of closed-mindedness. For example; I use bitmap fonts with my terminal. Why? Because at small font sizes (read: 6px high) I’d rather have my supremely readable bitmap font that I’ve been using for aeons than some scaled one. But Konsole4 I’ve found does not like to play nicely with bitmap fonts (admittedly this may be fixed by now). The unanimous answer from the KDE developers present? “You’re an idiot for using small fonts - it’s totally pointless”. Wow, way to go for the whole “free to do what you want” thing. I’ve also just done a quick benchmark and found its scrolling speed to be significantly slower than Konsole3’s. [1]

Second gratuitous example; I do not like desktop effects. They annoy me. I do not enable composite. I’m entitled to this opinion. Furthermore, it seems that enabling desktop effects increases power consumption. I spend a lot of time away from power (for example: at shooting ranges), and wish to maximise my battery life accordingly. Again, I was greeted with comments such as “why do you need to have good battery life?”, “it’s a ridiculous use case because you’re never away from a power socket for that long” and “you’re a corner case” (referring to the rifle range example) [2]. Nice to know that apparently wishing to minimise power consumption is a corner case now.

I was also greeted with a barrage of what I can only describe as sheer stupidity when I explained that I do 99% of my work in a terminal. This is also, apparently, frowned upon now.

Has KDE now become a desktop environment only useful to people whose usage patterns fit with what KDE prescribes as acceptable? Is there some sort of judge now in KDE who is able to decree whether someone’s usage pattern is “acceptable” or not? I do hope not. [3]

Very disappointed. [4]

[0] - OK I don’t actually do that, for a number of reasons really.

[1] - http://lwn.net/Articles/88249/; Konsole3 on my machine whacked out the whole thing in about 30s. Konsole4 (SVN trunk from a few months ago) took nearly 2 minutes. Both used the same font.

[2] - A fine example of deliberately missing the point to try and win an argument; the case of “wishing to extend battery life” is not a corner case. Mine is simply a specialisation of that.

[3] - To be fair, I am unfairly extrapolating the views of some KDE developers to the entire community, which I know does not as a whole think like this. But other people may not be so understanding. Fix it.

[4] - I don’t actually care all that much about KDE 4 as I’ve assessed it for my needs and have concluded it does not fit my requirements as well as KDE 3 does. I’m sure it’s fine for a lot of people. However, as stated at the beginning of this rant, I am somewhat dismayed with the direction the mentality of an increasing number of developers is taking. Just accept that I don’t like it, and sod off.

Edit: due to popular demand, comments are now enabled. Flame away.

Howdy, The official release notes for this release can be found at here . KDE 4.3.5 the last bugfix release in 4.3.x series. It was not planned to have KDE 4.3.5 in our Ports Tree, because we, the FreeBSD KDE Team spend all our energy to port KDE 4.4 release. But we thought it would be good to have it in [...]

(EDIT: For the uninitiated, Ubunchu is a free-licensed manga series thematically centered around Ubuntu Linux, and this is a review of the fourth chapter of said series cum my musings on the viability of free licenses when applied to artwork. I apologize if I have previously confused anyone by leaving out this introduction )

(EDIT: I can’t believe I forgot the link to the manga again!! You can find every translated chapter of the free-licensed Ubuntu-oriented manga here)

With every chapter so far thematically alluding to one Ubuntu / free software related idea or another, Ubunchu is starting to feel somewhat like a documentary. Reminds me of one of those “Manga guide to Databases” things. And that’s not a bad thing by the way

Anyway, this chapter is about free licenses. As usual we have a simple story involving our three main characters woven around the idea being introduced. The story is nothing noteworthy and can be leisurely consumed as lightweight entertainment, but I think Ubunchu has brought up something rather interesting this chapter. Free licenses are no foreign concept in the world of software, and free software has more than proven itself in the past decade or so. However when applied to broader realms, like artwork as in this chapter, things are a little more muddled.

Does it make sense to apply free licenses to artwork?

The question is much more grey than it is with source code. It is still philosophically appealing, of course, to think of works of art as celebrations of humanity that should be freely shared, admired without restrictions, and collaborated upon where possible. But, as Akane notes, “It’s Risa’s hard work, you know.”. Being products of talent, inspiration and hard work, it’s natural to wish to maintain a kind of ownership over it. Especially with the amount of plagiarism and theft of work going on nowadays. One could argue that this is to a certain degree the case with software as well, but with software the benefits of releasing your code is clearer. Source code is much more malleable than artwork is, and a shared, community developed piece of code can clearly be leaps and bounds better and more powerful than a piece of code maintained by even the most brilliant of programmers. It’s hard to argue the same case with artwork.

I did find the following conversation interesting though:

And not just for the perverse pleasure of watching Risa getting terrorised What’s noteworthy here is that Masato is right! Japanese otaku subculture is, unwillingly and unwittingly, the closest thing we can find today to a culture of freedom involving artistic works. And you know what’s interesting? It’s thriving – somewhat at the expense of the actual industrial players, but there is little doubt that the subculture itself is today as resilient, diversified, and far-reaching as can be. It isn’t coincidence or luck too. Why is anime a culture when Holiwood isn’t? When you trace it down to the ground the only reason anime cons are possible today is that you don’t need to ask permission or pay royalties for dressing up as characters of a copyrighted work, for singing copyrighted songs, and for displaying and selling blatant (but excellently done!) spinoff artwork and stories. The only reason I can adorn my wallpaper and this blog with tributary decorations to my favourite animes is because doujin and vector wallpaper artists aren’t being regularly persecuted. In fact the only reason we unenlightened gaijins are even able to regularly talk about the latest shows and manga chapters is because of the hard work of our faithful, legally dubious (but fantastic!) fansub/scanlation groups. Japan’s inability to keep a legal iron fist over the consumers of the industry has ironically empowered the subculture to spread freely across every nook and cranny of the world that the internet is able to reach. It has also allowed the culture to scale beyond the professional works themselves into a wildly diverse pool of literature, fan-works and spin-offs of jaw-dropping quality. And all these, offsprings of the subculture and the freedom that permits their existence, in turn contribute to the color and captivity of the culture itself, taking it further, bringing in more consumers, more contributors.

When you look at it like that, it’s almost just like what happened with free software. Could it be?

It’s still a push to make that claim of course, especially since we know that the heart of the otaku subculture – the producing industry itself, is falling on hard times, being unable to quite adapt to the free nature of the culture. The challenge would probably be to see if a critical group of companies – then again they may not need to be companies, organisations – is able to sustain itself while riding the currents of freedom. To some extent the industry is already adapting – leveraging the doujin/niko-niko culture to identify and poach promising artists whose works they could publish and sell. The story of Supercell in particular impresses and inspires me. It’ll be interesting to see where this goes

And oh shit, I went completely off tangent with the review – AGAIN. Well, I guess I don’t really have too much more to say about the chapter (unless you want to hear me RAGE about lack of Slackware-Infatuated, CLI-wielding Geek Tsundere-chan action!).

Nice that Risa decided to go through with releasing her work after all of that. It can get ugly, but it could also prove very rewarding. Especially in communities like Linux’s where people tend to appreciate their allies more

Wonder when the next chapter will be out, and what the next item in the documentary will be. Until next time

(EDIT: decided to try having this syndicated at Planet KDE and see if I get blown to bits xP)

So… I brought up activities on plasma-devel again the other day. One of the reasons for this was that I noticed the word being used in a few different ways – mainly by me – and wanted to clear up confusion.

Well, it turns out I was the source of that confusion. :) What I’ve been referring to as “Activities” should actually be called “Context”. That’s what aaron was calling it, months and months ago, and somehow I remembered the word as something completely different and was avoiding it. Oops. So, when you read my old blog post or see my presentation from campkde, just replace 99% of the times I say “activity” with “context”.

Some other good things came of that discussion, but I have several essays to write so I don’t feel up to doing a long blog post on top of it all; either I’ll blog next week, or after we’ve discussed it at tokamak. :)

So, just to be extra clear: an Activity is a group of widgets on your desktop (what developers call a desktop containment). Context is all the stuff you need for what you’re doing right now (windows, files, etc). And if you only have one monitor, chances are you’ll have one Activity per Context anyways.