Designing code for QML UIs
July 20, 2010 by Alan Alpert | Comments
QML is starting to approach its initial release. Those who have been using QML for a while can rejoice, for this means that we're no longer changing everything and the stability of having an actual release can now be seen on the horizon (although maybe I'm just bitter because I had to change Samegame again today, because the QML behavior underneath has changed in what should be the last destabilizing change of this release). To celebrate, I'm going to do some blog posts on QML; just some various brain dumps on how to get the most out of QML. I think this is useful, largely because I think that QML is so amazingly powerful when you do get the most out of it. For now, getting the most out of QML is sadly limited to just awesome, fluid UIs. It's still worth it. Since the docs explain how to get started and animating your UIs with QML, I'm going to start from the other side here. Presumably a lot of labs readers are C++ developers, and are wondering how they can get the most out of QML even though they write C++. In this case you can get a lot out of QML from using it as the UI layer on top of your C++ application logic. So here are the 'recommended best practices' to think about, so that you can make your next application QML-compatible from the start. Since this is basically just separation of the UI layer and the application logic layer, these practices are probably a good idea anyways. (Note that this is NOT the model-view-controller pattern, even though there is some overlap.)
Separating the UI from the application logic, QML style, starts at design time. Think about what it is that your application really does. Naturally you'll want to have a fluid, aethetically pleasing yet eminently usable user interface for it, but that part comes later. Your application may interface with a custom database, or it may play a game, or it may perform complex calculations over and over. For simple things, like just accessing web content or adding two numbers, you can make do with what comes with QML, such as the integrate QtScript or XmlListModel. For everything else, there's Qt C++. If your application is, for example, interfacing with a custom database then you'll likely be implementing that interface in C++ still. Because the layers are separate you should implement, on its own, the C++ parts that drive the application logic.
When writing the C++ layer, you want to end up with a QObject derived class which exposes all the relevant application data through properties, signals and slots. For a database example, you would have properties that get set to provide the connection details, then you would have signals when the connection state progresses, and then you would have some way of getting the data. Depending on the data, this could be slots that return a value, properties that include whole models for viewing in the UI, or a mixture with slots that might update the data in the models exposed through properties. This is similar to existing Qt APIs for data objects. If you look at QAction, you will see that it provides a variety of properties for setting details about the action as well as a signal when the action is triggered. Looking at QAction as an example, it also has slots for manipulating properties. While this is not necessary for QML, it is perfectly acceptable for use from C++. Another example would be the folderlistmodel plugin in src/imports/folderlistmodel, A final real-world example would be the system info API in Qt Mobility which you could expose to QML and then just pick up and use due to the property based interface.
For the most part it really is as simple as just using properties, signals and slots. The only QML specific advice I'd give is to think more declaratively. The techincal requirements for QML integration are easy to meet, but for something that's really easy to use with QML it helps to consider the declarative approach when designing the interface. This is not incompatible with a good C++ interface. The main difference is with the use of properties. From C++, properties are little more than a convenience for the documentation. But from QML, properties are the primary method of interaction. It will be more useful from QML to have a boolean property isOn than to have turnOn and turnOff slots in C++. It will also be a lot easier than having a toggleOnOffState() slot and a getOnOffState() slot. Because properties are the main method of interaction for QML, it's also better to have properties rather than just slots when passing data in or out of the C++ class - even when the communication is strictly one way. This is because the declarative approach thinks in terms of properties (The state is on. I want the state off.) rather than imperative steps (The state is on when getState()==true. If getState()==true, setState(false).). Other minor details from thinking declaratively are to always remember to have a notify signal for properties, and to allow the properties to be set in any order instead of having strict initialization order requirements. It's a subtle distinction though, and in the end though you'll just have a C++ class with a black box implementation and an interface comprised of properties, signals and slots. Such a class can then be used by a variety of things to construct a full application by adding a UI. From this class, you can add a C++ QWidget UI, a QML UI or something else (perhaps a pyside UI) on top to create a full application.
As this is a best practices approach, it includes a test plan. You'll want to test this with automated unit tests before even writing your first UI. Because you want a C++ part completely separate from the UI, it needs to be tested separately to any of your UI front ends. This can seem like a lot of overhead, but the actual data part is usually quite small compared to the UI. If it isn't then it's probably something really hairy and you need the extra testing anyways ;) .
The advantage of having a completely separate UI and data layer is that you can alter or add new UIs at a moments notice. Imagine 'themes' that can change the entire look and feel, not just a few colors and pixmaps. Even better, imagine the ease in which you can port your application to a completely different platform. I think Qt's cross-platform widgets do a fine job on some of the desktop platforms, although that is debatable. Less debatable is how well they do when porting your app from a desktop platform to a 240x320 keypad phone and a 800x480 touchscreen phone. With such radical changes in the form factor and basic I/O devices, there is no alternative to a complete UI rewrite if you want to have an excellent UI. But if you have the UI and data layer completely separated, you can easily rewrite the entire UI in QML, and get the same functionality behind it with a simple recompile. So while 'write once, deploy everywhere' is an impossible dream with the UI across phones (and similar devices) you don't have to give up hope on the application logic, which was the harder one to write anyways.
A second advantage is that the separate UI and data layer allows them to be developed individually. While a developer is writing and testing the data logic, a designer can prototype and write the UI with dummy data. Then the unification of the two to make a real application becomes really simple. Or, for free software projects, if the developer has a great idea but wrote a lousy interface for it, then a designer has a much lower barrier towards contributing to make it more usable. He could just write a UI in QML and, at least in cases where the C++ logic was deployed via the QML plugin system, actually create and use it without needing to compile or even read the 'intimidating' C++ code.
It might be Qt specific, but my advice for future designs is to expose the application logic in a QObject derived class, using properties, signals and slots for the interface. You can then expose it through a QML or C++ plugin, use it with a QML or C++ UI, or even run unit tests on it directly. This design helps with modularity where it counts, in the data layer, and allows UI swapping at will (or even at runtime, if you're so inclined).
Blog Topics:
Comments
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.8 Now!
Download the latest release here: www.qt.io/download.
Qt 6.8 release focuses on technology trends like spatial computing & XR, complex data visualization in 2D & 3D, and ARM-based development for desktop.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
Can you give some attention to QTCREATORBUG-2949 please? Autocompletion for c++ is still better in kdevelop than qtcreator and obviuosly qtcreator is better for other things and I want to use qtcreator
thanks
Nicola
One thing I'd really love to see: An appropriate tag in the repository before I seen an announcement of a new version here. ;-)
you are right @Guido Seifert
You tolls publish some beta, RC, final version but I don't see any tag in git.
Are you going to fix something letter ? :)
???
https://qt.gitorious.org/qt...
Sorry, my post was a bit misleading. No fault on your side. It is just that I pulled and rebuilt the creator this morning... only to see a few hours later that if I had waited a bit longer, I could have seen the rc tag and had an 'official' version. But that's how it usually works....no progress is made until 5 minutes after I downloaded everything and upgraded my system. ;-)
I hate you. :-)
Just checked: Eike Ziller commited 0672813 at 10:11.
My update: Wed, 16 Nov 2011 09:24:18 GMT
Btw... Looks very good. The only problem I discovered yet, is only a problem for those, who want to or have to stay with debian stable: gdb 7.0.x does not work correctly anymore.
@guido: ah, always a pleasure ;)
@Guido: 7.0.1 with python?
@Guido Seifert: anyway, 7.0.1 seems to work even without python, but this means "no prettyprinting", and building 7.0.1 is not supported with python 2.7 etc, so to make that work "again" is significant effort which does not seem to be worthwhile.
Andre',
yes. Python seems to be in by default in Debian squeeze:
http://packages.debian.org/...
And it worked fine for me in 717acb6bf4b4799dfb7e72b1481728fb95964d7c.
When I upgraded to 9df694c6eb9fb2cda1de6b6532d8f137c064d744 many of
the variables suddenly only showed 'Unavailable synchronous data'.
Fixed when I upgraded my gdb. As I wrote, generally not a problem. Problem only for those who have no saying in what build configuration they have to use. And Debian stable isn't such an uncommon release.
What a luck I took off yesterday afternoon. Otherwise I'd have distributed 2.4 beta to my users. Very cool that I can now at last get thread names when looking at core dumps :).
Is it possible to use Qt Creator as a software platform, in a similar way Eclipse RCP is used? I know the source code is available, but I would have to clean it up removing all IDE features so I could plugin my application features. I wish someone could have thought about it.
@guilherme: We had thought about it, from the beginning. And rejected it as being out of scope of what we want to do.
I haven't been keeping up with Creator for some time. I downloaded this RC and tried it on my 10.6 Mac with Xcode 4.2. Right away, the tool chains setup is confusing me.
First of all, it shows all the available gcc flavors, even the non-existent ones. Like PPC for LLVM-CLANG and gcc4.2-llvm. Those DO NOT have PPC output.
[](http://imgur.com/DBrIP)
Then in Qt Versions panel, the tool chain selection for building helper doesn't tell me which GCC is which:
[](http://imgur.com/jA9sb)
It also fails to find the installed Qt 4.8 RC.
On minor annoyance bit me today. I added a custom deployment step in run settings. But instead of 'make' in the command line I typed 'make '. The extra space was invisible, but prevented deployment.
My system is windows xp.
Installed QtSDK 1.1.4.
When I IDE after replacing QtCreator 2.4.0 RC .
When editing QML code , the program will automatically exit silently .
Each time you edit QML code will automatically exit the program , this is my problem?
Jason: Does that always happen? Even with a minimal QML file such as "import QtQuick 1.1; Item {}"? I suspect this might be the same as https://bugreports.qt.nokia... . Can you get a stack trace and file a bug report (assign to me)?
Please give some love to QTCREATORBUG-166 (it is the one that keeps me from switching to qtcreator).
Thank you.
Unfortunately, scrolling is still nearly unusable on Mac after opening Help. Most likely due to https://bugreports.qt.nokia... :(
Anyone compiled qt-creator with Qt 4.8? I did ages ago and found a strange bug, that in some dialog boxes I wasn't able to click a button until I moved the box a few pixels. Mouseover effects did always work. I dismissed this bug since Qt 4.8 was far from the state it is today so I could not be sure whether it was a qt-creator or a 4.8 problem. Last week I tried again to compile the creator with 4.8 on a different system and this bug still exists. I compiled several of my own programs with 4.8 and never experienced this problem somewhere else, so now I really think it might be a bug in qt-creator.
@guido: I've heard from a collegue that updating ubuntu supposedly might mend that problem (I suppose that you are on that platform).
Nope, Debian Wheezy. As updated as possible. Fairly recent Qt 4.8.
This problem does not exist when I compile with 4.7.4.
Verygood
That site looking good
@Christian Kamm: Yes, and https://bugreports.qt.nokia... similar problems .
As long as when using a custom component , modify the code to automatically close the QML QtCreator.
And very often , so I can not make any changes to the QML code .
QML is only open a separate file , not the entire project , it will not automatically shut down .
Sorry, I do not know where to find the stack in the log file .
qrjmwmbct, vrlureqxbn
When you compile it for Windows with MinGW?
What are the minimum system requirements for QtCreator now days? I am using Redhat Enterprise 5.5, all applications I develop have to run on this standard (controlled hardware/software). It seems that debugging with the python debugger helpers do not work on my machine. The last successful, for reading nice debugging output, version of QtCreator that I can use is 2.1.0. From what I understand that after this version QtCreator switched to the python way of doing things with NO ability to continue to compile the old debugger libraries even if we wanted them. I think forcing a developer to a certain way is wrong specially if the application runs on my machine. I like some of the features found in the newer versions but can't use them as they don't make debugging easy. 2.1.0 is easier to use and would like that option on the new builds of QtCreator. But with all the questions about this all over the web, it seems the Trolls don't care about giving the information needed to fix this or give a definite statement on which machines it will run.
I know some will say install this or upgrade that, sorry can't do. Develop machine has to stay as stock as possible as the machines running the developed app are stock and CAN NOT be upgraded due other priority software running on them.
Thanks for any and all help!
@jon: Debugging helpers on linux nowadays require a python enabled gdb 7, gdb 7.2 is recommended. If your machines don't have that you can try the binaries that we have on our ftp here ftp://ftp.qt.nokia.com/misc... (and tell Qt Creator to use it in Tools->Options->Debugger->Gdb)
Ever since Qt Creator 2.3.x if I have an enum like the one below (C++ code) then I get a wavy line under the last element and if I hover over it I get the following warning: commas at the end of enumerator lists are a C++0x specific feature
enum Type
{
TYPEONE = 1,
TYPETWO = 2,
};
I've ALWAYS left in the last comma and it's never given me any problems. How can I disable this warning as I don't want to change all my code!
@Eike: Thanks for the suggestion. I have installed on my machine the latest QtSDK, done before the earlier comment was posted, and used the gdb from there but get the following error message: "/path/to/app/qtc_test not in executable format: File format not recognized". Did a clean and then build a couple of times.
Setup was to clone the GCC that was auto detected and then browse to the gdb located in the QtSDK structure and set the project to use that tool chain. I left the g++ alone, so I am making a guess that my compiler is in need up updating as well.
I am unable to start a debug session - although I can attach to an existing process. Here is what I see in the debug log - error 193 even though the path exists. Sigh. Anyone?
sStarting debugger 'GdbEngine' for ABI 'x86-windows-msys-pe-32bit'...
dStart parameters: 'test' mode: 1
dABI: x86-windows-msys-pe-32bit
dExecutable: C:Documents and SettingscaldecorDesktopProjectstest-build-desktop-QtinPATHDebugdebugtest.exe
dDirectory: C:Documents and SettingscaldecorDesktopProjectstest-build-desktop-QtinPATHDebug
dDebugger: C:Qtqtcreator-2.3.1pythongdbgdb-i686-pc-mingw32.exe
dProject: C:Documents and SettingscaldecorDesktopProjectstest (built: C:Documents and SettingscaldecorDesktopProjectstest-build-desktop-QtinPATHDebug)
dQt: C:Qt4.7.4
dQML server: 127.0.0.1:0
d
dDebugger settings:
dUseAlternatingRowColours: false (default: false)
dFontSizeFollowsEditor: false (default: false)
dUseMessageBoxForSignals: true (default: true)
dAutoQuit: false (default: false)
dLogTimeStamps: false (default: false)
dVerboseLog: false (default: false)
dCloseBuffersOnExit: false (default: false)
dSwitchModeOnExit: false (default: false)
dUseDebuggingHelper: true (default: true)
dUseCodeModel: true (default: true)
dShowThreadNames: false (default: false)
dUseToolTips: false (default: false)
dUseToolTipsInLocalsView: false (default: false)
dUseToolTipsInBreakpointsView: false (default: false)
dUseAddressInBreakpointsView: false (default: false)
dUseAddressInStackView: false (default: false)
dRegisterForPostMortem: false (default: false)
dLoadGdbInit: true (default: true)
dScriptFile: (default: )
dWatchdogTimeout: 20 (default: 20)
dTargetAsync: false (default: false)
dMaximalStackDepth: 20 (default: 20)
dAlwaysAdjustStackColumnWidths: false (default: false)
dShowStandardNamespace: true (default: true)
dShowQtNamespace: true (default: true)
dSortStructMembers: true (default: true)
dAutoDerefPointers: true (default: true)
dAlwaysAdjustLocalsColumnWidths: false (default: false)
dListSourceFiles: false (default: false)
dSkipKnownFrames: false (default: false)
dEnableReverseDebugging: false (default: false)
dAllPluginBreakpoints: true (default: true)
dSelectedPluginBreakpoints: false (default: false)
dAdjustBreakpointLocations: true (default: true)
dAlwaysAdjustBreakpointsColumnWidths: false (default: false)
dNoPluginBreakpoints: false (default: false)
dSelectedPluginBreakpointsPattern: .* (default: .*)
dBreakOnThrow: false (default: false)
dBreakOnCatch: false (default: false)
dBreakOnWarning: false (default: false)
dBreakOnFatal: false (default: false)
dAlwaysAdjustRegistersColumnWidths: false (default: false)
dAlwaysAdjustSnapshotsColumnWidths: false (default: false)
dAlwaysAdjustThreadsColumnWidths: false (default: false)
dAlwaysAdjustModulesColumnWidths: false (default: false)
dState changed from DebuggerNotReady(0) to EngineSetupRequested(1).
dQUEUE: SETUP ENGINE
dCALL: SETUP ENGINE
dTRYING TO START ADAPTER
dENABLING TEST CASE: 0
Python path: C:Qtqtcreator-2.3.1pythongdblib
dSTARTING C:/Qt/qtcreator-2.3.1/pythongdb/gdb-i686-pc-mingw32.exe -i mi --tty=.pipecreator-5708-6334
dGDB STARTED, INITIALIZING IT
<1show version
<2-list-features
<3set breakpoint pending on
<4set print elements 10000
<5set overload-resolution off
<6handle SIGSEGV nopass stop print
<7set unwindonsignal on
<8pwd
<9set width 0
<10set height 0
<11set auto-solib-add on
<12-interpreter-exec console "maintenance set internal-warning quit no"
<13-interpreter-exec console "maintenance set internal-error quit no"
<14-interpreter-exec console "disassemble 0 0"
<15-interpreter-exec console "python execfile('C:/Qt/qtcreator-2.3.1/share/qtcreator/dumper/bridge.py')"
<16-interpreter-exec console "python execfile('C:/Qt/qtcreator-2.3.1/share/qtcreator/dumper/dumper.py')"
<17-interpreter-exec console "python execfile('C:/Qt/qtcreator-2.3.1/share/qtcreator/dumper/qttypes.py')"
<18-interpreter-exec console "bbsetup"
dADAPTER SUCCESSFULLY STARTED
dNOTE: ENGINE SETUP OK
dState changed from EngineSetupRequested(1) to EngineSetupOk(3).
dQUEUE: SETUP INFERIOR
dState changed from EngineSetupOk(3) to InferiorSetupRequested(4).
dQUEUE: SETUP INFERIOR
dCALL: SETUP INFERIOR
sSetting up inferior...
=thread-group-added,id="i1"
>~"GNU gdb (GDB) 7.2n"
>~"Copyright (C) 2010 Free Software Foundation, Inc.n"
>~"License GPLv3+: GNU GPL version 3 or later nThis is free software: you are free to change and redistribute it.nThere is NO WARRANTY, to the extent permitted by law. Type "show copying"nand "show warranty" for details.n"
>~"This GDB was configured as "i686-pc-mingw32".nFor bug reporting instructions, please see:n"
>~".n"
>&"show versionn"
>~"GNU gdb (GDB) 7.2n"
>~"Copyright (C) 2010 Free Software Foundation, Inc.n"
>~"License GPLv3+: GNU GPL version 3 or later nThis is free software: you are free to change and redistribute it.nThere is NO WARRANTY, to the extent permitted by law. Type "show copying"nand "show warranty" for details.n"
>~"This GDB was configured as "i686-pc-mingw32".nFor bug reporting instructions, please see:n"
>~".n"
>1^done
dPARSING VERSION: 1^done
d
dSUPPORTED GDB VERSION GNU gdb (GDB) 7.2
dCopyright (C) 2010 Free Software Foundation, Inc.
dLicense GPLv3+: GNU GPL version 3 or later
dThis is free software: you are free to change and redistribute it.
dThere is NO WARRANTY, to the extent permitted by law. Type "show copying"
dand "show warranty" for details.
dThis GDB was configured as "i686-pc-mingw32".
dFor bug reporting instructions, please see:
d.
dGNU gdb (GDB) 7.2
dCopyright (C) 2010 Free Software Foundation, Inc.
dLicense GPLv3+: GNU GPL version 3 or later
dThis is free software: you are free to change and redistribute it.
dThere is NO WARRANTY, to the extent permitted by law. Type "show copying"
dand "show warranty" for details.
dThis GDB was configured as "i686-pc-mingw32".
dFor bug reporting instructions, please see:
d.
d
dUSING GDB VERSION: 70200, BUILD: 2010
>2^done,features=["frozen-varobjs","pending-breakpoints","thread-info","python"]
dFEATURES: 2^done,data={features=["frozen-varobjs","pending-breakpoints","thread-info","python"]}
d
>&"set breakpoint pending onn"
>3^done
>&"set print elements 10000n"
>4^done
>&"set overload-resolution offn"
>5^done
>&"handle SIGSEGV nopass stop printn"
>~"Signal StoptPrinttPass to programtDescriptionn"
>~"SIGSEGV YestYestNottSegmentation faultn"
>6^done
>&"set unwindonsignal onn"
>7^done
>&"pwdn"
>~"Working directory C:Documents and SettingscaldecorDesktopProjectstest-build-desktop-QtinPATHDebug.n"
>8^done
>&"set width 0n"
>9^done
>&"set height 0n"
>10^done
>&"set auto-solib-add onn"
>11^done
>12^done
>13^done
>&"A syntax error in expression, near
0'.n" >14^error,msg="A syntax error in expression, near0'.">15^done
>16^done
>17^done
>~"dumpers=[{type="QLinkedList",formats=""},{type="QSize",formats=""},{type="QFileInfo",formats=""},{type="QAbstractItemModel",formats=""},{type="stdstack",formats=""},{type="QTextDocument",formats=""},{type="QTJSCJSValue",formats=""},{type="gnu_cxxhash_set",formats=""},{type="QStringList",formats=""},{type="QRegion",formats=""},{type="stdwstring",formats=""},{type="QString",formats="Inline,Separate Window",editable="true"},{type="QTextCodec",formats=""},{type="QBasicAtomicInt",formats=""},{type="QScriptValue",formats=""},{type="QTime",formats=""},{type="QSharedData",formats=""},{type="stdvector",formats="",editable="true"},{type="QRegExp",formats=""},{type="QTextCursor",formats=""},{type="QxXmlAttributes",formats=""},{type="QDateTime",formats=""},{type="QList",formats=""},{type="QStandardItem",formats=""},{type="stddeque",formats=""},{type="QFixed",formats=""},{type="QHash",formats=""},{type="QSharedPointer",formats=""},{type="QUrl",formats=""},{type="stdset",formats=""},{type="stdlist",formats=""},{type="stdbasic_string",formats=""},{type="QPoint",formats=""},{type="QStack",formats=""},{type="QScopedPointer",formats=""},{type="QRectF",formats=""},{type="QMultiMap",formats=""},{type="QMapNode",formats=""},{type="QObject",formats=""},{type="QHostAddress",formats=""},{type="QLocale",formats=""},{type="QSharedDataPointer",formats=""},{type="QVariant",formats=""},{type="string",formats="",editable="true"},{type="QBasicAtomicPointer",formats=""},{type="QVector",formats="",editable="true"},{type="QDate",formats=""},{type="QFile",formats=""},{type="QAtomicInt",formats=""},{type="wstring",formats=""},{type="QWeakPointer",formats=""},{type="QSizeF",formats=""},{type="m128",formats="As Floats,As Doubles"},{type="boostoptional",formats=""},{type="TBuf",formats=""},{type="QPointF",formats=""},{type="TLitC",formats=""},{type="QRect",formats=""},{type="QByteArray",formats=""},{type="QMap",formats=""},{type="boostshared_ptr",formats=""},{type="QChar",formats=""},{type="QDir",formats=""},{type="QPixmap",formats=""},{type="QFlags",formats=""},{type="stdmap",formats=""},{type="QHashNode",formats=""},{type="QTemporaryFile",formats=""},{type="QModelIndex",formats=""},{type="EigenMatrix",formats=""},{type="stdstring",formats="",editable="true"},{type="QImage",formats="Normal,Displayed"},{type="QSet",formats=""},],hasInferiorThreadList="0"n"
>18^done
>19^done
<20set substitute-path C:/iwmake/buildmingwopensource C:/Qt/4.7.4
<21set substitute-path C:/ndkbuildrepos/qt-desktop/src C:/Qt/4.7.4
&"set substitute-path C:/iwmake/buildmingwopensource C:/Qt/4.7.4n"
>20^done
>&"set substitute-path C:/ndkbuildrepos/qt-desktop/src C:/Qt/4.7.4n"
>21^done
>&"set substitute-path C:/qt-greenhouse/Trolltech/Codelesscreatemore/Trolltech/Codelesscreatemore/Troll/4.6/qt C:/Qt/4.7.4n"
>22^done
dALL COMMANDS DONE; INVOKING CALLBACK
&"maint print msymbols C:/DOCUME~1/caldecor/LOCALS~1/Temp/gdbns.hg5708n"
>23^done
dFOUND NON-NAMESPACED QT
dNOTE: INFERIOR SETUP OK
dState changed from InferiorSetupRequested(4) to InferiorSetupOk(6).
dState changed from InferiorSetupOk(6) to EngineRunRequested(7).
dQUEUE: RUN ENGINE
dCALL: RUN ENGINE
24^error,msg="Error creating process C:/Documents and Settings/caldecor/Desktop/Projects/test-build-desktop-QtinPATHDebug/debug/test.exe, (error 193)."
dError creating process C:/Documents and Settings/caldecor/Desktop/Projects/test-build-desktop-QtinPATHDebug/debug/test.exe, (error 193).
dNOTE: ENGINE RUN FAILED
dState changed from EngineRunRequested(7) to EngineRunFailed(8).
dState changed from EngineRunFailed(8) to EngineShutdownRequested(20).
dQUEUE: SHUTDOWN ENGINE
dCALL: SHUTDOWN ENGINE
dPLAIN ADAPTER SHUTDOWN 20
dINITIATE GDBENGINE SHUTDOWN IN STATE 0, PROC: 2
25^exit
dGDB CLAIMS EXIT; WAITING
dGDB PROCESS FINISHED, status 0, code 0
dNOTE: ENGINE SHUTDOWN OK
dState changed from EngineShutdownRequested(20) to EngineShutdownOk(22).
dState changed from EngineShutdownOk(22) to DebuggerFinished(23).
dQUEUE: FINISH DEBUGGER
dNOTE: FINISH DEBUGGER
dHANDLE RUNCONTROL FINISHED
sDebugger finished.
Ack. Seems to be the spaces in the pathname. Sigh
when open a xx.cpp file,the QCreator will be exit .I think this is the bug of the QtCreator.
The qt-creator@qt-project.org mailing list is really a better place for discussions.
@Eike: If I followed your suggestion and not try to out think you, things would have worked much better. I have now successfully made things work with QtCreator 2.3.1. But still unable to make it work with 2.4.0-rc, it will tell me it is unable to load the helpers. I found a bug report for this in your tracker, but it is listed as Qt5 only, well I think it might be 4 as well in these older systems.
Again thanks for the help and link to the proper gdb.
Hello,
Do you have an idea on the date for the launch of QtCreartor 2.4.0?
At least for Christmas ;).
Thanks.
Good luck
@dini: definitely
I love the new "Show Containing Folder" & "Open Terminal" features. Really nice for my workflow.
Could we please get the double-click drag bug fixed for this new release?
For the past few months in QtCreator I have had to precisely click around the start word and and word of the text that I want to drag around. I used to be able to just double click and drag across really quickly & easily.
@michael: The word-selection-drag problem is an issue with Qt 4.7.4 that we can't solve from Qt Creator. That issue is fixed in Qt 4.8, which isn't released yet. (If you rely on that feature heavily it might be worth compiling Qt 4.8 and Qt Creator yourself from source.)
@Eike Can we then also assume that Qt4.8 will be out by Christmas too?
@tony: no idea, you'll have to ask someone that is involved in the Qt release process for an answer to that.
I'm also having serious problems with the debugger. I've found it to be verry buggy and ruining what is otherwise my favorite IDE.
I've also opened a bug report for a problem I had on Linux but it's still unresolved (need to retest to see if it still happens ).
While I do understand the need to introduce new code and features it would be nice to have the existing one with less bugs.
It's nice that Qt Creator is able to use the MS debugger too but it ships with GDB for Windows and right now that's not working for me under Windows 7 x64. Speaking of which it would be really nice to have a 64 bit for Windows.
That's all , sorry if I'm being a bit harsh ... I'm trying to work on something and I can't really debug it properly.
I know you "trolls" have always been nice, open and receptive.