There has been a raising demand for querying the system idle time. The Qxt team runs to help again! A new method, namely QxtWindowSystem::idleTime(), was introduced last week. The current implementation covers X11 and Windows platforms. And in case you’re curious about the implementation, we did it with help of XScreenSaver and GetLastInputInfo(), respectively. A Mac implementation will hopefully follow later. Furthermore, it would be nice to introduce a timeout service without polling the system idle time, but I haven’t had time to further investigate the issue yet. The current implementation is naturally available in the trunk, and will be released sometime later in LibQxt version 0.5.0. Enjoy!

The Qxt team is proud to announce the immediate release of LibQxt version 0.4.0.

LibQxt, an extension library for Qt, provides a suite of cross-platform utility classes to add functionality not readily available in the Qt toolkit by Trolltech, a Nokia company.

LibQxt 0.4.0 introduces new features and contains bug fixes to the 0.3.x series:

• QxtCore
  • Added QxtDeplex
  • Added QxtLocale
  • Added QxtPointerList
  • Added QxtMultiSignalWaiter
  • Added QxtSignalGroup
  • Added QxtCommandOptions
  • Added QxtLogger
  • Added QxtAbstractConnectionManager
  • Added QxtDataStreamSignalSerializer
  • Added QxtAbstractSignalSerializer
• QxtCrypto
  • Added QxtHmac
• QxtGui
  • Added QxtItemEditorCreatorBase
  • Added QxtStandardItemEditorCreator
  • Added QxtItemEditorCreator
  • Added QxtBaseSpinBox
  • Added QxtCountryComboBox
  • Added QxtCountryModel
  • Added QxtLanguageComboBox
  • Added QxtScheduleView
  • Added QxtTabBar
  • Added QxtFlowView
  • Added QxtLetterBoxWidget
  • Improved QxtTabWidget
    • Added QxtTabWidget::alwaysShowTabBar
    • Added QxtTabWidget::tabAnimation
    • Added QxtTabWidget::tabMovementMode
  • Improved QxtConfirmationMessage
    • Added QxtConfirmationMessage::settingsFormat
    • Added QxtConfirmationMessage::rememberOnReject
    • Added QxtConfirmationMessage::overrideSettingsApplication
    • Added QxtConfirmationMessage::overrideSettingsKey
    • Added QxtConfirmationMessage::overrideSettingsOrganization
• QxtBerkeley
  • Added QxtBdbTree
• QxtWeb
  • Revised the whole module
• QxtNetwork
  • Added QxtTcpConnectionManager

More information and downloads are available at http://libqxt.org.

Here comes more Qxt news. Yesterday I introduced a header view with proportional section sizes. This makes it possible to say that for example “section A is twice as wide as section B and section C is 3 times as wide as section B”:
|--A---|-B-|----C----|

Btw, this TODO task was only 4 months old.

It was about the time to give Qxt some attention. Yesterday I finally took care of a TODO task added by myself in 14th of February: “draggable tabs”. Say hello to QxtTabBar::TabMovementMode:

• QxtTabBar::NoMovement
• QxtTabBar::InPlaceMovement
• QxtTabBar::DragDropMovement

Like the name suggests, QxtTabBar::NoMovement doesn’t allow tab movement. QxtTabBar::InPlaceMovement handles moving of tabs “in place”, which means that the tab being moved follows mouse. This is somewhat similar than how Konqueror handles tab dragging with the middle mouse button. QxtTabBar::DragDropMovement, implemented earlier by Momesana, does tab movement using drag and drop. This is a bit similar to how Firefox handles tab movement although QxtTabBar still misses a neat drop indicator.

I think I wrote nearly a thousand lines of code today after putting in 14 hours at the office, but I made a lot of progress. Specifically, the QxtWeb rewrite is shaping up quite nicely.

Anyone who wants to look at it can check it out via anonymous SVN:

svn co svn://libqxt.org/svn/libqxt/sandbox/ahigerd/web QxtWeb

The libqxt.org website will be ported to the new code soon, and if/when this is successful I'll write documentation for the new architecture and it'll be merged to trunk for the 0.4.0 release.

To give a brief overview of the design:

• Create a QxtAbstractWebSessionManager object for each protocol that can access the service. (Direct HTTP is the only thing supported right now, but SCGI, FastCGI, and NodeTalk are planned.)


• If using QxtHttpSessionManager, select a connector plugin. (Again, direct HTTP is the only one currently implemented, but SCGI and FastCGI will be available. NodeTalk is not an HTTP protocol.)


• Register a QxtAbstractWebService factory.
  
  • The factory is invoked each time a new session is created and returns a service object for that session.
  
  
  • QxtWebServiceDirectory allows you to register multiple services and selects between them based on the path.


• Invoke QxtAbstractWebSessionManager::start() to begin accepting connections.


• When a new visitor arrives who does not have a current session cookie, a new service instance is created.<.li>
  
• When a request is received, a pageRequestedEvent() is dispatched to the service.


• When the service is ready to respond to the request, it posts a QxtWebPageEvent to the session manager. This is done asynchronously; there is no requirement that the pageRequestedEvent() handler must respond to the request before the function ends.

