Tag Archives: Linux

KDE Marketing Sprint – Day 2(?)

Posted on by

Well, there wasn’t a Day 1 for me (I got to the hotel too late to follow the first day of the meeting), so that is why I’m starting on day 2. To start, I need to say that I had never been to a sprint before: I am already accustomed to meeting for real someone from online, but for all the attendants, they had been just names or nicks on IRC. That means I was a bit nervous.

The first encounter worked out pretty well, actually. I went with the others to have a dinner out, and I got to talk to “famous” KDE people such as Troy, Lydia, or Jos. I also had the nice opportunity to meet up with my fellow forum administrator neverendingo, and we discussed a bit on how to improve the forums. In short, the evening was really nice. I even got to see a N900! I thought I’d never see that. A very nice piece of hardware, I’d say.

The following morning, aside a little incident (the other people forgot about me!) I walked up to KONSEC where the meeting was held. While Cornelius led the discussion (the Dot will have more details in due time), I worked on helping out with a promo booklet the team is making. I’m used to writing, but writing in an appealing way to a less specialized audience is much harder. Thanks go to Jos who got me on the right track.

Then part of the people moved to another room to discuss about getting new contributors to KDE while I stayed with Jos and Stuart to work on other material. It was a little draining, but very productive overall. I am actually happy to be part of this, for a change, rather than passively reading about it on the web. It’s nice to give something back to your favorite project, as little as may be.

Lastly, we went out for a dinner in an Indian restaurant (nice food, not too much though), and we went back (with Eckhart showing us innovative ways to get back by changing multiple subway trains). And here I am, writing a small report of this day.

It’s been a very positive experience so far. I finally saw more people who use KDE, and they’re also both fun and nice. Now it’s time for bed, I still have a good half of a day for work before I get back.

danbooru2Nepomuk – a Nepomuk tagger for Danbooru images

Posted on by

If you dabble with anime and related things like I do, you may have heard about imageboards. A known variant, which powers sites such as moe.imouto (some links may be NSFW) or Konachan, is Danbooru, a Ruby on Rails application. One of the characteristics of this software is that images stored there can be tagged to be identified as precisely as possible: common tags are for example the magazine where the image was taken from, the characters depicted, and so on.

Once you save the file, however, all the tags are just present in your file name, and nowhere else. LIke that, they’re not that informative. That’s where danbooru2nepomuk comes into play. danbooru2nepomuk is a small Python program that can turn the tags present into the filenames into real semantic tags.

Requirements

As of this post, danbooru2nepomuk works only on Linux, so if you are a Windows user, you’re out of luck. Also, it requires a KDE (tested with version 4.3.1).

danbooru2nepomuk is a Python program, so it requires first of all the Python interpreter, version 2.5 or later. It has been developed to use the Nepomuk semantic desktop framework present in KDE, so you’ll also need PyQt4 and PyKDE4, along with a working Nepomuk installation. Most distributions use the broken Soprano redland backend, which will not work, so I suggest you to switch to the sesame2 backend, which (although dependent on Java) works reasonably well.

Download and installation

Simply get danbooru2nepomuk.zip, rename it to .py from .zip, save it in your PATH, and make it executable. Nothing more than that.

Usage

danbooru2nepomuk is a command line appplication. Its syntax is simple:

danbooru2nepomuk.py [-r] <file or directory>

If you specify a file, it will be tagged directly; if you specify a directory, it will be scanned for files, and those in turn will be tagged. If you add the -r switch to a directory, it will be scanned recursively, while it will be simply ignored if you use it with a file.

Configuration

You can specify a tag blacklist for tags in the filename that you don’t want to get in. To do so, edit the TAGS_BLACKLIST variable on line 41, and add more tags you don’t want Nepomuk to pick up.

Known issues

None that I know of, at least! If you find any, let me know.

danbooru2nepomuk is licensed under the GNU General Public License, version 2.

Interesting plasmoid: Drop2Tag

Posted on by

While browsing around kde-look.org, I’ve stumbled upon a nice little Plasma scripted widget, and I’m publishing this to have it get more exposure.

A good part of the KDE community knows at least little about Nepomuk, and its ability to attach semantic tags to your files – basically words that describe the file, be it an image, a text document, or anything you’d like. For example, you could tag all the photos from your vacation with the name of the place you’ve been. After that, you can recall tagged files by accessing the nepomuksearch://hasTag:TAG_NAME url in Dolphin or Konqueror (there are more advanced uses, but I won’t cover them here), where TAG_NAME is your tag.

Up to now, the usual way to tag files was to either select them in batch and add a tag, or do them individually, then click “Add tag”, then select the tag or create a new one. It was kind of laborious, although not too complicated. And that’s where Drop2Tag comes in.

Drop2Tag in plasmoidviewer

Drop2Tag stays in your desktop, configured for one of your Nepomuk tags. Then, you just need to drag files to it to have them automatically tagged. Also, clicking on the big Nepomuk icon will open your file manager with the nepomuksearch://hasTag URL with the selected tag. Neat.

The plasmoid is written in Python (I’ve taken a look at its source) and despite being very early in development, it already does the job very nicely – I have put one on my “Graphics manipulation” desktop activity to tag photos and images. A nice addition would be to select the tag from the plasmoid itself, rather than using the configuration option – it would make things much more flexible. Perhaps a Plasma.ComboBox would do the job here.

In any case, I’d like to congratulate its author (nik3nt3) for a job well done.

Scripting languages and KDE

Posted on by

Up to now, the main language in which KDE applications are developed is C++. This is a perfectly valid choice: however, at least for users that don’t have a computing background (I include myself in the list: I do science) C++ can be a rather steep requirement (although Hans, fellow staff member at the KDE Community forums, is doing a nice job in explaining his learning experience).

Scripted language bindings (that have a lower barrier of entry) for KDE exist: on top of my memory I can list Python, Ruby, and C# (and I’ve probably missed a few). Despite that, the only official non-C++ programs that are in KDE’s SVN currently, including only what’s in the official modules, are system-config-printer-kde and printer-applet, which are written in PyKDE. This is quite striking to me, because the language bindings allow full access to the API in kdelibs, and thus allow the creation of applications with (theoretically) less effort on part of the writer. Yet, such applications, despite the bindings being rather mature, are lacking.

Why is so? By applying Occam’s razor, Ithink that this is because most of the current KDE contributors are C++ coders. I seem to recall, though, a debate when system-config-printer-kde and printer-applet were introduced, where discussion arose between “pro-scripting” people and “anti-scripting” people. The major complaint is of course performance, as scripting languages are rarely at the level of C++. Still, I think that a more diverse language ecosystem would benefit KDE by making possible the arrival of new contributors that are not necessarily well-versed into C++. In some cases, such as Plasma, having programs directly written in scripting languages is a guarantee of less crashes dn more security. In the end, KDE would really benefit from it.

Before someone flames, let me state that I’m not advocating a reduction of C++ based programs in KDE. Just more choice. FOSS is all about it, right?

EDIT: After reading Richard Moore’s comment I thought I’d clarify my point. It is true that core modules need to stay C++ only to avoid more dependencies in the chain, but at the same time I feel that KDE does not stress enough that you can write applications (that can live well outside the core, for example in extragear) in languages that are not C++. This can be a limit for contributions from people that “do not speak” C++.