Simon
KDE
Labs
WebKit
Internet
Posted by Simon
 in KDE, Labs, WebKit, Internet
 on Tuesday, July 31, 2007 @ 10:21

Lars, Zack and I spent the last week making QtWebKit work on Windows. You may wonder why this is worth mentioning at all, since Apple released a WebKit based Safari for Windows not too long ago - and since QtWebKit uses Qt it shouldn’t require any changes at all to work on Windows, right? Indeed, we did not have to change anything in the bits and pieces of WebKit that use Qt, but WebKit is bigger than that. It comes with a lot of build requirements, such as bash, perl, bison, flex, libxml/libxslt, sqlite and more. As a result of that the WebKit for Windows that Safari uses requires a full cygwin installation. That is something we want to avoid as we need to be able to build QtWebKit with minimum dependencies and within “native” Windows environments. So we worked on making it easier to compile the sources and integrate better with QMake for a more portable build process. Below is the obligatory screenshot:

Screenshot of QtLauncher on Windows

QtWebKit can be built with Microsoft’s Visual Studio Compiler or with the MingW port of GCC and the Open Source Edition of Qt for Windows. We are collecting build instructions and help on the WebKit Wiki, so if you want to try to build it yourself I suggest to start there.

gunnar
Qt Jambi
Posted by gunnar
 in Qt Jambi
 on Friday, July 27, 2007 @ 09:08

A week or two ago, Eskil wrote a blog about how he’d been working on mixing AWT and Qt together in the same window. At the time he’d gotten to the point where we could embed a Qt widget inside an AWT component. Now we’ve gotten a bit further…

Based on the same approach we used for the Qt inside AWT embedding, we could also do the other way around pretty easy. The result is something along the lines of:

Qt Jambi and AWT

As opposed to Eskil, I decided to not show the picture of us with flowers in our hair that we took in San Francisco when we went for JavaOne earlier this year… What you’re seeing here is a QWidget with a grid layout with two QWidgets on the left, a QTextEdit with an html page and the CollidingMice example. On the right is the SwingSet demo. We also tried to embed a Java3D example there and that worked equally well.

The solution is not completely there yet, though. I did spend a day trying to get the focus handling between the two libraries right, and it was surprisingly non-trivial. AWT for instance doesn’t pass on the information that you’re doing SHIFT-Tab to do backwards traversal of the focus chain, so you need to figure that out based on the component that lost focus and where it is relative to the current one in the focus chain, and so forth… Lots of fun things. Right now its at a state where it works most of the time, but through mouse clicks and back/forward tabbing it breaks after a while so there is still work to be done.

The other issues are window activation, as we’re actually embedding the window natively and while the AWT component has focus, Qt becomes inactive, etc, but I’m not sure we’ll be able to get around that one. The other issue is OS X where AWT and Qt Jambi cannot run in parallel because of the Carbon event system not being thread safe.

Right now the code to get this example running looks something like this:

import com.trolltech.research.awt.*;
import com.trolltech.qt.gui.*;
import com.trolltech.launcher.*;

public class TestHost {

    public static void main(String args[]) {
        QApplication.initialize(args);

        QWidget root = new QWidget();

        QGridLayout layout = new QGridLayout(root);

        layout.addWidget(new QTextEdit(), 0, 0);
        layout.addWidget(new com.trolltech.examples.CollidingMice(null), 1, 0);

	SwingSet2 component = new SwingSet2(null, java.awt.GraphicsEnvironment.
                                            getLocalGraphicsEnvironment().
                                            getDefaultScreenDevice().
                                            getDefaultConfiguration());

        QAwtHost host = new QAwtHost(component);
        layout.addWidget(host, 0, 1, 2, 1);

        root.show();

        QApplication.exec();
        System.exit(0);
    }

}

All in all though, I find this pretty cool as it opens up for people to migrate from AWT / Swing to Qt Jambi and still being able to use thirdparty rendering libraries and the like.

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.

Kent
Qt
Posted by Kent
 in Qt
 on Tuesday, July 17, 2007 @ 19:31

As we all know, connecting to the signals of a QObject from QtScript code is trivial; for example

bossButton.clicked.connect(function() { desktop.showFakeSpreadSheet(); employee.grin(); } );

However, what if you don’t intend to expose your QObject to script code? Let’s say you got this crazy idea, that you only intend for scripters to be able to code some script function (AKA “slot”) that you bring into your application, then you want to handle the actual signal-to-slot connections yourself, in C++ (god forbid!). What do you do then? Scream out in agony?