There's enough here to write some real applications, but there's more to come!

So. you ever needed to debug a sockets read and write data?
Here is how you do that. This is actual production code :D

{    
    NodeTalkModel model;
    QxtDeplex deplex;
    QxtDeplex replex;
    QxtPipe   enplex;
    QxtPipe   enplex2;
    QxtPipe   debug_w_pipe;
    QxtPipe   debug_r_pipe;
};



    socket=new QSslSocket(this);
    deplex.setDevice(socket);


    /**

    Debugging the socket. Flow diagram.

                                        _________   ----------> debug_w_pipe          _________
    model   ->  enplex2 | enplex    >]  |        |   ------------------------------>  |        |  >]  socket
            <-                      [<  | replex |   <------------------------------  | deplex |  [<
                                        |________|             debug_r_pipe <------   |________|


    omfg. someone write a proper enplexer >_<
    */



    deplex.connect(&debug_r_pipe,QIODevice::WriteOnly);
    replex.connect(&debug_w_pipe,QIODevice::WriteOnly);


    deplex | replex;
    replex.setDevice(&enplex);
    enplex | enplex2;

    connect(&debug_w_pipe,SIGNAL(readyRead()),this,SLOT(w_readyRead()));
    connect(&debug_r_pipe,SIGNAL(readyRead()),this,SLOT(r_readyRead()));

    model.setDevice(&enplex2);

obviously (haha) you need that weird combination of QxtPipe instances to do a readAll() from the debug_{w|r}_pipe without distorting the data flow. the weird replexer combination is there to avoid feedback. if you would connect the replex device directly to the model, any deplex->replex data flow would be resent to any pipe connected, so also to the debug_w_pipe, but you dont want that. Sounds fun? It is, really. It's like connecting audio effect chains until you get the flow right. Try and error mostly ;)

First, let me say that I respect aep's opinion on KDE and patched versions of Qt. He has relevant technical reasoning and fair commentary on KDE's general policies and community. However, I don't share his disdain for the KDE project.

I agree that qt-copy probably isn't a good idea, and that KDE4 should ideally be able to run on an unpatched version of Qt. On the other hand, I also will note that the #1 most widely used piece of software in the Open Source world -- the Linux kernel itself -- has several semi-official patchsets that are actively maintained and widely accepted. And especially when the patches are intended for eventual contribution upstream, this is actually a very productive thing that brings improvements to everyone. In short, I think a fork of Qt is the wrong idea; anything that requires KDE to patch Qt (aside from bugfixes that prevent existing functions from behaving as they should) is something that hinders KDE's progress as a cross-platform toolkit. Release versions of KDE should not depend on feature patches to Qt -- functionality that requires a patch should be optionally supported.

The biggest problem with KDE's apparent fork of Qt is that pure Qt developers have to worry about inconsistent behavior in the toolkit. The open-source community has seen the issue before -- maybe not with Qt, but for every case where the open-source equivalent to a proprietary API has a subtly different behavior. Applications either have to detect the difference and somehow hack around it, or they malfunction on one and have to require the user to install the other. This could potentially mean that two applications are mutually exclusive -- you cannot run both at the same time, as their dependencies conflict.

That said, I don't believe this problem warrants actively fighting against the entire KDE project. KDE is the source of a lot of good things for the open-source community. Creating non-KDE alternatives just because you don't want to support KDE hurts everyone. There's a lot of duplicated effort, and even if it's successful, neither application will get the full attention they need to improve, which means we then have two pretty-good solutions instead of combining forces for one excellent one. KDE is more than just a library. It's a marketing strategy. KDE is going to be what brings Qt to the attention of non-Linux users.

We should choose our fights. KDE is far too big of a target, and most of it is excellent. What we should really be targeting is the mindset that KDE is a replacement for Qt. With the exception of platform-specific functionality, KDE should be able to run on any existing Qt installation; it shouldn't require uprooting the entire toolkit and replacing it with its own. We should fight using their own techniques: We should analyze KDE's source code, and we should contribute patches to code that doesn't work on an unpatched Qt. We should fight against KDE replacements for existing, working Qt classes. We should help it evolve past its need for a forked Qt and push for a unified Qt.

Fellow hackers,
i will be no more available on IRC.
This is not a technical issue, rather then a matter of life energy.
The freenode has unfortunately become a threat to my health, as i burn myself out with useless fights with people, who, like me, usually see the sunlight from home to work and back.
My role within my company is changing too, as i am no longer writing code myself, other then libqxt, and will be put into more business related tasks.
This doesn't mean Qxt is dead. In fact i might have more time to spend on it.
As for our communication, i please you to use the mailing list more often, and i will see into a video chat solution for meetings.
I am also sending this to the brave Trolltech warriors out there who face the IRC daily too. Please don't give up the fight for Qt and continue to spread your wisdom. Hopefully one day, freenode will be a place where Qt programmers aren't set equal to KDE programmers, and aren't ranted at everywhere as soon as they do their come out.
I am bold enought to send this to some kde developers too. I know you hate me anyway, so what do i have too loose? I'm not blaiming you for all the hatred i received on IRC, devdays, linuxtag, etc. Maybe one day you will wake up, figuring you are stuck in a big bubble of grey paste. Maybe you already noticed, but don't know where else to dedicate your Qt skills to. Write me a mail.

