I'd be OK if WebKitGTK could at least accept strings and pass them along ... wkjscore-result should be part of the core, IMO.
On Wed, Nov 1, 2017 at 12:28 PM, Sam Jansen <sam.jan...@starleaf.com> wrote: > > > On 1 November 2017 at 15:23, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> so ... it looks really like the exposed API is completely useless as it is >> >> ```js >> webkit.messageHandlers.gjs.postMessage('hello'); >> ``` >> >> Returns a >> >> [boxed instance proxy GIName:WebKit2.JavascriptResult >> jsobj@0x7fa08c2e4160 native@0x7fa052081d80] >> >> >> and if you try to get its value it goes bananas with a message like: >> >> Gjs-WARNING **: JS ERROR: Error: Unable to find module implementing >> foreign type JavaScriptCore.Value >> >> >> What's the purpose of register_script_message_handler at all? What am I >> missing? >> >> > Andrea, this is the problem Philip raised earlier and I replied to. I use > this library to solve the problem: https://github.com/sa > ifulbkhan/wkjscore-result > > 7 import * as WkJsCore from '../../gjs/WkJsCore' > ... > 85 let contentManager = this.webkit.get_user_content_manager(); > 86 if (!contentManager.register_script_message_handler('slinternal')) > { > 87 throw "register_script_message_handler() failed"; > 88 } > 89 contentManager.connect("script-message-received::foobar", > (obj, jsResult) => { > 90 let wkResult = WkJsCore.Result.new(jsResult); > 91 let str = wkResult.process_result_as_string(); > > > Unfortunately JavaScriptCore doesn't provide it's own GIR API to access > the JS data :( > > >> >> >> On Wed, Nov 1, 2017 at 11:02 AM, Andrea Giammarchi < >> andrea.giammar...@gmail.com> wrote: >> >>> I've quickly provided a proof of concept but you could have a >>> JSONChannel class singleton on the client side that queue each info and >>> wait for the GJS side to receive one before sending another. >>> >>> I might try a real implementation though and see how it works. >>> >>> however, this is just a work around for the fact you can send messages >>> without any content (... and I wonder how that can be useful in any way ...) >>> >>> Regards >>> >>> On Wed, Nov 1, 2017 at 10:50 AM, Sam Jansen <sam.jan...@starleaf.com> >>> wrote: >>> >>>> >>>> >>>> On 1 November 2017 at 11:55, Andrea Giammarchi < >>>> andrea.giammar...@gmail.com> wrote: >>>> >>>>> Actually the `notify::title` with a prefixed "secret-channel" and >>>>> serialized JSON looks like the best of them all, for the time being, as it >>>>> makes it straight forward for both client and server to communicate. >>>>> >>>>> ```js >>>>> // listen to each response >>>>> new MutationObserver(m => { >>>>> if (/^secret:response=/.test(document.title)) { >>>>> const data = JSON.parse(document.title.slic >>>>> e(RegExp['$&'].length)); >>>>> document.title = ''; >>>>> console.log(data); >>>>> } >>>>> }).observe( >>>>> document.querySelector('title'), >>>>> {childList: true} >>>>> ); >>>>> >>>>> // send info using client or simulate server sending in responses >>>>> document.title = 'secret:response=' + JSON.stringify({some: 'value'}); >>>>> ``` >>>>> >>>>> with a proper class/wrap to handle events and send data transparently >>>>> it might be a great way to exchange info >>>>> >>>>> >>>> I've just come to the opposite conclusion, though I don't disagree as >>>> such... >>>> >>>> My concern is that setting document.title, and having notify::title >>>> called is asynchronous (I believe). So in your JS, if one had: >>>> >>>> ``` >>>> document.title = '1' >>>> document.title = '2' >>>> ``` >>>> >>>> Then by the time notify::title is called, and you inspect your >>>> "webkit.title" property, I'd expect you'd only see the '2' value, and >>>> (likely) not the '1'. >>>> >>>> It's possible to solve this by ensuring the GJS side has picked up a >>>> message, and e.g. reset the title, I suppose. This feels like an awkward >>>> solution to me though. >>>> >>>> >>>>> >>>>> >>>>> On Wed, Nov 1, 2017 at 5:53 AM, Sam Jansen <sam.jan...@starleaf.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 1 November 2017 at 05:43, <philip.chime...@gmail.com> wrote: >>>>>> >>>>>>> On Thu, Oct 12, 2017 at 5:23 AM Andrea Giammarchi < >>>>>>> andrea.giammar...@gmail.com> wrote: >>>>>>> >>>>>>>> FWIW I've used the location with a private channel as protocol to >>>>>>>> intercept calls to/from the page and GJS. >>>>>>>> >>>>>>>> https://github.com/WebReflection/jsgtk-twitter/blob/master/a >>>>>>>> pp#L162-L175 >>>>>>>> >>>>>>>> The channel is a random string: https://github.com/Web >>>>>>>> Reflection/jsgtk-twitter/blob/master/app#L59 >>>>>>>> >>>>>>>> From the page, which is aware of the "secret" channel, I call GJS >>>>>>>> actions via location.href = `secret1234:method(${encodeURI >>>>>>>> Component(JSON.stringify(value))})`; >>>>>>>> >>>>>>>> The protocol secret1234 is intercepted and the >>>>>>>> `controller.method(JSON.parse(decodeURIComponent(restOfURI)))` >>>>>>>> invoked. >>>>>>>> >>>>>>>> To signal the page everything is fine I use >>>>>>>> this.webView.runJavaScript https://github.com/WebReflect >>>>>>>> ion/jsgtk-twitter/blob/master/app#L377 >>>>>>>> >>>>>>>> The page has a listener for the `secret1234` event on the main >>>>>>>> window, and such listener is instrumented to react accordingly with the >>>>>>>> CustomEvent .detail payload/info. >>>>>>>> >>>>>>>> This might look a bit convoluted, and it has JSON serialization as >>>>>>>> limitation for the kind of data you want to pass (i.e. I use base64 >>>>>>>> encoded >>>>>>>> images as source from remotely fetched files enabling somehow CORS for >>>>>>>> whatever I want) but it worked well, circumventing the missing >>>>>>>> communication channel available in Qt. >>>>>>>> >>>>>>>> Maybe today there are better ways for doing a similar thing and if >>>>>>>> that's the case, please share. >>>>>>>> >>>>>>> >>>>>>> Here is another, fairly new, way to do it. Start out by registering >>>>>>> a "script message handler": >>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.usercont >>>>>>> entmanager#method-register_script_message_handler >>>>>>> >>>>>>> To send a message to the page, use the same thing that Andrea uses: >>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.webview# >>>>>>> method-run_javascript >>>>>>> >>>>>>> To send a message from the page to the GJS program, use the >>>>>>> postMessage() method mentioned in the documentation, and connect to this >>>>>>> signal in your GJS program to receive the message: >>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.usercont >>>>>>> entmanager#signal-script-message-received >>>>>>> >>>>>>> >>>>>> Excellent - I had not noticed this. My first attempt at communicating >>>>>> between WebKit2 and GJS was via setting "document.title" and having GJS >>>>>> connect to the "notify::title" signal! Not a great approach, this looks >>>>>> much better. >>>>>> >>>>>> >>>>>>> Although I just realized that unfortunately the values won't be able >>>>>>> to be marshalled into GJS since you need to use the JavaScriptCore API >>>>>>> to >>>>>>> get at them. This is a really nice method in C, but in JS you can only >>>>>>> use >>>>>>> it to send a message without any content. That is annoying. I should >>>>>>> probably open up an issue about this. >>>>>>> >>>>>>> >>>>>> I just hit upon this problem myself. In researching it, I found it is >>>>>> solved (at least well enough for my use-case) with this open source >>>>>> library: >>>>>> >>>>>> https://github.com/saifulbkhan/wkjscore-result >>>>>> >>>>>> It's awkward having another dependency for me, especially one that >>>>>> isn't in a normal Ubuntu/Fedora/etc. package, but otherwise this approach >>>>>> worked fine for me. >>>>>> >>>>>> >>>>>>> On Wed, Oct 11, 2017 at 12:57 PM, Adriano Patrizio < >>>>>>>> adriano.patri...@hotmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you for response, this is my problem: have necessity to >>>>>>>>> implement methods into my web application webkit2 based and >>>>>>>>> comunicate with >>>>>>>>> GJS script (example: filesystem functions to read and write files or >>>>>>>>> window >>>>>>>>> managment). >>>>>>>>> >>>>>>>> >>>>>>> Regards, >>>>>>> Philip C >>>>>>> >>>>>>> _______________________________________________ >>>>>>> javascript-list mailing list >>>>>>> javascript-list@gnome.org >>>>>>> https://mail.gnome.org/mailman/listinfo/javascript-list >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list