[patch] dialog provider for projectcontroller

[Manuel Breugelmans]

On Monday 25 August 2008 23:33:17 Andreas Pakulat wrote:
> 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 :)

Aha, neat!

> > > 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 pluQtCongin-local.
>

I agree, 'using namespace X' is bad taste. However 'using Class::symbol' in 
.cpp is OK in my opinion. It's less verbose plus the reader can still track 
down the namespace from within the same file. Another solution for this are 
namespace aliases, like 'kdev' 'veri' etc, I'm not too found of those though.

The only thing to watch out for is pollution of the global namespace in 
headers etc, other than that is down to personal preference [or coding 
standards ...]

Obviously this kind of readability issues are totally irrelevant for a 
KDevelop4 user, the Context Browser will tell you instantly which namespace a 
symbol belongs to.


Manuel