Re: Question about extending QtAndroidExtras
Phil Thompson <[email protected]> Tue, 12 May 2020 09:19:31 +0100
| Newsgroups | gmane.comp.python.pyqt-pykde |
|---|---|
| Message-ID | <[email protected]> |
On 11/05/2020 22:38, Kálmán Viktor wrote: > My idea was that with a single string argument and string return value > users can simply pass in/return JSON and that would cover multiple > arguments and string/int/bool/float/list/dict types. > > It's a little hacky but probably still nicer than hacking Qt and > pyjnius > together. In that case I'd be more receptive to a method that took a QJsonObject argument and returned a QJsonObject value that under the covers converted to and from string data. That way it would be more obviously a PyQt extension and less likely to compromise a possible (future) wrapping of the actual API. Phil > Phil Thompson <[email protected]> ezt írta (időpont: 2020. > máj. > 11., H, 22:39): > >> On 11/05/2020 18:38, Kálmán Viktor wrote: >> > Hello! >> > >> > I'm wondering if it would be possible to >> > extend QAndroidJniObject's callStaticMethod to a version that supports >> > passing in a single string argument and the return value is also a >> > string. >> > >> > I tried something like this locally, but both gave me JNI error when >> > trying >> > to use them (the parameterless int return valued callStaticMethod works >> > fine but would it be good to pass in string, same for return value), >> > but >> > I'm not really familiar with SIP so it was just guess work (also tried >> > changing int to QString but that also gave me an error) >> > >> > static int callStaticMethod(const char *className, const char >> > *methodName, const char *signature, const char *parameter); >> > %MethodCode >> > sipRes = QAndroidJniObject::callStaticMethod<int>(a0, a1, a2, >> > a3); >> > %End >> > >> > static int callStaticMethod(const char *className, const char >> > *methodName, const char *parameter); >> > %MethodCode >> > sipRes = QAndroidJniObject::callStaticMethod<int>(a0, a1, >> > "(Ljava/lang/String;)I", a2); >> > %End >> >> And what about other combinations of arguments? Each combination would >> have to be implemented on a case by case basis and I don't want to >> start >> taking random requests. >> >> Phil >>