Basic Qt4 tutorial needed

[wysota]

[QUOTE=pthomas]Thanks for the links, however I've been through each one of those links already before posting and still couldn't put the whole picture together for creating a simple dialog with them.[quote]

The first link is the most helpful, but isn't quite what I'm looking for.

What are you loking for then?

And the last 3 either don't deal with Qt4,

Do they have to deal with Qt4? The overall mechanism is identical both in Qt3 and Qt4. Only minor things changed when it comes to the technique of writing applications and they are covered (those changes) either by that video tutorial from Trolltech or one of Johan's articles at digitalfanatics. If you want a huge tutorial about eveything, you won't find it.

or don't have any tutorials at all (link 2).

They do, you didn't look well enough (although they may not necessary be walk-by-hand tutorials).

I'm still trying to figure out how to get my simple dialog working, I've been referencing this link mainly, but still no luck.

What is wrong with your dialog? I stress it once again, that you CAN'T use KDevelop's embedded Designer component to create Qt4 widgets, I think that's your problem -- you don't have any Qt4 features of Designer.

http://doc.trolltech.com/4.1/designe...component.html
Sure it talks about sub classing the dialog, but the dialog they build leading up to that point isn't straight forward. They jump around way too much.

Could you explain? I don't see them jumping around, just presenting choices one has -- that page is especialy usefull for people transfering from Qt3.

I can build a dialog with Qt4 designer, but can't figure out how to make use of it. I can hop in Kdevelop ( I agree Kdevelop doesn't have Qt4 designer integrated!) and then can create a new project (c++ -> QMake project -> Hello world). Then under the project settings, select Qt4 and give it the path to the header files and such (/usr/include/qt4). Then in the automake manager I can add a main.cpp and the created dialog. But now what? Subclass the .UI file? Thats where I get the most lost.

You can't use KDevelop to manage Qt4 project, please remember that. You have to do it by changing the .pro file directly and making sure KDevelop doesn't mess it up. And answering your last question -- that's where the tutorial page you mentioned comes in -- you have there different choices you can take at that moment. One way or the other, you have to create a class derived from one of Qt widget classes and apply that UI there. It is explained in the tutorial how to do it.

[pthomas]

Thanks for the links, however I've been through each one of those links already before posting and still couldn't put the whole picture together for creating a simple dialog with them.

What are you loking for then?

Oh man. I'm not sure, but I'll know if I find it! I kind of did last night while I was still searching around and experimenting with stuff... Qt enlightenment

They do, you didn't look well enough (although they may not necessary be walk-by-hand tutorials).

- Yup, I agree.

What is wrong with your dialog? I stress it once again, that you CAN'T use KDevelop's embedded Designer component to create Qt4 widgets, I think that's your problem -- you don't have any Qt4 features of Designer.

I think I was still suffering from lack of understanding. I did actually get it working late last night. It was more of me not understanding how to use the .ui files after creating them with the designer. I'm going to give another one a try tonight. That was part of my problem originally too I think, using the designer in Kdevelop. I stopped using it shortly after opening this post.

Could you explain? I don't see them jumping around, just presenting choices one has -- that page is especialy usefull for people transfering from Qt3.

I wrote that badly, I meant the pages leading up to that link. Like if you click on that link and then jump back a few pages to where they first begin the dialog creation. I was trying to use it more like a how-to, but its more for reference.

You can't use KDevelop to manage Qt4 project, please remember that. You have to do it by changing the .pro file directly and making sure KDevelop doesn't mess it up. And answering your last question -- that's where the tutorial page you mentioned comes in -- you have there different choices you can take at that moment. One way or the other, you have to create a class derived from one of Qt widget classes and apply that UI there. It is explained in the tutorial how to do it.

Actually starting with version 3.3.x you can. They even stated Qt4 support on their features page for this release. And from my experience last night, it works quite well provided you setup the project right and then only use the Automake manager for adding/removing files.

Thanks for the help,
Paul

[wysota]

Actually starting with version 3.3.x you can.

