Plasma Javascript Contest.

I'd forgive you if you thought this blog was dead.

(The Konqueror Userscript plugin is on standby, I do not have a KDE4 dev environment anymore and I do not really use Konqueror no more.)

I am entering in the Plasma Javascript Contest, so the focus of this blog will be on discussions about various oddities and problems of the plasma javascript api

Latest news from Konqueror Userscripts

Hi everyone. (anyone? :P)

(Read on to see a video of the Konqueror Userscript Plugin in action...)

I spent some time today to fix a few issues to the khtml_userscript plugin for Konqueror (think of it as GreaseMonkey for KDE) and it now works to a point where I think its usable.

The installer now works. It can be used with:

• The builtin binary "khtml_userscript_installer"
• Clicking the Tools => User Scripts => Install Script button in Konqueror
• Double-clicking a *.user.js file in dolphin / konqueror

Also there is a very dumb greasemonkey compatibility script that gets installed. Right now it does *nothing* but provides the few functions GreaseMonkey provide. At least scripts that use the GM_log() function do not throw any errors anymore... (All other functions are likely to fail)

Internally, we don't use KJS anymore. KHTMLPart now provides a very handy executeScript() function. Basically the Konqueror Userscript plugin is simply an UI on top of this method...

Lots of issues remaining though: the status bar icon is not deleted so after browsing for a while you'll see 20 instances of the icon. Also the "Manage User Script" is still read-only (it shows the good information but no editing works).

For those of you who wonder what exactly is khtml_userscript, I made a small screencast that shows a few features. You can see it below, some explainations will follow...





First I install a user script from the konqueror "Tools => Konqueror UserScripts" menu. I install a script that was used in the previous example by neofreko. It highlights all link with a red border.

// ==UserScript==
// @name                KHTML Userscript (kuskus) Test
// @version             0.1.1
// @namespace           http://www.kde.org
// @author              Akhmad Fathonih
// @description         Change links in red, only for testing
// @include             *.kde.org*
// @exclude             *.google.com*
// ==/UserScript==

var elms = document.getElementsByTagName("a");
//alert(elms.length);

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

Then I install another userscript that acts on planetkde.org. In this one, all the image of class "hackergotchi" are replaced with another image and I add a h1 element at top of the page that says "Planet Thumbs Up!"

// ==UserScript==
// @name                KHTML Userscript Test in PlanetKDE
// @version             0.1.1
// @namespace           http://www.kde.org
// @author              Mathieu Ducharme
// @description
// @include             *.planetkde.org*
// ==/UserScript==

var imgs = document.getElementsByTagName("img");
//alert(elms.length);

for(var i=0;i<imgs.length;i++) {
     if(imgs[i].className == 'hackergotchi') {
         imgs[i].src = 'http://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Thumbs_up.jpg/420px-Thumbs_up.jpg';
     }
}

var h2 = document.getElementsByTagName('h2')[4];
var txt = document.createElement('h1');
txt.innerHTML = 'Planet Thumbs Up';

h2.parentNode.insertBefore(txt, h2);

Argh. I recently had to re-install my computer but totally forgot to backup the kde4 directory where I had a bit of uncommitted work.

This is a shame because I was *this* close to having neat stuff to show. Live & learn...

However a new little feature has been saved since last post, that is a strigi line analyzer for userscript file. It is in the khtml_userscript svn repository. Strigi is really cool to work with, however I chose not to include any Qt stuff and I must say that I missed QString's functionality. Not having Qt I remembered why so many people hate C++ :)

Still no work in the core, though. I had fixed the installer to actually work & be useful and started some work on the core / greasemonkey compat script but they're gone now :(

I also wrote a .gp4 (Guitar Pro 4) strigi analyzers for use in KTabEdit (the new, improved KGuitar) that was lost. I wonder if KFileMetaInfo actually feeds automatically from Strigi. If yes we could delete all the custom file-metadata-loading code and simply feed from KFileMetaInfo. Something to look for...

Sorry for the disorganized post, and lack of interesting updates.

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... (?)