Andreas
Uncategorized
Aggregated
Posted by Andreas
 in Uncategorized, Aggregated
 on Tuesday, February 05, 2008 @ 17:36

On my way home from work today, I somehow found myself in an awkward situation, laughing as I saw an elder man that I don’t know hit the ground with a thump. Didn’t look too serious, but it most certainly hurt, and it really made my day. Hehe! A wonderful sense of euphoria went through my body as I wondered whether or not I should flip a coin into the air towards this unfortunate fellow, for reasons that probably wouldn’t strike your average observer as being glaringly obvious (in contrary, for also-oh-so-unobvious reasons this might have been perceived as a very rude thing to do, but I don’t quite know why).

So it all started when I was humming and strolling through the streets, past the shops near where I live. Sometimes I enjoy looking at all the funny people around me, at the silly signs people put up outside their stores. I decided to take a trip into the indoor mall. As the weather is pretty harsh sometimes in this country (rain/snow/wind) the mall has this double set of automatic glass doors, mounted like the sluice in a shape ship, to make sure cold air doesn’t get in, and warm air doesn’t get out. So anyway. As I close in on these doors from the outside, I suddenly stop up, and realize that the doors open very slowly today. They’re set up at about half speed. Probably because weather has been bad. I think, “That’s funny, hehe”, and then I continue walking in once the doors are completely open.

Please Spare Some Change

Now, as I’m on my way out again after buying a bag of raisin buns, I see two teenage girls approaching from the outside, all poshed up and chatting like teenage girls do, and suddenly I hear a loud “Bang!” as one of the girls has managed to bang her forehaid on the door as she walked in. “Hehe,” I found myself bursting out aloud. Her reaction was to give me, and then the half-open door the evil eye before shouting “Fy F#¤N i H#”#¤e, er det muuulig!?” [*] And so her friend naturally immediately concurred, “Ja fy f#¤n er det mulig.”

This is truly the age where on one side of the street, your average lady is facing a closed door, and blinking her eyes, hoping that that’ll remove this funny obstruction which she hasn’t encountered before. The door, on its side, is presenting its knob as best it can, wishing it could just say “Here!!! it’s right here!! it’s a KNOB!! you can use it to open me!!”. Your average guy walks straight into the shop window (i.e., that glass thing with no handles, next to the door) BANG, and curses the heavens above, rubbing his forehead and rushing away. These people are angry and upset with a wooden board, or a sheet of glass, failing to meet with their absolute requirements of not being in the way. Ah, astonishing.

And so it happens. Within two seconds after the last girl had just caught her breath, the guy, a man whom I do not know, walks BANG right into the same half-open door. The door did not open (with the speed that he was expecting). His predicted trajectory intersected that of the door-which-moveth-too-slow. ;-) This was an underperforming lame excuse for an automatic door. And so, he fell backwards, dropped his two bags, and whammed into the ground, and of course, he too, cursed out loud, and angry.

And I laughed. I’m evil. I’m sorry. I laughed out loud. :-D

[*] The first girl’s outburst translates to “Oh, darn you bad devil from hell, is this not completely stupid, if at all possible?!?”. The other girl’s response would be something like “Yeah, I soo agree darn, you bad devil, it’s quite stupid, and not likely possible at all.” :-D Norwegian teenage cursing is great fun :-D.

Bradley T. Hughes
Qt
Aggregated
Contributors
 in Qt, Aggregated, Contributors
 on Wednesday, January 30, 2008 @ 06:00

The news about Nokia’s intentions to acquire Trolltech is very exciting and sobering at the same time. I would characterize my own opinions and thoughts as “cautiously optimistic.” As Trolls, we are still digesting the idea, discussing it amongst ourselves, and processing the incoming information from our own management team as well as the information from Nokia.

I hope that our community, both commercial and open-source alike, don’t get too distraught about a seemingly quiet Trolltech team. We, like you, just found out about this yesterday morning and need time to absorb what this means for us, for you, for everyone. After everything sinks in, we will come out with more information in the near future, and we appreciate your patience until then.

Rest assured, Nokia has the best intentions in making this move. More information will be available soon., however the message from Nokia is clear: development, sales, open-source and community support, etc. will continue as usual. Lee Williams, Senior VP, R&D at Nokia, told us Monday that Nokia wants us to teach them how to do cross-platform and open-source development on the desktop (and not just on mobile phones). This is a bit of a special acquisition because both Trolltech, in its current organizational form, and Nokia will be working together on what the future will bring.