The Qt Desktop solution has found a lot of supporters and i would like to continue it. i hope that my absence from irc doesnt hinder spreading the word that there is more then KDE in the Qt open source scene.
I know that you Trolls are as pissed and burnt out as i am, figthing for high code quality in a scene where most people have low or no social skills.
I'm sorry to be a coward but i have to bail out before i damage myself.

This is also a call for action. While i give up the fight on IRC, i won't give up fighting for Qt, for linux, and for open source.
There are several projects i would like to make you aware of, and for the first time i will make my real attentions behind them public.

Libqxt, the Qt extension library is built up on Qt. the website says "Qxt, the Qt eXTension library, provides a suite of cross-platform utility classes to add functionality not readily available in the Qt"
In fact i built this project centered around the idea to make Trolltech aware that there are young people out there who are eager to work on extending Qt for no charge, as well as there are companies who would like to contribute back to Qt. I think we quiet suceeded building a big codeset with high class coders, companies, and a lots of users, and i hope that a few of your might find jobs at Trolltech, or jobs somewhere else while using Qxt as a reference. Hopefully we will be able to push some Qxt stuff into the mainstream some day. (we definately have some fine classes that are worth it)
I'd love to talk about the new amazing technologies i am pushing like nodetalk and carrier, but i guess thats an extra mail some day.

The Qt Desktop Solution (no name yet)
as my fight with KDE began to be more and more pointless, i decided to found my own Desktop environment. The responses from the community where
amazing. I didn't know there are _SO MANY_ people who opose the kde organisation, its code structure, or simply the way they threat high class Trolltech developers. I actually want a working desktop, but of course my intentions are never pure: I see this as the future of Qt in the open source world.
Today i had a fight with the archlinux Qt maintainer. Archlinux was the last bastion of an unpatched Qt, becouse of its policy to not downstream patch.
But as the founder retired, archlinux lost its way. The Qt maintainer has switched from Qt to Qt-copy without notice.

My call for action is: we MUST gather non-kde developers and push non-kde applications hard, to regain attention for a clean unpatched Qt, as Trolltech made it, in the main distributions
There are several projects and people that might form this alliance, and eventually form a desktop environment:
cutebox, qdevelop, psi, communi, the qt demo browser, much of the Qt demos and examples. There is lot of work to do. For once code must be written. But also, the word has to be spread further. especially within Trolltech. the Qt examples are not fully developed. i would assume mostly becouse most Trolltech developers dont even know there are people on the linux platform who are sick and tired of KDE, and would apreachiate those applications.

Please, wake up, start fighting, you are not alone.

sincerely yours,
Arvid

So it's time to pollute the blogosphere with some qxt news again. First big news is we actually got two new contributors. Deepdiver, who isn't _that_ new anymore, and ilya. Deepdiver has already been approved and contributes to trunk. he is responsible for QxtCountryComboBox and related classes.

Ilya is fairly new and has to be approved before commiting to trunk. He announced to mainly work on smtp delivery facilities.



So.. did you note the new QxtBerkeley module yet? If not you should try it at once. It's a very convenient Qt wrapper around Berkeley Db. You got Container classes that can be used just like Qt containers, except that the content will be saved persistant to disk. Of course you can use all types that are registered with QMetaType and have stream operators. That includes all QVariant types. Adding your own type is fairly easy.


If you wonder what the heck a Tree Container is, you might want to look at QxtLinkedTree which is.. a linked tree.

So, Trolltech was bought by Nokia. Well actually they are not yet, but the fact that they both made a big press release, shows they are at the end of the negotiation.
This morning was a bad morning. I woke up with a hangover from my birthday party and directly stepped into a mess. The Qt channel was already crowded with people yelling and screaming. I was like "wtf" myself, when i heared the news.
Overall the Open Source community was angry and confused, Nokia is not exactly known to be a nice company. Also no one informed us and the "Letter to the Open source community" is rather a joke then a reasonable explanation of what the heck happened.
The confusion is not yet gone for many of us. And as we are trying to make the thought of doom and world end disapear, some thoughts come in mind. For example: "Why the f....?"
If you wonder what happened, are in fear what might happen, or are simply pissed becouse they sold us out, here is what i collected from various sources and persons.

What exactly happened?

Trolltech and Nokia are reaching the final stage of negotiating the exact circumstances under wich Trolltech will be handed over to Nokia in its entirety.
Nokia is offering 16 NOK (thats currently 1,9 Euro, or 2.9 dollar) per share. A Vote from the 27.01.2008 resulted in the majority of shareholders accepting the offer.
Except the Trolls were introduced to their new employe, nothing actually happened.

The official press anouncement.

