#include <QLineEdit>
#include <QApplication>

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

    QLineEdit *le = new QLineEdit(argv[1]);
    le->show();

    app.exec();
}

Of course, all this led to some very frustrating searching - in the QT Assistant as well as the web but there were no answers ... why on earth is my QLineEdit not resizing to show the entire string and how do I make it do so? There is no member function to do so directly.

As always, out of desparation, I fired up QT Designer and drew a QLineEdit widget and dragged it to be longer than its default length. When I saw the generated code, my heart sank ... the length of the widget was hard-wired in the code and so I couldn't use it as a generic solution. Back to digging in the documentation.

To cut off the rest of the drama and frustration, I finally got it working with the following code:

#include <QLineEdit>
#include <QFontMetrics>
#include <QApplication>

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

    QLineEdit *le = new QLineEdit(argv[1]);
    QFontMetrics fm = le->fontMetrics();
    le->setMinimumWidth(fm.width(argv[1]) + 20);
    le->show();

    app.exec();
}

./a.out /var/cache/apt/archives/stardict-common_3.0.1-4_all.deb

Took me about 3 hours to figure it out! This is so frustrating. I wish QT assistant had some "QT recipes" section for such small, "trivial" stuff that beginners might struggle with.

... Or perhaps I'm the only one dumb enough to not see how its done!

Anyhow, if you were also wondering how to make a QLineEdit widget display its entire contents, you know how its done now.

Ok, today I'm talking about a topic you probably don't know (yet): aMSN2.

Let's go straight to the point: aMSN2 is the next generation MSN clone. Multiplatform, multifrontend (yeah, I meant multifrontend) and written in Python.

I've been working on the core and on the Qt4 frontend. I wanted to show you a screencast, but somehow something went nuts on my PC and everything I can get is a crappy video full of redrawing bugs. But nevermind, I took some photos :)

Oh, yeah, the Qt4 login window, powered by QSS super powers, copyright by Profox. Already working with all the goodness. But let me show you something more interesting...

aMSN2 is the widget on the left, with my test account logged in. I made some chatting with my real account logged into emesene (on the right) to demonstrate chatting works.

Ok, chatting GUI still sucks, but what matters the most is that aMSN2 can already chat, send/receive typing notifications, send/receive nudges & status updates, and receive custom emoticons (even if they're not correctly handled yet). In short, it's taking shape :)

Please don't forget this is still work in progress, unstable, it might kill random members of your family or pets. And, quoting Kakaroto, every time the "When will it be released?" question get asked, we delay release of a month. So keep quiet!

But, for developers' sake, we have a git repository where we keep the code. It is here: http://github.com/drf/amsn2/tree/master .
If you're interested in helping (we need EFL, GTK, Cocoa [Mac frontend], Qt, and general python developers), just fork the repository, work on some patches, and send a pull request. One of the reason we are using git in this stage it's that it makes external contribution easier. Not to mention the #amsn channel on freenode, our base.

So stay excited, and see you on next aMSN post!

I wrote a simple program to display the properties of a file in a window - full path, UID, GID, etc. In keeping with OO styles, I went and defined a new class for this kind of dialog window:

// Class declaration 
class statDlg : public QWidget {
    Q_OBJECT
private:
    QString   fsize;
    QFileInfo finfo;
    QLabel *path_val;
    QLabel *ftype_val;
    QLabel *owner_val;
    QLabel *grp_val;
    QLabel *size_val;
    QLabel *atime_val;
    QLabel *mtime_val;
    QLabel *ctime_val;
    QFormLayout      *form;
    QDialogButtonBox *okBtn;
    QVBoxLayout      *dlg_grid;
    void getFileType(void);
public:
    statDlg(QString fpath);
    void showinfo(void);
};

// In the constructor 
    ...
    owner_val = new QLabel(finfo.owner());
    form->addRow(tr("Owner:"), owner_val);
    grp_val = new QLabel(finfo.group());
    form->addRow(tr("Group:"), grp_val);
    ...

When I ran it, it did what was expected. Great!

The next step, of course, was to see if I could do any code cleanups. Since I come from an "embedded C" background, I view having to dynamically allocate so many child widgets as rather wasteful - after all they're part of the entire dialog box - they get used only by the dialog box and get destroyed when the dialog box is destroyed. Why needlessly dynamically allocate memory for these objects - the memory used wheter these members are statically allocated as part of the class or dynamically allocated is the same?

So I proceeded to change the pointers to ordinary non-pointer member variables ...

