In all circumstances, this returned exactly the same thing as scanline_u8(),
so let's just remove the silly detour.
This does not add any new dependency on Bitmap-internals, because that already existed.
This is a follow up to #2936 / d3e3b4ae56aa79d9bde12ca1f143dcf116f89a4c.
Affected programs:
- Applications: Browser (Download, View source, Inspect DOM tree, JS
console), Terminal (Settings)
- Demos: Cube, Eyes, Fire, HelloWorld, LibGfxDemo, WebView,
WidgetGallery
- DevTools: HackStudio, Inspector, Profiler
- Games: 2048, Minesweeper, Snake, Solitaire
- Userland: test-web
A few have been left out where manual positioning is done on purpose,
e.g. ClipboardManager (to be close to the menu bar) or VisualBuilder (to
preserve alignment of the multiple application windows).
This adds a new header <sys/internals.h>, which provides access to LibC internals.
This is in the interest of type-checking LibC itself, as well as enabling less-hacky
access for uses like LinkDemo.
And, of course, this progresses LibC towards building cleanly with -Wmissing-declarations.
This makes DynamicLink, and in fact all Demos, build cleanly with -Wmissing-declarations.
Note that this won't be necessary for 'normal' dynamic shared objects, as those
usually already declare their symbols in a header file.
Because a line of eyes is just not impressive enough.
This does not change any of the default behaviours except breaking the
line of eyes at 13 eyes (the 'sweet spot' for the default resolution)
Since the vast majority of message boxes should be modal, require
the parent window to be passed in, which can be nullptr for the
rare case that they don't. By it being the first argument, the
default arguments also don't need to be explicitly stated in most
cases, and it encourages passing in a parent window handle.
Fix up several message boxes that should have been modal.
This removes the remaining flicker in the WebContentView widget and
makes it feel pretty good to use it. :^)
The increase in memory use is something we'll have to address in the
future with more sophisticated solutions like tiling, etc.
After adding the scrolling feature, content available space reduced and
thus the bitmap size was always larger, than the inner size.
This lead to the horizontal scrollbar always beeing engaged.
The WebContentView widget now inherits from GUI::ScrollableWidget and
will pass its scroll offset over to the WebContent process as it's
changing. This is not super efficient and can get a bit laggy, but it
will do fine as an initial scrolling implementation.
Just like the single-process Web::PageView widget, WebContentView also
paints scrolled content by translating the Gfx::Painter.
Port the WebContent service to the new MultiInstance mechanism that
Sergey added. This means that every new WebContentView gets its very
own segregated WebContent process.
