[commonqt-devel] How to invoke Qt methods on Strings/QStrings?
Hi, I ran into the next problem: when I evaluate an expression like (#_contains "Hello" "Hel") the first string argument is not treated as an Object but instead commonqt starts looking for a Qt Class named "Hello" and obviously fails. I am aware of the cl function search and cl-ppcre, but I am just curious whether it's possible to use the Qt stuff. I actually started looking at the source code (of commonqt), but couldn't figure out much yet. Regards, Olaf Merkert
Quoting Olaf Merkert (olaf@m-merkert.de):
Hi,
I ran into the next problem:
when I evaluate an expression like
(#_contains "Hello" "Hel")
I think that this is a reasonable restriction. Arguments to method calls undergo automatic conversion from Lisp types to C++ objects if possible in many cases. But the instance on which a method is being called needs to be a C++ object. So you need to make (and later free) a new QString explicitly in this case. The reason is that, at this point during (actually, before) method resolution, there is no context to decide what to do. For method arguments, we know which possible argument types to choose from. That isn't the case for instance object. (Thinking in terms of examples for possible difficulties: CommonQt already supports non-QObjects to some extent. What if we start supporting std strings? We certainly don't want to start guessing whether QString or string was intended. I admit that this example is a bit contrived, but I still wouldn't want to commit to special-casing QString. And what's next? Byte arrays as target objects, getting converted to QByteArray? Lists of things?) And comparing to other implementations: I believe most other smoke bindings are strictly object-oriented, and the idea of invoking a QString method on the built-in language type for strings would be even more foreign to them than for Lisp. It would be nice if you didn't have to call #_new manually though; perhaps there could be macro for that. (with-qstring perhaps?) d.
Am Mittwoch 23 März 2011, 15:25:06 schrieb David Lichteblau:
But the instance on which a method is being called needs to be a C++ object. So you need to make (and later free) a new QString explicitly in this case.
That sounds reasonable to me. I actually tried to use (#_new QString "Hello") but I just get class not found: QString [Condition of type SIMPLE-ERROR] And originally, the context for the call to contains was something like this: (#_contains (#_data (#_sourceModel model) index0) (#_filterRegExp model)) In my mental model, the actual data in the sourceModel should have been a QString, because it was part of a Qt datastructure -- or am I wrong about this? But it will automatically be converted to a native lisp string? I'm not sure here, because I put lisp strings into the datastructure (see attachment of my previous question) using setData. Ultimately, it is probably wiser to just use lisp libraries for these model level things. Thanks for your fast answer, Olaf Merkert
Quoting Olaf Merkert (olaf@m-merkert.de):
Am Mittwoch 23 März 2011, 15:25:06 schrieb David Lichteblau:
But the instance on which a method is being called needs to be a C++ object. So you need to make (and later free) a new QString explicitly in this case.
That sounds reasonable to me. I actually tried to use
(#_new QString "Hello")
OK. I think I've been getting ahead of myself (or of the code) a little with the #_new suggestion there. It turns out that there was a qobject lisp type wrapping such a pointer a long time ago, but it is commented out now, there's no marshalling code for it anymore, and especially no dispatching code, which you would need (and never has been)... [...]
Ultimately, it is probably wiser to just use lisp libraries for these model level things.
At the moment, I think you're right. As you can tell, I'm still more in "what do I want CommonQt APIs to look like eventually" mode at the moment with my thinking, and not quite in "how does it work today" mode. Perhaps Stas has a better suggestion; at least ISTR that someone actually worked with those models already. d.
participants (2)
-
David Lichteblau -
Olaf Merkert