[OT] plugins and QDockWidget

[kitts]

On Sunday 25 Mar 2007 at 3:43:54 am, Alexander Dymo wrote:
> On Saturday 24 March 2007 23:44, kitts wrote:
> > Going by what i have seen as a kdev3 user, each plugin has at most one
> > toolview.
>
> Well, not really. Debugger plugin has 5 or more actually.
> KDev3 plugin could add as many as it wanted. The problem is that
> user could not add more.
> For example, konsole plugin added one konsole toolview. But it was not
> possible for application or user to add one more konsole toolview.
>
> > Something like designer would require more than one toolview. In
> > kdev4, thanks to the factory approach, there can be more than one
> > toolview for a plugin but as i understand,
>
> I'd say not only "more than one toolview", but also
> "more than one same toolview"
>
> > the creation of the second toolview is
> > user invoked and not a decision made by the plugin itself.
>
> Yes.
>
> > Furthermore it is assumed that the toolview would be similar each time
>
> created. Taking the designer example again, which toolview is to be
> created? When you add a factory, you add a "type of toolview".
> So when one given factory is used, you end up creating similar toolviews
> (e.g. konsoles).
>
> 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.

> > > PS: currently UiController in KDevelop does not expose hiding/showing
> > > the toolviews for plugins. But that's easy to implement.
> >
> > A good addition? :-)
>
> Yep :)

I am glad that by this discussion at least something has gone back to 
KDevelop. :-)

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. Since my application is not software coding i had other thoughts but 
if an app like designer can be embedded in the way discussed here it is all 
i might need since the plugins view in my case would basically be a 
QGraphicsView widget.

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

In short, my requirements would be; plugin controllable context sensitive 
toolbars and dockviews and a mechanism by which one plugin can communicate 
to another. For information, i am working on developing an Electronic 
Design Assistant (EDA) for KDE where one would draw circuit schematics, 
simulate them and do board layout. The reason i wanted show/hide of 
toolviews is that a toolview belonging to a schematic would be irrelevant 
when layout tab is focused. Much like how designers properties toolview 
would be irrelevant when a C++ source file is in view. The reason i am 
interested in toolview creation is that depending on the complexity of the 
component selected within the schematic view more or less toolviews would 
be necessary. Of course, with proper design of the plugin i think the later 
problem can be eliminated.

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.
-- 
Cheers!
kitts