[Qt-creator] Settings for naming conventions
jochen_becher at gmx.de
Tue Jan 12 18:38:50 CET 2016
Am Dienstag, den 12.01.2016, 10:19 +0100 schrieb Nikolai Kosjar:
> On 01/09/2016 05:28 PM, Jochen Becher wrote:
> > I would add the new settings to the cpptools plugin but I am not
> > sure
> > about the preferred design:
> > 1. I could extend the coding style settings which are connected to
> > the
> > TextEditor by design (realization of a codiong style interface) but
> > naming conventions are not aligned to the TextEditor in the same
> > manner
> > as coding style are.
> > 2. I could implement a new settings class which is loosely coupled
> > to
> > the cpptools plugin like e.g. the todo plugin settings.
> > 3. Or I could implement a new settings class which is strongly
> > coupled
> > to the cpptools plugin.
> > What do you prefer? Do you have a different preferred design in
> > mind?
> Could you elaborate a bit on 2. and 3.? What would be the difference?
> How does "strongly coupled" look like in this case?
Ad 2: ToDoPlugin uses ProjectExplorer::Project::setNamedSettings() to
set its settings on a project. ProjectExplorer::Project has no
dependency on ToDoPlugin.
Ad 3: cpptools plugin knows a number of settings (e.g. CppToolsSettings
If I follow (2) I could write a new plugin that supports naming
convents. Every client of the API needs a dependency to the plugin
(which could be an optional dependency if the plugin has a fall-back if
the NamingConvention plugin is disabled).
If I follow (3) I add NamingConventionSettings to cpptools plugin. This
has the advantage that the naming conventions will be available for
most use cases (e.g. C++ wizards and refactorings) without any need for
handling optional plugins and fall-back code. It has the disadvantage
will not work with this design.
I do need a naming convention settings class, global option page,
project settings widget, some model classes and a controller class and
a boundary class for the public API. About 8 classes in total. Will
make the cpptools plugin even larger.
I like (2) because it is a clean plugin based design and can be
extended for other languages than C++.
I like (3) because it is easier implementing both the settings and the
clients of the naming conventions.
> The integration into current code style settings as seen by the user
> the options dialog (Menu: Tools > Options > C++ > Tab: Code Style)
> the projects mode (Projects Mode: Code Style) seems appropriate.
> CppCodeStylePreferences and CppCodeStyleSettings are already
> exported, I
> don't see a problem enhancing those. This is for C++.
> Now, if there is substantial overlap with QML / Qt Quick or other
> languages, this probably should be put somewhere into the text editor
> itself. For instance, we put all the highlighting settings into one
> central place (Options > Text Editor > Fonts & Colors), covering
> thingies, but also C++ and QML. This corresponds to your first
Placing the UI is mostly independant from the source code design, see
ToDo Plugin. It is implemented as an extra plugin, integrates into the
project settings mode but has its own page in options dialog.
Naming conventions have not much to do with the text editor (in
contrast to code style which is very much related to it). As a user I
would expect to have naming convention as part of C++ settings and Qt
More information about the Qt-creator