[Fwd: kdevelop.cpp]

[Falk Brettschneider]

Hi,

> On Mon, 26 Jun 2000, Falk Brettschneider wrote:
>
> > Hi Bernd,
> >
> > I inserted code to kdevelop.cpp and you simply disable and bridge it in
> > cvs. This is not the fine English way-of-life. ;-(
>
> Hmm, I bridged it because it is necessary to get parts
> running. You hardcoded names of objects. This is neither
> necessary nor wanted in the KParts approach.

It is necessary to indicate the incoming QWidgets and put them to the right appropriate
KDockWidget. You know, we don't want to use the special widgets types, just class QWidget
in kdevelop.cpp. Every view is embedded in a certain dockwidget, also defined by the
previous application session.

> If a part
> isn't installed, then no dockwidget for it should be
> created. If the user added a part he wrote himself, it
> should automatically be embedded.

I think this sounds good but is not possible in general. Why? Every dockwidget has got an
appropriate View menu show/hide entry (maybe in a sub-popupmenu), the main
application-control connects actions with the focusing of certain dockwidgets (for instance
focusing a cpp file view switches from DOC to CV or LFV or RFV), a few toolbuttons are
connected with special dockwidgets, for instance debugger widgets are shown or hidden
dependent on the program state ... and so on.
You see much dockwidget stuff is highly involved in the application itself. You can't make
it totaly independent and dynamical. Just my current opinion.
You say 'automatically be embedded'... When? Where? Connected to which dockwidgets?
Restrictions (not everything can be allowed)?

> If I knew what you
> wanted to achieve I could have found a way to integrate
> it,

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.
Imagine hiding all dock stuff behind the embedToolViewInGUI(..)-wall lets the possibility
to make a complete change of what we do with all the tool views (of course concerning to
its appearance). For example, what if I decide to use QextMdiChildViews in ToolView mode
(top-level stay-on-top tool views like in Photoshop) instead of using KDockWidgets? ;-) I
think keeping stuff apart from each other is good to have...

>
> The same applies for the growing number of hardcoded
> kdevelopui.rc paths.

Yeah, Sorry, I will remove my line. Was slipping through the commit.

>
>
> > Furthermore your approach for the initialization of dockwidgets is not
> > right.
>
> What is not right? :-)

Your approach just docks as it comes. The order how the plugins are loaded is quite
randomly using your code. But the dock order is very important for the appearance of the
whole GUI. For instance docking to dock-tab widgets builds up from left to the right, or if
you dock to an index, it will be important how many dockwidgets are already docked there. I
suppose with your random-dock the GUI will look different from start to start.
Furthermore there is the config-file state that is read/written on startup/finish of
KDevelop. That is why the mechanism is, KDevelop provides a common default dock-state and
the read dock-state from file changes the final positions right after that (but before
showing the whole application). Well, for instance, loading the state from config file will
fail, if suddenly there are other dockwidgets object names (That's also why I was using
hard-coded object names). Furthermore, I don't know what happens with new (not-considered)
additionally appearing dockwidgets or with missing dockwidgets which are expected by the
config-file state.
Well, that's a short brainstorming of experience I made with the dockwidget stuff.

Last but not least I recommend to give the widgets of the loaded parts in the hand of the
dockwidget GUI-control (embedToolViewInGUI(..)). That control will accept hints here but
the visiualization and order process (taking hints from the config file, too) as well as
some behaviour should be done by that dockwidget control located in kdevelop.cpp.


Ciao,
  F at lk

----
P.S.: Just an additional thought, Bernd: How about moving the Plugin-loading code to
another place than the GUI class KDevelop? I think it is not GUI-related and could begin to
overcrowd class KDevelop... Maybe it should move to an application main-control class
(dividing into GUI and application control).

P.P.S.: Please don't misunderstand me, I don't want to sound as like I know all and
everything. At the moment I'm much learning-by-watching-your-activities and I'm open for
good arguments. :-)


============
Informatikerwitz: Was macht ein Informatiker,wenn er vom Bäcker kommt und zeigt, was er
gekauft hat? - (Antwort: Bug-Report) *:-))*



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