Opened 10 years ago

Closed 9 years ago

#205 closed task (fixed)

Porting of Qt Creator

Reported by: Yagiza Owned by:
Priority: major Milestone: Qt 4.7
Component: General Version: 4.6.3
Severity: low Keywords: Creator IDE


It looks like Qt Creator is a part of Qt SDK from Nokia. So, I think it's a good idea to port it also, 'cause there is no IDE for OS/2 (eCS) now to be used to work on Qt projects, so developers need to use Windows/Linux? to develop Qt apps and use OS/2(eCS) prot of Qt just for building OS/2(eCS) port of their apps. Porting Qt creator will let use OS/2(eCS) as an enviornment for developing Qt apps.

Attachments (8) (32.4 KB) - added by Silvan Scherrer 9 years ago.
last diff from Rudi (36.6 KB) - added by Silvan Scherrer 9 years ago.
patch from Rudi fot qtcreator 2.2.1 (36.8 KB) - added by rudi 9 years ago.
Fixes a minor problem with shadow builds (file name quoting) (5.8 KB) - added by rudi 9 years ago.
Diff from after merging 2.2.1 to my current tree
dumper.diff (436 bytes) - added by rudi 9 years ago.
Don't install DebugHelper?
navigationtreeview.diff (534 bytes) - added by rudi 9 years ago.
Fix for unwanted folder icon scaling
fileicons.diff (2.3 KB) - added by rudi 9 years ago.
Fix for unblured file icons
foldernavigationwidget.diff (1.1 KB) - added by rudi 9 years ago.
Don't show ".." in root dirs

Download all attachments as: .zip

Change History (39)

comment:1 Changed 10 years ago by Dmitry A. Kuminov

Milestone: Qt EnhancedQt 4.7

Sure. It will be done as part of 4.7, I think.

comment:2 Changed 9 years ago by rudi

Qt Creator 1.3.1 can be found here

This is the "newest" version that can be built using Qt4.6.3. Debugging doesn't work due to the lack of a suitable GDB. (Maybe I didn't search hard enough). There is a diff file in the package, which might help porting a newer version of Creator.

comment:3 Changed 9 years ago by yagiza

Jist installed and tried it. For some reason, this line seems to be hardcoded:

qmake.exe S:/Working/eyeCU/eyecu/ -spec D:\Coding\qt\qt-all-opensource-src-4.6.3-os2\mkspecs\os2-g++ -r

I have Qt installed in different path, so an attempt to run qmake ends up with an error message:

Failure to read QMAKESPEC conf file d:\Coding\qt\qt-all-opensource-src-4.6.3-os2\mkspecs\os2-g++\qmake.conf.

comment:4 Changed 9 years ago by yagiza

  1. S.

I mean this part of the line is hardcoded:


comment:5 Changed 9 years ago by rudi

See ticket #211 for a quick workaround.

Changed 9 years ago by Silvan Scherrer

Attachment: added

last diff from Rudi

Changed 9 years ago by Silvan Scherrer

Attachment: added

patch from Rudi fot qtcreator 2.2.1

comment:6 Changed 9 years ago by rudi

Note that Qt Creator 2.2.x needs tickets #221, #222 and #223 to be resolved. When using a separate build directory (as suggested in README), ticket #220 has to be fixed as well. However, building within the source tree is possible.

Last edited 9 years ago by rudi (previous) (diff)

Changed 9 years ago by rudi

Attachment: added

Fixes a minor problem with shadow builds (file name quoting)

comment:7 Changed 9 years ago by Dmitry A. Kuminov

I decided to host the process of porting Qt Creator to OS/2 in GIT instead of SVN since GIT is much more powerful and better suits our development needs. For this task, I created a project on github: We will work on a dedicated branch, which is based on Qt Creator 2.2.1 (tag v2.2.1) because this is a target version for our OS/2 release of Qt Creator.

