[Fwd: kdevelop.cpp]

[John Birch]

On Tue, 27 Jun 2000, you wrote:
> John Birch wrote:
> > Hmmm,
> >
> > Interesting.
> >
> > I have intended to put all the debugger into a part and have it create
> > the dockwidgets, attaching them to a dockwidget supplied by kdevelop. And
> > in fact that's what I have, except that it isn't hooked up and isn't
> > complete (it could be commited, though)
> >
> > Falk, are you saying that this won't work? And if so, why not? It would
> > be a shame if we cannot allow parts to create their own dockwidgets.
>
> John, you and Bernd use a decentralized approach (every part docks itself,
> and uses direct calls of methods of the dockwidgets).
> I am opposed to it and I want to implement a centralized approach. That
> means: No other part than a special source code part for managing the
> dockwidgets (within class KDevelop) uses any special dockwidget call. It
> should be hidden and abstracted to the outside code (within the KDevelop
> project). The current small abstraction interface is
> embedToolViewInGUI(QWidget*,...hints...). In my opinion the centralized
> approach is also necessary because of the centralized loading/saving of
> dockconfigurations and global dockwidget control (dependencies, etc.).
> Furthermore a decentralized approach makes it harder to change the GUI in
> 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. Last but not least approach of the Dockwidget class set
> itself is more thought as centralized one.

So, are we arguing a philosophical viewpoint, rather than a technical 
implementation problem ?

Doesn't the centralised approach mean that every window must be "created" by 
kdevelop - that doesn't feel right to me.

Hmm, what to do. We could do with a whiteboard, a few cold beers, and a 
summer's afternoon, in the same room :-)

jbb