[Qt-creator] Some thoughts about 2.5

[eike.ziller at nokia.com]

On 29 May 2012, at 15:08, ext Geronimo Ma. Hernandez wrote:

> On Dienstag 29 Mai 2012, eike.ziller at nokia.com wrote:
>> On 27 May 2012, at 06:14, ext Geronimo Ma. Hernandez wrote:


>>> - support for different window (number, size, position) for debug session
>>> and editing session and each session should save column size for lists
>>> too.
>> 
>> If you mean changing the layout of the debugging mode (I'm not sure what
>> you mean): Turn Window > Views > Locked off (also available through the
>> context menu on the debugger tool bar).
> 
> Thanks for that hint :)
> So I finally could place the variable window at the left from the editor. 
> Great!
> 
> But I did not mean that. 
> It would be nice, if each session (edit-session and debug-session) would be 
> able to handle different split-state / -number of editors and of cause different 
> size and location of windowparts.
> 
> As I already wrote before, during editing I like to have 4-6 editors, each 
> with different files. During debugging, I'd like to have only one editor and the 
> change in number of splitted windows should happen each time I start/stop the 
> debugger.

Aha. Thanks for the clarification.

>>> - files created by "new C++-class" should automatically become part of
>>> the (active) project, or add a context menu entry for project tree-nodes
>> 
>> As stated already, doesn't work with CMake build system support in Qt
>> Creator.
> 
> Ok - please lets take for granted, that I don't have any special interest in 
> cmake or any other build system. Its completely beyond my focus.
> The only thing I want, is an ide, that is able to import existing projects 
> (even from other build systems) and handle the tasks necessary during 
> development process - and for so: handle the build-task for me.

The decision had been made long ago that we don't want Qt Creator to actually perform a build. So we always rely on an underlying build system. How much of that build system a user must learn (e.g. to get even the simple things done) then depends heavily on the integration of that build system into Qt Creator. So, also on how well a build system can be integrated into an IDE, and also if someone took the effort to do it (or how *much* effort was spent to do it). From the Qt/Trolltech/Nokia viewpoint qmake integration was always the first priority, so that is in best shape atm. Konstantin seems to have worked on improving/replacing the cmake part, using a completely different approach than the current. Unfortunately there's nothing to show for the public (yet?), see http://lists.qt-project.org/pipermail/qt-creator/2012-March/000504.html and corresponding thread.

> Actually I use only 3 ide: netbeans, kdevelop and QtCreator and currently 
> netbeans is closest to my expectations of an c++ ide.
> netbeans generates all makefiles (and other stuff necessary for build, that I 
> don't want to care about) and it has dialogs, where I can add libraries and 
> set compiler switches. Most of them with checkbox or dropdown elements, but 
> there's also a plain text entry, where unknown options can be entered.
> 
> It's fine, if you say, qmake is the tool of choice - but please then add import 
> wizards and tools for transformation of other build systems.
> May be an import wizard could work like build-systems in java-world, where any 
> source below a given directory is part of the project and for so imported.

"qmake -project" tries to do something like that, and also a little command line tool "qtpromaker" that we ship with Qt Creator. But the Java world tends to be pretty simple compared to the C/C++ world, so you'll need to edit the result heavily in all except the most trivial cases. A C/C++ project has most probably *not* been written in a way that makes that kind of importing possible.

>>> - follow symbol under cursor should keep track of open editors and if
>>> more than one editor is open (splitted), the current active editor
>>> should not change.
>> 
>> If the "target" file is currently visible in another split that probably
>> would be better. Otherwise, if the editor is only split in two, it might
>> be better to open in the non-active split, I'm not sure about that though.
>> If it is split further, what would the heuristics be for choosing where to
>> open the file?
> 
> Well, kept thinking about that.
> It looks to me, as if you don't make any differences between the editor-
> instances in splitted windows. That's not bad at first sight, but ...
> 
> What about a virtual link between editor parts.
> If you number the editors on each split action, you have unique ids for the 
> editor. I could imagine a context operation which says: editor #1 is the 
> header editor for editor #3
> 
> With such a link, the dropdown boxes of editor #1 could be filtered to show 
> only headers (*.h*) and the dropdown box from editor #3 will be filtered to 
> show only sources (*.c*). Additionally these both editors could be linked, 
> that whenever one changes its file, the other loads the appropriate matching 
> file too.
> 
> As a java-developer I only think in classes, not in declaration and definition 
> - as that difference does not exists in java. Well - if I have to care about 
> the differences, it would be nice, to have the complete class at fingertips.
> 
> And talking about editor improvements:
> I believe, human beings are faster for pattern matching on sorted lists, than 
> on others, So it would be great to sort the outline-dropdown from editor. I'll 
> guess, the order of occurrences in file is not important, if you just want to 
> jump to another entry.

Right-click, "Sort alphabetically".

>>> - mark all occurrences of symbol under cursor (variable, function, class,
>>> what ever) in the current file (or better in all visible files) so
>>> usages can be visualized very fast
>> 
>> Qt Creator marks occurrences inline since a while (also in 2.5).
>> [cid:f982770b-b545-4251-924d-a7b8152bffcd at mgd.nokia.com]
> 
> Yes, I realized that - meanwhile.
> But - its too anemic to get rid of it.
> I use a desktop with 3600x1900, so the dotted box is nearly invisible.
> Beyond that, I consider the little dashes that mark all occurrences outside 
> the viewport more important than the little dotted box.

Yes, an indicator showing all the occurrences in the file on once glance sounds like a good thing to have.

> If you ever worked with such a visualization, you don't wonna miss it any 
> more. Just imagine - you put the cursor on a printf and see all lines you have 
> to comment out or remove ;)

