tip?

[Andras Mantia]

On Tuesday 18 April 2006 21:27, Jens Dagerbo wrote:
> QuickOpen and ClassView are two different plugins, so It's hard to
> see a really clean solution to this problem:
>
> 1. The cleanest is probably what Matt seems to suggest - move the
> QuickOpen functionality into ClassView (and, presumably,
> FileTree(?)). This is fairly invasive and would force someone wanting
> to use QuickOpen to have ClassView loaded (which is a toolview, and
> we all seem to love to have as few as possible of those). Personally,
> I don't much use ClassView, so I wouldn't really like this option.

Don't do it. It will mean that we can't have QuickOpen in Quanta without 
the ClassView, which is useless outside of C++.

> 2. Implement a way for plugins to tell each other.. umm..
> "Class/Method Opened"? This through some API in core, probably in
> PartController or ProjectManager (nothing really fits well), which
> would then emit a signal. One good thing about this is that it would
> probably make it possible for ClassView to signal itself to reopen
> the selected class/method when it is forced to reread the codemodel
> after a build. It really is pretty annoying that the ClassView closes
> after every build... Again, somewhat invasive. And ugly.
>
> 3. You could communicate with the ClassView directly, via the
> Extension API (see kdevplugin.h) but this is only really "allowed"
> for plugins that implement a known interface. ClassView doesn't, and
> creating one for this single purpose seems overkill.

4. Create an interface for communication, check if the other plugin is 
loaded and communicate with the other one if possible. 
Pros: 
- the plugins can be compiled and distributed separately
- the plugins will work separately, but will communicate with each other 
if both are loaded at the same time
Cons:
- you need an interface file (.h) in a common place, most probably 
kdevelop/libs.

I know this is hard to imagine, and it was hard for me too until we 
implemented it, but I give some examples:
- branches/work/kdevquanta/lib/tagdialogsif.h is the interface. 
"createNewTag" is the method that can be called form another plugin. You 
can make a QuickOpenIf.h here and call the method "addEntires", which 
is used to add the class names and some meta data (file, line, column) 
to the QuickOpen plugin.
- one of the plugins are in branches/work/kdevquanta/plugins/tagdialogs. 
This inherits from the above interface, so it can use createNewTag 
directly (in your case make the QuickOpen plugin inherit from the 
interface you've created)
- in  branches/work/kdevquanta/quantacore there is our core plugin 
(don't be fooled by the name core, it is still a normal KDevelop 
plugin) we check for the existence of the TagDialogs plugin and use it 
if it's present:
    TagDialogsIf *tagDialog = 
extension<TagDialogsIf>("KDevelop/TagDialogs");
    if (tagDialog)
    {
      QString selection = m_activeQuantaDoc->selection();
      TagPair newTagPair = 
tagDialog->createNewTag(QTag::tagFromDTD(m_activeQuantaDoc->mainDTEP(), 
name), selection, attributes, KURL()); 
      [...]
      return;
    }

You would do something similar in ClassView plugin.

BTW, this is the same what Alexander said later in the thread.

Andras


-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060419/8f3843fb/attachment.sig>