Nokias press release contains rarely any usefull information, as usual. Neither does Trolltechs.
So here are the most important statements from Trolltechs announcement:
"Nokia aims to continue the development of Trolltech’s products and support of new and existing customers."
"Nokia intends to continue to enhance Trolltech products through active and ongoing development, for both desktop and mobile."
Also there is an official letter to the open source comunity that claims, Nokia will continue to support KDE as Trolltech did.

Do you trust them?

Thats actually a valid question. Of course i do not trust Nokia. Of course i don't believe they have the same ideas about OpenSource as Trolltech. If i may cite a Symbian developer: "OpenSource developers are cheap code monkeys".
Althought i personally dont trust them, and i fail to believe they are honest with us, there are some simple things that make me consider this beeing not so evil at all.
Btw, Trolltech/Nokia, if you read this: people misstrust you a lot less if you are honest about your intentions and future plans.

The Free Qt Foundation protects KDE.

As you might or might not know, the KDE Foundations and Trolltech have built a legal instance that will protect Qt, in case Trolltech tryes doing crazy things. In return KDE has to offers similar securities. This is kindof like an marriage contract.
If, and only if, Trolltech fails to release a Qt/X11 version under the GPL, for 12 months, the KDE foundation will make use of their right, to release the entire QtX11 (Open Source) Source code under a BSD like license. Thats something Nokia won't let happen. Even if they were evil and were trying to lock out us Open Source folks. They _cannot_ deny us access to the X11 version of Qt, or they loose all controll over it, wich is exactly what they _not_ want.

Qt/Windows.

There have been theories that Qt/Windows might be dropped. I'm sorry to offend, but thats plain stupid. Nokia doesn't buy a huge technology just to throw its most profit-making part away. Of course no one can know for sure if Qt/Windows remains OpenSource, but know this: In any event Qt/X11 _will_ remain OpenSource and backporting Qt/X11 changes to the last GPL release of Qt/Windows is an minimal effort. Nokia would gain nothing from denieing Qt/Windows to the OpenSource comunity after it has been released anyway.

What the fsck is Nokia doing?

They are aquiring technology. Every company has to grow or they die pretty soon. And looking at the current share loss Nokia is suffering, you realise they have to do something pretty quickly. The N95 went very well for nokia and proved that the multi media market is the future. Cheap mobiles don't cut it anymore for a giant like they are. Nokia will focus on the high price, multi media market. This does include high end mobiles, but is not limited to it. Aquiring young, inovative people like there are in and around Trolltech is the perfect chance to hop on the train, before it passes.

QTopia vs Symbian

For a while i realy thought Qtopia will be in jeopardy. Nokia stated clearly they have no intentions whatsoever to use linux on their mobiles. And they won't replace maemo. Understandable, if you look at what they invensted in it already. This would mean Qtopia is of no use for Nokia. In fact, making it open source leads to the rise of cheap mobile manufactures from eastern europe and china. Wich is not a great threat, but considered anoying by nokia. So they get rid of Qtopia? No way, look at the bigger picture. Symbian doesnt really prove to work in the high performance sector. But instead of building on top of a brand new and unstable technology, Nokia will continue to work with symbian. They will use the newly aquired Qtopia to increase pressure on symbian ltd. , wich effectivly means QTopia will be lowered in priority, but not dropped. For the time beeing, Nokia will make Trolltech focus on devlivering a cross platform Toolkit. There are rumors that there will be a Qt/Symbian port.

Trolltech was for sale anyway

It was long planned to sell Trolltech and rise it to the big boys table. The founders deserve a rest too, don't they :)

Summary:

The only things that might suffer are Qt/WinMobile and Qtopia, but only becouse they will be lowered in priority. Nokia does not intend to reorganise Trolltech, and does not intend to lay off any developers. What might change is the marketing/sales department. And to be honest, i don't care. Trolltech will continue to work with the OpenSource comunity. In fact Nokia finally needs something to look like a good company, and they will put more money in KDE (and zero in qxt *sigh*). Qt4.4 will be released as scheduled in a few weeks. There will be no influence of the buy on the Qt4 line at all.


sources:
http://trolltech.com/company/newsroom/announcements/press.2008-01-28.4605718236
http://www.nokia.com/NOKIA_COM_1/Press/Press_Events/Nokia_to_acquire_Trolltech_to_accelerate_software_strategy/Nokia_to_acquire_Trolltech_to_accelerate_software_strategy.pdf
http://www.kde.org/whatiskde/images/agreement3.png
http://www.libqxt.org/stuff/

Hi there,

i know it has been a long time since i wrote my last blog. Sorry for that.
But now i'm back and want to introduce a new module that is currently
more in planning than in an implemented state, but it slowly evolves.
Me and Mark started to work on a module called the PO module. PO means Persistent Objects.
Now some of you will get excited because it seems object persistence is a feature that is really
needed out there. We still need to figure out some basic stuff but i want to show you the current state.

So what does it take to make your objects persistent? Here is the good part: Not much.
The PO module uses the Qt property system to load and save your object dynamically.
So your Objects only need to be derivered from QObject and add a small Macro:

QXT_DECLARE_PERSISTENT(YourObject);