Well, if you’re using the daily Qt snapshots, there’s actually no need to do so; a couple of days ago we added the necessary functionality. Let’s have a look at the obligatory, completely useless example. First, we have a fair amount of bland code (sorry about that) that sets up a widget with two buttons:

#include <QtGui>
#include <QtScript>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QWidget window;
    QVBoxLayout *vbox = new QVBoxLayout(&window);
    QPushButton *awakenButton = new QPushButton("Rise From Your Watery Grave");
    vbox->addWidget(awakenButton);
    QPushButton *exitButton = new QPushButton("Exit");
    vbox->addWidget(exitButton);

Then we create our script engine, and a script object, and give the object a suitable name:

    QScriptEngine engine;
    QScriptValue object = engine.newObject();
    object.setProperty("name", QScriptValue(&engine, "Megatron"));

We read our “slot” script function from a file:

    QFile file(":/slot.qs");
    file.open(QIODevice::ReadOnly);
    QScriptValue slot = engine.evaluate(file.readAll());
    file.close();

Nothing out of the ordinary so far. But now we’re actually ready to do a signal-to-slot connection:

    qScriptConnect(awakenButton, SIGNAL(clicked()), object, slot);

Wow. Just… Wow. How much easier, consistent and intuitive can it get? Both syntactically and semantically, it’s very similar to QObject::connect(). The main difference, of course, is that the last two arguments to qScriptConnect(), the receiver and the slot, are QtScript objects (one can be any type of object, the other must be a function object). When the QtScript “slot” function is executed in response to the signal, the receiver that you specified will act as the this-object. If you specify an invalid QScriptValue as the receiver, the this-object will be the interpreter’s Global Object; this even makes qScriptConnect() consistent with ECMAScript Function.prototype.call() and Function.prototype.apply(), for the purists who care about that stuff (hey, don’t look at me). There is of course also a qScriptDisconnect() function, which destroys a connection.

Finally, demonstrating the principle of “Why do it the easy way when you can do it the hard way”, let’s round off main() by using qScriptConnect() to connect to QApplication::quit() as well:

    QScriptValue scriptApp = engine.newQObject(&app);
    qScriptConnect(exitButton, SIGNAL(clicked()), scriptApp, scriptApp.property("quit"));

    window.show();
    return app.exec();
}

Mmm, beautiful. Last, but not least, the QtScript function loaded from slot.qs, which is executed when the first button is clicked:

return function() {
    var sender = __qt_sender__;
    sender.text = "YES! " + this.name + " is now alive and kicking!";
    sender.styleSheet = "background: lime";

    sender["clicked()"].disconnect(this, arguments.callee);

    sender.checkable = true;
    sender.toggled.connect(sender.hide);
}

First we use a QtScript extension to ECMAScript, __qt_sender__, to grab hold of the button that sent the signal (in general a dubious practice, if you ask me, whether it be script code or C++; but sometimes it’s just too tempting). We change the button’s text, give it a nice background color, then we break the connection that we established in C++ (arguments.callee to the rescue, as usual). Finally we do some more silly stuff, just to show that we can and aren’t afraid to do so.

Oh yeah, in case you were wondering, you can also do a connect from C++ with the QtScript 4.3 API, by doing this:

QScriptValue scriptButton = engine.newQObject(awakenButton);
QScriptValue scriptSignal = scriptButton.property("clicked()");
QScriptValueList args;
args << object << slot;
scriptSignal.property("connect").call(scriptSignal, args);

It’s simple to create a convenience function based on this code, having arguments identical to qScriptConnect(). Way to go 4.3, counterattack!

lorn
Qt
Qtopia
KDE
Greenphone
Posted by lorn
 in Qt, Qtopia, KDE, Greenphone
 on Monday, July 16, 2007 @ 22:37

After a long dormancy, (the last qtopia snapshots available were from the 1.6 series), I am pleased to say that Qtopia snapshots have returned!

They are available for the 4 series from here:
ftp://ftp.trolltech.com/qtopia/snapshots

As with Qtopia 4 series source code, these packages contain everything to compile Qtopia and all Trolltech’s tools needed for developing - Qt x11, Qtopia Core and Qtopia (not including the toolchain compiler and other system dependencies), are licensed under the GPL to ensure the code and it’s derivative’s remain free software. You want more free software, right?

All hail Free Software!

zack
Qt
Aggregated
Posted by zack
 in Qt, Aggregated
 on Saturday, July 14, 2007 @ 14:59

