[Digikam-devel] Re: Very slow context menu invocation

Andi Clemens andi.clemens at gmx.net
Wed Dec 1 22:40:13 GMT 2010


Should be fixed now

Andi Clemens
-----------------
www.digikam.org

On Wednesday 01 December 2010 23:23:22 Andi Clemens wrote:
> Several problems:
> 
> 1. it doesn't compile
> 2. if named correctly, the ImageWindow::loadPlugins() method crashes =>
> digiKam doesn't start
> 
> Andi Clemens
> -----------------
> www.digikam.org
> 
> On Wednesday 01 December 2010 15:52:09 Gilles Caulier wrote:
> > Fixed. Try with my commit #1202606
> > 
> > Gilles
> > 
> > 2010/11/30 Gilles Caulier <caulier.gilles at gmail.com>:
> > > 2010/11/30 Andi Clemens <andi.clemens at gmx.net>:
> > >> Well it is used, the problem is that the BQM window initializes all of
> > >> its plugins, even though there are not used / assigned at this moment.
> > >> 
> > >> Maybe we can initialize plugins only when they are assigned?
> > > 
> > > Not when they have assigned, but when BQM main windows is displayed at
> > > the first time.
> > > 
> > > Typically, All tools instance are created by BatchToolsManager class
> > > 
> > > This manager is created in QueueMgrWindow constructor, as a lots of
> > > other classes, as ActionThread, which can be created only when BQM
> > > window is displayed at the first time on screen...
> > > 
> > > Gilles
> > > 
> > >> Andi Clemens
> > >> -----------------
> > >> www.digikam.org
> > >> 
> > >> On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote:
> > >>> Marcel,
> > >>> 
> > >>> This method already exist :
> > >>> 
> > >>> class QueueMgrWindow : public KXmlGuiWindow
> > >>> {
> > >>> 
> > >>>     Q_OBJECT
> > >>> 
> > >>> public:
> > >>>     ~QueueMgrWindow();
> > >>>     
> > >>>     static QueueMgrWindow* queueManagerWindow();
> > >>>     static bool            queueManagerWindowCreated();
> > >>> 
> > >>> ...
> > >>> 
> > >>> So it can be used in ContextMenuHelper...
> > >>> 
> > >>> Gilles
> > >>> 
> > >>> 2010/11/28 Marcel Wiesweg <marcel.wiesweg at gmx.de>:
> > >>> >> Digikam::QueueMgrWindow::QueueMgrWindow() at
> > >>> >> queuemgrwindow.cpp:137 0x827d80a
> > >>> >> Digikam::QueueMgrWindow::queueManagerWindow() at
> > >>> >> queuemgrwindow.cpp:106 0x827d24b
> > >>> >> Digikam::ContextMenuHelper::addQueueManagerMenu() at
> > >>> >> contextmenuhelper.cpp:741 0x81b096a
> > >>> >> Digikam::DigikamImageView::showContextMenuOnInfo() at
> > >>> >> digikamimageview.cpp:222 0x81d3a92
> > >>> >> 
> > >>> >> We call this instruction chain whenever the context menu is
> > >>> >> openend. But why? Wouldn't it be enough to just generate the
> > >>> >> QueueMgrWindow without all this stuff? Especially when no images
> > >>> >> have been added to the BQM?
> > >>> > 
> > >>> > If the QueueManagerWindow is supposed to be a singleton, like the
> > >>> > ImageWindow, there should be an additional method which returns the
> > >>> > singleton pointer (or a bool) but does not create it. With
> > >>> > K_GLOBAL_STATIC, there is a method exists() on the creator
> > >>> > _______________________________________________
> > >>> > Digikam-devel mailing list
> > >>> > Digikam-devel at kde.org
> > >>> > https://mail.kde.org/mailman/listinfo/digikam-devel
> > >>> 
> > >>> _______________________________________________
> > >>> Digikam-devel mailing list
> > >>> Digikam-devel at kde.org
> > >>> https://mail.kde.org/mailman/listinfo/digikam-devel
> > >> 
> > >> _______________________________________________
> > >> Digikam-devel mailing list
> > >> Digikam-devel at kde.org
> > >> https://mail.kde.org/mailman/listinfo/digikam-devel
> > 
> > _______________________________________________
> > Digikam-devel mailing list
> > Digikam-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-devel
> 
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel



More information about the Digikam-devel mailing list