[Fwd: kdevelop.cpp]

[Bernd Gehrmann]

On Tue, 27 Jun 2000, Falk Brettschneider wrote:
> 
> I think this sounds good but is not possible in general. Why? Every dockwidget has got an
> appropriate View menu show/hide entry (maybe in a sub-popupmenu), 

That's similar to Konqueror.

> the main
> application-control connects actions with the focusing of certain dockwidgets (for instance
> focusing a cpp file view switches from DOC to CV or LFV or RFV), a few toolbuttons are
> connected with special dockwidgets, for instance debugger widgets are shown or hidden
> dependent on the program state ... and so on.

Debugger widgets should mark themselves with a certain property which
allows them to be treated that way.

> There's embedToolViewInGUI(QWidget*). You should use it and let the dockwidget control
> decide what to do with the widget. This is the small interface.
> I could agree with making suggestions as parameters of embedToolViewInGUI(..). I disagree
> with concrete calls of dockwidget commands (e.g. createDockWidget) in other source code
> parts than the dockwidget part because that chains the code  to the current GUI solution.

No problem, I'm much for that. You can separate out the createDockWidget() and 
the following three lines or so (I don't have the source code here) into a
different function and move the part creation code around.

> you dock to an index, it will be important how many dockwidgets are already docked there. I
> suppose with your random-dock the GUI will look different from start to start.
> Furthermore there is the config-file state that is read/written on startup/finish of
> KDevelop. 

That's similar to Konqueror. Wen you save the GUI layout in a session-management 
routine, you have to do it in such a way that all necessary information
for creating the necessary parts is present at restore() time. If a part
(i.e. its .desktop file) has disappeared at restore() time, simply drop
it. I there is an additional part which wasn't there before, put its
widget in a default position.

> P.S.: Just an additional thought, Bernd: How about moving the Plugin-loading code to
> another place than the GUI class KDevelop? I think it is not GUI-related and could begin to
> overcrowd class KDevelop... Maybe it should move to an application main-control class
> (dividing into GUI and application control).

Well, I said already last week that I'm supporting that idea :-)

> P.P.S.: Please don't misunderstand me, I don't want to sound as like I know all and
> everything. At the moment I'm much learning-by-watching-your-activities and I'm open for
> good arguments. :-)

That's the case for everyone, isn't it? :-)

Bernd.