englich
Uncategorized
Aggregated
Posted by englich
 in Uncategorized, Aggregated
 on Tuesday, December 11, 2007 @ 14:12

I have not yet seen an API for XQuery in which integrating the data model, atomic values, nodes and all, into the interfacing language has been a walk in the park.

At the top of the list of things people tend to ask on the forums around is “How do I get XML represented as a sequence of bytes in Java/C++ into my query?”, whose result is clear — a tree fragment for the query to operate on — but whose method for reaching is not that given if you ask me.

There is no “bytestream” type in XQuery. Should the user build the tree herself and then pass the tree to the query? Should the implementation in some voodoish way be instructed how to treat a string or custom type? Shouldn’t the query engine do it such that its scope of analysis is increased and its done the way it prefers it?

What I sense have been the problem with some solutions is that they mix the data, the bytestream, with interpretation.

In Qt this manifestate itself with that the content of a QIODevice should appear in a QXmlQuery. The way it’s now provided, is that when a QIODevice is bound to a variable using QXmlQuery::bindVariable(), the query sees a URI(an instance of xs:anyURI) which behind the scenes maps to the QIODevice the user bound. Hence, if the purpose is to build an XML document, one passes the URI to the builtin fn:doc() function.

I hope this is clean. Since it’s handled like any other URI, custom extensions stays at a minimum, error reporting is consistent, and the interpretation hasn’t been coupled with the data. For instance, later on I hope to merge in support for XInclude and XQuery Update, and in those cases the URI is again simply passed to for instance fn:put().

One can weight quite well on URIs and the abstraction the XPath Data Model provides, it seems.

Bradley T. Hughes
Qt
Labs
Aggregated
 in Qt, Labs, Aggregated
 on Thursday, November 22, 2007 @ 13:54

A couple of years ago (3, to be exact), my girlfriend and I bought a house about 45 minutes outside of Oslo. The little village is just far enough and small enough to not get cable TV. So, that means we have to have satellite. I consider myself a lucky geek, because my tuner runs Linux.
Read the rest of this entry »

englich
Qt
Aggregated
Patternist
Posted by englich
 in Qt, Aggregated, Patternist
 on Thursday, November 15, 2007 @ 10:52

People have asked for Qt’s XQuery & XPath support to not be locked to a particular tree backend such as QDom, but to be able to work on arbitrary backends.

Any decent implementation(such as XQilla or Saxon) provide that nowadays in someway or another, but I’d say Patternist’s approach is novice, with its own share of advantages. So let me introduce what Qt’s snapshot carries.

<ul>
    {
        for $file in $exampleDirectory//file[@suffix = "cpp"]
        order by xs:integer($file/@size)
        return <li>
                    {string($file/@fileName)}, size: {string($file/@size)}
                  </li>
    }
</ul>

and the query itself was set up with:

QXmlQuery query;FileTree fileTree(query.namePool());
query.setQuery(&file, QUrl::fromLocalFile(file.fileName()));
query.bindVariable("exampleDirectory", fileTree.nodeFor(QLibraryInfo::location(QLibraryInfo::ExamplesPath)));
if(!query.isValid())
     return InvalidQuery;
QFile out;
out.open(stdout, QIODevice::WriteOnly);
query.serialize(&out);

These two snippets are taken from the example found in examples/xmlpatterns/filetree/, which with about 250 lines of code, has virtualized the file system into an XML document.

In other words, with the tree backend FileTree that the example has, it’s possible to query the file system, without converting it to a textual XML document or anything like that.

And that’s what the query does: it finds all the .cpp files found on any level in Qt’s example directory, and generate a HTML list, ordered by their file size. Maybe generating a view for image files in a folder would have been a tad more useful.

The usual approach to this is an abstract interface/class for dealing with nodes, which brings disadvantages such as heap allocations and that one need to allocate such structures and hence the possibility to affect the implementation of what one is going to query.

But along time ago Patternist was rewritten to use Qt’s items & models pattern, which means any existing structure can be queried, without touching it. That’s what the FileTree class does, it subclasses QSimpleXmlNodeModel and handles out QXmlNodeModelIndex instances, which are light, stack allocate values.

This combined with that the engine tries to evaluate in a streamed and lazy manner to the degree that it thinks it can, means fairly efficient solutions should be doable.

So what does this mean? It means that if you would like to, you can relatively cheaply be able to use the XQuery language on top of your custom data structure, as long as it is somewhat hierarchical.