>>>>  UNSUPPORTED GDB VERSION GNU gdb (GDB) 7.0.1-debian
>>> 
>>> Why not pop a messagebox, with a (localized - is QtCreator localized?)
>>> message, telling that the gdb is not supported.
>> 
>> That would certainly be better, at least for
>> really-too-old-or-otherwise-known-not-to-work-gdbs. (With the usual never
>> tell me again (about this specific gdb version?) option.)
>> 
>>>> Sorry to be blunt, but if you move outside the area (and era) of what
>>>> your distribution offers you, _you_ are responsible for making sure
>>>> all dependencies are met.
>>> 
>>> I partially agree. If I'd build QtCreator from sources, I'd fully agree.
>>> 
>>> But using a binary installer, that ships all but one requirements?
>> 
>> Well, we also don't ship a compiler tool chain, nor 'make', nor 'qmake' or
>> cmake or any other actual build tool, 
> 
> OK - that was misleading.
> 
> I don't expect you to ship a debugger.
> Just add a little check to the installer and everything is fine :)

I'd claim that finding out what debuggers someone has installed on a Linux system is next to impossible. Anyhow, some kind of more visible warning at runtime (when Qt Creator definitely knows what debugger the developer tries to use) would be nice, as stated above.

>>>> Works here. Note that <F3> is typically taken by "Find Next".
>> 
>>> So what steps are necessary to make it work?
>> 
> 
>> Whenever you change a shortcut and it turns red it's possible it won't work
>> because of a conflict.
>> (Unfortunately I couldn't figure out how it could be possible to catch the
> 
> I thought about conflicts and sorted the list by shortcut, to get rid of 
> doublets - I thought, I got them.
> Anyway - meanwhile I noticed, that it works sometimes. Don't know yet, what it 
> depends on.

Ctrl+Shift+C is bound to running semantic qml checks which is a global action that is always enabled, while F3 is bound to "Find Next" which is only enabled if you have searched for something. Shortcuts work as long as you only have one enabled at the same time.

>>> I'll be surprised if builds from Ubuntu 10.04 work on Debian stable.
>> 
>> He installed our 2.5 binary packages that were also built on Ubuntu 10.04.
> 
> Well, normally installers check the system, before they vomit on disk - so I 
> thought, that QtCreator was statically linked or will handle paths for shared 
> libs in special manner.
> But if your installer does not check the system, its a miracle, that my system 
> still works.

We don't touch your system. We only write things to the directory that you give the installer (or tell 7z where to extract the nightly build). Qt Creator uses the libraries that we ship (mostly the Qt libs, using RPATHs, some bits statically linked). All other libraries that Qt and Qt Creator depend on are taken from the system as is, and it's surprising that your system provides libraries that can actually be used by Qt and Qt Creator.

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori