general class design

[John Birch]

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

Is this what others are thinking?

jbb

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(w.name()==QString("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.