Registered Member
|
I've been meaning to learn C# and the Qt/KDE API so I thought I'd play around with the Kimono bindings. I'm having some trouble reproducing the KParts tutorial at http://techbase.kde.org/Development/Tutorials/Using_KParts. I translated the line:
KService::Ptr service = KService::serviceByDesktopPath("katepart.desktop"); as: KService service = KService.ServiceByDesktopPath("katepart.desktop"); which crashes at runtime with the message: Cannot handle 'KSharedPtr<KService>' as return-type of KService::serviceByDesktopPath Is it possible to use KParts with the Kimono binding? Also, functions like CreatePartInstanceFromQuery() don't appear to be implemented. Also, is there any way to give a different application name? For example, when I pass the --help option, the usage note says "kde-dotnet.dll" instead of whatever I pass to KAboutData. |
Registered Member
|
Ah sorry, this type must've slipped through. I've committed a fix to master and the 4.6 branch, so it should be in 4.6.0.
What currently does work though is the KService::List or QList<KSharedPtr<KService> > types. So you could use KServiceTypeTrader.Self().Query() to get a list of matches and then user KService.CreateInstance<T>() to create an instance from that. The CreateInstanceFromQuery() methods are not implemented because they are template methods (which are a pain to wrap) and you can easily work around them by first using KServiceTypeTrader.Query() and then KService.CreateInstance() as described above. Hope this helps |
Registered Member
|
Thanks for the help!
I can imagine the problems templates cause with bindings. Using KServiceTypeTrader.Self().Query() is working fine till 4.6 comes out, but it revealed another problem. If Smoke doesn't know about a derived class does it try to use the nearest base class in the hierarchy? It looks like, instead of creating a KateFactory object, the bindings are trying to create an instance of the abstract class KParts.Factory.
|
Registered Member
|
Yes, this is what the bindings do. I don't know if KateFactory is public or not, but often there are completely private implementations of a class returned from such a method, so we have to fall back to the return type.
I don't think this can be worked around currently If you post your code or a small test case exhibiting this behaviour, I can fix it in time for 4.6. though. |
Registered Member
|
The code I had was essentially what's in http://techbase.kde.org/Development/Tutorials/Using_KParts translated to C#. There's not much fat to trim, but a slightly slimmer version would be:
which, at the line: part = service[0].CreateInstance<KParts.ReadWritePart>(); produces the same error I posted before. I've never worked on bindings before, so I'm curious what the best solution is in a case like this. Are changes like making KParts.Factory concrete typical? |
Registered Member
|
I just tried running
and it looks like the KService marshaller is working fine, but it still gives the error for trying to create an instance of KParts.Factory. Is there anything I can do to help it happen for 4.6.1? |
Registered users: bartoloni, Bing [Bot], Evergrowing, Google [Bot], ourcraft