class statDlg : public QWidget {
    Q_OBJECT
private:
    QString   fsize;
    QFileInfo finfo;
    QLabel path_val;
    QLabel ftype_val;
    QLabel owner_val;
    QLabel grp_val;
    QLabel size_val;
    QLabel atime_val;
    QLabel mtime_val;
    QLabel ctime_val;
    QFormLayout      form;
    QDialogButtonBox okBtn;
    QVBoxLayout      dlg_grid;
    void getFileType(void);
public:
    statDlg(QString fpath);
    void showinfo(void);
};

// Needless dynamic allocations removed 
    ...
    owner_val.setText(finfo.owner());
    form.addRow(tr("Owner:"), &owner_val);
    grp_val.setText(finfo.group());
    form.addRow(tr("Group:"), &grp_val);
    ...

The compilation went fine and so did the execution ... until I quit the application, upon which I got a big "oops":

*** glibc detected *** ./qstat: free(): invalid pointer: 0x00007fff328fa588 ***
======= Backtrace: =========
/lib/libc.so.6[0x7fe828abd968]
/lib/libc.so.6(cfree+0x76)[0x7fe828abfa76]
/usr/lib/libQtGui.so.4(_ZN10QBoxLayoutD2Ev+0xf3)[0x7fe829d70c83]
./qstat[0x40617a]
./qstat[0x405037]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7fe828a681a6]
./qstat(_ZNK7QWidget6metricEN12QPaintDevice17PaintDeviceMetricE+0x89)[0x403709]
======= Memory map: ========
...

Ouch!! What did I do wrong? I scoured my code all over, to see if I had forgotten to pass the address of a widget (and passed the widget itself by mistake) ... nope, no problem. A backtrace obtained by running it in GDB showed:

#0  0x00007f44e5cc5ef5 in raise () from /lib/libc.so.6
#1  0x00007f44e5cc7413 in abort () from /lib/libc.so.6
#2  0x00007f44e5d023e8 in ?? () from /lib/libc.so.6
#3  0x00007f44e5d07968 in ?? () from /lib/libc.so.6
#4  0x00007f44e5d09a76 in free () from /lib/libc.so.6
#5  0x00007f44e6fbac83 in QBoxLayout::~QBoxLayout () from /usr/lib/libQtGui.so.4
#6  0x000000000040617a in ~statDlg (this=0x7fffefb46600) at qstat.h:13
#7  0x0000000000405037 in main (argc=2, argv=0x7fffefb468e8) at qstat.cc:84

Aha, so the problem is in a call to the QBoxLayout destructor. But my class does not define any destructor function - it relies on the parent destructor to do the cleanup required. So where's the problem?

After battling around for an hour I scoured the net for clues ... didn't get any helpful results. I got an old post where the poster encountered the same problem as me but there were no replies to the post.

Out of desperation, I just took a wild guess and googled for "qt widgets must be dynamically allocated".

Bingo! A thread way back in 1997 mentioned that:

You can't really do this - Qt expects every widget to be allocated
on the heap with new, if they aren't then you'll get a segmentation fault in
your destructor.

Aha, thats exactly what was happening. However, as noted by the original poster of that thread, there is no mention of this in the QT documentation and, even now, more than 10 years later, I can't seem to find any mention of this behavior in the QT documentation (as provided by "QT Assistant")!

So, if you're another QT newbie, pulling out your hair and wondering why your QT application is crashing when your widgets are not dynamically allocated, its because thats a design restriction imposed by QT.

