extragear/sdk/kdevplatform/plugins/genericprojectmanager

[Milian Wolff]

On Thursday, 28. January 2010 17:55:03 Andreas Pakulat wrote:
> On 28.01.10 15:31:19, Milian Wolff wrote:
> > On Thursday, 28. January 2010 09:42:10 Andreas Pakulat wrote:
> > > On 28.01.10 02:40:40, Milian Wolff wrote:
> > > > SVN commit 1081271 by mwolff:
> > > >
> > > > remove obsolete api (the signals are defined in the interface), mark
> > > > an arg as unused
> > >
> > > Uhm, they're declared there, but AFAIK that won't work. The interface
> > > doesn't (and cannot) inherit from QObject and has no Q_OBJECT macro,
> > > hence moc doesn't generate signal-code for it. So thats why you have to
> > > duplicate  the signals on the manager.
> > >
> > > For some VCS signals (IIRC and KTE also does this), the signals are
> > > pure virtual functions without the Q_SIGNALS macro. That way the
> > > subclasses _have to_ declare and implement (via the .moc file) those
> > > and they're still visible in the public interface for documentation
> > > purposes.
> >
> > OK, thanks for the clarification. Should I:
> >
> > - revert the commit and emit the Signals where appropriate? This is not
> > done so far and afaik there is also nothing listening to these signals.
> > Do we really need them?
> 
> Thats a good question. I'm not sure, create and delete signals would be
> useful for VCS-integration, so we could have a single place that does this,
> instead of replicating it in each manager (i.e. notifying the vcs of
> created/deleted files/folders).

Yeah, it makes sense to have the signals there, _if we need them_.

> I can only find a use-case for the added
> signals right now: If a file is added to a project it should automatically
> be scheduled for parsing, same thing for a folder that is being added.

This is so far done also in the manager by doing project-
>add/removeFromFileSet()

> Also IMHO right now the semantics of the functions and signals are not 100%
> clear (and together with that what exactly a project tree contains). I
> suggest to talk about that during the sprint in person.
> 
> For now I think just reverting the change is ok. Until we've clarified the
> meaning of the signals, I wouldn't add code emitting them.

OK, thanks.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de