Age | Commit message (Collapse) | Author |
|
|
|
With this, System Monitor has "System Monitor" instead of
"SystemMonitor" as tooltip, matching the app's title bar
and menu bar title.
Same for File Manager and Text Editor.
|
|
If we add "(Not responding)" to the title of an unresponsive window,
the title rect needs to be wider or we'll have text-on-stripes.
Thanks to @SharpOB for reporting this bug!
|
|
The theming system can now control title bar height, title button
size, title stripe color and the title text shadow color.
The implemented theme metrics system could be later extended to LibGUI
to allow themes to change widget padding, border width, etc.
|
|
We need to mark windows as destroyed and not consider them
when picking a new active window. Fixes lost focus after
closing some windows.
|
|
When walking the modal window stack upwards, we need to check if
the top modal window is still a descendant of the window that
the parent is blocked by. Fixes not all windows being brought to
the front when trying to active a parent in the middle of the
modal window stack.
|
|
|
|
Since the user can't really do much with windows that are blocked
by a modal window, there is no point in showing multiple buttons.
|
|
* The parent information is necessary by the Taskbar to be able to
determine a modal window's parent
* Minimize and maximize modal window stacks together
|
|
This fixes a few problems with modal windows:
* If any child window, or any child window further down the
tree is considered modal, then all windows in that chain
are modal.
* When trying to activate a window blocked by a modal child
bring the entire stack of modal windows to the front and
activate the modal window.
* A window is modal if it has a parent and it's flagged as
modal, regardless of whether the ClientConnection has
created modal windows.
This technically supports diverging modal window trees as well,
where two modal windows share the same parent, allowing both to
be activated (including for input) but not the parent. And it
should also support modal window stacks of arbitrary depth.
|
|
|
|
This solves a problem where windows don't receive a WindowInputLeft
event when popup menus are opened. This prevented ComboBox being
closed when right clicking the application on the task bar.
|
|
Accessory windows are windows that, when activated, will activate
their parent and bring all other accessory windows of that parent
to the front of the window stack. Accessory windows can only be
active input windows. The accessory window's parent is always the
active window regardless of whether it is also the active input
window.
In order to route input correctly, input is now sent to the active
input window, which can be any accessory window or their parent,
or any regular window.
|
|
By adding a special LauncherType::Application we can still
get meta data for the application, but also know that we should
consider executing that binary as the default action. LaunchServer
will not do this for us, as it should probably not be allowed to
run arbitrary binaries that haven't been registered as handlers.
|
|
This allows applications to get additional information,
such as name or icons, for each launch handler.
|
|
context menu
By specifying an optional Action for Menu::popup an application
can specify what item should be displayed as a default item.
|
|
This allows marking a MenuItem as a default action, e.g. in a
context menu for an action that reflects what e.g. a double click
would perform.
Also enhance the window menu to mark the close action as the
default, and when double clicked perform that action.
Fixes #1289
|
|
This commit makes the WebServer accept a base path to serve.
This makes taking files out of the system significantly more simple
(depending on whom you ask).
|
|
|
|
|
|
|
|
|
|
It's very annoying to crash the WindowServer when something harmless
is a little weird.
|
|
I saw this assertion fire once and I don't know how I made it happen,
but it seems fine for client-less windows to become active, they just
don't have a menubar to install.
|
|
As usual, this was just a matter of plumbing the PageClient calls from
the WebContent side over to the WebContentView side. :^)
|
|
|
|
You can now react to links being clicked via the on_link_click hook.
|
|
Everyone who connects to ProtocolServer now gets his own instance.
This means that different users can no longer talk to the same exact
ProtocolServer process, enhanching security and stability.
|
|
Note that there is only ever one client.
|
|
This avoids getting into the awkward situation where the socket is
still part-owned by main() in multi-instance service. Also it just
reads nicer.
|
|
Also add a little GUI::StatusBar to the demo app so we can see the
hovered link URL's live. :^)
|
|
This makes resizing the window a little less obnoxious. :^)
|
|
Instead of painting synchronously whenever a Paint request comes in,
the WebContent process will now buffer pending paints and coalesce
them and defer the actual paint using a zero-timer.
This significantly reduces flickering already, without doing any
double-buffering in the WebContentView widget.
|
|
The WebContentView widget will now be able to react to scroll-into-view
requests from the WebContent process.
|
|
WebContentView now fires its on_title_change hook, like Web::PageView.
We use this in the WebView test app to update the window title. :^)
|
|
|
|
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.
|
|
|
|
|
|
The WebContentView widgets reacts to this by requesting a repaint.
|
|
This actually looks a lot nicer without the [] and I'm not sure that
the visual cue about minimization state was actually useful.
|
|
This makes it look nicer with wide window icons.
|
|
|
|
|
|
Having this on the stack makes whole-program teardown iffy. Turning it
into a Core::Object allows anyone who needs it to extends its lifetime.
|
|
|
|
fixes #2575
The extra ResizeEvent would be handled after on_rect_change, and would
reset the size of main_widget to what it was before the resize.
Bonus: Less unnecessary events.
|
|
It's less code, and it's potentially more efficient once
posix_spawn is a real syscall.
|
|
It was shutting down even if selected Restart.
|
|
This makes wider icons look better, since they no longer rub up against
the left edge.
|