Ugh! The more I use QT the more I seem to dislike it :(. Of course, I haven't used other toolkits (other than Tk which I find elegant in design, but thats at another level so its not fair to compare it with QT) so I won't (outright) say that QT is bad, ... just that I'm not liking it :(.

BTW, since I was stuck with dynamically allocating the widgets, I ended up with the following code:

// Class declaration
class statDlg : public QWidget {
  Q_OBJECT
private:
  QString   fsize;
  QFileInfo finfo;

  QFormLayout      *form;
  QDialogButtonBox *okBtn;
  QVBoxLayout      *dlg_grid;

  void getFileType(void);
public:
    statDlg(QString fpath);
    void showinfo(void);
};

// Code 
    ...
    form->addRow(tr("Owner:"), new QLabel(finfo.owner()));
    form->addRow(tr("Group:"), new QLabel(finfo.group()));
    ...

I was trying to write a simple widget that contains a QFrame. What I wanted was something like this:

But I ended up with something like this:

I had to resize the window to show all the widgets.

The code itself was simple enough:

    this->setWindowTitle("Show/Hide Widgets");

    container = new QFrame(this);
    container->setFrameStyle(QFrame::StyledPanel | QFrame::Plain);
    container->setContentsMargins(10, 10, 10, 10);

    vlayout = new QVBoxLayout(container);

    label1  = new ToggleText("Label 1");
    label2  = new ToggleText("Label 2");
    hlayout = new QHBoxLayout;
    vlayout->addWidget(label1);
    vlayout->addWidget(label2);
    vlayout->addStretch();
    vlayout->addLayout(hlayout);

    toggleBtn   = new QPushButton("&Show/Hide");
    dellabelBtn = new QPushButton("&Delete");
    quitBtn     = new QPushButton("&Quit");
    hlayout->addWidget(toggleBtn);
    hlayout->addWidget(dellabelBtn);
    hlayout->addWidget(quitBtn);

I searched the net and got nothing. I skimmed through the QFrame reference documentation in QT Assistant N number of times but didn't get anything. Finally, in sheer desperation, I decided to go through the list of all member functions of the QFrame widget (including those inherited by QFrame). I should've done this earlier ... an adjustSize() member function caught my eye. When I added the following lines to the function:

    ...
    hlayout->addWidget(toggleBtn);
    hlayout->addWidget(dellabelBtn);
    hlayout->addWidget(quitBtn);

    container->adjustSize();
    this->adjustSize();

I got the following result:

Perfect :).

So, just in case somebody out there is struggling with the same problem and wondering why their windows aren't getting created with the correct size, ... try the adjustSize() method :).

IT http://www.archlinux.it/forum/viewtopic.php?pid=20192
INT http://bbs.archlinux.org/viewtopic.php?pid=429971

Avevo praticamente trovato tutto, cosa mancava? Un programma per l'editing grafico che sostituisse gimp, pare infatti che l'unico al momento sia Krita, completamente dipendente da KDE, in alternativa c'è pixel a pagamento. Ci sono andato vicino ma aimè ho dovuto abbandonare il mio desktop qt-based per tornare a gtk2+...spero di trovare presto un programma grafico qt che sostituisca gimp!

To avoid this problem one could use the Qt Resource files to produce a .py module and then access all the icons from this module. First, you must create a .qrc file with the details of the resources you want to include. The .qrc file is a simple XML text file like the example below:

[sourcecode language='html']


images/appicon.png
images/exit.png
images/fileexport.png
images/fileimport.png
images/fileopen.png
images/help.png


[/sourcecode]

Then you must run pyrcc4 with the following command to produce a resource module from this resource file

pyrcc4 -o resources_rc.py resources.qrc

Finally, you import your resources_rc.py module into your main application and you can use images with the following syntax: QIcon(":/help.png"), where the leading :/ informs PyQt that you are using a resource file.

You can also use resource files with Qt Designer as the following image suggests.

After the creation of your resources you can simple drag and drop an icon, for example, from the Resource Editor into the icon property of the object you want to add a icon in your Property Editor.

Have fun!

per sistemare la situazione installate il pacchetto gtk-qt-engine

pacman -S gtk-qt-engine

riavviate kde e poi mi dite la differenza!

qmake -project
qmake -spec macx-g++ yourprojectname.pro

after that you can run:

qmake
make

(And your program is compiled)

You can now edit the pro -file as suits you best. To make it effect again, run qmake without parameters. If you encounter weird errors after changing the .pro -file, it might be because you have not run make clean. So after doing this, always run make clean before attempting to compile, otherwise you may get some headaches about issues that actually do not exist.

Das soll dann auch erstmal für heute reichen, evtl. setze ich das bei Gelegenheit ja mal fort.

Evidentemente a Nokia il nome Trolltech non andava molto a genio: il colosso norvegese ha infatti rinominato Trolltech in “Qt Software” ed il framework per dispositivi mobile/embedded Qtopia in “Qt Extended”. Nello stesso giorno del cambio di nome sono stati aperti i sorgenti della versione Linux di Qt Eclipse Integration e rilasciati Qt Extended (Qtopia) 4.4 e Qt Jambi 4.4.3. Per chi fosse interessato, Ars Technica offre una panoramica delle novità incluse in Qt Extended 4.4.

In occasione della sua adesione alla Linux Foundation come Gold Sponsor, Nokia ha inoltre svelato alcune delle caratteristiche della prossima versione di Maemo, la sua piattaforma per Internet Tablet: tra queste sono presenti la compatibilità con il protocollo HSPA, la migrazione ai processori OMAP3 di Texas Instrument ed il supporto a sensori grafici ad alta definizione

