general class design

[Simon Hausmann]

On Fri, 23 Jun 2000, John Birch wrote:

> Hi,
> 
> I've been thinking in terms of each part knows only about it's own actions 
> and controls those. I'm not sure if a kdevelopGui class would be necessary in 
> this case.
> 
> Wouldn't class KDevelop just create the parts, connect up the signals/slots 
> and nothing more. Okay, I know this is a simplistic view but ...

If I had the choice ;) , then I would make the shell class (the one that
inherits from KParts::MainWindow) provide the skeleton GUI (like file
open, close and the dockwindow stuff) . Oh, and probably the help menu.
(and perhaps some other global stuff) .

The rest I would let the components provide, as they contain the actual
implementations of the functionality the GUI provides.

IMHO it does not make sense to put all actions objects in one big class
and then try to connect those actions too all the numerous
component's slots. Put the action objects where the implementation is and
let kparts merge it all together :)

Just my 0.02 euro ;)

Bye,
 Simon