[Qt-creator] Suggestions for 'new class' dialog

[Eike Ziller]

> On Dec 8, 2020, at 16:43, Kevin André <hyperquantum at gmail.com> wrote:
> 
> On Tue, Dec 8, 2020 at 9:43 AM Eike Ziller <Eike.Ziller at qt.io> wrote:
>> 
>>> On Dec 8, 2020, at 00:27, Kevin André <hyperquantum at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Every time I use the dialog for adding a new class, there is still a
>>> lot that I need to do manually after the files were generated:
>>> 
>>> 1. Add cpp file and often the header file as well to CMakeLists.txt
>> 
>> Unfortunately automatically adapting CMakeLists.txt files is a bit difficult.
> 
> If it is only "a bit" difficult, then it's doable ;-)

I suppose the prerequisite would be a CMake parser (at least a minimal one), which we don’t have. After that there is the problem of finding out how/where to add the file. Often enough CMake files don’t call the standard CMake functions for that directly, only indirectly via custom functions...

> 
>>> 2. Add GPL header to each file (copy from another file and update the
>>> year if necessary)
>> 
>> In Options > C++ > File Naming (not the best heading), there is “license template” where you can point Qt Creator to a file that should be copied to the top of generated source files. Unfortunately that is not available as a project setting, only globally.
> 
> This seems less than ideal. I use the name of my project in the text
> of the GPL header, and other (open source) projects that I sometimes
> work on do not use the GPL license. So having it as a global setting
> would make it impractical to use Qt Creator for more than one project.
> I have created QTCREATORBUG-25067 to request a project-specific
> setting.
> 
>>> 3. Add namespace to each file
>> 
>> You can type MyNameSpace::MyClass for the class name to generate it in a namespace.
> 
> Well, since there are multiple suggestions asking for this
> functionality that already exists, it may indicate that many users
> don't know it's there:
>  QTCREATORBUG-937
>  QTCREATORBUG-2493
>  QTCREATORBUG-18965
> 
> An important principle in the design of user interfaces is
> discoverability. Anyone looking at the dialog for the first time will
> simply think "this dialog is too simplistic to support namespaces". No
> one will go read the manual first.
> 
>>> 4. Change naming of include guards (add prefix)
>>> 5. Remove comment "// MYCLASS_H" at the #endif line
>>> 6. Change "signals" to "Q_SIGNALS" in the header file
>>> 7. Change "ClassName *parent" to "ClassName* parent" in the
>>> constructor (if it inherits QObject)
>> 
>> Hm, not sure, can’t you specify that in C++ > Coding Style ?
> 
> I did, but those settings seem to be ignored in this case. So I added
> QTCREATORBUG-25065.
> 
>>> 
>>> It would be really useful if these actions could be automated as well.
>>> 
>>> 1. It may be possible to add the new files everywhere its peers are
>>> mentioned as well. So add "newclass.cpp" everywhere
>>> "existingclass.cpp" occurs and add "newclass.h" everywhere
>>> "existingclass.h" is found. The existing class should be a similar
>>> class in the same directory.
>>> 
>>> 2. I guess it should be possible to automatically extract the GPL from
>>> an existing file, copy it to the new file, find the copyright line and
>>> change the year(s) mentioned there to the current year.
>>> 
>>> 3. By looking in the bug database I discovered that the wizard already
>>> provides this in a very obscure way. This should be made explicit in
>>> the user interface, either by adding a separate "namespace: " field or
>>> by a visible note mentioning that the namespace can be specified along
>>> the class name.
>>> 
>>> 4. It would be really great if a heuristic could figure out the naming
>>> scheme for include guards from existing header files in the same
>>> directory.
>>> 
>>> 5. I wouldn't mind the comment so much if I didn't have to fix the
>>> name of the include guard several times for each header.
>>> 
>>> 6. Maybe add a code style setting that says "don't use the Qt
>>> keywords" and obey that setting.
> 
> Added QTCREATORBUG-25064.
> 
>>> 7. This can be fixed by taking the code style settings into account
>>> when generating the files.
>>> 
>>> Should I add a separate suggestion for each of these to the bug database?
>> 
>> 1+2: No.
>> 3: Not sure. What where the arguments against a separate namespace field? I don’t see any issues with adding one.
>> 4+5: Yes, though we usually don’t like magic so much, so an explicit setting providing a template would be preferred IMO.
> 
> You mean something like this: a project setting "include guard naming"
> with a default value like "%HEADERNAMEWITHOUTEXTENSION%_H" that I
> could change to "MYPREFIX_%HEADERNAMEWITHOUTEXTENSION%_H"?

Something like that.

> 
>> 6: Yes, could be done.
>> 7: I see, so we don’t apply the code style after generation? Yes -> bug.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B