Before boarding a flight I’m eagerly awaiting the security presentation that is about to ensue. I figure that these people spent their valuable time learning how to point to the ground, back, forward and to the side and someone needs to appreciate that effort. During my last flight I even went ahead and tried to inspect my life jacket. “Tried” because as it turned out my seat was missing it. As the security announcement advised, I “calmly” informed the fellow sitting next to me that “in the unlikely event of a water landing” he’s screwed because as a stronger man I’m taking his life jacket. This also prompted me to think about tools that make our life easier (just to clarify, when I say “our” I mean “my”). I’ve spent a little time yesterday creating a tool that will make my (when I say “my” I mean “our”) life a lot easier. So today I wanted to tell him (when I say “him” I mean “you”) about us (when I say “us” I mean “it”).

I’ve spent a lot of time writing simple C++ applications to test out some kind of rendering algorithm. Internally we had a tool that automated a lot of it. The tool uses a very simplistic, reg-exp based language to specify commands. I wanted something more powerful. This is how scripter came to be. Scripter is a very simple application that uses QtScript’s bindings to Arthur to do its rendering. It allows for rapid prototyping of algorithms and most importantly for me, quick testing of Qt’s rendering framework. At first it was a whole IDE with its own code editor, very quickly though I decided to remove the editor and just make it a content widget that monitors the file it was opened with for changes. The reason for that is that I wanted to keep working in my own editor and just have a dynamic, visual preview of everything I was doing. So with Scripter one can be writing rendering code while the visuals effects of the editing are immediately visible. Here are two screenshots of examples included with it:



But the whole beauty of this application is ability to create animations, while seeing the changes done in real-time. I recorded two demos:

Scripter requires Qt 4.4. If you don’t have Qt 4.4’s snapshot it won’t work. Get it from the SVN at labs.trolltech.com with :

 svn co svn://labs.trolltech.com/svn/graphics/scripter
ettrich
KDE
Posted by ettrich
 in KDE
 on Friday, July 13, 2007 @ 09:32

In case you wondered why I - again - didn’t make it to aKademy, here you go: Our daughter Helen was born on June 16. Here’s the obligatory screenshot:

Helen

She looks like an angel, and she totally is one. So far we had a fantastic time, and it’s getting better every day. Getting a daughter is simply awesome. Think of it as having your birthday at the same day you win the lottery and KDE 4 is released, and you won’t even get close.

Looking in her eyes I can’t say I regret not having been to Glasgow, but reading all the postings about the conference I’m really looking forward to participating again next year.

Alessandro
Qt
News
Posted by Alessandro
 in Qt, News
 on Wednesday, July 11, 2007 @ 14:54

Trolltech is about to release its development tools as Qt Eclipse Integration. Here is a short introduction in Q&A style to what it is and how you can start hacking, today, plus a few screenshots.

About

  • What is Eclipse?
    Many people think of it as just a Java IDE. But Eclipse is a plugin-based platform for creating (for example) IDEs. It is often shipped with the Java development tools, hence it offers a Java IDE out-of-the-box in those cases.
  • Does Eclipse support C++ development?
    Support for programming languages in Eclipse is realized via plugins. There are Eclipse plugins for all possible languages. The standard C++ Plugin for Eclipse is called CDT. It brings GDB based debugging, managed makefiles, simple refactoring and so much more to Eclipse. Trolltechs Qt Eclipse Integration is built on top of the CDT.
  • What does the Qt Eclipse Integration add to Eclipses C++?
    The Qt Eclipse Integration seamlessly integrates the whole Qt development workflow:

    • Pure qmake based project management (not imposing Eclipse specific project file formats) with a .pro file importer and graphical project editor
    • Embedded, well known UI Designer with its Form- Property- Signal/Slot- and Action editor
    • Wizards for creation of new Qt gui and console projects. Wizards for creation of new Qt classes.
    • Embedded Qt Resource editor
    • Integrated Qt reference, a Qt Eclipse tutorial and a “cheat sheet”
  • Which platforms are supported?
    The plugin runs on Windows and Linux x86. Debugging does not work on Windows x64, because GDB crashes, there. OSX will be supported in a later release.
  • What do I need in order to start?
    Download and install the following ingredients:

  • How do I start?
    Start Eclipse (on Windows, use the “Start Eclipse with MinGW” shortcut from the Start Menu). Follow the instructions of the Qt Eclipse Integration cheat sheet, which will guide you through the necessary steps.
  • Who will help me?
    Subscribe to the Qt preview mailing list and post your question and browse the archive. You will get polite and competent answers

New Qt Gui Application Wizard

Define the name of the project, the type of the first UI class and the required Qt modules.
New Qt Gui Application Wizard

Code editor with auto completion

Editing code can be easy and fun when the auto completion actually works and gives usable suggestions.
Code editor with auto completion

The Qt designer components, embedded into Eclipse

