general class design

Falk Brettschneider gigafalk at
Thu Jun 22 22:55:48 UTC 2000


Now I don't know what you think where the right place is for the
sub-widgets of class KDevelop...Can you give me your opinions?
And what new sub-classes or parallel classes of class KDevelop are
What should the new class hierarchie be?
How is the core functionality placed and distributed within the whole
Currently, I'm quite desoriented at all. ;-(

My thoughts are:
one class for the application logic (KDevelopMainControl ? or
   - has got a class member KDevelopGUI* m_GUI
   - has got a document-view control class
   - has got the project control
   - connects the actions of class KDevelopGUI (see below) with the own
application logic
   - accesses the several plugins and calls its functionality
   - ...
one class for the GUI (looks like the current class KDevelop, better
would be KDevelopGUI)
   - has got the actions
   - has got and controls the dockwidgets

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).
Something like this:

class KDevelopMainControl : public ...
    MainFrame* m_pMDIMainFrm;
    void doSomeActionsConcerningToTheSpecialMDIMainFrm(...)

class KDevelopGUI : public KParts::DockMainWindow
    KDockWidget* dockbaseMDIMainFrm;
    void embedConcreteWidget(QWidget*);

KDevelopGUI::embedConcreteWidget(QWidget* w)
    else if("CV"))
    else if(...

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.

Waiting for replies,
   F at lk

Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.

More information about the KDevelop-devel mailing list