Every Q_PROPERTY in your Object that sets STORED to true is pushed into the Database.
To register a Object with a database you have to create a QxtPOManager:

QxtPOManager manager;
manager.registerPOType < YourFirstObject > ();
manager.registerPOType < YourSecondObject > ();
manager.registerPOType < YourThirdObject > ();

Thats everything. After you did that work your classes are fully useable with the PO module.
The manager will handle load/save/deletetion of your objects.
Well there is still a lot of work to do so don't expect something in the next time. I guess before libqxt 0.3.3 or .0.3.4 there will be nothing useable. But we are working on it and will provide a tarball when there is something to test.
If someone is interested or has expirience with creating peristence frameworks and wants to contribute, post a comment to this blog, write me a mail or join the #qxt channel on irc freenode and just ask.

zbenjamin
"your friendly developer from the neighbourhood"

p.s. the ScheduleView is still in work, but we are currently testing if there is a better way to
implement it.

A few days ago, LibQxt 0.3.0 was released. Congratulations again, keep up the good work guys!

I’m particularly impressed how QxtGlobalShortcut found its shape. This change derives from last fall when QxtNativeEventFilter was introduced. This gave us the possibility to refactor global shortcut aka. hotkey functionality out of QxtApplication. Today, as in LibQxt 0.3.0, QxtGlobalShortcut is pretty much identical to QShortcut. Yay!

PS. It also looks like a new member is joining our forces. Welcome Thomas Müller alias DeepDiver! Your work on QxtCountryComboBox so far has been pretty impressive.

At the devdays2007 we gathered a lot of input from Trolls, Trollfriends and Qxt users. When talking about QxtRPCPeer the most common requests where supporting xmlrpc and dotnet-like marshaling objects.

While xmlrcp didn't end up on my todo list, everything that could make devs use qt over dotnet makes me jumpy. So dotnet has this "remoting". Say we have a class Foo with the function bar, you can do something like channel.expose(new Foo); channel.remoteObject()->bar(); of course with an much uglier MS syntax, haha.

Dotnet is an interpreter, so it can do some tricks to map function calls to remote calls without needing a code generator. Usually you can't do that in C++, unless you have moc.

Normally moc parses the function definition from your header and maps metacalls to real functions.
Hacking into this mapping, we can actually map metacalls to remote calls.

Well, enought details, hereby i anounce QxtMarshalChannel. It will allow you to expose any QObject to a remote location (actually over a QIODevice, so you could also use pipes,files,buffers,etc...)

    QxtPipe  a_pipe,b_pipe;
    a_pipe|b_pipe;

    QxtMarshalChannel a_channel(&a_pipe);
    QxtMarshalChannel b_channel(&b_pipe);

    SomeQObject obj;
    a_channel.expose(&obj);

    QMetaObject::invokeMethod(&b_channel, "foo",Q_ARG(QString, "baz"));

