Debugging a socket. Coders with a wizzard hat.

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 ;)

leaving freenode. open letter to the Qt community

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

new faces at qxt /some fun with berkeley db

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.

Nokia aquires Trolltech

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/

marshal objects with qt

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.

DevDays 2007

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 :)

the end of all blocking sql querys.

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);
    }
};