File Templates wizard

[Andreas Pakulat]

Hi,

On Sun, Dec 23, 2012 at 2:39 PM, Milian Wolff <mail at milianw.de> wrote:
> On Sunday 23 December 2012 10:48:44 Andreas Pakulat wrote:
>> - "Qt Object" does not seem like a good description, a Qt object could
>> also be a QWidget subclass, or QString subclass. Just call it what it
>> is, QObject subclass?
>
> +1

Fixed.

>> - it looks like the option to add function declarations has gone
>> missing, the 'class members' page allows to add some strings but at
>> least for QObject they're seemingly interpreted as properties. I also
>> noticed that if I do specify a return type for the 'function' its not
>> included in the generated file at all. Since supporting this is quite
>> complex, maybe just drop the possibility and let the user write
>> declarations in the source file?
>
> Hm the page which offers you to override functions should be still there - is
> it not? But we never had a page to add arbitrary functions afaik.

That works.

> And class members is for data members. This page be useful if it could handle
> getters/setters as well (which is theoretically possible). We should
> reevaluate and eventually merge the getter/setter review request...

That should be made clearer IMHO. For me a member function is also a
class member.

>> - There is always a private-class generated which I think is confusing
>> and unecessary in most of the use-cases. Private classes are necessary
>> when doing library development, but for normal apps there's no need
>> for the indirection. Maybe add an option for this or drop it
>> completely, people knowing about private-classes will know how to add
>> them themselves?
>
> I thought there was an extra pimpl'ed file template - looks like I really need
> to reevaluate all these templates...

There is an extra private_pointer template, but that does not involve
Qt and hence the special Q_DECLARE_PRIVATE and Q_D macros. Do we need
that though? I can add a new template with that

Otherwise fixed, i.e. I removed the extra private class.

>> - The generated include in my case is a path relative to the project
>> directory. This might be related to using the custom-buildsystem
>> manager, but then I would've expected at least getting the absolute
>> path from the manager there. Ideally though it would just be
>> <qobject.h>.
>
> True. We'll need to check whether this also happens with CMake and fix it then
> either centrally or in the build system manager.

Yeap, also happens with CMake, but seemingly not with a Qt4 project. A
CMake Qt3 project however shows the same problem.

>> - The page to select which functions to generate/override is taking
>> quite some time before its showing any content. The first time I was
>> about to skip the page because I thought this was broken. An indicator
>> that KDevelop is doing something would be good inside the page itself.
>
> Oh, I never noticed that. But since it waits for DUChain parsing to finish it
> can of course happen. Thus, showing a progress bar would be a very good idea.

Filed now as https://bugs.kde.org/show_bug.cgi?id=312533

Andreas