[Qt-creator] Planning Qt Creator 2.8 + 0.1

[Ziller Eike]

On 13.06.2013, at 20:15, Jan Krause <jan.krause.no19 at gmail.com>
 wrote:

> Hi all,

Hej,

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

Indeed it isn't, and the slow introduction of source/binary compatibility policies (i.e. that we have a policy that goes a bit further than "there is no compatibility") is not meant as a focus change :). The focus is still that Qt Creator is an IDE, that can be extended wrt some functionality. We want to make it easier for plugins that are not upstreamed for whatever reasons to follow Qt Creator's release cycle, though.

Br, Eike

> 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
> 
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B