I'm currently in the process of applying Rudi's patches to GIT (and learning/practicing with this wonderful tool in parallel since there is a plan to move all our projects to GIT actually). Rudi, please hold your Qt Creator activity until I finish. Your further updates should go directly to github through the "pull requests" facility (most likely).

comment:8 Changed 9 years ago by Dmitry A. Kuminov

Ah, a working port of git for OS/2 you will find here

comment:9 Changed 9 years ago by Dmitry A. Kuminov

Note that in r884 I added a workaround to qmake that makes it unnecessary to fix statements like DEFINE += VAR=\\\"STRING\\\" in each .pro file (relates not only to Qt Creator of course). We face this issue so frequently, and it's much easier than getting this fixed in GCC builds -) so I decided to fix qmake instead.

comment:10 Changed 9 years ago by Dmitry A. Kuminov

Rudi, I have several questions about your patches (it was actually not a good idea to submit them as one .diff, but let's go like that this time since I already started applying them).

  1. What is the purpose of PluginSpecPrivate::os2AddToLibPath()?
  2. Why did you change the timeout from 120000 600000 in buildablehelperlibrary.cpp?

Also, you didn't notice (and I didn't check) that your patches are cumulative, so I started with the 2.2.0 patch. Can you please attach here a diff between your patched 2.2.0 and 2.2.1 trees so that I will see what was changed?

JFYI, you may check what I already pushed to github here:

comment:11 Changed 9 years ago by rudi

1.) In some cases a plugin (A) depends on other plugins (B, C). In this case A is linked against B's and C's import lib. Creators extension system contains code to determine the proper load order from the *.pluginspec files. However, when B and C are also loaded via fully qualified name, OS/2 refuses to resolve A's imports. Even though B and C got loaded successfully before A. My solution is to add each directory from which a plugin was loaded to "LIBPATH". I choose ENDLIBPATH because I thought that this would interfere less with the default LIBPATH setting. Also see:

2.) On a slow machine building of the helper library got aborted prematurely.

The patches are meant to be applied to the officially downloadable creator source code from the Nokia web site. I.e. on top of

Last edited 9 years ago by rudi (previous) (diff)

comment:12 Changed 9 years ago by Dmitry A. Kuminov

I guessed that the patches are applied to the downloadable bundles, and I believe that what is tagged with v2.2.1 is what the 2.2.1 downloadable bundle contains.

Regarding the last diff. Sorry, I wasn't clear enough about what I need. I need a diff between your patches, not the diff between the whole trees (this is a very huge diff, I will spend years sorting it out -) Can you just give me what you patched after you took the, excluding the official 2.2.0 to 2.2.1 changes? You can do that by svn merge -r A:B <path_to_wc_root> where A is the revision after the 2.2.1 merge and B is the head. If there were patches after but before merging 2.2.1 in, you can get them using the same command with the respective revisions as well.

1.) Okay, that's what I guessed. I had the same issue in Java and used a similar solution there (I do really think it'a bug in the loader). Though I use BEGINLIBPATH without humbleness and I guess we should go that way here too: imagine if there is a DLL with the same name as the plugin somewhere in LIBPATH/BEGINLIBPATH just by accident -- it will be found first...

2.) Okay, I see.

Last edited 9 years ago by Dmitry A. Kuminov (previous) (diff)

comment:13 Changed 9 years ago by rudi

I have a bit of a problem due to my limited knowledge of SVN. However, I *think* the newly attached diff should represent what you want. Even though it contains some - IMHO unnecessary - updates to the "extrasplugin".

Changed 9 years ago by rudi

Attachment: added

Diff from after merging 2.2.1 to my current tree

comment:14 Changed 9 years ago by Dmitry A. Kuminov

It seems that you did it right this time. Thank you! And I of course meant svn diff -r A:B above, not merge...

In either case, we will be thankful if you review how I apply your patches at github (the link is above).

If you have any particular questions about SVN, GIT or the cosmetic changes I sometimes apply to your patches before committing them to the official tree, don't hesitate to ask -- I will try to answer them all.

comment:15 Changed 9 years ago by Dmitry A. Kuminov

