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

[Kevin Krammer]

Hi Eric,

On Sunday 24 February 2008, Eric Laffoon wrote:

> > I had a quick look at the 3.5 branch source of Kommander and there seems
> > to be a KmdrMainWindow class (in kommander/widget) so you could probably
> > place your code in there if this is the class the executor creates when
> > it encounters a QMainWindow in the XML file.
>
> Yes, that would be a great place, and probably easier. Unfortunately
> compared to a plugin it would require a an upgrade of Kommander. I'm trying
> to make a plugin.

Ah, sorry, I kind of missed that.

> 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

> 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.

> 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();
}

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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail01.fortunecookiestudios.com/pipermail/kommander-devel/attachments/20080224/db7b5764/attachment.pgp