Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

C# wrapper feasibility - question

48 views
Skip to first unread message

tom...@jastrzebski.net

unread,
May 1, 2019, 10:17:49 AM5/1/19
to dev-...@lists.mozilla.org
Hi, I was just wondering how difficult it would be to create C# wrapper for
Servo, conceptually similar to CefSharp
(https://github.com/cefsharp/CefSharp).

What I am missing in CefSharp is methods to directly create/manipulate
widgets, without JavaScript and/or CSS and receive events like onmouseover.

It goes without saying that such functionality would allow for using Servo
as desktop/mobile non-web application GUI engine, in a similar fashion
Spotify uses Chromium - if I am not mistaken. I know about Avalonia
framework (http://avaloniaui.net) but its performance is limited since
everything above renderer is built in .Net Core.

Paul Rouget

unread,
May 2, 2019, 5:44:03 AM5/2/19
to dev-servo
What you can do today, with C# (or any language that can load a C
library) is to render a page in a GL buffer, and get few events about
what's going on in the page (new title, page navigation, resize, etc.
See: https://github.com/servo/servo/blob/master/components/embedder_traits/lib.rs#L114).
It is quite limited as you can't manipulate the DOM, get DOM events or
access the JS context. And there is not way (yet) to pass messages
between the embedder and servo.

A deeper integration with the engine is something that has been
requested in the past, and we might eventually look at in the future.
But it's not possible yet without adding hooks all over Servo.

A possible workaround is to setup a websocket server in your C#
application that your webpage could communicate with in JS.
> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo

tdjast...@wp.pl

unread,
May 2, 2019, 9:40:56 AM5/2/19
to pa...@mozilla.com, dev-...@lists.mozilla.org
Thank you for your answer and clarification.
Websockets and Java communication is exactly what I would like to avoid.
I encourage you to look into the case I and perhaps others previously
described.
Maybe that would not that too difficult. Needed objects/routines must exist
internally since they are available to Java.
Note the proposed feature would allow for much better Web Assembly Modules
(WASM) implementation than Microsoft Blazor.
0 new messages