For instance, a backend could bridge the QObject tree, such that the XQuery language could be used to find Human Interface Guideline-violations within widgets; molecular patterns in a chemistry application can concisely be identified with a two or three liner XPath expression, and the documentation carries on with a couple of other examples. No need to convert QWidgets to nodes, or force a compact representation to sub-class an abstract interface.

A to me intriguing case would be a web robot that models the links between different pages as a graph, and finds invalid documents & broken links using the doc-available() function, or reported URIs that a website shouldn’t be linking to(such as a public site referencing intranet pages).

Our API freeze is approaching. If something is needed but missing, let me know.

englich
Qt
Aggregated
Patternist
Posted by englich
 in Qt, Aggregated, Patternist
 on Tuesday, October 23, 2007 @ 09:26

Attention to details is ok, but compiler messages has historically not received it. Here’s an example of GCC’s output:

qt/src/xml/query/expr/qcastingplatform.cpp: In member function 'bool CastingPlatform::prepareCasting():
qt/src/xml/query/expr/qcastas.cpp:117: instantiated from here
qt/src/xml/query/expr/qcastingplatform.cpp:85: error: no matching function for call to ‘locateCaster(int)’
qt/src/xml/query/expr/qcastingplatform.cpp:93: note: candidates are: locateCaster(const bool&)

Typically compiler messages have been subject to crude printf approaches and dignity has been left out: localization, translation, consistency in quoting style (for instance), adapting language to users (e.g, to not phrase things preferred by compiler engineers), good English, and just generally looking sensible.

To solve that it requires quite some work, and that’s probably the explanation to why it often is left out. To have line numbers, error codes, names of functions, and whatever available and flowing through the system requires quite some plumbing and room in the design.

Another thing is that nowadays we really should expect that compiler messages within IDEs or other graphical applications should be sanely typeset. If not, we’ve lost ourselves in all this UNIX stuff. Keywords and important phrases should be italic, emphasized, colorized depending on the GUI style.

For shuffling compiler messages around it is customary to pass a set of properties: a URI, line number, column number, a descriptive string, and possibly an error code. Apart from that it falls short reaching the goals outlined in this text, it encounters a problem which I think is illustrated in the above example with GCC. What does one do if the message involves several locations?

Even if a message involves several locations, it is still one message and should be treated so, and presented as so. The approach of using a struct with properties falls short here, and chops the message into as many parts as it has locations.

For Patternist I wanted to make an attempt at improving messages. So far it is an improvement at least. For instance, for this message that the command line tool patternist outputs:

cli.png

the installed QAbstractMessageHandler was passed a QSourceLocation and a message which read:

<p>Operator <span class='XQuery-keyword'>+</span> is not available between atomic values of type <span class='XQuery-type'>xs:integer</span> and <span class='XQuery-type'>xs:string</span>.</p>

It was subsequently converted to local encoding and formatted with ECMA-48 color codes. (The format is not spec’d yet, it will probably be XHTML with specified class ids.)

While using markup for the message is a big improvement, it opens the door for formatting and all, this API still has the problem of dealing with multiple locations.

What is the solution to that?

Striking the balance between programmatic interpretation(such that for instance source document navigation is doable) and that the message reads naturally as one coherent unit is to… maybe duplicate the information, but each time tailored for a particular consumer?

<p xmlns:l="http://example.com/">In my <l:location href="myDocument.xml" line="57" column="3">myQuery.xq at line 57, column 3</l:location>, function <span class="XQuery-keyword">fn:doc()</span> failed with code <span class="XQuery-keyword">XPTY0004</span>: the file <l:location href="myDocument.xml" line="93" column="9">myDocument.xml failed to parse at line 93, column 9</l:location>: unexpected token <span class="XQuery-keyword">&</span>.</p>

This is complicated by that language strings cannot be concatenated together since that prevents translation. But I think the above paragraph is possible to implement. As above, the message reads coherently, but still allows programmatic extraction. A language string and formatted data sits in opposite corners of extremity, and maybe markup is the balance between them.

Would this give good compiler messages and allow slick IDE integration? If not, what would?

englich
Qt
Aggregated
Patternist
Posted by englich
 in Qt, Aggregated, Patternist
 on Tuesday, September 18, 2007 @ 10:03

The Qt snapshots now includes support for XPath 2.0 and XQuery 1.0.

Being part of the XML library, the idea is that Qt 4.4 will ship with a C++ API for running and evaluating such queries. On the side too, is a command line tool called patternist, for quickly testing queries, scripting and old-school web solutions. But who cares, blogs with screenshots is the thing:

cli.png

