Haiku monthly activity report - September 2019 | Haiku Project

Hi there, it’s time for the monthly report!

This report covers hrev53461-hrev53529. Let’s see what happened this month in Haiku.


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2019-10-03_haiku_monthly_activity_report_-_september_2019/
12 Likes

Axeld implemented basic monospace font support in the HTML5 remote desktop client, making Terminal and other monospace application a lot more usable there.

What’s this “HTML5 remote desktop client?”

It is like the native RemoteDesktop client but ot is multplatform as it uses HTML5 canvas to draw the Desktop.

https://www.haiku-os.org/node/6007/

1 Like

Thanks! I had no idea; there’s no reference to the HTML client there!

Edit: the source code referenced is here: https://github.com/haiku/haiku/tree/master/src/tools/html5_remote_desktop. I suppose it can connect to the Haiku remote desktop server.

As always, thanks to the Haiku dev team for all the hard work done with the system! It’s greatly appreciated! :smiley:

2 Likes

It started as an april 1st joke (on how modern web browsers are way too powerful for what we need them to do), and then people actually made it work. It’s still quite far from complete, and as a result, it is not yet exposed in the official user documentation.

2 Likes

Thank you! That makes sense.

Technically you could make a QT remote desktop client and port it with emscripten… might be slower though. Certainly it could be possible to take advantage of webassembly though.

Guacamole (https://guacamole.apache.org/) is a web client for RDP and VNC and it works really well - maybe this could be ported to Haiku?

We are talking about the reverse direction here - remote desktop allows to access your Haiku desktop using any web browser on another system. We do not want to use VNC or RDP, the idea is to do the rendering completely on the web browser side, so that Remote Desktop only sends drawing commands, instead of streaming the video data (which is how VNC operates). The result is better performance. It is more similar to X forwarding than to VNC and RDP.

If what you want is VNC, we already have both native servers and clients, and I don’t think adding a web browser to that would be of any interest.

X forwarding might not be the best comparison since it can perform worse than VNC and certainly worse than a better RDP implementation in most situations (if the person you are discribing it to is actually familiar with it). Hopefully it is a bit smarter along the lines of XCB an NX protocol or at least allows the potential for it.

X forwarding is powerful/convenient but bad as is.

Basically the thing to avoid is lots of back and forth between the server and client that could be scheduled or bundled together and or compressed better.

It certainly will be interesting to see it once it’s working.

It’s already working if you use the native (not browser based) client between two haiku machines.

X forwarding on itself works fine, for applications that actually do server-side drawing. Unfortunately, the server side drawing in X11 is quite limited (no antialiasing, etc) so “modern” toolkits (GTK2 and later, Qt4 and later) render a lot of things client-side, and indeed in that case X11 forwarding is suddenly a lot worse. We will likely have similar problems with some applications which do a lot of client side drawing or at least manipulate BBitmaps a lot.

1 Like

What’s the latest on Haiku’s own native remote desktop client capabilities? Is it just missing some GUI for exposing its usability?

That and the occasionnal rendering glitch because of missing features in BPicture (which also causes problems with printing)