File Templates wizard

[Andreas Pakulat]

Hi,

On Thu, Jan 3, 2013 at 4:01 PM, Milian Wolff <mail at milianw.de> wrote:
> On Thursday 03 January 2013 14:40:28 Andreas Pakulat wrote:
>> On Thu, Jan 3, 2013 at 2:25 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>> > 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:
>> >>> - 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.
>>
>> Actually this also happens with Qt4 when making sure to generate in a
>> subdir (due to https://bugs.kde.org/show_bug.cgi?id=312105), I get
>>
>> #include <qt4/QtCore/QObject>
>>
>> generated as include instead of just #include <QtCore/QObject> or
>> #include <QObject>
>
> Can you (or did you already?) report a bug for that with the steps required to
> reproduce it? Thanks.

https://bugs.kde.org/show_bug.cgi?id=312576

I guess the Qt3 breakage is something I'll have to look into myself,
I'd appreciate any pointers on where to look for the special handling
for QObject's header.

> Btw, fixed the other two bugs for you. And some other stuff I found while at
> it.

Thanks a lot.

> One major gripe I have with the wizard currently is that it requires the
> mouse... But I can't for the life of it manage to get proper focus management
> done. I.e. the line edit for the class name should be preselected when the
> page becomes active. Somehow it seems we'll have to add some kind of
> "setFocus" or similar to the pages, or listen to the showevent and set
> focus... Ugly :-/

Haven't looked at the code at all yet, except for one of your fixes
and seeing a 'currentPage() == someSpecialPageType' already made me
shiver a bit (for no particular reason) :)

> Also, somehow KAssistantDialog always sets "cancel" as the default button...
> Only once you *click* inside the dialog, is "next" becoming focused and the
> active button... This looks like a bug in  KAssistantDialog to me - or?

Looking at http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=7a5fe14a90fb962e1d6a828d2f0c759a823ffa34&hb=7d8f4fadac549c9d1c2d5ead529686cdfafc58ff&f=kdeui%2Fdialogs%2Fkassistantdialog.cpp
it seems the default button should never be the cancel one, but rather
Finish or Next. So you may actually run into a style-behaviour or a
KDialog/QDialog bug/misfeature here. Then again, KAssistantDialog
tries very hard to enable the buttons and set the right default with
that showEvent override. I guess some debugging with a break on
setDefaultButton would be needed to find the place where it happens.

Andreas