of course we can't support real calls on the object without another code generator, so direct calls need to use invokeMethod. what you can do though, is hooking the remote object into local signal connections, like

    connect(obj2, SIGNAL(foo(QString)),b_channel,SLOT(foo(QString()));

see http://qtnode.net/pastebin/5073 for a full example.

It was two weeks ago when Qxt turned one year and two days ago when svn passed revision 1000. Congrats guys!

A few pics from Trolltech Developer Days 2007 held in Munich: http://jpnurmi.kapsi.fi/devdays2007. Sorry for poor quality at times. I’m a lousy photo shooter.

Last weekend J-P, Benjamin , and myself were following Trolltechs invitation for devdays 2007 in Munich. Besides libQxt, also invited were lots of kde folks, as well as the devs of quasselirc.
We joined the coctail party at the first day. It was quiet... overwhelming when we arrived at the Hilton, one of the most expensive Hotels in Germany (of course we didn't stay there, but the devdays were helt there). Althought i'm not actually a soccer fan, i was quiet amazed seeing our german national team stepping aside.
Trolltech booked the entire floor, so they had to move :D
Besides the extremly expensive high class hotel, we also enjoyed meeting the heads of Qt and Qtopia. Including Bradley, whom we have to thank for all that :)

Isn't this a real pain: Qt is an event based toolkit, everything uses signals and slots, except QSqlQuery.....
This is not really qts fault but rather a limitation in the supported sql librarys. The common way to prevent a query from blocking your GUI is a thread, but since you can't call your GUI from a thread, you end up in serialising your data.
Oh you could use QxtSqlPackage and QxtRpcPeer, but in the end it's all so much hassle.

But fear not! Qxt has a Solution! It's called QxtSlotJob.

QSqlQuery query;
bool result = QxtSlotJob::detach(
              &thread,&query,SLOT(exec(QString)),
              Q_ARG(QString, "select NOW();"))
             .delayedResult(3000);
q.next();
qDebug()<<q.value(0).toDate();

Obviously this has something to do with Qxt::bind. It uses QxtBoundFunction. But what's that obscure detach and wait combination doing?

detach will yield a few complex internals to make sure your slot is executed on the thread you specified. It will not block but rather return QxtFuture which is internaly linked to the Job Object. ALthought using delayedResult on it looks kind of pointless, it's actualy black magic. delayedResult() will not block your gui thread, rather will it use QxtSignalWaiter to wait on the done() signal. That makes sure your gui still responds while we wait on the query to be finished.


The experienced user will have noticed i was cheating. Since QSqlQuery is not a QObject you have to wrap it, wich are aditional 9 LOC, but you only have to do it once.

class QueryWrapper : public QObject, public QSqlQuery
{
Q_OBJECT
public slots:
    bool exec(QString a)
    {
        return QSqlQuery::exec(a);
    }
};

Now that we have QxtWeb in the 0.2.4 release, and i finished rewriting www.libqxt.org in it, let me give you a short introduction what it actually is.

So is one of these true?
- You like the Qt Api
- You code Web Applications
- PHP makes you want to scream

Well those are all 3 true for me, that's why i simply invented a Qt Style Web Developement framework. Simple, yes, really. It's not actually that much complex. Well in the backend it is, but that's nothing you have to bother with.

Let me show some hello-world example:

class Page : public QxtWebController
{
Q_OBJECT
public:
   Page():QxtWebController("page"){}
public slots:
   int index()
   {
       echo()<<"Hello World";         return 0;     } }; 

so. what's this? well, obviously it just prints hello world, but where,how,what,why,whatever.
a QxtWebController is part of the M/V/C concept qxtweb has. It's the controller that grabs data from the model and pushes it into a view.
This concept is shamelessly stolen from Cake Php

You could of course just echo out html code but that's not really M/V/C so we invented templates. QxtHtmlTemplate to be precise. It uses php style variables in the html code which can get filled from the controller.

Ok so we can use Qt to have some fun with web applications, and now what's the advantage over all the other frameworks around?

it's Qt
yes, i love qt. really!

reuse
just image you code a gui application and want to put that thing into the web later. Future plans of QxtWeb even do that automaticly from a ui file.

state engine hacks
One thing that realy made me unhappy with common php is the flow. it is designed after http. Means it has a begining and an end. Even persistance frameworks cannot compensate that. Qxt tryes hard to keep the programing away from the http state engine and make it feel like coding Gui applications. for example you don't actually need to terminate the connection after a function has ended. just do it at any time later. (of course you need to be carefully with reentrance here)

did i mention it's qt?

After long time of developing (well the real work did not took so long, but there were so much other things to do) i have some working QxtScheduleView class.
I already used it in one of my other apps and it worked nice ;).

I'm not shure if i can put QxtScheduleView in the next release of libqxt.
But it will go into trunk in the next weeks. It also lacks all kind of docs so noone will know how to use it.
After i have QxtScheduleView finished for trunk i will start hacking the QxtScheduleWidget . It will have a internal Model and QxtScheduleWidgetItem that will make your life easier.

Well if someone wants to have a look at the current state,
the source can be checked out of my repository:

zbenjamin's sandbox
(https://libqxt.svn.sourceforge.net/svnroot/libqxt/sandbox/zbenjamin/QxtScheduleView/)

cya zbenjamin
"your friendly developer from the neighbourhood"

Hi there,

last time i added two new classes to Qxt:

• QxtStringValidator
  
• QxtFileLock.

QxtStringValidator was initialliy a class to validate over a QStringList, but this was not really worth to put it into Qxt. So i decided to make it more powerfull. Now it provides a String based validation over a QAbstractItemModel. :

QxtStringValidator validator = new QxtStringValidator();
validator->setLookupModel(myCoolCustomModel);

/*now we have to choose the right column
this will lookup in column 3, starting from row 0
*/
validator->setStartModelIndex(myCoolCustomModel->index(0,3));
//case insensitive lookup
validator->setCaseSensitivity(Qt::CaseInsensitive);
//and now set the validator to a lineEdit
lineEdit->setValidator(validator);

There are some other features like :

• wrapping lookup
• case sensitive/insensitive lookup
• recursive lookups
• looking up different model rows

And it is also possible to use a QStringList as data source (never forget your roots ;) ).

QxtFileLock is something i had in my mind for a long time since i thought about writing a isam filemanager based on QT. The first thing i realized was that there is no file lock available in Qt. Well it is possible but not using a nice crossplattform class like Qt offers them. So here is my solution for that:

void doSomeOpOnFile()
{
off_t lockStart = 0x10;
off_t lockLength = 20;
QxtFileLock readLock(&file,lockStart,lockLength,QxtFileLock::ReadLock);
if(readLock.lock())
{
/*do some read operations*/
/*the lock gets cleaned up after it is deleted it is not needed to call unlock()*/
QxtFileLock writeLock (&file,lockStart,lockLength,QxtFileLock::WriteLock);
if(writeLock.lock())
{
/*do some write operations*/
}
}
/*in this case we don't have to care about releasing the lock. QxtFileLock will do it when the instance is destroyed*/
}

I had to do some extra work on *nix based systems. On *nix a lock does not behave like a normal unix lock. In fact on *nix locks are process wide, means a process can get a lock on a file as often as it wants to. With QxtFileLock this is not possible, locks are threads and handles bound. That means: A Thread can writelock the same region of a file twice only if it uses the SAME handle. If a different handle holds the lock a call to lock() will fail.
On *nix we use fcntl and on windows LockFileEx to implement the locking stuff.