Rudi, I committed all your patches except the hack that works around QProcess piping and UIC EOL problems. I will fix those in Qt instead of applying the hack. Also the change that adds the desctiption to all DLLs and EXEs is left out; I will deal with that later (needs some small qmake fix).

files-to-patch-os2 is also left out since that should not be necessary once #211 is closed. (Note also that as opposed to other platforms, paths returned by QLibraryInfo are *not* hard-coded into the DLLs on OS/2).

Note that I only found one change made by you since your original 2.2.0 patch (excluding any Nokia's 2.2.0 to 2.2.1 updates): aa63ca. If there were more changes from you, then your last patch was not fully correct (or I screwed up applying it). Anyway, please clone the git repo and compare to your local 2.2.1 tree to check that I picked up everything. You can clone to a local directory <dir> with this command:

git clone git:// <dir>

WRT the LIBPATH fix for plugins. I committed it in 525da6. Note that I changed ENDLIBPATH to BEGINLIBPATH (and also fixed a small file name case problem).

comment:16 Changed 9 years ago by Dmitry A. Kuminov

Also, after cloning, you will have to switch from master to the 2.2-os2 branch by doing this while staying in <dir>:

git checkout 2.2-os2 

comment:17 Changed 9 years ago by rudi

There were not so terribly many changes between the 2.2.0 and the 2.2.1 patch. However, I'm not sure if I can manage to look at this in detail before the end of next week. One thing I noticed is that a small change in /share/qtcreator/ is missing. You will see the consequences when you do a "make release-install".

@@ -53,7 +57,7 @@
     copy2build.output = $$IDE_DATA_PATH/${QMAKE_FUNC_FILE_IN_stripSrcDir}
     isEmpty(vcproj):copy2build.variable_out = PRE_TARGETDEPS
     win32:copy2build.commands = $$QMAKE_COPY \"${QMAKE_FILE_IN}\" \"${QMAKE_FILE_OUT}\"
-    unix:copy2build.commands = $$QMAKE_COPY ${QMAKE_FILE_IN} ${QMAKE_FILE_OUT}
+    unix|os2:copy2build.commands = $$QMAKE_COPY ${QMAKE_FILE_IN} ${QMAKE_FILE_OUT} = COPY ${QMAKE_FILE_IN}
     copy2build.CONFIG += no_link
     QMAKE_EXTRA_COMPILERS += copy2build
@@ -106,7 +110,7 @@
 unconditionalCopy2build.output = $$IDE_DATA_PATH/${QMAKE_FUNC_FILE_IN_stripSrcResourceDir}
 isEmpty(vcproj):unconditionalCopy2build.variable_out = PRE_TARGETDEPS
 win32:unconditionalCopy2build.commands = $$QMAKE_COPY \"${QMAKE_FILE_IN}\" \"${QMAKE_FILE_OUT}\"
-unix:unconditionalCopy2build.commands = $$QMAKE_COPY ${QMAKE_FILE_IN} ${QMAKE_FILE_OUT}
+unix|os2:unconditionalCopy2build.commands = $$QMAKE_COPY ${QMAKE_FILE_IN} ${QMAKE_FILE_OUT} = COPY ${QMAKE_FILE_IN}
 unconditionalCopy2build.CONFIG += no_link
 QMAKE_EXTRA_COMPILERS += unconditionalCopy2build

Initially (2.2.0) I thought that we should use the windows-style command. However, since our QMake will automatically quote file names, the unix way is the route to go (2.2.1). BTW, be sure to let the environment variable INSTALL_ROOT point to the absolute destination path before making any of the "install" targets.

comment:18 Changed 9 years ago by rudi

Another issue that is missing in the patch: Creator's qmldesigner plugin does have sub-plugins of it's own. These are "qtquickplugin", "extrasplugin", "meegoplugin" and "symbianplugin". The supplied *.pro files don't generate installs targets for those plugins. Thus "make install" will not copy them to the desired destination directory. My fix is to create a file named "plugindestdir.pri"

macx {
} else {
    DESTDIR = $$IDE_BUILD_TREE/lib/qmldesigner

    target.CONFIG += no_check_exist
    target.path = /$$IDE_LIBRARY_BASENAME/qmldesigner

    win32 {
        target.files = $$DESTDIR/$${TARGET}.dll
    } else:os2 {
        isEmpty(TARGET_SHORT): target.files = $$DESTDIR/$${TARGET}.dll
        else: target.files = $$DESTDIR/$${TARGET_SHORT}.dll

    INSTALLS += target

in the directory src/plugins/qmldesigner . In the *.pro files of the mentioned plugins, I changed the line:




which makes multiple instances of "plugindestdir.pri" (in each plugin subdir) obsolete.

Last edited 9 years ago by rudi (previous) (diff)

comment:19 Changed 9 years ago by rudi

except the hack that works around QProcess piping and UIC EOL problems

Yep. Tickets are #212 and #199 . #213 might be related to the latter. You can see the consequences with Creator when you edit a form in designer mode. When the designer panel is closed, the CPU load will jump up to 100% and Creator will become unresponsive for 30 seconds (default QProcess timeout).

Last edited 9 years ago by rudi (previous) (diff)

comment:20 Changed 9 years ago by Dmitry A. Kuminov

I applied the plugindestdir improvement based on your patch from comment:18 as well as the rest of mentioned differences.

Will now work on the above tickets.

Besides that, do your patches cover all OS/2-specific differences or there is anything else that needs to be done?

comment:21 Changed 9 years ago by rudi

I have checked the GIT sources and it looks O.K. to me. A minor thing is that we should not generate an install target for DbhHlpr?.dll. See comment on first line of src/plugins/debugger/ Will do some more tests as time permits...

Changed 9 years ago by rudi

Attachment: dumper.diff added

Don't install DebugHelper?

comment:22 Changed 9 years ago by Dmitry A. Kuminov

Qt Creator works not bad now. Some cosmetics:

  1. The stock Desktop and Folder icons (used in the UI to denote the current build configuration on the left toolbar and regular folders in the Filesystem view, respectively) are badly scaled. Done (see comment:29).
  1. Different fonts in Application Output (seems to use the Editor's font) and in Compile Output / Version Control (seems to use the UI font, i.e. Warpsans) windows. The commit message text box has also a strange font. Moved to
  1. The message "The binary 'git' could not be located in the path " when pressing OK or Apply in the Options dialog if it is open on the Version Control / Git tab. But git itself actually works (quite nicely I must say). Moved to
  1. Ctrl-> and Ctrl-< shortcuts don't work. Interesting that the Keyboard shortcuts setup dialog does recognize them, but when used in the editor, they don't perform the assigned action. Moved to
  1. The Qt Creator main window's icon changes when external commands are run (e.g. when you qmake/build the project). Also, the window list entry gets changed. Moved to
  1. Qt Creator ignores external file changes despite the setting on the General tab of the Environment page. (Fixed within #231, was a Qt problem).

PS. The fix for dumper.diff has also been applied.

Last edited 9 years ago by Dmitry A. Kuminov (previous) (diff)

comment:23 Changed 9 years ago by rudi

1.) You really don't like blurred icons, aren't you ?

2.) I think this is done by purpose. At least the Windows version is also using different fonts for application and compile messages. I have not used Git within Creator. Only SVN.

3.) That is strange. Did you have "Environment Variables" checked ? If so, it the path is taken from the entry field and if this one is empty you'll get this message. If you uncheck it the regular path should be used. But there appears to be a bug at least with respect to the path that is shown in the error box.

4.) Ctrl-< does work here, Ctrl-> does not. At least on a German keyboard the latter requires shift as well. Maybe this is the culprit. However, it works in Windows.

5.) This is a nice one. I already spent a few hours in order to find out why this happens (Creator 1.3 shows this behavior as well). Somehow I have the feeling that this is a PM bug, that is triggered by the use of a QEventLoop (i.e. the creation of a secondary message queue + handling thread).

