[Fwd: kdevelop.cpp]

[John Birch]

On Tue, 27 Jun 2000, you wrote:
> John Birch wrote:
> > On Tue, 27 Jun 2000, you wrote:
> > > Hi!
> > >
> > > John Birch wrote:
> > > > So, are we arguing a philosophical viewpoint, rather than a technical
> > > > implementation problem ?
> > >
> > > Yep. The technical problems are depending on those things.
> > >
> > > > Doesn't the centralised approach mean that every window must be
> > > > "created" by kdevelop - that doesn't feel right to me.
> > >
> > > It means the inner view widgets (ClassView, BreakPointManager,...) are
> > > created by every part itself. But they are docked together centralized,
> > > no part does not know nothing about docking, that's why dockwidgets are
> > > created centralized (class KDevelop), not in the parts.
> >
> > You're saying that there are x number of "outer parts" that wrap the
> > inner parts.
> >
> > In the debuggers case we have disassembler, var, breakpoint, framestack
> > inner widgets. Each must have a dock outer widget that must be created by
> > kdevelop.
>
> What exactly does 'kdevelop' mean here?

class KDevelop

>
> > How is this done?
>
> Using the interface KDevelop::embedToolViewInGUI(QWidget*,...hints...) in
> an init() routine of your special part. It registers your widget to the
> main GUI control but does not know where it will appear (and if it is
> worthy to appear at all ;-).
> I think the interface should also provide an
> removeToolViewFromGUI(QWidget*) command, and maybe a command for changing
> hints. That should be enough for a dynamic handling.
>
> > What happens if I create a perl debugger part that has only var,
> > breakpoint, and framestack?
>
> It will call only 3 commands on the main GUI control:
>   pGUIControl->embedToolViewInGUI(m_pVAR,...hints...);
>   pGUIControl->embedToolViewInGUI(m_pBreakpoints,...hints...);
>   pGUIControl->embedToolViewInGUI(m_pFrameStack,...hints...);
> // finished.

Hmm. This is in the part?
That would mean the part would have to know about class KDevelop. So the part 
couldn't be used elsewhere (unless that app "faked" a class KDevelop, of 
course). For instance the class viewer couldn't be used by kuml or kdestudio 
And doesn't the hints imply that the part knows about dockwindows? which was 
what you wanted to prevent? I think I'm confused. :-)

>
> Well, a problem I see is that the main GUI control must know all types of
> incoming tool widgets, I mean the semantics of each of such widgets. I
> don't know the solution for the problem that with every new widget one has
> to put the semantics interpretation to the main GUI control, in a way that
> the dockwidget control knows what to do with the special incoming
> part-widget. I suppose that could be done by the hints or  maybe the main
> GUI control could provide a default handling.

Don't understand this bit. What are the semantics of each widgets?

jbb