[Qt-creator] Planning Qt Creator 2.8 + 0.1

[Jan Krause]

Hi all,

it would be great if QtC could be better used as a framework for 
developing applications with different background (e.g. modeling, 
engineering, verification, test generation, etc.); similiar to eclipse 
but easier and much more beutiful ... :)

I think the most is done. The plugins are clear and with some more 
documentation it is very easy to implement own plugins. With the new 
multi-monitor support, I think all features are available for using QtC 
as an application framework building nice apps with a very good user 
experience...

But for this case some must-use-plugins (core, projectexplorer, welcome) 
should be implemented with a more clearly defined functionality; e.g. I 
don't need kits, compilers, etc. for my projects but I need the other 
functions of the projectexplorer-plugin. There are some more similiar 
issues, also within other plugins...I think, it is not much to do, but 
maybe some plugin-redesign is necessary...Also, it is really an option, 
that I'm totally wrong...

But, I know, it is not the major focus of QtC being an application 
framework...but maybe...;)

Thx for QtC, its really the best all time C++IDE...

Cheers
Jan

Am 13.06.2013 16:06, schrieb Poenitz Andre:
> Hi all.
>
> With 2.8 beta out of the door it's not yet time to call the release done, but
> we can already spend a few brain cycles on what should happen after 2.8 final.
>
> A few ideas are already sort of fixed, a few completely open for discussion,
> some need feedback from users and the developer crowd.
>
> 1. Time line: We'd like to stick to the usual 4-month cycle, putting the
> target date for the Final somewhere to November. Reason: The current cycle
> setup works well, no need to change. Also November is generally a rather nice
> month for releases, due to its distance to holiday seasons.
>
> 2. 2.8 + 0.1 makes 3.0, as we use base-9 for version numbers ;-). More
> seriously, we'd like to make the point that with Android and iOS support we
> have a new "phase". At the same time we'd like to stiffen the rules on core
> compatibility to make it easier for 3rdparty plugin developers to keep their
> plugins working. Current thinking is to aim at source and binary compatibility
> within a minor series (i.e. 3.0 and 3.0.1 could be interchanged, but not, say,
> 3.0 and 3.1).
>
> 3. We will focus on building of Creator itself with Qt 5. The plan is to keep it
> compilable as long as painlessly possible with Qt 4. I think by then (almost a
> year after Qt 5 came out) the point has been made that it is possible to keep
> a code base of the size of Creator without much pain compilable with Qt 4 and
> Qt 5 at the same time. It's time to get access to the Qt 5-only goodies now.
> This would also make it possible to upstream generally useful parts from
> Creator into Qt again which is currently hindered by the "don't play with Qt 4"
> policies.
>
> 4. "committed" contents: Essentially tying up loose ends. There are obvious
> gaps in Android and iOS support that needs to be closed, and we have a couple
> of other "in progress" or currently "experimental" items (multi-monitor
> support, lldb debugger support) that should be finished.
>
> 5. "committed" maintenance: In preparation of the potential compatibility
> promises the core interfaces need some auditing, and possibly re-shuffling
> and "real" documentation. In addition there should be general performance
> audit/profiling including fixing the most glaring issues that will come up.
>
> Not-so-fixed:
>
> 6. Use of C++11. There are quite a few goodies in the language nowadays
> that look very interesting. We should identify a few ones that would really
> help us, and double check with the compilers we need to support which
> ones we could actually use, and then decide on whether we should, or not.
> For that, input on which compilers people actually use, and which they
> really need to use to compile Creator would be beneficial.
>
> 7. wip/clang: Progress would be highly desirable. It's unlikely though, to get
> this anywhere close "production ready" in this period, so the current thinking
> is to bring it in a state where it's user-configurable, and perhaps have that
> configurable per-language, so that it can get some exposure in the Real
> World for, say, C projects, where the performance impact is less visible.
>
> Andre'
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator