Building project with QtCreator
Hi,
I managed to set up my KDE workplace using the kdesrc_build script in the
end. There are still a couple of modules which reported some errors, but
the most important ones as mentioned in the HOWTOs installed successfully.
Now, I'm trying to build a small project with QtCreator to verify whether
everything works or not and I got over another error which I don't know how
to solve or what exactly causes it.
So I cloned the project ktimer because I saw it is pretty small. Then I
followed the steps (
http://techbase.kde.org/Getting_Starte/Using_an_IDE_with_KDE4#QtCreator )
in order to load an existing project in QtCreator and I have the following
CMakeError.log file ( attached ). As far as I know, it doesn't simply find
a couple of variables which should be, I guess, included from some library.
What makes me more confuse is that I have qt installed and I think those
variables are part of its libraries but those compilations doesn't find
them.
Thank you very much!
Determining if the Q_WS_X11 exist failed with the following output:
Change Dir: /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make "cmTryCompileExec2662169773/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec2662169773.dir/build.make CMakeFiles/cmTryCompileExec2662169773.dir/build
make[1]: Entering directory `/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec2662169773.dir/CheckSymbolExists.c.o
/usr/bin/cc -I/usr/include/qt5-o CMakeFiles/cmTryCompileExec2662169773.dir/CheckSymbolExists.c.o -c /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ‘main’:
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: error: ‘Q_WS_X11’ undeclared (first use in this function)
return ((int*)(&Q_WS_X11))[argc];
^
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [CMakeFiles/cmTryCompileExec2662169773.dir/CheckSymbolExists.c.o] Error 1
make[1]: Leaving directory `/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec2662169773/fast] Error 2
File /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include
int main(int argc, char** argv)
{
(void)argv;
#ifndef Q_WS_X11
return ((int*)(&Q_WS_X11))[argc];
#else
(void)argc;
return 0;
#endif
}
Determining if the Q_WS_WIN exist failed with the following output:
Change Dir: /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make "cmTryCompileExec3203077664/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec3203077664.dir/build.make CMakeFiles/cmTryCompileExec3203077664.dir/build
make[1]: Entering directory `/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3203077664.dir/CheckSymbolExists.c.o
/usr/bin/cc -I/usr/include/qt5-o CMakeFiles/cmTryCompileExec3203077664.dir/CheckSymbolExists.c.o -c /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ‘main’:
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: error: ‘Q_WS_WIN’ undeclared (first use in this function)
return ((int*)(&Q_WS_WIN))[argc];
^
/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [CMakeFiles/cmTryCompileExec3203077664.dir/CheckSymbolExists.c.o] Error 1
make[1]: Leaving directory `/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec3203077664/fast] Error 2
File /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include
int main(int argc, char** argv)
{
(void)argv;
#ifndef Q_WS_WIN
return ((int*)(&Q_WS_WIN))[argc];
#else
(void)argc;
return 0;
#endif
}
Determining if the Q_WS_QWS exist failed with the following output:
Change Dir: /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make "cmTryCompileExec2503831420/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec2503831420.dir/build.make CMakeFiles/cmTryCompileExec2503831420.dir/build
make[1]: Entering directory `/home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report /home/calin/kde/src/ktimer-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec2503831420.dir/CheckSymbolExists.c.o
/usr/bin/cc -I/usr/include/qt5-o
"RE: Building project with QtCreator"
Hi again, I managed to solve the problem in my previous e-mail. It was caused by the fact that I have installed both qt5 and qt4. In fact, this also caused many other errors from what I was told. The problem was that my implicit qmake was the version 3 and the qt version 5. I tried then to modify the path this way: PATH="/home/my_name/qt4/bin:$PATH" . After this modification, the build was successful. But then, when I ran make, it got to 80% and I received a couple of errors saying that libkdecore.so.5.11.5 has undefined reference to QSslSocket::(and many functions here). Then, someone on IRC told me that it may be caused by my self-compiled qt4 and advised me to try the system qt4. So I modified the PATH to PATH="/usr/lib/x86_64-linux-gnu/qt4/bin:$PATH". And now the make and install also works. But now comes my question: Why I was getting that error with QSslSocket ? It's pretty weird to not use the qt4 self-compiled from my /home after I spent a couple of days trying to make kdesrc_build script to run. Thank you very much! >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: "RE: Building project with QtCreator"
I never succeeded compiling kdesrc_build to run... I think not enaugh practical examples, for me it's pity because I would like to use it with kf5 as I have to do it manually. Le 13/02/2014 15:26, Cruceru Calin a écrit : Hi again, I managed to solve the problem in my previous e-mail. It was caused by the fact that I have installed both qt5 and qt4. In fact, this also caused many other errors from what I was told. The problem was that my implicit qmake was the version 3 and the qt version 5. I tried then to modify the path this way: PATH="/home/my_name/qt4/bin:$PATH" . After this modification, the build was successful. But then, when I ran make, it got to 80% and I received a couple of errors saying that libkdecore.so.5.11.5 has undefined reference to QSslSocket::(and many functions here). Then, someone on IRC told me that it may be caused by my self-compiled qt4 and advised me to try the system qt4. So I modified the PATH to PATH="/usr/lib/x86_64-linux-gnu/qt4/bin:$PATH". And now the make and install also works. But now comes my question: Why I was getting that error with QSslSocket ? It's pretty weird to not use the qt4 self-compiled from my /home after I spent a couple of days trying to make kdesrc_build script to run. Thank you very much! Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Friendly reminder: we need GSoC ideas *now*!
The GSoC 2014 organization application deadline is tomorrow. Lydia and I have taken the liberty of applying on behalf of KDE, but our GSoC ideas list [1] is still shorter than last year. The amount of slots we get depends on the quantity and quality of our project ideas, so it's absolutely crucial that prospective mentors add their ideas *now*. If you're willing and able to mentor a student this summer, and you have one or more project ideas, please add them to our Ideas page [1] as soon as possible. Thanks! [1] http://community.kde.org/GSoC/2014/Ideas Cheers, -- Teo Mrnjavac & the KDE Student Programs team >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Keyboard shortcut enhancement.
It may be that I didn't fully understand the idea behind hotkeys in KDE, but I found some issues that might require tweaking. The mechanism behind that feature is quite strict. There are always some mod keys + ONE other keys (such as letters). There is no way to create a shortcut with two "other keys". I know it is quite more difficult in desing because user rarely will press two keys in exacly the same time, and adding any delay to avoid this issue might disapoint people using regular hotkeys (depending on delay time). What I would like to actually reproduce is the behaviour from Visual Studio. The user is able to desing hotkeys as: -Press CTRL -Press first key -Press second key -Release CTRL It is activated upon last step. Of course it would bound us to unacceptable behaviour. For example user pressing ALT+Tab is expecting that it will immediately invoke some kind of task switcher animation. I think it could be solved by executing the action before releasing of mod- button if there is no further combination available. For example if user has created shortcut ALT+Tab+Q, the task switcher would be shown after releasing CTRL, because it's still possible to press Q, and invoke different action. I think many would benefit from such enhancement. For example I am thinking of enabling all features of VIM in Kate's normal mode. VIM-mode itself is too difficult for new programmers, and there is too many commands to do it right now. Of course we can find some flaws. Example: user is expecting some hotkey to be instant and current application adds the new one that extends it. Let's say that given app add CTRL+S+X. CTRL+S is no longer instant. Unaware user want to quickly save the file and open a new one. He use CTRL+S and CTRL+O without releasing CTRL to make it faster. It is interpretet as CTRL+S+O which is unknown. I think we all can imagine other cases where it would be disastrous. I still don't have idea how to deal with it. I always tend to realease CTRL after every hotkeys but I believe some people doesn't. Anyway. I think it looks interesting. I'd like you to think about it and share your thoughts. Maybe something like this is worth adding to KDE. Maybe it would be valuable GSoC idea, as I heard there aren't too many of them. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Keyboard shortcut enhancement.
On Friday 14 February 2014 01:07:10 p.kubik...@gmail.com wrote: > The mechanism behind that feature is quite strict. There are always > some mod keys + ONE other keys (such as letters). There is no way > to create a shortcut with two "other keys". I just tried it in Kate, and assigned Ctrl+Y, Ctrl+X as a shortcut for "About Kate", and it worked without a problem. As long as Ctrl+Y is not assigned, you can use it to initiate a multi-key shortcut. Since Kate uses the standard "Configure Shortcuts" dialog, I assume it works in any KDE application. > I always tend to realease CTRL after every hotkeys but I believe > some people doesn't. Exactly, I do not release the Ctrl key when using multiple shortcuts. Christoph Feck (kdepepo) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Keyboard shortcut enhancement.
On Freitag, 14. Februar 2014 01:22:19 CEST, Christoph Feck wrote: On Friday 14 February 2014 01:07:10 p.kubik...@gmail.com wrote: The mechanism behind that feature is quite strict. There are always some mod keys + ONE other keys (such as letters). There is no way to create a shortcut with two "other keys". I just tried it in Kate I think he points kglobalaccel (kcmshell4 keys/khotkeys) - it should be possible (on X11, might require Xtst), but rather not trivial as inside a focused client. kglobalaccel could only grab the first modified key, would use it to grab the entire keyboard, wait for the next key and see whether it's some global shortcut. If not, or the modifier changed, the first key event /has/ to be repeated and the second one passed on. No idea whether that's possible on OSX or Windows at all. FYI: That's emacs style shortcuts and RMS is probably upset enough that MS dared to add it to VS 2005 - but he will certainly not like that people now associate it there ;-) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Keyboard shortcut enhancement.
On Friday 14 February 2014 01:44:05 Thomas Lübking wrote: > On Freitag, 14. Februar 2014 01:22:19 CEST, Christoph Feck wrote: > > On Friday 14 February 2014 01:07:10 p.kubik...@gmail.com wrote: > >> The mechanism behind that feature is quite strict. There are always > >> some mod keys + ONE other keys (such as letters). There is no way > >> to create a shortcut with two "other keys". > > > > I just tried it in Kate > > I think he points kglobalaccel (kcmshell4 keys/khotkeys) - it should be > possible (on X11, might require Xtst), but rather not trivial as inside a > focused client. > > kglobalaccel could only grab the first modified key, would use it to grab > the entire keyboard, wait for the next key and see whether it's some global > shortcut. If not, or the modifier changed, the first key event /has/ to be > repeated and the second one passed on. No idea whether that's possible on > OSX or Windows at all. iiuc that feature was even supported on kde3 and was removed by lubos with intent because of all the problems around it. So this is unfortunately a won't fix. Which should not hinder anyone to implement it outside of kde. I am btw not really sure khotkeys should still be part of kde5. its broken, never really reached kde4 anyway and both lubos and i don't work on it anymore. And it failed to attract anyone else. Mike >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Keyboard shortcut enhancement.
On Friday 14 February 2014 04:19:04 Michael Jansen wrote: > I am btw not really sure khotkeys should still be part of kde5. its broken, > never really reached kde4 anyway and both lubos and i don't work on it > anymore. And it failed to attract anyone else. Thanks for letting us know. I ported it over to frameworks but to be honest had no idea how to properly test it ;-) So if you think it should be killed, maybe just do the git rm. Cheers Martin signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Keyboard shortcut enhancement.
On Fri, Feb 14, 2014 at 7:39 PM, Martin Gräßlin wrote: > On Friday 14 February 2014 04:19:04 Michael Jansen wrote: >> I am btw not really sure khotkeys should still be part of kde5. its broken, >> never really reached kde4 anyway and both lubos and i don't work on it >> anymore. And it failed to attract anyone else. > > Thanks for letting us know. I ported it over to frameworks but to be honest > had no idea how to properly test it ;-) So if you think it should be killed, > maybe just do the git rm. Please note that certain parts of KHotkeys functionality, particularly that related to executing an arbitrary command have been particularly useful for integrating non-KDE applications which don't support global shortcuts, as well as for working around problems in the global shortcut support provided by some applications. Given it's status, perhaps someone might want to advertise that we're looking for a rewrite / new maintainer for the KF5 iteration? > > Cheers > Martin > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << > Thanks, Ben >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Keyboard shortcut enhancement.
Hi, On Fri, Feb 14, 2014 at 7:46 AM, Ben Cooksley wrote: > On Fri, Feb 14, 2014 at 7:39 PM, Martin Gräßlin > wrote: > > On Friday 14 February 2014 04:19:04 Michael Jansen wrote: > >> I am btw not really sure khotkeys should still be part of kde5. its > broken, > >> never really reached kde4 anyway and both lubos and i don't work on it > >> anymore. And it failed to attract anyone else. > > > > Thanks for letting us know. I ported it over to frameworks but to be > honest > > had no idea how to properly test it ;-) So if you think it should be > killed, > > maybe just do the git rm. > > Please note that certain parts of KHotkeys functionality, particularly > that related to executing an arbitrary command have been particularly > useful for integrating non-KDE applications which don't support global > shortcuts, as well as for working around problems in the global > shortcut support provided by some applications. > > Given it's status, perhaps someone might want to advertise that we're > looking for a rewrite / new maintainer for the KF5 iteration? > Would be sad to see khotkeys go without any replacement, I'm not having a truckload of shortcuts configured there but there are a few and so far I haven't seen any replacement. In particular I'm using it to start my preferred browser and to control my preferred mp3 player. The latter is a cli-tool so it has no global shortcuts support but it has invocations which talk to the running instance and can do play, pause etc. That part of khotkeys has been working for me from KDE 4.2 up until now (4.11 here), so no idea why it is considered to be 'broken'. Andreas >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
