[Kommander-devel] Mainwindow proxy - again

[Eric Laffoon]

Hi all,
especially Andras and Kevin. I have come to the conclusion I need to make this 
plugin work. I've invested quite some time and development to a Mainwindow 
based Kommander application for my business and it has proven not only to be 
a little slow with the DCOP calls (which Andras says I'm "abusing"), but it 
has proven quite unstable. On my wife's system she crashes on open sometimes 
several times in a row and probably 10%-20% of the time using these calls. 
Mine is not quite as bad. There's a small chance it has to do with the KPart 
plugin, but I doubt it. I just did a test on my system and switched forms 
repeatedly several dozen times loading parts and called scripts from the 
parent MainWindow without a problem. However opening and closing it about 
four times cased a lockup. There is some DCOP initialization going on there.

So after having written some more C++ I went back to the code I'd written that 
Keven so graciously helped with and got it to where I have one error and a 
clear understanding of the problem and how it might be solved.

First off, the source is in SVN here. 
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

Keven had suggested the code might well go in kmdrmainwindow.cpp and I was 
going to just try this as I think I might get somewhere. Then it occured to 
me the best I could do from there is send something as a QString or integer 
from a signal on initialization because I can't access properties or members 
as it's not a Kommander widget. If not for the editor, making it a Kommander 
widget would solve everything. I've half a mind to try that, but I remember 
marc and Michal both spendind days trying and they have much more experience 
than I do. The plugin gives me the ability to run those functions in 
Kommander as a Kommandr widget. I just need to be able to communicate with 
the parent MainWindow.

Keven's last suggestion started with this line of code.
  QWidget* mainWindow = kapp->mainWidget();
The problem is that kapp is not declared here and I'm not sure it can be. I 
want to address the main top level object, but it seems paradoxical that it 
can't actually be declared or exist inside this plugin. Right? That is the 
question, how to get that, or get a copy of it because there can only be one.

This led me to a curious observation. When creating the object we declare a 
name for it. I have only one top level object and I know it's name. 
KApplication has kApplication which returns the name. This is the only 
reference I could find. Unfortinately I could no figure out how to make this 
work either. The current code is clean enough that if you can get that object 
it will compile, a plugin can be loaded and it can be tested. Just getting it 
to compile would be nice. I suspect the answer may be in referencing it by 
name, which oddly there is almost no documation on. Maybe I should look at 
KPart classed as they might have an example.

Once I get the ability to talk to an action I should be able to talk to menus, 
toolbars and the statusbar and eliminate the clumsy and unstable DCOP calls. 

Any help would be appreciated.
-- 
Eric Laffoon
Project Lead - kdewebdev module