[Qt-creator] Some thoughts about 2.5

[Geronimo Ma. Hernandez]

On Dienstag 29 Mai 2012, eike.ziller at nokia.com wrote:
> 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:
> > 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.

Don't know, whether I do understand what you like to say.
You don't want QtCreator perform a build, but you spent build an entry at main 
menu level?

To me "perform a build" means do anything necessary to compile and link the 
sources / the project. QtCreator does exactly that.
It offers all major tags, that are expected by a decent build system.

So what means, you don't want QtCreator perform a build.
Do you plan to caponize QtCreator and force the user to execute commandline 
tools?

So what does the first letter of IDE means?
or isn't QtCreator an IDE?

QtCreator is on the way to become the best C++ IDE out there. I would be very 
sad, if you reduce QtCreator to become just an editor.
Then I have no reason to continue using it.

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

Hm, from my point of view - you already past the biggest challenge. What can 
be harder than parse C/C++?
I don't think that any build-system is as complex as C/C++ sources could be.

Why not be pragmatic like at gdb-front:

For example:
It's no issue to collect all sources and headers down a certain tree. Combine 
each entry with a checked checkbox and offer that dialog to the user for 
import.
Most would be very happy having just an import like that.

If you then (additionally) read the build-system files, you already understand 
and support for creation, the IDE-benefit would rise a lot.

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

:) - you made my day :)

Thanks!

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

I'll execute something like "gdb --version" and have to parse only a single 
line. It works fine from Java-apps and I think its no issue for the c++-world.
You know the debuggers, you support, so asking for their version should be no 
challenge ;)


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

May be its possible to improve the shortcut-dialog that way, that the user 
understands when a shortcut is used and where conflicts circumvent their usage.

kind regards

Gero