Stronger XML support in Qt has been consistently asked for by users over a long time, with XPath being one of the main requests. Hopefully Patternist, with the help of KDE folks, users, and customers expressing what’s missing, will please those needs. Considering the similarities of XQuery and XSL-T, Patternist also serves as a foundation for implementing XSL-T, if so decided.

For KDE folks all this might ring a bell. Patternist was indeed first developed for a long time in the KDE repository, as part of KDOM. We just thought it would make a lot more use as part of Qt.

And I think exactly that makes this exciting. W3C’s XQuery working group has registered an astonishing number of exciting implementations. But for users, reliability is what matter in the end. Whether bugs will be fixed, whether people can answer questions, whether the piece is maintained and documented. Persistency. Trolltech swiftly carries this on its shoulders(assuming I brush my teeth and all that).

Combined with that Qt is open source and the Patternist SDK used for development is as well, this is like eating some nasty chocolate while at the same time singing a little duet with Miss Piggy. I can’t sing, nor can Piggy (although she tries), but you get my point.

Humble modesty aside, it is worth to mention that this still needs work. About 94% of the test suite is passed, the API needs more work, and there is performance issues.

Nailing test cases and trimming code paths are problems that have known solutions (though typically horrible to carry out). Harder is to know what people need and how they need it. It’s hard to guess what kind of APIs or extensions Amarok or KOffice or a GNOME or web application need.

If you got input, feel free to add a comment to the blog, send a report to Trolltech, grab me(FransE) on the Open Projects IRC network, or ask a question or two on the qt-interest mailing list.

The documentation starts over here.

zack
Aggregated
Posted by zack
 in Aggregated
 on Friday, August 31, 2007 @ 15:09

Today was my last at Trolltech. Some of you already knew that, the others are likely getting mouth to mouth reciprocation right now while a heavy set man is charging defibrillator paddles next to them (breath, breath!).

Technically Qt is years ahead of all of its competition and with Trolltech’s amazing engineering team it will continue doing great. I felt that other parts of the Open Source graphics stack could use my work a little more at the moment.

We (Open Source community) move at an astounding pace but the lower parts of our graphics framework are lagging a little bit behind. I wanted to go back to working on those parts of the graphics stack and it made sense for me to join a company that would directly profit from my work on Mesa, DRI, drivers and X.

This Monday will mark my first day at Tungsten Graphics. The engineering team at TG includes the likes of Brian Paul, Keith Whitwell, Michel Dänzer, Alan Hourihane and others, which reads almost like “Who’s who in Open Source graphics”. Clearly the only thing that was missing there was someone who looks really good naked. That’s me. I also know a thing or two about this whole “graphics” thing which tends to help.

I’ll be living in London for the next ~2 months or so. In England, while mainly working on Mesa, I’ll be filling the void left by the departure of Victoria and David Beckham.

zack
Qt
WebKit
Aggregated
Posted by zack
 in Qt, WebKit, Aggregated
 on Monday, August 20, 2007 @ 09:20

I was on vacations last week but I’m being all jealous of my luggage. It got a free trip around the world. During my last 8 flights my luggage has been lost 5 times. Is that a record? Confetti anyone? It’s a celebration. If you’re going to meet me during any of the upcoming conferences I’ll be the outgoing and highly sarcastic naked guy with a sign on my chest saying “for my face look this way” and an arrow pointing up.

I neglected to mention that, as Simon said, QtWebKit is working on Windows. Simon did an amazing job of porting all the quirks of the build system but “amazing” is the default state for all of his code so it’s not a surprise at all. While he was doing that I’ve sat down and ported XML tokenizer to QXmlStream from LibXML. If you never wrote a web rendering tokenizer (and unless you’re crazy, the chances of that are pretty high, and if you did you’re crazy and won’t remember doing it anyway) you know that “fragile” is a term that nicely describes it. After it was ported Lars and I sat down to fix the regressions and they didn’t even know what hit them (ha! ninja reference).

In other news I’ve merged in FreeType2 rasterization algorithm patches in Qt. Our raster engine, uses the beauty that is FreeType’s rasterizer, with a few patches on top. Because they break BC in FreeType’s public interfaces we can’t merge them back at the moment. In any case the patches improve rendering speed in general antialiased paths of the raster engine (meaning on Windows, Qtopia Core and in general whenever rendering to a QImage) by about 10% which is gangsta awesome (”gangsta awesome” is a very high level of awesomeness, at least judging from MTV).

