Age | Commit message (Collapse) | Author |
|
ClassicWindowTheme can now also paint notification window frames.
|
|
This patch introduces the ClassicWindowTheme, which is our default
theme implemented as a Gfx::WindowTheme subclass.
In this initial cut, we move normal window frame painting and title
bar metrics helpers out of WindowServer and into LibGfx.
This will eventually allow us much greater flexibility with theming
windows, and also makes it easier to build applications that want to
render a window with a specific style for some reason. :^)
|
|
We can't do any file syscalls anyway because of the reduction of pledges,
so we might as well lock the veil anyway.
|
|
This time, without trailing 's'. Ran:
git grep -l 'codepoint' | xargs sed -ie 's/codepoint/code_point/g
|
|
This reverts commit ea9ac3155d1774f13ac4e9a96605c0e85a8f299e.
It replaced "codepoint" with "code_points", not "code_point".
|
|
|
|
|
|
|
|
|
|
This makes contenteditable work in multi-process mode. :^)
|
|
Unicode calls them "code points" so let's follow their style.
|
|
When clicking on a window's frame that is blocked by a modal
window, we want to bring the entire window stack to the front
regardless of where the user clicked in the frame (not just the
icon).
|
|
This makes gemini.circumlunar.space (and some more gemini pages) work
again :^)
|
|
|
|
Change #2811 made window title stripes and window title shadow themable,
but it used the same stripe and shadow color for all window modes.
This is fine for the new 'basalt' theme which uses the same color
in all four window modes, but it changed the default theme so that
background windows had brown stripes and a brown shadow.
Instead, make the title stripe and title shadow themable per window mode,
and change the default theme to restore the colors it had before
change #2811: The title stripe color is the same as Border1 for all
window modes, and the title shadow is the same as the title stripe
darkened by 0.6.
|
|
This prevents windows from being opened directly on top of eachother,
and provides default behavior for when window position is not specified.
The new behavior is as follows:
- Windows that have been created without a set position are assigned one
by WindowServer.
- The assigned position is either offset from the last window that is
still in an assigned position, or a default position if no such window
is available.
|
|
Custom buttons can now be set using TitleButtonIcons under the
Paths group in themes. WindowFrame recognizes window-close.png,
window-minimize.png, window-maximize.png and window-restore.png
filenames.
|
|
|
|
|
|
|
|
I was a bit confused by the fact that a method named `build_system_menu()`
first enumerates a directory. Moving the app/category discovery to a dedicated
function that returns the GUI-relevant information makes this process a bit
less surprising.
As an added bonus, `g_app_category_menus` was actually only a temporary mapping,
and didn't need to be global. In theory, SystemMenu should use a handful fewer
of bytes now.
|
|
|
|
Just adding some basic folder/file icon makes a big difference here.
|
|
Use Core::guess_mime_type_based_on_filename() for this. It's obviously
not perfect, but it works better than just sending "text/html" for
everything no matter what. :^)
|
|
Use tables to align stuff instead of putting everything in a <pre>.
|
|
|
|
MenuApplet windows can now call rect_in_menubar to return their
location in the MenuBar.
|
|
Applet rects are now recalculated when changed.
|
|
If we use this everywhere, it may one day become possible to change the
window title font.
|
|
This feels a bit tricksy, but at least makes window icons look much
better with the "Basalt" theme. :^)
|
|
|
|
"Image" was a bit too vague, "ImageWidget" is obviously a widget of
some sort.
|
|
|
|
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).
|