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

[Eric Laffoon]

Hi Kevin,
First of all I greatly appreciate your helpfulness. Sadly it is not yielding 
the joy of a  compile, but I am studying and understanding the code better. I 
may not have time to become a C++ guru, but I may get there out of my 
obsessive-compulsive problem solving. Comments and feedback below.

On Saturday 23 February 2008 8:18:00 am Kevin Krammer wrote:
> Hi Eric,
>
> On Friday 22 February 2008, Eric Laffoon wrote:
> > I didn't expect to hear from you. Actually I'm not using DCOP, but a
> > Kommander plugin to access QActions by proxy. I have the concept and
> > everything looks good except how to get it to talk to the QAction.
> > Kevin's idea seems good, I just can't seem to get the syntax with my weak
> > C++ abilities.
> >
> > This won't compile...
> > bool QtActionProxy::actionIsOn(const QString& action)
> > {
> >   return QObject::child(const char * action)->property("isOn").toInt();
> > }
>
> You will need a pointer to the main window.
>
> e.g.
>
> bool QtActionProxy::actionIsOn(const QString& action)
> {
>   QObject* childObject = mainWindow->child(action.utf8(), "QAction");
>   if (childObject == 0) return false;
>
>   return childObject->property("on").toBool();
> }

Very nice, though I need to verify I can use bool, conversion is the easy 
part. However the first problem is that mainWindow is not in scope, so maybe 
I missed an include. More on attempts and results below...
>
> 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. 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.
>
> In this case you the code is almost the same, just without the
> "mainWindow->" part.

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?
>
> > So... Should I be using QVariant as I have char and QString? Should I
> > just use a dynamic cast?
>
> A dynamic cast solution would look like this:
>
> bool QtActionProxy::actionIsOn(const QString& action)
> {
>   QAction* childAction =
> dynamic_cast<QAction*>(mainWindow->child(action.utf8 (), "QAction"));
>   if (childAction == 0) return false;
>
>   return childAction->isOn();
> }
>
> Cheers,
> Kevin

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

It looks like there is something fundamentally wrong here, probably something 
I am not clear on and not communicating.

What I did was go ahead and put this in SVN so that it can be peer reviewd and 
whatever silly mistakes I'm making or oddities that arise can be more clear, 
assuming you or anyone else would be so gracious to look. Again I really 
appreciate your efforts. I think I could make this work for me without the 
plugin, but I'd like to make it easy for others to use...

all Kommander plugins
svn.kde.org/home/kde/trunk/playground/devtools/kommander-plugins
this Kommander plugin
svn.kde.org/home/kde/trunk/playground/devtools/kommander-plugins/qtactionproxy

Thanks again for your help. Once I can get a working prototype function I can 
cover the reset of the action functions and at least add access to the 
statusbar.
-- 
Eric Laffoon
Project Lead - kdewebdev module