Hi; You want to send this email to gtk-devel-list, if you want to reach the GTK development team.
Additionally, you have to keep in mind two things related to the Broadway GDK backend: - the rendering model of GTK has dramatically changed in GTK 3.9x (and thus in GTK 4.0); this means that the Broadway backend in the current development branch of GTK is barely functional. There is currently no effort being directed at Broadway; unless somebody steps up, the backend is likely to be removed in the next major API version. - Broadway has always been a kind of "science experiment"; it kind of works, if you know exactly what you're doing, and if you accept the limitations of the implementation; even in the 3.x API it's a "best effort" code base that survives mostly because it has minimal impact on the rest of the toolkit. Any work towards making Broadway work ought to be directed towards adapting it to the new GTK rendering model, based on GSK and (possibly) hardware accelerated rendering. If you wish to contribute to the development of Broadway, please feel free to pick up the master branch, and join the #gtk+ IRC channel on irc.gnome.org. Ciao, Emmanuele. On Wed, 7 Jun 2017 at 22:49, chrysn <chr...@fsfe.org> wrote: > Hello GTK list, > > with WebAssembly becoming a fixed part of modern browsers, this opens a > new execution environment for GTK applications. > > The emscripten library already provides an environment where C programs > can be compiled with minimal modifications to run in the browser; > emscripten provides a virtual file system and an SDL2 implementation for > them. > > I imagine (and that's why I prefixed the thread with "vision", though > the subtext of madness is fitting too) that in Broadway the trip through > the web socket could be cut short: rather then buffer updates being sent > via websockets, they could be sent via WebAssembly syscalls right into > the Broadway JavaScript page that is fully hosting the WebAssembly > application rather than just opening a socket to one. > > > This would allow for some applications to run completely standalone in > the browser (eg. games[1]), while others could shift much workload from > the application server to the client (the terminal server for Evolution > would not need to run an instance for each user any more, but only > statically serve the executable and then act as file system and > networking gateway). > > I think this would be possible to implement; do you think it would be > practical, and for which applications? > > > Best regards > chrysn > > > [1]: The few file accesses those have can be served from a read-only > statically shipped file system, or one could take the game further to > gio and implement a dav:// with "system calls" to XMLHttpRequest... > > -- > I shouldn't have written all those tank programs. > -- Kevin Flynn > _______________________________________________ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list > -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
