New in Fedora 7: xdg user directories [Update]

fedora-logo-bubble
One seldom mentioned new features of Fedora 7 are the new directories in the $HOME directory. These are due to the xdg-users-dir program from the Portland xdg project. In other news, Hello Planet Fedora.

When I started my fresh Fedora 7 install I found several directories in my $HOME i never saw before. Among them:

  • Applications
  • Download
  • Videos
  • Music
  • Templates

I was surprised because I haven’t seen that mentioned anywhere recently. But it was ok since I already knew that this was Portland xdg related. The directories are created by the xdg-user-dirs.

The xdg-user-dirs have the aim to create and also manage directories with pre-defined functions like “Music directory”, “Video directory”, “Documents directory”, and so on. These are also localized and are managed in the $HOME./config file.

If you want to change the pre-defined values simply modify the config file. If you want to delete a directory, point it to your home directory and afterwards trash the directory itself – in other cases the directories might be re-created.

In other news: Hello Planet Fedora! My blog has been added – well, at least the Fedora related posts. Thanks for that, I just hope that I can meet the readers’ expectations. We will see.
As a short introduction to these who are not familiar with me: In the Fedora world I am a small package maintainer who sometimes writes a howto or a bug report or tries to keep an eye on the German FedoraWiki. Outside of Fedora I also write about KDE and Linux in general. And that’s it, I guess.

Semantic Desktop and KDE 4 – State and Plans of Nepomuk-KDE [Update]

kde-logo-official
Nepomuk-KDE is the basis for the semantic technologies we will see in KDE 4. Sebastian Trüg, the main developer behind Nepomuk-KDE, provided me with some up2date information about the current state and future plans.

The Semantic Desktop describes the idea where users will not only be able to search existing information, but also to search for the meaning and relation of these information. The Nepomuk project creates open standards and APIs around this idea.
And Nepomuk-KDE is the implementation of these standards for KDE.

Nepomuk-KDE: Basics

Technically Nepomuk-KDE uses mainly RDF/S for storing the aggregated data. RDF/S is the standard for storing meta data for the Semantic Web and is therefore also used as the standard in the Semantic Desktop.
The current implementation of Nepomuk-KDE contains an implementation of an RDF repository which stores all the data. According to Sebastian the data can be accessed by DBUS which is the default way to communicate in Nepomuk-KDE (of course). But there are also other ways which might be more convenient to KDE developers:

For a KDE developer, however, it is much simpler to use the knepomuk library which provides convenience wrapper classes to access the repository.
Additionally there is the KMetaData library which is yet another wrapper library which provides easy access to the metadata by a resource-centric view. This is what is supposed to be used for implementing stuff like tagging or rating in applications.

The definitions (aka Ontologies) how the data like tags, comments and so on should be stored in the repository can be found in kmetadata/ontologies in KDE’s svn or in the directory $KDEDIR/share/apps/knepomuk/ontologies if you install kmetadata on your hard disk.

Last but not least, if you integrate Nepomuk-KDE with an application KMetaData can help generating code that hides all “nasty meta data type and property named and type conversion”. See the tutorial KmetaData First Steps at techbase. Also, have a look at the KMetaData apidox.

Besides these entry links and the homepage itself the best place to entry the development is, of course, subscribing to the Nepomuk-KDE e-mail list. Btw., one of the current topics is about a possible new, more catchy name for Nepomuk-KDE :)

Nepomuk-KDE: Current State

So much about the basics and development stuff – now to the sparkling bits:
In the current implementation Nepomuk-KDE enables the user to store additional meta data in form of tags, comments or ratings. See Nepomuk-KDE in action within Dolphin:

Nepomuk-KDE - Dolphin integration with rating

The music file is rated, has a comment and also a tag below the comment field. And this cannot only be done with music files but with all kinds of files:

Nepomuk-KDE - Dolphin integration with txt file

These comments and tags can be searched of course:

Nepomuk-KDE - search after environment in comment

Nepomuk-KDE - search after KDE 4 in tags

In the first image everything is searched for the term “environment” – and a file with a comment containing this string is listed. In the second search example the string “KDE4″ is searched, and the result shows files which are tagged “KDE4″.

So, finally, tagging has also reached KDE 4 – I must admit that I’m very pleased with this result because I’ve waited for tag support in KDE for much too long.

Nepomuk-KDE: Future

At the moment Sebastian works at a backend for strigi. The final goal is to share the data backend so that strigi uses RDF as well. This would create one single data pool for all meta data on your machine.