Attention: don't mix QxtFileLock and lockf or flock on linux they are NOT compatible.
Also use only fcntl to lock the files in other apps.

Well i hope these two classes can go into the 0.2.4 release.
Due to vacation and other things i had to do the QxtScheduleView did not make it into the trunk.

zbenjamin
"your friendly developer from the neighbourhood"

12::00 to 12:20 GMT libqxt.org and all sites hostet on exys where not reachable due to an attack from outside. A cpu was bursted and a harddisk started glowing (that's what the technican sayd at least, heh)

The Attackers started a massive POST request on a qxtweb instance from a single IP to all IPs of the system. The post was started announcing a 6GB file and imidiatly interupted leaving the socket open to starve, then the next was started. Due to a bug in the webserver we are using this coused thousands of defunct processes before the servers finaly died.

I reconstructed the scenario and my proof of concept shows several more bugs in several more webservers. The answer i got so far from the developers of the server we where using, was "NOT A BUG" , and "it's not our fault if the user sends broken POST requests, they might update their browser". As a consequence exys will switch back to apache the next days.

using QxtRPCPeer to transport signals over the network was already posible thanks to ahigerd. Well that was already realy exciting to see. Actualy just one connect on each side and you're done. The next step was using QxtRpcPeer over an arbitrary QIODevice. After a few hours even that was posible.

But, hold tight, you can actually do that over stdin with Qxt out of the box!
all you have to do is to start your client with QProcess and hook the started() signal so you can put QxtRPCPeer on it(QPocess is a QIODevice, yay) on the other side you start a QxtStdin (another QIODevice, double-yay) so you can, guess what, put QxtRPCPeer on it.

and that's all? yes!



client
host
----
update:
it's renamed to QxtStdio. works both ways now

I committed QxtMetaObject::bind and QxtMetaObject::connect to the trunk last night. These are an answer to the classic newbie mistake:

    connect(button, SIGNAL(clicked()), myObject, SLOT(doSomething(123)));    // wait, that doesn't work

Experienced Qt developers will immediately spot that not only do the function signatures here not match, but you can't specify parameter values in the connect call. QxtBoundFunction introduces this behavior:

using namespace QxtMetaObject;
                connect(button, SIGNAL(clicked()), bind(myObject, SLOT(doSomething(int)), Q_ARG(int, 123)));

Now, when button->clicked() is emitted, myObject->doSomething(123) will be called. It's not the most elegant syntax in the world, I know, but it's how Qt does things so I just followed the crowd.


This isn't all, though. You can also bind to parameters from the signal:

    connect(lineEdit, SIGNAL(textChanged(QString)),
                        bind(myObject, SLOT(doSomething(int, QString)), Q_ARG(int, 123), QXT_BIND(1)));

QXT_BIND(n) is a reference to the nth parameter from the signal, which is filled in with its value when the signal is emitted. Therefore, lineEdit->textChanged("foobar") will now trigger myObject->doSomething(123, "foobar").


My next task is to add an invoke() method that can call a bound function with a given set of parameters, without needing signals or connections. This is mostly useful for generic programming -- callbacks and such. I'll have to tinker with it for a while to figure out the best way to handle return values.

This is a story of a programmer who participated in the Qt Centre programming contest.

January
The contest was announced in January 2007, the same time when Qt Centre was celebrating its first anniversary. As an active user on the forum, I really wanted to participate, but the problem was that I had no decent idea. Luckily, at the end of the same month, someone special (sorry for forgetting your nick) stopped by on #qt. He was looking for a label which can be shrunk below to its preferred size while it automatically elides any text that doesn’t fit. This is where everything started — I decided to write one. On 30th January I joined the Qxt team which consists of some #qt regulars. The same day I introduced QxtLabel which is able to elide its contents as requested. As a further addition, QxtLabel was made rotatable.

A rotatable button — QxtPushbutton — followed immediately after QxtLabel. Later during the spring QxtPushbutton was also improved with rich text support.

February
The next target was to write a delegate being able to decorate top level items in a tree, like Qt Designer does. This is how QxtItemDelegate and QxtTreeWidget were born. The original plan was to write a bunch of different kind of styles (including a popular MS Office look) but sadly only two were gathered up so far. Later during the spring QxtItemDelegate was extended with a progress role. Returning valid data for QxtItemDelegate::ProgressRole makes the delegate to render an item as a progress bar in a similar way than the torrent example does.

Somewhere in the middle of February a couple of more classes — QxtTabWidget and QxtApplication — were introduced. QxtTabWidget attempts to make it extremely easy to handle tab specific context menus. QxtTabWidget supports same context menu policies than QWidget does but per tab. QxtApplication (improvised by this thread) makes it possible to register global shortcuts that trigger even while application is inactive.

March
In the next turn of month, I decided to add QxtCheckComboBox — a combo box with checkable items. Thanks go to qiank128 for the original idea and aep for throwing out the idea of different checking modes. Thanks to him it’s possible to choose whether items are checked by clicking anywhere on an item or just inside a check indicator.

While suffering from a temporary lack of improvisation, I decided to include a couple of a simple classes — QxtStringSpinBox and QxtProxyStyle. The former is a simple QStringList wrapper for QSpinBox to have textual items instead of numbers and the latter is the famous proxy style as discussed in Qt Quarterly 9.

April
The mission was continued with addition of QxtSpanSlider which is a slider with two handles. The idea for a double headed slider was yet again adapted from various posts at Qt Centre. This must have been the most challenging widget of the submission of mine. On the other hand, the most challenging utility class was definitely QxtDesktopWidget on which I started working next. QxtDesktopWidget provides access to all windows on the desktop, not just Qt ones, but also native windows. This makes it rather simple to for example implement a screenshot application. As a proof of concept, I did a quick port of KSnapshot. QxtSnapshot is included as a demo in the submission package.

Suddenly — while working with tooltips — I got an idea of QxtToolTip which would allow one to show any arbitrary widget as a tooltip. I somehow felt QToolTip a bit restrictive. By this time I had also plucked up enough courage to actually register to the contest. Funnily enough, the reply got somehow marked as spam so for a while I didn’t even notice the approval of my contest entry.

May
The approaching deadline run me into going through what I’ve had gathered together so far. The beginning of May was time of improvements in documentation, some little refactoring and writing of demo apps & unit tests. Somewhere in the middle of May I got a nice little boost. Yet half a doze new classes were introduced.

QxtDockWidget fills in the gap in QDockWidget and makes the dock widget to remember its size while toggling visibility off and on. QxtListWidget, QxtTableWidget and respective item classes provide more convenience such as editing notifications, check state changes and item flag handling. QxtStars is a funny little stars assessment widget. QxtProgressLabel does the work for you and automatically calculates the estimated time awaiting while being connected to a QProgressBar. QxtGroupBox is a checkable group box that automatically shows/hides its content according to the check state. Behaviour is pretty much identical to GtkExpander. A couple of last minute additions were QxtConfigDialog and QxtConfirmationMessage. The former wraps common type of a config dialog into a convenient API and the latter provides an common confirmation message with “do not show again” option.

According to this post, the judging process is soon about to finish. I’m eagerly waiting for the results. My personal favourite is definitely the Marple Desktop Globe. It looks awesome!

Hi, Qxt!

~ahigerd

"Wait a minute," you might ask, "why can Qxt be distributed under the CPL, when it's based on the open-source version of Qt, which is licensed under the GNU GPL?"

That is a very good question, and the answer isn't easy to find.

Qxt was originally written under a disjunctive license that stated that it was GPL if linked against GPL Qt, QPL if linked against QPL Qt, and LGPL if linked against commercial Qt. This wasn't exactly an ideal solution, but it seemed like it would work, at first, but it didn't stand up to closer examination.

Some research discovered an entry on Trolltech's knowledge base that said that anyone could write a Qt program and release it under any license compatible with the GPL. There was also a page documenting an exception to the GPL that allowed open-source Qt programs to be distributed under a certain list of alternate licenses. Qxt was relicensed under the LGPL at this time, since it seemed appropriate, and ahigerd continued to research to make sure that the LGPL really was the correct license and to make sure that an LGPL Qt library could be used with closed-source commercial Qt applications. (There's a clause in the commercial Qt license forbidding the incorporation of code developed with the open-source version of Qt.)

