ResizeToPreferred will only relayout the window once. Further calls will
not change anything, even if the text in the BTextView changed. So make
sure to compute the preferred size with a very high text view, and only
then, set the (rather short) english text.
This makes the text view large enough to fit the text in all languages,
and the window never changes size.
An application is allowed to set an empty drag bitmap. In that
case, the offset from the cursor doesn't matter, because there
is nothing to draw anyway.
app_server would end up confused by the empty bitmap (which has
no bits) and invalid offset (it would try to allocate a 2^16
x 2^16 pixels bitmap to fit both the cursor and the empty
bitmap), and eventually it would crash.
Fixes#13577.
At present, does not work (it fails to properly set up interrupts,
resulting in thousands of unhandled ones which all but grinds the system
to a halt) but this at least is some progress.
It is implemented using websockets and canvas darwing. It directly
speaks the remote desktop protocol. A websocket proxy that translates
the TCP connection into a usable form is needed. Websockify works for
this out of the box directly under Haiku.
Note that not all drawing modes are implemented, and most of them don't
have a good match on the canvas side. Fonts are also not properly
supported yet. A sans serif font will be used on the client for
everything and the metrics between the client and server will diverge
and cause drawing artifacts.
Usage:
* Run an application with a target screen to create the desktop:
TARGET_SCREEN=5001 Terminal
* Use a websocket proxy to expose the port via websockets:
websockify.py 5000 localhost:5001
* Open HaikuRemoteDesktop.html in a browser and connect.
To get the full desktop experience you may want to run Tracker and
Deskbar inside the virtual desktop. As they are both single launch
and controlled by the launch_daemon, you have to stop them via:
launch_roster stop x-vnd.be-trak
launch_roster stop x-vnd.be-tskb
And then start them manually from within the virtual desktop:
/system/Tracker &
/system/Deskbar &
The ScreenOwner interface gets an additional ScreenChanged() hook. It
is implemented in the Desktop class to automatically set the preferred
screen mode on the changed screen.
The HWInterfaceListener, previously only used by the downstream
DrawingEngine, gets an additional ScreenChanged() hook as well to inform
an upstream client of a changed screen.
The ScreenManager ties these two mechanisms together.
Instead of the server connecting back to a listening client, make it
into a more traditional setup with the server listening on a port and
the client connecting to it.
The client can now either connect directly, unencrypted and without the
ability to trigger listening and specifying a command, or through SSH,
as before with the possibilty to run a target application and causing
the creation of the listener.
With the direction change, there's only the need for one, local, port
forward with SSH, which simplifies things.
It is not a good idea to have a thread get an address from the request
cache, while another thread is deleting said address as the cache has
grown too large. Add a lock around the cache access to make it safe.
Since it handles physical address it should really be this.
It's not like many drivers actually used it anyway. It shouldn't harm
compatibility, drivers calling it with only 32bit would leave garbage in
the higher bits but since on x86 it's a noop anyway, it would end up in
the MSB register tha's ignored because it expects a 32bit result.
* Window frame might change based on set size limits.
Creating view with rectangle used to create the window causes it
to anchor outside the window.
To address that pass current frame rectangle to the view.
* Fixes#13167.
- Do not update more than twice a second
- Do not use tabs, so we can reliably compute the string width
- Cleanup and tweak other parts of the code
There is still a glitch when resizing Terminal, but it isn't as bad as
before. Ideally, using the SIGWINCH signal would solve that, but it is
sent to the app only when you release the mouse after a release
operation, so in our case, it is already too late.
Creating BDateTimeFormat and BDateFormat objects is a costly operation
(it loads locale data from ICU, etc). So, we should do it only once when
the format changes, instead of doing it each time we format a date
or time.
In some languages, the buttons would end up outside of window bounds, as
changing the BTextView content does not automatically update the window
size (even with B_AUTO_UPDATE_SIZE_LIMITS). So, we need to manually call
ResizeToPreferred after changing the text.
However, this exposed another problem: the view size is computed using
GetHeightForWidth, with a width as small as allowed by layout
constraints. In our cases, there weren't much layout constraints so we
would end up asking the text view to compute its height for a width of
52px, leading to a very high window. Add some explicit sizing
constraints to the text view and language list to make sure we get a
sane size.
Also tweak the layout a little to allow the keymap menu field to be
wider than the language list view, and make the window not resizable as
that makes it much easier to keep things under control and there isn't
really a need to resize it.
Accelerant interface:
Introduce new hooks B_SET_BRIGHTNESS and B_GET_BRIGHTNESS. Brightness is
a float in the 0..1 range.
App_server:
Forward brightness things between BScreen and the accelerant.
intel_extreme:
Implement the hooks. Note that this only works for laptop panels, but
the driver will pretend to support it in other cases as well.
Screen preferences:
If the accelerant supports the B_GET_BRIGHTNESS hook, allow to set
brightness with a slider. Otherwise, the slidere is hidden and these
changes aren't visible.
The libvterm implementation was sending characters to app_server one by
one. This made it very slow to update the view and SerialConnect would
have noticeable flickering.
We now look through each line and try to find ranges of characters with
the same attributes. We can then draw each of these with a single
FillRect+DrawString. In the normal case (no special attributes or colors
anywhere), this means just one call per line, plus two for the cursor.
