Porting of Qt Creator

[Yagiza]

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.

[Dmitry A. Kuminov]

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

[rudi]

Qt Creator 1.3.1 can be found here ​http://svn.netlabs.org/qtapps/wiki/QT4%20Development

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.

[yagiza]

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

qmake.exe S:/Working/eyeCU/eyecu/eyecu.pro -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.

[yagiza]

16. S.

I mean this part of the line is hardcoded:

D:\Coding\qt\qt-all-opensource-src-4.6.3-os2\mkspecs\os2-g++

[rudi]

See ticket #211 for a quick workaround.

[Silvan Scherrer]

last diff from Rudi

[Silvan Scherrer]

patch from Rudi fot qtcreator 2.2.1

[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.

[rudi]

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

[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: ​https://github.com/dmik/qt-creator-os2/. We will work on a dedicated branch, ​https://github.com/dmik/qt-creator-os2/branches/2.2-os2 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).

[Dmitry A. Kuminov]

Ah, a working port of git for OS/2 you will find here ​http://bauxite.sakura.ne.jp/software/os2/.

[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.

[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: ​https://github.com/dmik/qt-creator-os2/commits/2.2-os2.

[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:

​http://groups.google.com/group/comp.os.os2.programmer.misc/browse_thread/thread/aef964bdd5aaaf9/cba9aaa25d5ef16c?lnk=gst&q=libpath#cba9aaa25d5ef16c

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. qtc221_patch_v2.zip on top of ​http://get.qt.nokia.com/qtcreator/qt-creator-2.2.1-src.zip

[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 qtc220_diff.zip, 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 qtc220_diff.zip 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.

[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".

[rudi]

Diff from after merging 2.2.1 to my current tree

[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.

[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://github.com/dmik/qt-creator-os2.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).

[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 

[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/static.pro 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}
     copy2build.name = 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}
 unconditionalCopy2build.name = 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.

[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 {
    DESTDIR = $$IDE_LIBRARY_PATH/QmlDesigner
} 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:

include(plugindestdir.pri)

to:

include(../plugindestdir.pri)

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

[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).

[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?

[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/dumper.pro. Will do some more tests as time permits...

[rudi]

Don't install DebugHelper

[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).

2. 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 ​https://github.com/dmik/qt-creator-os2/issues/1.

3. 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 ​https://github.com/dmik/qt-creator-os2/issues/2.

4. 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 ​https://github.com/dmik/qt-creator-os2/issues/3.

5. 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 ​https://github.com/dmik/qt-creator-os2/issues/4.

6. 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.

[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).

[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.

[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...

[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.

[rudi]

Fix for unwanted folder icon scaling

[rudi]

Fix for unblured file icons

[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...

[rudi]

Don't show ".." in root dirs

[Dmitry A. Kuminov]

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

[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).

[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.

[Dmitry A. Kuminov]

I created issues at ​https://github.com/dmik/qt-creator-os2/issues/ for all remaining problems including the last one (​https://github.com/dmik/qt-creator-os2/issues/5). 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.