[patch] dialog provider for projectcontroller

[Andreas Pakulat]

On 25.08.08 20:41:46, Manuel Breugelmans wrote:
> On Monday 25 August 2008 19:25:57 Andreas Pakulat wrote:
> > On 25.08.08 18:02:16, Manuel Breugelmans wrote:
> > > This patch introduces an extra class, IProjectDialogProvider.
> > > ProjectController delegates dialog creation to this one, instead of
> > > inline'd KDialog:: etc calls. Also some cleanups and extensions for
> > > ProjectControllerTest.
> > >
> > > The reason I think this is useful:
> >
> > +1 from me for the idea.
> >
> > > Currently it resides in shell but maybe it makes more sense to have this
> > > in interfaces ...
> >
> > I don't think thats useful. I can't think of a good reason for a plugin
> > to change that dialog provider, the testability-case is covered by
> > having the API available in shell. BTW: No need to put the
> > dialog-provider declarations into the .cpp files, you can just as well
> > put them into the .h so you don't need the #include "moc_..."
> 
> Right, then I'll get rid of the I-version altogether. Btw addition of new 
> virtual slots to this provider is BC, yes? Techbase seems to confirm this but 
> only in a little vague comment at the bottom.

No, you can add slots, but you can't add virtual methods to a class -
and a virtual slot is still a new virtual method.

> > > Btw, Andreas, project-reloading is broken (part of this is exposed
> > > through the extra test in this patch)
> >
> > I guess you're talking about re-opening while a project loads? Yeap
> > thats an untested case basically.
> 
> A standard reload also acts weird here. The reload gets through but the 
> project-manager toolview gets removed, probably not that hard to fix.

Thats because you only have a single project open and Evgenyi already
comitted the fix for that :)

> > And why that using declaration?
> > Its not like writing the QTest:: in the macro saves you a lot of code :)
> 
> kWaitForSignal is used somewhere else as well. Basicly I found 
> QTest::kWaitForSignal( object, SIGNAL( mySignalMemberFunction( ) ), 20000 ) a 
> tad verbose.

I don't have a religious opinion either way, I just find it better with
all these "namespaces" and class-static methods all over the place to
easily see where a method call comes from. Thats also why I'm getting
rid of "using namespace KDevelop" anywhere I find it :) At least I've
found myself reading such code more often than writing it - literally -
and hence think its good to easily see where a given function is
defined - wether it comes from a platform library or is plugin-local.

Andreas

-- 
You seek to shield those you love and you like the role of the provider.