Last edited 9 years ago by rudi (previous) (diff)

comment:24 Changed 9 years ago by rudi

The reason for 6.) is, that our native file system watcher doesn't recognize changes in modification time stamps. We only get notified, when the creation time stamp is updated. If the polling file system watcher is enforced, Creator behaves as expected.

comment:25 Changed 9 years ago by Dmitry A. Kuminov

Re 6., I was having problems with not getting RCNF_CHANGED (as Google reminded me -) when I implemented the Dos*ChangeNotify-based file system watcher. Now I see why. How stupid one should be to implement RCNF_CHANGED that way! I don't get it.

Anyway, this draws the current implementation completely useless (as file change notifications is obviously the most needed feature). We will have to permanently switch back to the polling approach...

comment:26 Changed 9 years ago by rudi

About 1.). The attached patch improves the appearance of sub-folders within the project tree. While top-level nodes (Headers, Sources, Forms etc) have a forced size of 16x16, sub-folders use the default (small) icon size of the system. In our case this is 20x20 and since we don't have any real pixmap of that size the 16x16 one is upscaled.

Thinking a bit more about this: The icon size should be forced on any platform, not just on OS/2. The code should never rely on the fact that a small icon size is 16x16.

The blurred "Computer" icon on the left action bar is avoided by #237.