I’ve also optimized the path clipping code. Andreas uses the path clipping code in GraphicsView for collision detection, so when I say “path clipping code” you should read “path clipping and GraphicsView collision detection”. A lot of the time in that algorithm has been spent on vertex allocation for tested paths. I’ve used a few tricks to speed it up by about 15%. The code for that algorithm is the number two reason why baby seals die (the first is still undisputed). It’s not even the algorithm itself but the inherent complexity of the problem. I’m a big fan of computational geometry in computer graphics because it makes grown man cry, except me and I like feeling like the lean, mean, killing machine that I am. My favorite part of the path clipping problem is that there are two ways of solving the precision problems and neither of them really works. The trick is that paths operate in double coordinate system, efficient snap-rounding implementations that I’ve seen operate in fixed-point coordinate system which falls apart in this case because of absolutely random distribution of vertices across the full double spectrum. Tessellation and clipping itself can be done in a screen coordinate system, which makes it possible to consistently represent your coordinates with fixed-point representation. That doesn’t work for paths because, e.g. boolean operations on paths need to be done in native path coordinates not screen coordinates. So the algorithm forces an absolutely crazy mix of dynamic fixed-point size, reduced-predicates, magic and good-will to work. Aren’t you happy that I’m doing it for you? You better be.

Yours(1) Latino(2) Lover(3)

1) Not really “yours”, more “community”. I love “you” but “you” need to realize that I need to be seeing other people.
2) Not really “Latino”. Unless of course my Spanish or Brazilian friends would like to name me an “honorary Latino” or “Latino by association”. I’d be definitely down with that. The only food I can make that is eatable and doesn’t force the fire department to evacuate the building before are nachos. I’m a definition of grace in the kitchen. “Whatever you have in the kitchen I will make it burn” is my motto. Plus I’m sporting quite an attitude to boot. “Make Zack a Latino” campaign. We can make it work!
3) Not really “lover”. More “no feelings haver”. Though technically I’ve worked on software for so long that hate is, next to sarcasm, my primary export.

zack
Qt
WebKit
Aggregated
Posted by zack
 in Qt, WebKit, Aggregated
 on Sunday, July 22, 2007 @ 13:35

There are days when I do something quite interesting and in my mind I can almost see myself on a stage in tight, tight spandex pants, long hair, perm, cowboy boots yelling angrily “are you ready to roock?!”. People cheering, babies laughing, women throwing their bra’s on the stage. It’s poetic. Then I remember that I’m a computer scientist and I snap right out of it. I go back to the life filled with math equations on napkins, sleepless nights in front of buzzing computers, stacks of books in corners and no spandex pants (although I can deal with the last one just fine). The fact that I hate rock lessens the blow, but it doesn’t make it any less disappointing. So in those moments of sadness I blog, yearning attention and approval, so readily available on the internet. Cough, cough…

I was wondering how hard would it be to create a QGraphicsItem that uses QtWebKit to render pages on a canvas. The idea being that combining full blown canvas like QGraphicsView framework with web rendering engine would give us quite a killer combination. So I’ve sat down today and done it. At first I had to redo some of the rendering code in QtWebKit and once I was finished I had a QWebGraphicsItem that beautifully renders pages. It being a QGraphicsItem all the effects available to graphics items in Qt are available for free to it. So you can animate, scale, rotate, perspective-transform and do a whole bunch of neat effects on it for free. Once I’ve done that I figured that it’s obvious that this is the best way of getting Apple’s Dashboard widgets to work. So I’ve done that too. I quickly hacked up a class that reads-in Apple Dashboard widget bundles and can render them on a QWebGraphicsItem. The compatibility is not 1:1 quite yet, because some of the Dashboard widgets use JavaScript objects that I haven’t implemented yet, like AddressBook object. To be honest I’m not 100% sure whether I want to implement them, I think we can get those things done a lot nicer, it’s just a question of whether 1:1 compatibility with Apple Dashboard is worth the extra effort needed to make all those JavaScript objects work on KDE.
First a screenshot of one Apple Dashboard widget rendered and on top a scaled to half its size KDE homepage:


Now a Dashboard widget with a perspective-transformed dot.kde.org page. Since this is QGraphicsView I can interact with the item while it’s transformed so I’ve selected some text on it.

Crackalicious. (no drugs were used while hacking on this, but I did touch myself a little after getting it to work). Furthermore (yes, there’s more… what can I say, I’m a giver…) in QtWebKit we have this neat interface that allows you to inject QObject’s into the framework as JavaScript objects at run-time, so adding new JavaScript objects is trivial and getting Opera widgets to work would be very, very simple. No spandex pants included though.