[Fwd: kdevelop.cpp]

[John Birch]

On Wed, 28 Jun 2000, you wrote:
> On Tue, 27 Jun 2000, John Birch wrote:
> > On Tue, 27 Jun 2000, you wrote:
> > > On Tue, 27 Jun 2000, Falk Brettschneider wrote:
> > > > general. As I said before if one wants to change from dockwidgets to
> > > > another GUI design, he/she have to change all involved parts, in the
> > > > worst case, basically.
> > >
> > > No. The parts are only creating a widget with a parent given as
> > > argument to the create() method of the factory. They don't know
> > > anything about window management or dock widgets. They don't even know
> > > that a class KDevelop exists!
> > >
> > > Bernd.
> >
> > What about parts that have multiple widgets? What would the code look
> > like for that?
>
> Mmh, an alternative to using different parts would be to introduce a
> signal widgetCreated(QWidget *w, PositionHint) which the part emits
> for each created widget. In that case you couldn't create widgets
> in the part constructor because at that time the signal isn't
> connected, but why not?

> It would also make the use of KParts::Part
> a bit questionable, because the method widget() wouldn't be
> meaningful.

??
In the case of the debugger there is one controlling widget, lets call it 
dbgManager (surprise :-)

The problem is that this widget has multiple sub widgets that want to be 
docked. So my question stands. How does a part make these subwidgets without 
knowing about docking?

Is the widgetCreated signal an option? And arn't the position hints 
dockwidget specific so that the part cannot know this?

It doesn't make sense for me to continue without knowing this :-)

jbb