How to test strigi analyzers?

Yea, a call for help on a blog...

If you remember the first post on this blog was about a nzb KFileMetaInfo plugin that I wrote. Lucky that I am, the entire KFileMetaInfo functions was dropped from KDE4 a few weeks later, superceded by strigi.

I am currently in the process of converting this plugin to a strigi based plugin, as well as a few other file formats (more on those later).

Although I would say the "barrier to entry" for strigi is a bit higher that for KFileMetaInfo, it is a very easy framework to work with. However, I expected metadata from strigi to be shown in dolphin, the new File Manager for KDE4.

But it's not. So far the only way to test strigi analyzers in the "xmlindexer" binary, which works fine but doesn't give a real sense of the purpose of it all.

So, where is strigi used in KDE4, and how do I see it?

Konqueror Userscripts - Coming soon to a KDE4 desktop near you.

Well I'm not dead, but I would understand if you thought I was, given it's been 5 month since the last post on this blog.

And (even better?), the KHTML Userscript plugin to provide Greasemonkey compatibility to Konqueror is not dead either. In fact, lots have happened since january.

I'll post new screenshots and maybe a screencast (since those are all the rage in kde4 these days... which is cool). For now, just some instruction on how to build it.

1. You should have a working KDE4 environment with kdebase, because you will obviously need konqueror.
2. svn co svn://anonsvn.kde.org/home/kde/trunk/playground/utils/khtml_userscript
3. cmake (cmakekde, if you run the scripts from techbase)

Please play around with the installer and test as many scripts from userscripts.org as possible. Right now there is *NO* compatibility layer so every GM_* functions from the scripts are very likely to fail, as well as anything using firefox-only functions, such as xpath.

If you want to help with these issues, let yourself known! :)

More work on Konqueror's User Scripts

I'm currently reading as much doc as I can on KJS, KHTML and related parts so I can evaluate what's needed for full GreaseMonkey support in the Konqueror User Script Plugin. I won't attack the "core" until I know exactly what I'm doing so I worked a bit on the "shell" (namely, the user interface)

Since the goal of this plugin (code named Kuskus, btw) is to replicate GreaseMonkey's functionality, the first step was to replicate its UI. GM basically offers 2 things:

• A Script Manager
• A Status Bar icon (which duplicates the "Tools" menu entry)
  

I thought the preferred KDE way of designing dialogs was to create .ui files, so I did. Here's the (final?) mockup:


I think it looks a bit more tidy than the original GM dialog. That's subjective, of course.

I also added a menu entry under "Tools". Right now it shows the script(s) that were activated for the page as well as the option to enable/disable the plugin.



So although it still is as dumb as before (only execute scripts) at least the UI front is progressing.

Next steps: the status bar icon, manager integration, and GHNS.

Userscript for KDE4

I love KDE. I use it every day, at home, at work, on the laptop, everywhere I can. The desktop feels right, Kate, Quanta, Amarok and others are just the best of their categories, and it's suuuper fast.

However I must admit Firefox is still my web browser of choice. I actually do prefer *using* Konqueror (faster, better UI imho), but when it comes to HTML/CSS rendering and JavaScript parsing, sometimes I just need to use Firefox. 3 reasons, really

• Better rendering of websites. I'm not saying Konqueror sucks, I'm just saying that web designers do not target or test for Konq.
• Better JavaScript parsing. While rendering feels much faster in Konqueror, JS code execution feels waaaayy faster in FF. Also, many scripts just work better. FCKEditor, amongst others
• Extensions. I actually don't care that Firefox has a million extensions, but three of them are now essential:
• AdBlock
• FireBug
• GreaseMonkey

Since 3.5, there is now an ad blocker plugin for Konqueror. Works great so far, hopefully the KDE4 version will support FilterSet.G -- Not a reason to use FF anymore

As a web developer, FireBug is a god-send. It turns Firefox in a very nice Javascript/CSS debugging environment. The next version will be absolutely amazing. Nothing close exists for Konqueror. Seriously, this is the best plugin ever. -- Until there is a similar tool, I will need to use Firefox at work.

Coincidentally, GreaseMonkey is also the best plugin ever. All it does is allow to run custom scripts on a given website. Why is that great? All those annoying behaviors on certain websites can be fixed with custom javascript, and their features can be extended. A gigantic amount of cool scripts already exists on http://www.userscripts.org

So I was *very* happy when I saw a small plugin appears on kde-apps.org that runs custom user scripts. Neofreko did a very cool job laying out the concept, for KDE3. Basically, a khtml plugin scans for js file in a given directory, parses their metadata and attaches the javascript to the page. Quite different from the actual GreaseMonkey plugin (which is written in XUL/JavaScript) but works none the less.

In all honesty, I couldn't compile it because of my broken Kubuntu installation so I thought, hey, why don't I just port this to KDE4/Qt4/CMake? Since the script was only a few lines it was quite easy and fast, and now there is hope for user script support in KDE4.

Here's a first screenshot of Konqueror (KDE4) running neofreko's sample script



Sample script:

var elms = document.getElementsByTagName("a");

for(var i=0;i
elms[i].style.color="red";
elms[i].style.border="1px solid";
}

This is still in "Proof Of Concept" stage; right now it simply executes any script matching the domain, it does not offer any of the GreaseMonkey functions (mostly, the cross-site XMLHttpRequest object) and is not optimized or secured in any form. But I believe both neofreko and I are committed to delivering this plugin and adjusting it to meet KDE's quality.

Our goal for now is full compatibility with existing GM scripts. It remains to be seen if it can be achieved.

It should appeared in KDE svn soon (watch for it in trunk/playground/base). Stay tuned!

nzb support for KDE

A few days ago I hacked a very simple plugin for KDE to provide support for .nzb files meta-information. It is a small kfile-plugin which I based on mpyne's torrent plugin (only mine is much, much simpler since the file itself is a simple xml)

It also meant that I created a small .desktop file to create the application/x-nzb mimetype so nzb file actually gets recognized as such by konqueror.

I basically took the nzb xml parser from klibido and adjusted it to parse only the info needed. It's not fast or optimized but I don't think it needs to be. The following (meta) information is retrieved from the file:

• Number of files
• Total Size
• Oldest File
• Group(s)

Here is a screenshot: wooooohaa.



I'll be commiting those changes in trunk/kdenetwork/kfile-plugins in the next days.

What are NZB files?
.nzb are "NewzBin Usenet Index" file. They are meant to reference usenet posting. Good tools for linux that supports nzb files are KLibido, nzbperl and hellanzb.

What's next?
Hopefully, support for those files in KNode as well as KGet... (?)