[via: phoronix.com || ossblog.it]

Sì, questa serie di classi sono molto potenti, inoltre sono multi piattaforma, ovvero funzionano per Microsoft Windows, Mac OS X, GNU/Linux, FreeBSD, OpenBSD, NetBSD e Unix vari. Ovvero si ha la comodità di scrivere il codice una volta e di ricompilarlo sulle varie piattaforme. Qt ha due licenze. Una licenza libera (GPL, LGPL, ...) e una commerciale. La prima permette di usare le Qt per una applicazione che sarà rilasciata con una licenza libera di cui si rende disponibile tutto il codice sorgente. La seconda è per coloro che non vogliono mettere a disposizione i sorgenti, ma desiderano vendere l'applicazione e rilasciare solo il file eseguibile. Qt è disponibile anche per Windows CE e permette di creare applicazioni per diversi dispositivi embedded, ovvero "computer" di piccola dimensione di limitate prestazioni (poca memoria, processore "lento"). Sul sito di Trolltech troverete tutte le informazioni: www.trolltech.com. Trolltech, inoltre, è stata acquisita da Nokia e il che fa ben sperare. La qualità e la versatilità del codice renderà disponibili le Qt anche per dispositivi Nokia di ultima generazione che sono a metà strada tra un cellulare e un palmare dove si annotano appuntamenti, si naviga su internet, ci si può collegare a una rete wireless ecc...

Il contest 2008

Ritorniamo a parlare di questo famoso Contest 2008. In pratica la Trolltech/Nokia mette a disposizione dei premi per il miglior codice C++ scritto con le Qt. Una bella sfida. Ci sono varie categorie. Programmare con Qt è una cosa davvero rilassante. Si fanno tante cose con poco codice. Per esempio, mostrai come creare un browser elementare a dei ragazzi a Open Mind con tre linee di codice grazie a QtWebKit.

Al contest ho presentato QRunner. Ancora non scaricabile da nessuna parte. L'idea è venuta fuori a un mio collega di lavoro quando circa due anni fa ci ritrovavamo a fare dei test per un gateway/router basato su una distribuzione GNU/Linux. Eravamo costretti a fare sempre clic e clic e clic. Allora il mio collega pensò a organizzare una serie di script per testare le funzionalità Web con cui si configurava il gateway/router multifunzione e pensò anche di farmi realizzare una interfaccia grafica per gestire gli stessi script. Organizzarli in gruppi e sottogruppi. Abilitare e disabilitare alcuni di essi senza rimuoverli dal progetto. Associare delle proprietà a ogni singolo script in modo indipendente dagli altri. Proprietà come l'esecuzione ripetuta di uno script per N volte, possibilità di avere una linea di comando per lo script e un proprio ambiente di esecuzione (assegnando delle variabili d'ambiente). Mi misi con interesse perché prima di allora avevo programmato solo con Qt3, quindi era un buon motivo per mettere mano alle Qt4 e ne restai travolto. Le Qt3 mi piacevano, ma le Qt4 sono ancora meglio. Hanno rivoluzionato la programmazione C++ anche se oggi nessuno, in ambito lavorativo, le usa... Non sanno cosa si perdono ;) (Tutti si rivolgono a Java, Java e Java, anche per mettere su applicazioni che una volta si facevano con M$ Visual Studio in C++).

L'applicazione salva il progetto in XML, carica il progetto riassegnando tutte le proprietà agli script e durante l'esecuzione degli stessi si producono dei file di log accessibili sia all'atto dell'esecuzione dello script sia in seguito alla chiusura dello stesso. Si può decidere di non eseguire l'intero progetto ma un solo sottogruppo di script, o anche uno solo. Si possono immette parametri a tempo di esecuzione se lo script ne necessita. L'attività e l'evoluzione dei processi è resa anche in modalità grafica, ovvero uno script in esecuzione diventa arancione e diventa rosso se per qualche motivo si sono verificati errori o verde se è terminato correttamente.

Il contest è interessante perché mi ha dato la possibilità di imparare e giocare molto con il Drag & Drop, infatti gli script vengono immessi nel progetto trascinandoli direttamente dal file system, inoltre il codice verrà valutato da un serie di esperti e finalmente potrò capire quanto sono bravo/pessimo nello scrivere in C++ :) .

In attesa dei risultati, se volete e se vi ho sufficientemente incuriositi, è possibile scaricare da KDE Italia una presentazione per imparare le basi minime per operare con Qt. Sono un semplice punto di partenza, ma sono sufficienti per cominciare con piccole applicazioni.

1. Check for compiler warnings about non-existent signals and/or slots.

2. Use break points or qDebug to check that signal and slot code is definitely reached:
- the connect statement
- code where the signal is fired
- the slot code.

3. Check that the parameter types of the signal and slot are exactly correct and, as appropriate, that they match.

4. Make sure you haven't added a name to the signal or slot argument: for example, use textChanged(const QString &) not textChanged(const QString &text).

5. Check that the connect argument types and syntax are correct. The connect statement should look like this: SIGNAL(mySignal(...)), receiver object, SLOT(mySlot(...)). Check brackets, check that SIGNAL and SLOT are capitalised and that the sender and receiver are both objects, not class names.

6. Check that the signal is being fired as expected. You can do this with code like the following:
connect(this, SIGNAL(mySignal()), qApp, SLOT(aboutQt()));

7. Check that slots are declared correctly in the public/protected/private slots sections of your class declaration (not the public/protected/private sections).

8. If you use custom signals, check that these are declared correctly, with a void return type, in the signals section of your class declaration.

9. Make sure the Q_OBJECT macro is inserted at the beginning of your class declaration.

10. Check that classes using signals and slots inherit QObject or a QObject subclass.

11. Make sure to run qmake after adding the Q_OBJECT macro to a class.

12. Use break points or qDebug to check that slots are being called the appropriate number of times: make sure the connection isn't made repeatedly.

13. Put all connect statements before functions calls that may fire their signals, to ensure that the connections are made before the signals are fired. For example:

   _myObj = new MyClass();
   connect(_myObj, SIGNAL(somethingHappend()), SLOT(doSomething()));
   _myObj->init();

not

   _myObj = new MyClass();
   _myObj->init();
   connect(_myObj, SIGNAL(somethingHappend()), SLOT(doSomething()));

14. Check that your connections aren't affected by disconnect statements.

15. Don't add a semi-colon after Q_OBJECT:

   {
   Q_OBJECT
   ...
   }

not

   {
   Q_OBJECT;
   ... 
   }

16. Check the return value of the connect statement: connect returns true if it successfully connects the signal to the slot.

17. Follow Qt's naming conventions for signals and slots:

signal: somethingHappened()
slot: doSomething()

In grammatical terms, signal names are usually constructed from a past participle: changed, pressed, etc. They describe an event or change of state that has occurred. Slot names are imperative verbs and describe an action to be done: clear, setDate, etc. ]]> http://drfav.wordpress.com/?p=53 Wed, 01 Oct 2008 23:05:00 +0000 drfav http://drfav.pl.wordpress.com/2008/10/02/inhibiting/ Disclaimer: this post is mainly for Developers!!

That said, I thought a blog post would have been better to explain the new, cool Inhibition feature in PowerDevil/Solid. On my message to the list I've been unclear, and let me say _don't use the DBus interface_ but the provided methods. So let me show a sample of an application inhibiting suspension.

void InhibitTest::setInhibition()
{
kDebug() << "Setting inhibition";
m_cookie = Solid::PowerManagement::beginSuppressingSleep("We're testing inhibition, don't bother us!");
}

int main(int argc, char **argv)
{
KAboutData aboutData( "testinhibit", 0, ki18n("Test Inhibition"),
"1.0", ki18n(""), KAboutData::License_GPL,
ki18n(""), ki18n(""));
KCmdLineArgs::init(argc, argv, &aboutData);
KApplication app(true);
app.setQuitOnLastWindowClosed(false);
InhibitTest test;
test.setInhibition();
QTimer::singleShot(15000, &test, SLOT(releaseInhibition()));
app.exec();
}

Seen how easy it is? You just have to call the static method Solid::PowerManagement::beginSuppressingSleep() specifying a reason for your inhibition, and store the cookie it returns. If you try to suspend after you call it, you get this:

Yeah, I've also improved notifications, but this will come in a future post :D The user will be notified and suspension won't happen.

When you want to release the lock, Solid::PowerManagement::stopSuppressingSleep() is your friend, just pass it the cookie you stored before (you did store it, right?), and that's enough.

This feature is really cool. I see a lot of cool usages, for example in video players, package managers, whatever else. And given the fact it's just a private member+2 lines of code, integration is really easy :)

P.S.: A post with all new cool stuff in Powerdevil is coming, and PowerDevil 1.3.0 for KDE4.1 is coming too :)