Actually you can't. At least not in my definition of the word "manage". I mean a Qt project not a KDE one. Qt projects are managed by QMake, not by automake and KDevelop's QMake project manager doesn't support Qt4 at all. I'd even say in anti-supports it, as it breaks Qt4 project files and you can't do anything about it. You can't even compile a project using Qt4 out of the box. The only thing that works there is providing proper include names while defining superclasses to a class. I know KDevelop is a KDE project and KDE people use automake instead of QMake, but in my opinion "support" is not about using one of the undocumented options to make something work but to work by default (it's not documented anywhere that this "support" concerns only automake based projects).

[pthomas]

What type of IDE or what programs do you use for your Qt development stuff? It seems like the best way so far might just be a combination of the Qt Designer for dialogs and main windows + Kate for code editing.

Is there another good combination/IDE that you would recommend?
Paul

[wysota]

Qt Designer+Qt Assistant+Qt Linguist+Kdevelop

[kandalf]

to pthomas:
Here you can find a good explanation of changes in .ui files.

For coding you can still using KDevelop and manage .pro files by hand or by qmake if you rather prefer.
About subclassing ui, you can run uic by hand on the .ui file like:

uic somefile.ui >somefile.h

uic somefile.ui >somefile.h

To copy to clipboard, switch view to plain text mode 

and then use the header generated file as a normal file with a parent class definition.

Hope it helps.

[cioannou]

I use KDevelop in linux and Code::blocks under windows.

You can find my first Qt4 successfull attempt in creating a simple dialog with designer and add two buttons and custom slots.

http://www.qtcentre.org/forum/showpo...4&postcount=27

Hope this helps

[niko]

i found this imho very good book:
http://cartan.cas.suffolk.edu/moin/O...page=main.html

it probably could help you
(however it doesn't contain designer)

[Matt Smith]

What type of IDE or what programs do you use for your Qt development stuff? It seems like the best way so far might just be a combination of the Qt Designer for dialogs and main windows + Kate for code editing.

Is there another good combination/IDE that you would recommend?
Paul

I don't think there is one, right now. KDE 4 is not due out until towards the end of this year, although it's likely that KDevelop will start supporting Qt4 projects before then (at least, I hope they would). I do most of my development with Emacs (recent versions I've used don't seem to have the formatting versions which were a pain in the backside when writing Q_OBJECT header files in particuar), and compile with qmake and make.

[ucntcme]

Actually you can't. At least not in my definition of the word "manage". I mean a Qt project not a KDE one. Qt projects are managed by QMake, not by automake and KDevelop's QMake project manager doesn't support Qt4 at all. I'd even say in anti-supports it, as it breaks Qt4 project files and you can't do anything about it. You can't even compile a project using Qt4 out of the box. The only thing that works there is providing proper include names while defining superclasses to a class. I know KDevelop is a KDE project and KDE people use automake instead of QMake, but in my opinion "support" is not about using one of the undocumented options to make something work but to work by default (it's not documented anywhere that this "support" concerns only automake based projects).

I would be interested in hearing your definition of the word manage. I am using Kdevelop 3.3, and using it for my QT4 stuff quite well. It won't compile the included sample app, but it is compiling my QT4 projects just fine. Granted, I did set QT4 in the options box for the project options.

I'm using qmake, and so far everything works just fine for me. When I click the build project button on a new project it tells me I need to run qmake first, and then asks me if I want to go ahead and do that. How is that broken or not using qmake? If I make clean and/or take my .pro along with headers and code files, move them all to a new directory, run qmake then make, it all wokrs[1] just fine.

Maybe something somewhere is broken I'll grant indeed as noted above something is. As I am new to Qt and Kdevelop (not to mention KDE .. I've tried it every few years for a long time but until now never for this long), I'd be interested in exactly how the above behaviour is broken .. mainly so I know what to expect when said behaviour is "fixed".

And in the event someone asks, it's Gentoo and kde3.5.

Cheers

1: works

[wysota]

For example try adding a resource file to your project using KDevelop. Or add it manually to the project file, then load it into KDevelop and do something so that the project file gets saved by KDevelop. Then look at the resulting .pro file.

Another example -- try turning on or off some of the modules from Qt (like gui, xml or whatever). Or try to do it manually in the project file and then open KDevelop and make it resave the file. Then look at it. You can repeat that for every feature which is not present in Qt3.

Third example -- install Qt3 development files along Qt4 development files. Make sure that Qt3 files are ahead of Qt4 ones in your $PATH and then try to tell KDevelop to compile using Qt4 without changing the $PATH.

Fourth example -- did it install Qt4 documentation so that you can use it from KDevelop's integrated documentation browser? Do you see both Qt3 and Qt4 documentation in the tree there?

If you want more examples, drop me a line.

What is more funny -- there is an entry somewhere in the configuration dialog of KDevelop to set the path to qmake. Well... the funny part is, that KDevelop never checks that when looking for qmake. It has some paths hardcoded, so if you have qmake in some non-default location, it won't find it.

[high_flyer]

What is more funny -- there is an entry somewhere in the configuration dialog of KDevelop to set the path to qmake. Well... the funny part is, that KDevelop never checks that when looking for qmake. It has some paths hardcoded, so if you have qmake in some non-default location, it won't find it.

That is strange.
Mine uses QTDIR , not hard coded, as can be seen from the first build line:

cd '/home/kish/vision/projects/autotracker/src' && QTDIR="/usr/lib/qt3" gmake -k -j1 clean && QTDIR=&q

[wysota]

That is strange.
Mine uses QTDIR , not hard coded, as can be seen from the first build line:

Do you use a vanilla kdevelop or an rpm from some distro? Besides, /usr/lib/qt3 is one of the hardcoded paths to look for Qt (as among other, mdk uses it).

QTDIR="/usr/lib/qt3" gmake -k -j1 clean

Try setting a custom QTDIR before running KDevelop and it'll still use /usr/lib/qt3. It's because it sets QTDIR on its own, overriding all that has been set before. So the only way I found to make KDevelop (or rather TrollProjectPart) compile using Qt4 is to put Qt4 qmake in front of Qt3 qmake in $PATH.

I'm just rebuilding KDevelop rpm, so I have its sources with me:

bool TrollProjectPart::isValidQtDir( const QString& path ) const
{
    return QFile::exists( path + "/include/qt.h" );
}
 
QStringList TrollProjectPart::availableQtDirList() const
{
    QStringList qtdirs, lst;
    qtdirs.push_back( ::getenv("QTDIR") );
    qtdirs.push_back( "/usr/lib/qt3" );
    qtdirs.push_back( "/usr/lib/qt" );
    qtdirs.push_back( "/usr/share/qt3" );
 
    for( QStringList::Iterator it=qtdirs.begin(); it!=qtdirs.end(); ++it )
    {
        QString qtdir = *it;
        if( !qtdir.isEmpty() && isValidQtDir(qtdir) )
            lst.push_back( qtdir );
    }
    return lst;
}

bool TrollProjectPart::isValidQtDir( const QString& path ) const
{
    return QFile::exists( path + "/include/qt.h" );
}

QStringList TrollProjectPart::availableQtDirList() const
{
    QStringList qtdirs, lst;
    qtdirs.push_back( ::getenv("QTDIR") );
    qtdirs.push_back( "/usr/lib/qt3" );
    qtdirs.push_back( "/usr/lib/qt" );
    qtdirs.push_back( "/usr/share/qt3" );

    for( QStringList::Iterator it=qtdirs.begin(); it!=qtdirs.end(); ++it )
    {
        QString qtdir = *it;
        if( !qtdir.isEmpty() && isValidQtDir(qtdir) )
            lst.push_back( qtdir );
    }
    return lst;
}

To copy to clipboard, switch view to plain text mode 

You could say -- "Ok, so it reads QTDIR env, so it should work". Well... yes, but not for Qt4. Look at how it check for valid QTDIRS -- it looks for $QTDIR/include/qt.h and with Qt4 no such file exists... A workaround would be to create one of course, but there are better ways to check for a Qt installation than scanning for $QTDIR/include/qt.h which may not be valid even for Qt3 (some distros keep Qt include files inside /usr/include/), so a patch is needed for different distros.

Anyway it doesn't look for Qt in a place, which was entered by the user in the configuration dialog.

[high_flyer]

Do you use a vanilla kdevelop or an rpm from some distro?

SUSE10 KDevelop 3.3.x (can't remember not on that machine at the moment)

Try setting a custom QTDIR before running KDevelop and it'll still use /usr/lib/qt3. It's because it sets QTDIR on its own, overriding all that has been set before.

I actually did, two days ago, since my enviorment was abit messed up, and it didn't work, meaning, KDeveloped whent to the QTDIR and could not find qmake, or was it moc, I can't remembet now any more, but it could not compile at all.

You could say -- "Ok, so it reads QTDIR env, so it should work".

Actually no, I am not yet in to that discussion.
I didn't try enough to say "I know it".
All I know, is, that the first time I installed SUSE10 I noticed it installed Qt4 and Qt3 by defalut.
I tried beifly to compile a Qt4 project in KDevelop, it worked ok, but I didn't try fancy things with it, so I don't know how well it would have behaved.
Since then I uninstalled Qt4, and when I tried to install it back, yast2 messed up my KDE.
So my next try (once I find a bit of time) is to compile my self Qt4 and install it my self, with out letting yast mess up things.

[yop]

...but there are better ways to check for a Qt installation than scanning for $QTDIR/include/qt.h which may not be valid even for Qt3 (some distros keep Qt include files inside /usr/include/), so a patch is needed for different distros...

Could you please elaborate more on that? What would be a better way? I'm relying heavily in QTDIR, and as I can see it's still there in my Qt 4.1.0 windows installation. On my linux box I'm still with 3.3.5

[wysota]

Could you please elaborate more on that? What would be a better way? I'm relying heavily in QTDIR, and as I can see it's still there in my Qt 4.1.0 windows installation. On my linux box I'm still with 3.3.5

I meant defining a QTDIR as "a directory which has an 'include/qt.h' file inside". This file is not present in Qt4. And it doesn't have to be present there in Qt3 too.

There is also a question what to define by a "QTDIR". The directory which holds includes? One which holds plugins? What if there are no plugins? Binaries maybe? What if they are in /usr/bin/? Mkspecs files maybe? But they can be elsewhere too...

Qt4 doesn't use "QTDIR" anymore. I guess the path is somehow hardcoded into qmake or mkspecs files.

[yop]

So if you have multiple Qt installations (3.x and 4.x) do you think that the best way would be to call qmake with full path to the instalation you want to link to or do you think that Qt dir is still a reliable way that will work, say to at least 90% of the users? It seems kind of theoretical, but this is a season of moving to Qt 4.x so if you want to distribute a Qt 3.x app the instructions should be "run qmake [whatever].pro" or "run [fullpath to the qmake exec]/qmake [whatever].pro" but then again doesn't Qt 3 qmake take the paths to the include and libs dir relative to QTDIR? I am still assuming in all of my Qt related work that QTDIR is set I must admit.

[wysota]

QTDIR is only relevant with Qt3. Qt4 seems to rely only on qmake. So the only thing you need to build with Qt4 is a proper installation and qmake in your path. The best proof for that is KDevelop itself -- to compile using Qt4 and having both Qt3 and Qt4 installed it is enough to do (in my case): "PATH=/usr/local/Qt4/bin:$PATH kdevelop".

And what's more -- QTDIR is only needed during compilation (qmake relies on it, I guess)! If you distribute your compiled app, there is no need for that. Normal dynamic linker rules apply.

With Qt4 it seems to be.... emm... different. The path to Qt libraries seems to be imprinted into the app itself, at least under Linux, so as long as I don't move my libraries, I can have them in a custom place (not usually scanned by the linker) and they will still be found (which wasn't the case with Qt3 -- libqt-mt.so had to be in a standard library path).

[ucntcme]

For example try adding a resource file to your project using KDevelop. Or add it manually to the project file, then load it into KDevelop and do something so that the project file gets saved by KDevelop. Then look at the resulting .pro file.

By project file you mean the kdevelop project file, or the .pro?

Another example -- try turning on or off some of the modules from Qt (like gui, xml or whatever). Or try to do it manually in the project file and then open KDevelop and make it resave the file. Then look at it. You can repeat that for every feature which is not present in Qt3.

If by this you mean the .pro, I have not had the problem you describe.

I have added new files into .pro by hand (vi), modified by config variables, then loaded up kdevelop and added new files (e.g. using the new class wizard) resulting in modifications to the pro (as verified by file timestamp checking) and not had any problems.

Third example -- install Qt3 development files along Qt4 development files. Make sure that Qt3 files are ahead of Qt4 ones in your $PATH and then try to tell KDevelop to compile using Qt4 without changing the $PATH.

I don't mean to get snarky by that's not kdevelop, that is you telling your system what order you want things searched, and kdevelop obeying as any good app should.

That said, I have both installed - hence the running of KDE3.5. Now, it may well be specific to gentoo, but I don't have a problem here *in managing qt4 development*. What you are describing while being useful, is beyond the question of kdevelop managing a Qt4 project. I have compiled a Qt3 app done in kdevelop 3.3.x or qt4 w/o changing anything. In fact, I just did it.

Perhaps it because Qt3 uses QTDIR and Qt4 does not, combined with gentoo putting QT4 first in the path. That way it finds Qt4 by natural path and uses QTDIR for qt3 stuff. That was what was described in the Gentoo forum regarding qt4 alongside qt3.

It apparently works fine if you have Qt4 first, and use QTDIR to determine Qt3's location. Why insist on doing it the other way?

Fourth example -- did it install Qt4 documentation so that you can use it from KDevelop's integrated documentation browser? Do you see both Qt3 and Qt4 documentation in the tree there?

I never use that tool so I can't say. It's not that I don't need the docs (I do!), it is that even before I installed Qt4, the Qt docs refused to show up in kdevelop anyway. So for Qt (3 or 4). SO in that respect kdevelop didn't support managing qt3 proejcts for me. I use either "assistant" or a web archive and firefox. It also grants me more control over the look (such as text size and coloring).

If you want more examples, drop me a line.

What is more funny -- there is an entry somewhere in the configuration dialog of KDevelop to set the path to qmake. Well... the funny part is, that KDevelop never checks that when looking for qmake. It has some paths hardcoded, so if you have qmake in some non-default location, it won't find it.

If Kdevelop (or qmake) are not honoring environment variables, then that is a bug in them that has nothing to do with qt4. Any app that will refuse to honor enviornment variables and use a "hardcoded" environment variable should either have an option not to or at least be very up front about it.

That said, I have not found anywhere to set the qmake path in the kdevelop option screens, nor in the project options screens. There is a qt root path in the Qt tab in the make options screen of project options.

There is a "make command" option in the make screen. I just set it to /bin/true and it did in fact execute /bin/true as expected. I then proceeded to set it to my embedded-qt qmake (full path including the binary) and it tried to use that qmake. no problems here on that front.

But then again, maybe I still don't understand what you're saying.

As a newbie to Qt the QTDIR being listed in my compiler commands for my Qt4 stuff did give me pause. So I went into my project options and set a blank QTDIR. Now it shows up as such. not that it ever seemed to matter anyway.
Which reminds me, if your various projects need differing environment variables, why not set them in kdevelop on the project options dialog? Seems to work so far here. If it doesn't that would seem to me to be a kdevelop/qmake bug, not a "kdevelop can't manage Qt4 projects" "bug".

Cheers,
Bill

[wysota]

By project file you mean the kdevelop project file, or the .pro?

If by this you mean the .pro, I have not had the problem you describe.

I have added new files into .pro by hand (vi), modified by config variables, then loaded up kdevelop and added new files (e.g. using the new class wizard) resulting in modifications to the pro (as verified by file timestamp checking) and not had any problems.

Are we talking about resource files here? Can you add resource files from within KDevelop?

I don't mean to get snarky by that's not kdevelop, that is you telling your system what order you want things searched, and kdevelop obeying as any good app should.

Well... you are wrong. If you have both Qt3 and Qt4 installed, it is the apps responsibility to invoke the proper qmake and it shouldn't force you to modify your path before starting the IDE.

That said, I have both installed - hence the running of KDE3.5.

Running kde 3.5 has nothing to do with it. It can be running without Qt3 qmake installed.

Now, it may well be specific to gentoo, but I don't have a problem here *in managing qt4 development*.

Can you change the content of the .pro file to add Qt4-specific features without changing the .pro file manually?

What you are describing while being useful, is beyond the question of kdevelop managing a Qt4 project.

So I guess vi supports Qt4, too, right? So a piece of paper also supports Qt4? In that sense KDevelop supports any project because it can edit text files?

I have compiled a Qt3 app done in kdevelop 3.3.x or qt4 w/o changing anything. In fact, I just did it.

Without touching .pro file outside kdevelop?

Perhaps it because Qt3 uses QTDIR and Qt4 does not, combined with gentoo putting QT4 first in the path. That way it finds Qt4 by natural path and uses QTDIR for qt3 stuff. That was what was described in the Gentoo forum regarding qt4 alongside qt3.

So this may be a gentoo patch which was applied to KDevelop. The code I pasted in this thread is from vanilla KDevelop, which doesn't do anything to distinguish between Qt3 and Qt4.

It apparently works fine if you have Qt4 first, and use QTDIR to determine Qt3's location. Why insist on doing it the other way?

Tell that to KDevelop people.

I never use that tool so I can't say. It's not that I don't need the docs (I do!), it is that even before I installed Qt4, the Qt docs refused to show up in kdevelop anyway.

Did they work in a standalone Assistant?

If Kdevelop (or qmake) are not honoring environment variables, then that is a bug in them that has nothing to do with qt4.

It has nothing to do with environment variables but about incorrectly identifying Qt installation directory and not supporting Qt4 options from KDevelop's KDevTrollProject.

That said, I have not found anywhere to set the qmake path in the kdevelop option screens, nor in the project options screens. There is a qt root path in the Qt tab in the make options screen of project options.

It is but it is ignored when looking for Qt installation.

There is a "make command" option in the make screen. I just set it to /bin/true and it did in fact execute /bin/true as expected. I then proceeded to set it to my embedded-qt qmake (full path including the binary) and it tried to use that qmake. no problems here on that front.

It is a hack. Hacking doesn't mean support.

So I went into my project options and set a blank QTDIR. Now it shows up as such. not that it ever seemed to matter anyway.

So you hacked a hack -- a double hack doesn't mean support too.

Which reminds me, if your various projects need differing environment variables, why not set them in kdevelop on the project options dialog? Seems to work so far here. If it doesn't that would seem to me to be a kdevelop/qmake bug, not a "kdevelop can't manage Qt4 projects" "bug".

It seems like a hack to me, and... you know the rest

By support I mean -- I open kdevelop, enter some code, press "Build" and it builds successfully. Without even knowing that some things like QTDIR or qmake exist. That's what's an IDE for.

I could (which doesn't mean I will) agree with a statement that KDevelop partially or passively supports Qt4, but not with "KDevelop supports Qt4" one. We are talking about an IDE here and with developing software from IDE I demand more than from a simple text editor.

I think with KDevelop there is a problem of a wrong approach of its developers. They want Qt3 project and Qt4 project to be maintained by the same project manager. Which is wrong, because Qt3 (qmake 3) and Qt4 (qmake 4) differ very much.