The next steps are to integrate Nepomuk-KDE further with the applications of the desktop: There is a Google Summer of Code project to replace digikam’s rating and tagging system with the one from Nepomuk-KDE. Amarok already has exactly the features supported by Nepomuk-KDE for all files (rating, tagging, comments) therefore it only makes sense to merge the data as well. And of course all PIM applications contain a huge amount of data which should be analyzed semantic wise: think of displaying not only an e-mail by a contact but also all related e-mails by other contacts and also all related files which were sent and received.
You can extend this list of applications with any program which needs or wants to store any kind of additional information to used or modified files.

Besides integrating Nepomuk-KDE into other files there is also work ongoing to bring other meta data to Nepomuk-KDE: while atm tags, rating and comments are supported there will be many more types in the future. As already mentioned above with the PIM example data can be grouped around discussions (which e-mail is a forward or reply to which) but also around origin (where does this file comes from and where have it been before).
Also, think of an image viewer which does not onl display the given image but also all images taken at similar times or with similar people on it (digikam supports this already with person tags) or even taken at similar places (geo tagging or identifying names like barcelona07.jpg).
And if you really dare to have a look at a possible but yet far away future: IBM, a Nepomuk partner, has text analyse tools which could be used to analyze the content of for example mails to get a better understanding of what the e-mail is really about.

And there are other things which have to be done as well: Data export, cooperation with other desktop environments, etc. For example, the Nepomuk project itself plans to create a P2P based solution for sharing files together with their meta data, and at some point in the future Nepomuk-KDE should implement this part of the standard as well.

As you see there are lots of things to do, and there is room for almost every kind of participation. Just send an e-mail to the developers list. You can also simply leave a comment at this post if you are interested, the developers will keepn an eye on the comments.

Update
Sebastian has posted a FAQ about Nepomuk-KDE, featuring also the question about x-attributes.

Howto: Sun Java on Fedora 7 [2. Update]

fedora-logo-bubble
For legal reasons Sun’s Java is not included with Fedora 7 yet. However, with a bit of effort you can install it in a sane way.

The stress is on “a sane way” because the different Java versions could interfere with each other. Also, if you do it the wrong way, your java might be upgraded to the new, Fedora own version gcj.

However, before you start you should be sure that you really need Sun’s Java: read the Java FAQ from the Fedora project and also the information about the current state of OpenJDK on Fedora.
Also, first look at the Current Issues mentioned below before you start following this Howto!

The main part of this howto is taken from Jpackage’s help pages, which are much shorter and not distribution specific.

Download and Install

Here are the steps you have to do:
Prepare your system by installing necessary build tools (yes, you do have to compile stuff, unfortunately): yum -y install rpmdevtools. Also, make sure the package jpackage-utils is installed, which should be default.

Afterwards, download the latest java-1.x.0-sun-1.x.0.x-1jpp.nosrc.rpm package from the non-free branch at jpackage. In this case I took the 1.5.0 file.
It is a source rpm file, therefore it will install itself into /usr/src/redhat/... if installed as root, or into the local package build environment if installed as user.
Afterwards, check the given spec file java-1.x.0-sun.spec which is in .../SPECS or similar but in your home directory. Again, in my case it was a 1.5.0 file.
Now you have to download the appropriate java bin file from Sun – and this can be a bit tricky. In the worst case check the mentioned spec file for any link (search for the string http) – in my case I found the needed binary here.
Take the SDK and download the binary, not the self extracting RPM, to the .../SOURCES directory. Make also sure that the minor numbers of the binary are ok with the numbers given in the spec file: in my case the binary had the minor version 1.5.0-12, while the spec file defined the buildver 11. Correct this if needed.

Afterwards, recreate the java rpm: rpmbuild -ba java-1.x.0-sun.spec. You should find your new java binary in .../RPMS/i586. If they are not there, something went wrong, and you should hurry over to the next Fedora specialized forum.

However, if it did work, you can now install them. There might be some dependencies, solve this by using yum:
yum --nogpgcheck localinstall java*.rpm
You need the no-gpg option here because your local created rpms are not signed, of course.

Configure your system

After the install your basic system should already be configured:

$ java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)

If this did not happen for any reason, change the default java system to Sun’s:

/usr/sbin/alternatives --config java

You also might want to install the Firefox/Mozilla plugin:

ln -s /usr/lib/jvm/java-1.5.0-sun-1.5.0.12/jre/plugin/i386/ns7/libjavaplugin_oji.so /usr/lib/mozilla/plugins/libjavaplugin_oji.so

Current Issues

This way has one current issue: the spec file calls the mkfontdir executable at the wrong place, resulting in an error during install of the java-fonts package. However, patching a spec file would go beyond this short point&click howto (although it is already a bit beyond that).

Update
For a working Java Web Start look at this posting. You might also want to have a look at the much shorter version of the pure Java post here by Avi Alkalay posted in the comments. However, no guarantee that it works.

2. Update
The FedoraFAQ has recently renewed the part about Fedora and Java. The way mentioned there could also work as an alternative for many people.