The seamlessly embedded Qt Designer reduces the creation of great UIs to a few clicks. No external Designer instance needs to be launched.
The Qt designer components, embedded into the Eclipse based IDE

Eskil Abrahamsen Blomfeldt
Qt Jambi
 in Qt Jambi
 on Wednesday, July 11, 2007 @ 09:51

A common question I get when I’m doing talks on Qt Jambi is how well it plays with other toolkits, specifically Swing and AWT. There’s a lot of code out there written in either or both, and people who want to port their projects to Jambi or build new components on top of existing legacy code require some sort of migration layer.

So far, our answer to the question has been that top level windows in Qt Jambi and Swing play well together, while window components are more reluctant to partake in any sort of social activity.

It has, however, been our goal all along to change this, and implement migration classes that allow a Qt Jambi widget to be adopted by a AWT/Swing component, vice versa, and in general make it even more convenient to use Qt Jambi together with existing Java code.

Yesterday I had some time to sit down and sketch up a crude solution for part of this migration layer. It currently works on Windows and Linux, only supports putting Jambi into AWT (not the other way around), and is not at all perfect. It’s quite functional already, though.

On the technical side, it uses JAWT to access OS specific data about a Canvas-subclass that I’ve called QAwtWidget. The QAwtWidget also takes a reference to a QWidget, which is the Qt component it will bind into AWT/Swing. It will then use all this information to have the operating system reparent the Qt widget to the QAwtWidget-canvas. This means that all event handling is automatically delegated to the correct widget, so the widget will immediately be fully operational.

There are snags, however, and a solution like this will never be completely perfect. I’m not sure if we will ever be able to make it work on Mac, and there will be some oddities in focus handling, window activation, etc. that I don’t think we’ll be able to remove entirely. But it’ll be a great tool for parts of a project where it’s unnoticable, and it will definitely be a great tool to have for porting existing AWT/Swing-code to Qt Jambi.

Here’s an example of the image viewer demo running on Windows inside a GridLayout with a couple of buttons for extra evidence.

Qt and Awt running side by side

The code for making this happen:

public static void main(String args[]) {
    QApplication.initialize(args);

    JFrame f = new JFrame();
    f.setBounds(0, 0, 500, 100);

    GridLayout flayout = new GridLayout(2, 2);
    f.setLayout(flayout);

    // The widget to embed
    QWidget w = new com.trolltech.demos.ImageViewer();

    // The migration layer
    QAwtWidget awtWidget = new QAwtWidget(w);

    JButton swingButton = new JButton();
    swingButton.setText("Swing button");

    Button awtButton = new Button();
    awtButton.setLabel("AWT button");

    f.add(swingButton);
    f.add(awtWidget);
    f.add(awtButton);
    f.setVisible(true);
    f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    f.pack();

    // Run Qt event loop in main thread
    QApplication.exec();
}
 
Comments Off
lorn
Qt
Qtopia
KDE
Greenphone
Posted by lorn
 in Qt, Qtopia, KDE, Greenphone
 on Monday, July 09, 2007 @ 21:00

While others are touting about their linux phone stuff as being “the future”, and “the first open source Linux phone”, Trolltech has the future and the worlds first open source Linux phone right now.

Qtopia Greenphone!

You can make phone calls, send SMS messages, AND easily add your own customized functionality, right now!. (they would too, had they used Qtopia) Heck you can even use it as your primary phone. I have been using mine for almost a year now.

You can hack on applications all you want, because Qtopia is GPL, and will always remain GPL. As an open source developer for more than 5 years now, I just don’t get the LGPL and why advocates of free, open source software keep using that license. Do you want more proprietary closed source or software that will always be free?

Back to the Greenphone, in phone bounce mode, you can use the modem from your desktop. You can ssh into the device and get a console. Play audio and video, using the highly optimized Helix libraries. And, if you are like me, you can write your own Shopping list and bar recipe applications to impress your friends and bartender.

We have created an SDK that runs in a virtual machine so you can develop from Windows or Mac. We have a simple script that builds the root filesystem (complete with the toolchain!). No having to install unstable and complicated distribution building tools that eat your hard disk space and make you want to poke your eyes out with a spork.

We have done so much work on Qtopia for the Greenphone, it would make your head spin and let the blue smoke out of your computer! We have a huge team of dedicated professional engineers, working night and day (Europe + Australia!) bringing you the best and easiest gui toolkit in the world to use (when we are not playing ping-pong or drinking beer).

Best of all, the Greenphone is an awesome shade of green and does not look like a hockey puck!

[edit]
Just so everyone knows, these are my personal opinions.



© 2008 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners.