[OT] plugins and QDockWidget

[Alexander Dymo]

On Sunday 25 March 2007 10:40, kitts wrote:
> > If the plugin has another toolview, it needs to add another factory.
>
> I think i mostly understand now. Just one last question. Apaku in the other
> mail mentioned about the  addToolView( "name", factory); API. I assume that
> it is used by the plugin to register a factory with the UIController. The
> UIController immediately creates one toolview using the factory. Is it
> possible that either the creation is deferred or rather that another
> toolview creation for already registered factory is invoked by the plugin?
> Anyway this does not seem as important anymore.

For KDevelop atm that's the question of missing API. If we had
IUiController::addToolView( name, factory, show_mode )
the plugin would be able to pass the third parameter telling the
shell to not create a view immediatelly.

And if we had the IUiController::showToolView(factory) thing
then the plugin could show it afterwards.

Internally KDevelop shell creates so-called "Sublime Document"
which represents the toolview and knows about the factory.
When UiController adds the toolview, it creates that document.
Then it creates a view for a document in active main window.

The later part may be deferred until the plugin explicitly asks.

> Actually, now after understanding the design in the context of kdev4 it
> seem to me that much of the infrastructure i am trying to develop already
> exists with kdevelop and all i may need to do is write a plugin for
> kdevelop shell. 

You can also write your own application using KDevelop shell. The only
thing that is currently missing is profile support (to let your application
load its own plugins and do not load plugins we ship with KDevelop).
The is the whole goal of KDevelop platform. People will have to write
only 100 loc application and plugins and the platform will take care of
everything else.

> Is there a place i can read more on what is the role of the shell separated
> from the various plugins?

Well, you can take a look at our wiki with KDev4 information:
http://kdevelop.org/mediawiki/index.php/KDevelop_4

> In short, my requirements would be; plugin controllable context sensitive
> toolbars and dockviews and a mechanism by which one plugin can communicate
> to another. 

We have the infrastructure for inter-plugin communications also:
http://kdevelop.org/mediawiki/index.php/Extension_Interfaces_and_Plugins

> Unlike the way kdev3 handles toolviews, i like the way qt handles dockviews
> where more than one toolview can be seen simultaneously. Will this be the
> way it works in kdev4 or visually will the kdev3 style continue? Current
> screenshots suggest the former.
I don't exactly like the current toolview management but mostly because of
non-existant keyboard navigation. I think we will not change it for KDev4
and just use whatever Qt has.