[Kommander-devel] Re: Accessing a QAction in a Kommander Plugin

Eric Laffoon eric at kdewebdev.org
Sun Feb 24 15:36:13 EST 2008


Hi Kevin,

On Sunday 24 February 2008 5:12:35 am Kevin Krammer wrote:
> > BTW if I were to begin here I could also loop at
> > replacing or writing new calls based on KMainWindowInterface for actions.
> > This could give me DCOP by changing the call from KAction to QAction. If
> > I understood the differences and QActions better I could consider on the
> > fly conversion and implementation of XMLGUI, but all of this is work we
> > chose not to do on this release, fascingating as it is to ponder. It
> > won't be an issue in KDE4. For now an action proxy plugin seems the best
> > course.
>
> Hmm, theoretically all QObjects of a KApplication can be accessed through
> the "Qt DCOP bridge".
> If you have a look at the application with dcop or kdcop one of the
> interfaces is named "qt"  and calling its "objects" method list all
> QObjects using a file path like syntax for addressing them indiviually.
>
> This path can then be used to do DCOP calls on the object, e.g.
>
> % dcop application "qt/path/to/object" method arguments

Yes, that is rather nice... if not for what we did using the Designer 
MainWindow and how the code reads in kmainwindowiface.cpp.

	QValueList<KAction *> lst = m_dcopActionProxy->actions();

Where all the DCOP is generated they reference KActions, which is what a KDE 
app should do. If KDE3 weren't at end of life... regardless this will all be 
nicer in KDE4.
>
> > Unfortunately that header file is not exported. I can copy it and leave
> > the constructor alone, (tacky and error prone I know but it's the last
> > release of 3x) then look at adding functionality in another file which
> > can be used by my plugins. Unfortunately this is where I confuse myself.
> > I don't want to call the constructor twice for obvious reasons. I know I
> > can externally reference this class with KmdrMainWindow::myNewFunction
> > but it looks like I'm back where I started with needing to get a pointer
> > to the QObject to extend it, or do I?
>
> Yes, I think it will be easier to do it without the Kommander mainwindow
> header.

That's good.
>
> > In each solution when I get to where I should see working code I get this
> > error.
> > ../../src/qtactionproxy.cpp: In member function 'bool
> > QtActionProxy::actionIsOn(const QString&)':
> > ../../src/qtactionproxy.cpp:145: error: expected primary-expression
> > before '->' token
> > ../../src/qtactionproxy.cpp:149: error: expected unqualified-id before
> > numeric constant
> > ../../src/qtactionproxy.cpp:149: error: expected ';' before numeric
> > constant ../../src/qtactionproxy.cpp:149: error: '1' cannot be used as a
> > function
>
> I had a quick look at the code. Try this:
>
> bool QtActionProxy::actionIsOn(const QString& action)
> {
>   QWidget* mainWindow = kapp->mainWidget();
>   if (mainWindow == 0) return false; // no main widget
>   QAction* childAction =
> dynamic_cast<QAction*>(mainWindow->child(action.utf8 (), "QAction"));
>   if (childAction == 0) return false;
>
>   return childAction->isOn();
> }

Nice safety checks. my initial try got 
'kapp' was not declared in this scope
So I need to look at headers, but I need to eat first.
>
> kapp is a global pointer which is set to the KApplication instance.
> (you can also write KApplication::kApplication() instead, which is a static
> method and can be called without object, returning exactly the same pointer
> kapp points to)
>
> As far as my rather skin-deep check of the code told me, the Kommander
> Executor sets the main widget in Instance::run() specifically if it is a
> main window, so mainWidget() should return exactly the object you are
> looking for.

Right, and my self mandated studies indicate this is exactly where a dynamic 
cast would be useful.
>
> Cheers,
> Kevin

That's good stuff. I can't tell you how much I truly appreciate your help 
Kevin. I think I may be able to get it working now, and I will of course post 
and let you know. If you are at aKademy this year I'd love to buy you a beer.

-- 
Eric Laffoon
Project Lead - kdewebdev module


More information about the Kommander-devel mailing list