WindowServer seems to only notify clients of theme changes when they have a Window. As SystemMenu spends most of its time connected to WindowServer without displaying a window, it misses most theme changes. This PR adds a new asynchronous IPC call to WindowServer (RefreshSystemTheme,) which causes WindowServer to reply with an UpdateSystemTheme message. A relevant helper method is added to LibGUI::Window, and called in SystemMenu::ShutdownDialog's constructor so that it immediately receives and processes an UpdateSystemTheme message containing the current system theme shbuf ID.

This is great! 😀

I was trying to do something similar with Core::File::read_link() — please take (another) look at that. So you think it makes sense to do this at the LibC level? Perhaps it does! What are the implications for Core::File::read_link() then?

But please don't allocate 4KB for the initial buffer, that's way too much for normal paths.

@awesomekling Not sure if this is the right solution. Should maybe all Window events be accepted? Or are there legitimate cases where a parent window would want an event that was technically sent to another window? Seems like EventLoop::pump will always bubble them up unless they're accepted.

Always accept the key events so that they don't bubble up to the parent object.

Fixes #4967

Right, that's what it'd do. As the commit message says, I tried the other behavior first but it gets a bit messy because the lower few resolutions at 2x are below Serenity's minimum resolution.

Exposing logical coordinates everywhere is self consistent with the code too. I think I'd like to try this for a bit and see how it feels. We can definitely iterate on the ui though.

This behaviour is also present in Terminal with the Settings and About dialogs.

Oh, and I didn't click "Apply" yet in screenshot two. When you click "Apply" after switching from 100% to 200% without touching the resolution dropdown, the qemu window sizes doubles in each dimenson.

So then it would use a display resolution of 2048x1536 in this particular example? That sounds confusing when it only shows 1024x768.

Hm, I can't see a button for this in Ubuntu.

Maybe it requires certain hardware support to show up? Not sure, Here's how it looks like on 20.10:

Windows only has a ui scale slider and no pixels at all as far as I can tell – I guess it always uses the display's native resolution? (But a qemu window has no such thing as a native resolution.)

Well in Windows 10 it's the madness of settings all over the place. I believe the resolution setting is in one place and then you have to click on advanced settings or something and then they have it there. Too lazy to boot into it to take a screenshot, but it's effectively the same as in Ubuntu: You pick the resolution as-is (in most cases you'd pick the native resolution of the display) and then a scale factor where 1x/100% is normal, 2x/200% everything is twice the size.

Discovered this whilst trying to use TextEditor via keyboard navigation only. I attempted to close TextEditor having unsaved changes via Alt+F4. This opened the 'Unsaved Changes' modal. I struck the 'y' key, more or less expecting this to save changes, however it seems these keys haven't been bound yet in these dialogs (this is another issue.) To my surprise, my keypresses were still flowing to the text editor, even though the modal dialog was in the foreground. Enter/space still action the highlighted button in the dialog, so it seems that only the uncaught keypresses are flowing to the parent window.

Screenshot

fwiw, TextEditor has a suggestions API you can use (on that note, maybe the suggestion trigger should be configurable?), and I think TextBox (which is a TextEditor) has a history thing.

That does look interesting, my original plan was to replace the TextBox with an editable ComboBox and populate it with the Run history, however using the TextEditor autocompletion may be another possible route. I feel the combo option would be the simplest to implement, and keeps us most true to a Windows-style Run, however I'd be open to the idea of possibly doing cool things with TextEditor suggestions.

By the way, I've just rebased the PR onto master and pledged sendfd so we should be working with the anonymous file changes :)

Oh, and I didn't click "Apply" yet in screenshot two. When you click "Apply" after switching from 100% to 200% without touching the resolution dropdown, the qemu window sizes doubles in each dimenson.

Hm, I can't see a button for this in Ubuntu. (I'm using https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment) ). Windows only has a ui scale slider and no pixels at all as far as I can tell – I guess it always uses the display's native resolution? (But a qemu window has no such thing as a native resolution.)

Hm that seems rather confusing. I would have expected things to be twice as big when I select that option. At least that's what Windows and Ubuntu do. It would never cross my mind that I'd have to select a resolution other than the monitor's native resolution, half the resolution. Or am I misunderstanding this?

Yes, I'm using read, not recv. Turns out with recv this behaves as I expected! Thanks so much, I'd never have figured this out, I've always assumed recv was the same as read except that you can pass flags.

well, it's a io_uring specific behaviour, read(2) and et al. don't do that.

Does this depend on the kind of file descriptor I'm reading from? I think when I was reading from stdin instead of a socket I did see the short reads.

It should not. There was some specific bits that can indirectly slightly shift the observable behaviour, but that's not for sure

(fuzzer build is "/home/runner/work/serenity/serenity/Userland/Libraries/LibGfx/Bitmap.cpp:502: undefined reference to `Gfx::Bitmap::to_bitmap_backed_by_anon_fd() const'", not caused by this change, already broken at head.)

I have this issue in k8s. :((

 # k logs mssql-57f6f78dbb-4jwwk
SQL Server 2019 will run as non-root by default.
This container is running as user mssql.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
/opt/mssql/bin/sqlservr: Error: The system directory [/.system] could not be created.  Errno [13]

And, when I change the mapping to /var/opt/mssql/data I get this :

This container is running as user mssql.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
2021-01-15 23:50:05.95 Server      Setup step is copying system data file 'C:\templatedata\master.mdf' to '/var/opt/mssql/data/master.mdf'.
2021-01-15 23:50:06.05 Server      ERROR: Setup FAILED copying system data file 'C:\templatedata\master.mdf' to '/var/opt/mssql/data/master.mdf':  2(The system cannot find the file specified.)
ERROR: BootstrapSystemDataDirectories() failure (HRESULT 0x80070002)

Why is an Ubuntu image looking in C: drive for template data?

Adding bool self_allocated = false; and self_allocated = true; in 7f66663 would make more sense in my opinion though.

Oh, nevermind. you added it in ed3410f but only used it from 7f666635. I didn't notice.

You forgot did not use self_allocated.

This is the surprisingly short result of a surprisingly long discussion about long paths. Now

This covers all cases of that use MutableBufferArgument (readlink and realpath). If this gets general approval, we should implement a similar "retry dance" for other syscalls that can return arbitrarily long paths, at least getcwd.

CC @bugaevc, what do you think? :)

It would be very nice if we could see what was in the CPU registers when the crash happened.

It would be cool if we could see the arguments and environment passed to the crashed process.

Right now it seems limited to one thread. If I crash FileManager after it has spawned a thumbnail generation thread, I only see the thumbnail thread backtrace, not the main thread.

(To reproduce, open FileManager and browse to /res/icons/16x16 or any directory with images, then killall -ABRT FileManager)

As promised. Crashing programs just got even more exciting!

Featuring:

• Tabs, because there's no way all of this will fit into the UI otherwise.
• Per-thread backtraces
• CPU register states (also per-thread)
• Process arguments and environment