Whilst SystemMenu maintains a constant WindowServer connection, there
isn't always a Window active on that connection to listen for theme
changes - this causes the current theme in this process to fall out of
sync with the rest of the system. This fixes this problem by
re-requesting an UpdateSystemTheme message when the dialog is
instantiated.
Adds a mechanism through which windowing clients can re-request an
UpdateSystemTheme message. This is currently used in SystemMenu's
ShutdownDialog to refresh it's theme when the dialog is instantiated.
Window icons in Taskbar were previously received in WM events with
shbuf ID's. Now that Gfx::ShareableBitmap is backed by anonymous files,
we can easily switch to using those.
Now, `chres 640 480 2` can set the UI to HighDPI 640x480 at runtime. A
real GUI for changing the display factor will come later.
(`chres 640 480 2` followed by `chres 1280 960` is very fast since
we don't have to re-allocate the framebuffer since both modes use
the exact same number of physical pixels.)
It's in efficient, and it also meant we wouldn't reallocate a bigger
backing bitmap in a lowdpi->highdpi transition, leading to minor drawing
glitches after such a transition.
(Whoops!)
Problem:
- `HttpDownload()` and `HttpsDownload()` implementations are the same
except for types and certificates.
Solution:
- Follow the "Don't Repeat Yourself" mantra and de-duplicate the code
using templates.
Almost all logic stays in "logical" (unscaled coordinates), which
means the patch is small and things like DnD, window moving and
resizing, menu handling, menuapplets, etc all work without changes.
Screen knows about phyiscal coordinates and mouse handling internally is
in physical coordinates (so that two 1 pixel movements in succession can
translate to one 1 logical coordinate mouse movement -- only a single
event is sent in this case, on the 2nd moved pixel).
Compositor also knows about physical pixels for its backbuffers. This is
a temporary state -- in a follow-up, I'll try to let Bitmaps know about
their intrinsic scale, then Compositor won't have to know about pixels
any longer. Most of Compositor's logic stays in view units, just
blitting to and from back buffers and the cursor save buffer has to be
done in pixels. The back buffer Painter gets a scale applied which
transparently handles all drawing. (But since the backbuffer and cursor
save buffer are also HighDPI, they currently need to be drawn using a
hack temporary unscaled Painter object. This will also go away once
Bitmaps know about their intrinsic scale.)
With this, editing WindowServer.ini to say
Width=800
Height=600
ScaleFactor=2
and booting brings up a fully-functional HighDPI UI.
(Except for minimizing windows, which will crash the window server
until #4932 is merged. And I didn't test the window switcher since the
win-tab shortcut doesn't work on my system.) It's all pixel-scaled,
but it looks pretty decent :^)
This patch replaces the use of shbufs for GUI::Window backing stores
with the new anonymous files mechanism.
Backing bitmaps are now built on memory allocated with anon_create().
They are passed across the IPC socket as IPC::File. This means that
WindowServer now pledges "recvfd" and graphical clients need to pledge
"sendfd" to work.
To support the cached bitmap swapping optimization on the WindowServer
side, each backing store is assigned an incrementing serial number on
the client side. (This allows us to re-use an already mapped file.)
Problem:
- `HttpProtocol::start_download` and `HttpsProtocol::start_download`
implementations are the same except for a few types.
Solution:
- Follow the "Don't Repeat Yourself" mantra and de-duplicate the code
using templates.
If you don't need a file descriptor after sending it to someone over
IPC, construct it with IPC::File(fd, IPC::File::CloseAfterSending)
and LibIPC will take care of it for you. :^)
This API was a mostly gratuitous deviation from POSIX that gave up some
portability in exchange for avoiding the occasional strlen().
I don't think that was actually achieving anything valuable, so let's
just chill out and have the same open() API as everyone else. :^)