Finally here is a solution that avoids the blurred icons in the file system view. It switches the icon size to 20x20 and centers the 16x16 overlay pictures that are drawn on top of them.

Last edited 9 years ago by rudi (previous) (diff)

Changed 9 years ago by rudi

Attachment: navigationtreeview.diff added

Fix for unwanted folder icon scaling

Changed 9 years ago by rudi

Attachment: fileicons.diff added

Fix for unblured file icons

comment:27 Changed 9 years ago by rudi

Not sure, if I should open a ticket for that but it's something we already discussed. Some (but not all (!)) file systems on OS/2 report a (hidden) ".." entry in root directories. In case of Creator this allows the user to change up to the drive list. On Windows this is not possible and I'm not 100% sure that this scenario is correctly handled by Creator. In order to achieve consistent behavior, I modified foldernavigationwidget.cpp to not allow changing to "My computer". However, I still think we should filter out ".." for root directories in the lower level file system code...

Changed 9 years ago by rudi

Attachment: foldernavigationwidget.diff added

Don't show ".." in root dirs

comment:28 Changed 9 years ago by Dmitry A. Kuminov

Hmm, I think we already did it after that discussion (at the lower level). I will check.

comment:29 Changed 9 years ago by Dmitry A. Kuminov

Re 1). Yes I don't really like blurred icons. I'm a Mac kind of guy. My eyes hurt before and now they feel relief when looking at Qt Creator after fixing #237 as you suggested and applying the fileicons.diff patch -) Thanks!

Note that navigationtreeview.diff is not applied. I'm not sure if we should use iconSize() there as well as I couldn't find a place where it affects the icon size (didn't search hard though).

comment:30 Changed 9 years ago by Dmitry A. Kuminov

Regarding "..". Yes, it looks like this behavior is unintended but are you sure it's a bug? It looks like a (handy) feature to me. The only other way to change drives in this view is to RMB on the header, select Choose Folder..., select the necessary drive from the popped file dialog etc., in other words much more actions to perform.

What do you think if we improve it a bit instead? E.g. by making sure ".." is always added to the root directory listing (even on Windows) and clicking it shows My Computer. We will also need to sort items in the My Computer list properly (they look unsorted now) and to make the header show "My Computer" (instead of ".." as now).

Regarding filtering out ".." on a lower level, I created #242 for that. To be further discussed.

Last edited 9 years ago by Dmitry A. Kuminov (previous) (diff)

comment:31 Changed 9 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: newclosed

I created issues at for all remaining problems including the last one ( So let's move our discussion there, please.

This task is considered to be done as Qt Creator is already good enough for releasing as it is now.

Note: See TracTickets for help on using tickets.