Unfortunately, the knowledge base entry and the GPL exception said different things about this, and to make matters worse, the GPL exception vanished from the Trolltech website, and it couldn't be found in any of the source code packages. ahigerd spent three months in communication with Trolltech Sales, and eventually one of Trolltech's attorneys, to iron out the details. Meanwhile, he also continued researching licenses; the LGPL had a few problems that made using Qxt in closed-source applications worrisome, even if it may have been technically possible.

In the end, the members of the Qxt project decided on the CPL as a much more straightforward alternative to the LGPL, one of Trolltech's attorneys confirmed the validity of the GPL exception and invalidated the knowledge base entry, and one of Trolltech's developers e-mailed the project managers a copy of the GPL exception, which is now available in Qxt SVN for reference.

benjamin and me had some kind of mini meeting last LinuxTag. i wanted to report earlier but could not for *cough* technical reasons.
The further development of QxtScheduleView, QxtWebWidgets, and the Qt persistance framework was on discussed while eating pizza and abusing our hands and arms as a scratchpad.
Later then back to the camping side we had some fun, beer, and found some australians to entertain us. LinuxTag was disapointing due to... well... i mean.. whatever. At least the Trolltech talks where awesome, as expected. My question how they solved the problem of absense of pointers was answered by quiet elegant trying to not say they actualy invented pointers in java. Uh we love the Trolls for the meta hacks, don't we.
Ah right, introduction, benjamin is at the left and me is the guy at the right with the weird hairdo. ya and i wear a qxt shirt. And we're drinking Leikeim what has a thingy - the dutch girls told us - is named "plopper".