general class design

John Birch jbb at
Fri Jun 23 10:09:26 UTC 2000


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 ...

Is this what others are thinking?


On Fri, 23 Jun 2000, you wrote:
> On Fri, 23 Jun 2000, Falk Brettschneider wrote:
> > I think it should be sufficient if every plugin gives KDevelopGUI a
> > common QWidget* pointer to enable the embedding of the widget in the
> > right dockwidget parent. So KDevelopGUI will keep clean from other
> > classes (more independent).
> Well, the plan is actually that plugins decide themselves about
> their name, icon and comment via a .desktop file (see current
> version of the KDevelop class).
> >     if("mainframe"))
> BTW, this reminds me that names of widgets (the second
> argument of the QWidget and QObject constructs) are
> not user-visible and consequently const char*, not QString.
> Therefore, I would suggest to make the first argument of
> DockMainWindow::createDockWidget() a const char* as
> well, to avoid conversions to and from UTF16.
> > What do you think about this approach?
> > I think in this way at least the GUI class will keep independent from
> > the other special ones.
> This is certainly a good idea.
> Bernd.

More information about the KDevelop-devel mailing list