[Qt-creator] Some thoughts about 2.5

[Geronimo Ma. Hernandez]

On Dienstag 29 Mai 2012, eike.ziller at nokia.com wrote:
> On 27 May 2012, at 06:14, ext Geronimo Ma. Hernandez wrote:
> 
> Collecting from different mails:
>
> > I gave QtCreator another try and found out, that the behaviour is
> > different for changing the prototype of a function and adding a
> > function.
> 
> Usually adding the definition of a function would be meaningless without
> putting something into the function body. Both after adding a function
> declaration and definition, one usually will want to change the exact
> location of that code too. So "usually" jumping to the corresponding
> source/header is the better thing to do.

Already thought about that, but I believe, its not the only/best choice. Best 
choice is to allow the user to choose what shall happen. 
Either by different shortcut or by configuration setting.

Your assumptions are right, if you add only one function and then code that 
function. These assumptions fail, when you create a new class and add a bunch 
of functions and like them all be created by refactoring.
... or if you split an existing function into several functions and want them 
to get added to declaration.

And if you use splitted editors, background processing is still the best 
choice, as the other file most probably will be open in another editor.

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

> > - support templates for file, class and method creation (file-templates
> > distinct for each extension), with placeholder for date, username,
> > classname, ...
> 
> That could certainly be extended / be made more GUI friendly. For what you
> can do right now: http://doc.qt.nokia.com/qtcreator-extending/index.html
> (Generating Domain Specific Code and Templates)

As QtCreator becomes more beloved with the time using it, I'll check it out.
 
> > - 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.
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.

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

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

> > I'm quite sure, that I'm not the only user of debian stable, who likes to
> > use a sophisticated ide.
> 
> I'm not sure of that ;)

:D
 
> >>   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 :)

>>> 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.
Well, F3 (follow cursor) works sometimes, but Ctrl-Shift-C workes no times.

> It depends on Qt, so sort of internal-external...
>
Could there arise conflicts with older Qt-libs?
My system uses qt4.4 and I don't know - does the window-manager checks the 
events too? My X-Server will be outdated too.

> Message about conflict is printed to debug output, isn't it?

Hm, I know from eclipse, that one keyboard-shortcut could trigger several 
actions, depending on the editor context. 
That's why I asked, whether QtCreator has different Ide-states too.

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

by the way:
In the meantime I debugged a bit with QtCreator and even as I'm no friend of 
kdevelop, I have to state, that the var-section from kdeveloper is much 
better, than the one from QtCreator.
Especially the handling of static buffer is great in kdevelop. If you have a 
char buf[2000] and hit the + infront of the buffer, you don't see any other var 
in QtCreator. Kdevelop shows only a chunk of 4 elements, and offers the choice 
to extend the visual part. That's really useful, so you don't loose the 
overview.
I also like the point, that char pointers show the first element as hex and 
decimal (below the string). That's really helpful, especially to get rid of 
whitespace in buffer.
May be you could enhance the representation of static buffers and show the 
string for char[n] the same way as for char*

Another option to enhance var section would be a detail section like in 
eclipse, where each var is shown in detail, if it is selected by cursor. That 
way you can leave the vars collapsed and inspect the details by walking with 
the cursor.

kind regards

Gero