[Fwd: kdevelop.cpp]

[Falk Brettschneider]

Hi,

John wrote:

> > It will call only 3 commands on the main GUI control:
> >   pGUIControl->embedToolViewInGUI(m_pVAR,...hints...);
> >   pGUIControl->embedToolViewInGUI(m_pBreakpoints,...hints...);
> >   pGUIControl->embedToolViewInGUI(m_pFrameStack,...hints...);
> > // finished.
>
> Hmm. This is in the part?

Yes.

>
> That would mean the part would have to know about class KDevelop. So the part
> couldn't be used elsewhere (unless that app "faked" a class KDevelop, of
> course).

So what about emitting a signal (as suggested below by Bernd).
Such signal can be connected to KDevelop::embedToolViewInGUI(..)

> For instance the class viewer couldn't be used by kuml or kdestudio
> And doesn't the hints imply that the part knows about dockwindows? which was
> what you wanted to prevent? I think I'm confused. :-)

Well, the hints could be simple booleans or flags:
   embedAsOutputView, embedAsSelectView, ...
and explanation strings, geometry

>
> Don't understand this bit. What are the semantics of each widgets?

The logical contents. Probably the hint flags from above.


Bernd wrote:

> The parts are only creating a widget with a parent given as argument
> to the create() method of the factory. They don't know anything about
> window management or dock widgets. They don't even know that a class
> KDevelop exists!

Well, that's what I want. I don't want that Parts call dockwidget methods.


On Tue, 27 Jun 2000, Falk Brettschneider wrote:

> >
> > Well, a problem I see is that the main GUI control must know all types of
> > incoming tool widgets, I mean the semantics of each of such widgets.
>
> For the DocTreeView, ClassView, AppOutputView, GrepView, MakeView
> it's not necessary. All they provide is a property
> X-KDevelop-ComponentType. It gives a hint where they should be
> placed.

For instance the main GUI control must know if it's of type 'select-view' or 'output-view' to choose the right placing decision.
But it could use the hints of embedToolViewInGUI(...hints...)...

>
> On Tue, 27 Jun 2000, John Birch wrote:
>
> > I have intended to put all the debugger into a part and have it create the
> > dockwidgets

Please, don't do it.


John wrote:

> > What about parts that have multiple widgets? What would the code look like
> > for that?

several calls of signals that are connected with (slot?) embedToolViewInGUI(...)

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

OK. :-) I realize you agree with me.

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

OK. Good idea. :-)

> > What about parts that have multiple widgets? What would the code look like
> > for that?
>
> Mmh, an alternative to using different parts would be to introduce a
> signal widgetCreated(QWidget *w, PositionHint)

Yeah! :-) The signal that should in the end be connected to KDevelop::embedToolViewInGUI(QWidget*, ...hints...).

> which the part emits
> for each created widget. In that case you couldn't create widgets
> in the part constructor because at that time the signal isn't
> connected, but why not? It would also make the use of KParts::Part
> a bit questionable, because the method widget() wouldn't be
> meaningful.

Use a 2-step-initialization. init1() connects all necessary signals and slots, init2() does the rest.

>  Simon (who thinks that the idea of a widgetCreated signal is cool :)

OK.

I summarize, it is becoming clearer now:
A part signal widgetCreated(..) is connected to the main program in the initialization right after load time.
A second stage of initialization (run-level 2) creates the Part widget (e.g. VarOutputView) and emits something like this: widgetCreated(m_pVarOutputView,
flag & Type::OutputView,...).
The signal triggers the connected slot (maybe there are more signals between start and goal) and in the end it calls embedToolViewInGUI(QWidget*,...type
hint...positioning hint...size hint...).
The slot itself calls something like: m_dockbaseVAROutputView->setWidget(pIncomingWidget);


Ciao,
  F at lk



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com