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