Qt and trees

I am looking for a class for storing and presenting trees with C++, at best I'd like it to be a Qt thing. But I need anything really. Great thanks for any hints.

Help Flash 9 on Linux !

Using a webcam in the crazy non-standardised world of linux ? Share the details of what mechanisms does it use with the Flash 9 linux developer on Penguin.SWF camera question
There are a bit of other questions, like which IME should be supported etc. Go check the Penguin.SWF blog out.

I wish Qt was LGPL

Or at least more free. There have been several buisness initiatives recently in which I acted as software design advisor. I was not involved in writing code, but my task was to make sure the software is good enough designed and that its creation process will not take more resources then needed.

All of them were about commercial applications, directed at companies, multi-platform, GUI, network transmission, different stuff usually B2B. Applications were not in fact what was the center of the product, they were just a way to transfer content effectively to clients. The protocol of the transfer was the biggest Intellectual Property behind them and the content was what companies later paid for. In fact the apps were going to be at least a sale good enough to bring back the investment. I was and I am even sure that in one year those apps will be a big hit in Poland among medium-sized and bigger companies.

So what does it have to do with Qt? All those applications were designed by students finishing the Universities, realising their ideas, etc, in short - they had a good idea, they are now going to turn into profit with help from a professional manager (not a student). The problem is, they do not have the money they are going to earn, at the moment they start writing code.

 To write it shorter: to start a company, get an office, buy computers with macos,win,linux, hire developers etc is to pay a lot of money students usually get from a bank credit. Those credits are not enormous, usually they are enough to cover the beginning with a 200$ margin.

Qt was ideal for all of those projects and believe me those projects would be able to pay for Qt lets say after a year (year is a good period becuase statistically companies that cant handle the market, die in around a year, also note that usually its after a year when company starts turning profit that can be used). But Qt will not be used. No project could afford buying Qt Commercial Licence at the starting moment. We sticked to wxWidgets and GTK2.

 Now here is something I do not get, why the hell won't Trolltech build some kind of a program for small, starting companies, that would give them commercial licence for their project free of charge for the first year. It is not stupid! A project developed with Qt that would prove a success and bring profit would mean that after a year Trolltech gets their money when the company buys a commercial licence for the next year (seeing as the application is already written in Qt, rewriting it just not to buy the licence would be stupid and no company would do that, really).

Trolltech would gain a client a happy one too! And a happy client is not only a client that will continue to buy the product but also a good marketing tool.

 On the other hand a company might not bring revenue after a year and bancrupt, well Trolltech would not loose that much in this situation right? It still does not get paid if the company does not use Qt.

 

Who knows maybe someone from Trolltech reads this and next time I am asked for advisory I can tell the company: hey, Trolltech's got Qt, best toolkit there is and they are giving you a hand at starters!







 

gocr, optical recognition and oKular

So i sat down this evening and investigated the possibility to use gocr as a fallback for getting the text layer of a document in oKular (for example if the backend does not support generating text layer information). To let things be clear - gocr is not ready, to say the least. Personally I'd even say the effect of trying to OCR a page is so crappy it is not even worth installing the gocr engine (seems like the total rewrite in 0.40 did not help much). And I am talking about an ascii black text on a white page, without other elements. Gocr seems to go all the way down here - error in 98% of recognized characters, randomly added spaces, etc. For example: content is C unrir in gocr, sounds like drunken elvish to me.

So at least for now, it is not worth it, no OCR in oKular - opensource does not have good, working OCR software yet.

UPDATE: I also tried ocrad, which is advertised as good for latin1 only bitmaps. 3 out of 2400 characters in the probe were correctly matched, content here is C_ll_ICll_ - sounds like a totally drunken elf wih heroine injections.

New feature ideas

Ever used Acrobat Reader and felt it missed something badly?

Ever wanted to be able to do something with a document and your viewer didnt allow it?

Have an idea for a feature the KDE 4 document viewer should have?

Tell me about it! The sooner you tell me the bigger the chance you'll see it in KDE4 are.

Hot New Features!

Having completed most of classes this semester I had some time to hack oKular. I am developing new features mostly alone - Eros is offline since his laptop burnt in August and Albert is helping porting kdelibs to Qt4 and in spare time backports bugfixes to oKular from kpdf 3.5 - therefore the ratio of new features per month is not as high as I would love it to be. It is not low though.

oKular got three new features:

Overview mode

Another viewing mode - you can specify how many rows and columns the Page View can have. Plus you can have a continous and a non-continous one. Useful for looking through the whole pdf in a hasty manner or just checking whether all pages of a print are ok.

Editor-like text selection

Ever bothered the select tool was just too big for what you wanted to select? Editor-like text selection is the thing for you. It feels like kate ;) Plus in the future i'm going to add selection of images too and later Richtext copying to clipboard :) Yay oKular!

Hardware blending!

Yes, since KDE4 is for now a bit far away, oKular uses XRender directly to create the alpha-blended selection rectangles. Now selection is faster then ever. Thanks go to fredrikh for giving me an idea on how to implement it. oKular could damn use Qt4, but I will blog about it later today.

Postscript support is back

Well not a new feature as it already existed, but now with libqgs separated and cleaned up (and released), it is faster then ever! Sometimes even faster then pdfs.

Here is a sample of what all the features together look like.

oKular beta1 'monoKle'

API work

While working on oKular I faced or was asked to consider a list of things the file format handling generator/backend might need. First problem was search, kpdf when branched did not have a page abstraction class, it did not handle searches between the lines too, it could only search for words on the same line.

Page abstraction

So the first thing I wrote was the page abstraction class, which holds a vector of text entities and implements the search functions. Text entities are a character or a set of them with a rectangle box describing a normalized ([0;1] coordinates) position on the screen. The text entity class has also information about whether new line follows this entity (used for getting the text for given coordinates) and the standard rotation and baseline data. The search algorithm is quite fast and includes a simplifying function when returning a result.

The result is a regular area, which is a finite set of normalized rectangles that describe positions of the found words. The great thing about it is being a template which can be used for virtually anyobject, or even for regular areas if we need regular areas of different shapes! Don't you just love object oriented coding ?

Information pushing

How should the file format backend inform the program about an error? Or maybe it would want to display a message or a warning. It is a simple as emitting a signal now! The user can configure whether he wants the messages displayed using kpdf's supreme popups in the page view or a standard KDE message/error/warning box (the latter not included in beta1).

Settings

Support for generator settings is easy when you think about allowing to set settings only when the generator is loaded with the document, but what about allowing to configure all backends at all time? The solution was simpler then I thought but at a cost. All the generators that have settings support are loaded if user chooses to configure them, later if the user opens a filetype and a generator for it is already loaded, its not loaded again - just reused. Who would have thought it would be that easy.

Adding pages to the configuration dialog is done by the generator in Generator::addPage(KConfigDialog *).

Intercepting the event of the page and adding components to the GUI

The need for a possibility to intercept the events, such as a right mouse click, in the page view was reported by Wilfred Huss of kviewshell. To be generous, I am allowing the generator to intercept nearly all events page view receives, just reimplement the bool Generator::handleEvent(QEvent *) function! Return true if the page view should parse the event itself after your function finishes.

Adding components to the GUI was another important aspect, the most important GUI items in kpdf are the QToolBox in the navigation pane and the menu. You can specify an XML menu layout that is to be merged with the standard menu by subclassing the newly added getXMLFile function, while the QToolBox and KActionCollection objects are available to the generator in setupGUI (QToolbox*,KActionCollection *).

The Ghostscript generator for Postscript

The next deliverable I pointed in the SoC proposition for Google was a backend using Ghostscript. I admit taiming Ghostscript library (libgs) was hell. A partially documented API along side with some typos (like sending void** instead of void*) and the library having a C object API made it really no fun. But with help of ghostscript developers (great thanks to ghostgum of #ghostscript, the author of the API) I managed to understand how it works and wrote a perfectly good wrapping class. The road was harsh though, as ghostgum lives in Australia and I live in Poland, so it usually ment to me no sleep at night if I needed to talk to him.

Asynchronous renderer

The asynchronous renderer based on ghostscript is the first fully synchronous generator in kpdf. libgs was not thread aware and did not allow more then one instance in the generator, reusing the synchronous renderer was too slow for me to accept so I wrote a helper application that uses the wrapper class to generate a pixmap and uses X11 functions so do an ultra fast transmission of the QPixmap. The asynchronous renderer is a masterpiece, the wrapper around it includes even asynchronous killing of the no longer used instances of helper apps. I'm proud of it.

Finally one night i managed to overcome the problems.

• 18:27 30th of July - The libgs wrapper works, does not receive the pixmap properly from Ghostscript


• 03:27 31st of July - Broken receiving after enabling alpha channel, disabling it.


• 05:00 31st of July - First close attempt after understanding the format of the pixmap.


• 31st of July - Second attempt with the alpha channel being broken.


• 14:00 31st of July - First correct attempt, third times the charm.


• 18:00 31st of July - Working synchronous generator without antialiasing.


• 19:00 31st of July - Working synchronous generator without antialiasing.


• 19:00 13th of July - A screenshot of a fully working asynchronous and sychronous generators with antialiasing and Ghostscript message window.

Replacing kghostview

oKular is now a full replacement of kghostview without support for PDF files, which is easy enough to implement later. The replacement in KDE4 will close 90% of kghostview bugs, which kpdf implemented earlier like review support or better navigation panel.

No text search support

Unfortunately there is no currently available solution for postscript searching, pstotext handles only some PostScript files and does not work with anything other then latin1. Also note there is no such thing as encoding in PostScript, it uses a set of glyphs and when more are needed the unneeded ones are removed and new ones are added, locally on page, so the encoding migh change several times inside a document. Currently there is no sane possibility to work this out.

Ghostscript library

To use the Ghostscript generator you need a Ghostscript compiled with shared library. To do it manually, take the sources and after configuring do:

make so

and to install

make soinstall

A list of RPMS with libgs can be found here. Debian does not currently provide any package with libgs.

Make sure you have it in your library path because using the --with-gs-library switch does not work yet (no idea how to add it to the list of directories checked by KDE_CHECK_LIB).

oKular Beta 1 "monoKle"

I am releasing oKular SVN revision as beta 1. It should work correctly with PostScript, Image and PDF files. For now my working version includes CHM support I did not put in this beta, due to some pagesize calculation problems. The CHM support is based on the chmlib wrapping code from kchmpart (three files actually), I did a few changes to make it usable in oKular, wrote the code that uses khtml to render the compressed html pages myself. Beta 2 is planned for mid October, when I have most of the kviewshell plugins ported to oKular. So get: the tarball for oKular beta1 'monoKle' Do not report this to slashdot. If the server gets slashdotted, there will be no betas and you'll have to wait until KDE4.