[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Bug in KMainWindow::toolBar()
From:       mosfet <mosfet () mandrakesoft ! com>
Date:       2000-11-28 14:59:55
[Download RAW message or body]

David Faure wrote:
> 
> On Tuesday 28 November 2000 02:38, mosfet wrote:
> > The requirement for calling addToolBar is new - KTMainWindow didn't
> > require this for toolbars created with the toolBar() call, nor did
> > KMainWindow until a few days ago.
> 
> I certainly didn't change anything in that area. I just looked into the
> problem (now I can finally reproduce it!!!), and it seems KToolBar doesn't
> call the right QToolBar constructor. This hasn't changed a "few days ago", it
> has changed at the beginning of September !!! Where have you been ? :-)
> 

I usually update and recompile libs and base about once a week - I'm not
sure what happened but it just broke a little while ago... As far as
using XMLGUI - I do for my main filelist window but simply ported my
other toplevels from KTMainWindow. I'm lazy and had other things I
wanted to do than port a bunch of windows to XML ;-)

Adding a new constructor seems to the right thing to do.

> Basically, there are two QToolBar constructors.
> 
> --------------------
> 1 - QToolBar::QToolBar ( const QString & label, QMainWindow * mainWindow,
> QWidget * parent, bool newLine = FALSE, const char * name = 0, WFlags f = 0 )
> 
> Constructs an empty horizontal tool bar with a parent of parent and managed
> by mainWindow. The label and newLine are passed straight to
> QMainWindow::addToolBar(). name is the object name and f is the widget flags.
> 
> This is the constructor to use if you want to create torn-off toolbars, or
> toolbars in the status bar.
> --------------------
> 2 - QToolBar::QToolBar ( const QString & label, QMainWindow * parent,
> QMainWindow::ToolBarDock dock = QMainWindow::Top, bool newLine = FALSE, const
> char * name = 0 )
> 
> Constructs an empty tool bar which is a child of parent and managed by
> parent, initially in dock, labelled and starting a new line in the dock if
> newLine is TRUE. name is the object name, as usual.
> --------------------
> 
> When Reggie ported KToolBar, he made it call the first one...
> 
> This patch fixes the problem for me, but does it break anything else ??
> 
> --- ktoolbar.cpp        2000/11/15 16:28:05     1.253
> +++ ktoolbar.cpp        2000/11/28 10:13:33
> @@ -168,7 +168,7 @@ QSizePolicy KToolBarSeparator::sizePolic
>  KToolBar::KToolBar( QWidget *parent, const char *name, bool b, bool
> readConfig )
>      : QToolBar( QString::fromLatin1( name ),
>        parent && parent->inherits( "QMainWindow" ) ? (QMainWindow*)parent : 0,
> -      parent, FALSE,
> +      QMainWindow::Top, FALSE,
>        name ? name : "mainToolBar")
>  {
>      init( readConfig, b );
> 
> Hmm, yes, I see what it changes. The toolbar didn't appear up to now because
> the mainwindow had to way to know where to put it ! It was "Unmanaged" because
> the mainwindow didn't know the position. The change above tells it to put it
> on Top, but this is just an assumption... It would probably be better to add
> another constructor to KToolBar, one where you can specify the position.
> Bah, why not use the XMLGUI anyway ? :-)
> 
> --
> David FAURE, david@mandrakesoft.com, faure@kde.org
> http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
> KDE, Making The Future of Computing Available Today
> See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

[prev in list] [next in list] [prev in thread] [next in thread]