[PATCH] KToggleToolbarAction, KWidgetAction

[Tobias Koenig]

On Tue, Apr 16, 2002 at 05:44:55PM -0700, John Firebaugh wrote:
> On Tuesday 16 April 2002 2:43, Tobias Koenig wrote:
> > Ok, this is the new patch. I called the class KToggleBarAction
> > (better suggestions?) and it takes a QWidget pointer as first argument.
> > So you have to use
> > 	new KToggleBarAction(toolBar(), "Show Toolbar", actionCollection(),
> > "show_toolbar"); new KToggleBarAction(menuBar(), "Show Menubar",
> > actionCollection(), "show_menubar"); new KToggleBarAction(statusBar(),
> > "Show Statusbar", actionCollection(), "show_statusbar"); to create the
> > actions.
> >
> > Is it an acceptable solution?
> 
> I'm not crazy about this patch. First, it relies on the fact that connect() is 
> a macro that does not type-check its arguments. It will work if m_barWidget 
> has a visibilityChanged() signal but not otherwise.
Why should a programmer use a non tool/menu/statusbar widget as first argument?
If a non-bar widget is used, nothing bad will happens (beside a QObject connect
error message) so the programmer will see that something in his code is wrong.

> Second, what is the point of requiring a QWidget* parameter in the constructor,
> but then changing the widget to the widget named m_barWidget->name()
> if it's a toolbar?
The pointer to the bar widget I get in the ctor of this class is stored in
m_barWidget. Normaly after calling the ctor of the class, KMainWindow::createGUI()
will be called. In this function the toolbar list of the mainwindow is cleared
=> m_barWidget is set to 0 when it pointed to a toolbar.
To workaround it, I save the name of the toolbar and create a new one in
the plug() function.
I know it's not a nice way to do...

> My preference would be a pure-virtual KToggleBarAction and subclasses 
> KToggleMenuBarAction, KToggleStatusBarAction, and KToggleToolBar action that 
> take a KMenuBar*, KStatusBar*, and const char* respectively as constructor 
> arguments.
1) Wouldn't you have to duplicate the code in all the subclasses?
2) Why do you need this pure-virtual class?
I'm not so familiar with virtual classes, so I see no sense in creating one.


So the remaining problem is: Implement 3 classes (separated or diverted by one
superclass) or using one class that takes a pointer on the bar widget?
Does somebody know a better way or could make a decision between the both above?

Ciao,
Tobias
-- 
In a world without walls and fences who
needs Windows and Gates???