extragear/sdk/kdevplatform/plugins/genericprojectmanager

[Andreas Pakulat]

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). 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.

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.

Andreas

-- 
Your reasoning powers are good, and you are a fairly good planner.