| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
buttons. Provide as much contrast between white, gray and black as possible.
|
|
|
|
| |
presented
|
|
|
|
| |
gsettings.
|
|
|
|
| |
the OSK theme accordingly.
|
| |
|
|
|
|
| |
gtk-theme-name and gtk-icon-theme-name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality doesn't make sense, for two reasons:
- If we query the gtk-theme-name property before setting anything
else, we will certainly get the default theme name. But that is
hardcoded in GTK and not exactly secret. It can't be configured
directly, only by changing specific macros in GTK's source code and
recompiling it. The chances of someone doing that are... very small.
Thus, we can also just hardcode "Adwaita" in AG.
- If we query the gtk-theme-name property after setting it to a
different value... we will fetch the value we just set. That's
totally useless. My initial idea was that GTK is doing some input
sanitization on the provided theme name and handles an invalid name
by falling back to its built-in default and setting the
gtk-theme-name property to this built-in default as well. This,
however, is not true. Setting an invalid theme name will just mean
that GTK will fail loading the new theme and stay on whatever theme
it was before, copying the new value to the gtk-theme-name property
regardless. Unfortunately, querying the property is not something we
could use for error handling, which makes it completely useless.
It's better to just get rid of this.
|
|
|
|
| |
toggle icon theme if a11y indicator's high contrast switch gets toggled.
|
| |
|
| |
|
|
|
|
|
|
| |
This adds a configurable 'high-contrast-background-color' gsetting
parameter (defaulting to #000000), so the high contrast bgcolor becomes
customizable.
|
|
|
|
|
|
| |
background change requests.
Also reference the conncted-to gsettings by its class property name (KEY_HIGHT_CONTRAST).
|
| |
|
| |
|
|
|
|
| |
eye to identified code-blocks.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
sorting on a deep copy of the session list from LightDM.
This resolves the issue of loosing all session types starting with lower
case letters from the session chooser when accessing the chooser list
the second time.
|
|
|
|
| |
size unit 'pt' now (and reducing font size by 3).
|
|
|
|
|
| |
The preferred-session gsetting shall provide an ordered list of preferred
sessions for detecing the default session type.
|
|
|
|
| |
Fixes: https://github.com/ArcticaProject/arctica-greeter/issues/56
|
| |
|
|
|
|
|
|
|
|
|
| |
spawn_async them directly.
This assures DBUS_SESSION_BUS_ADDRESS being shared between
greeter and indicators, so DBus session bus operation work
out-of-the-box (which is not the case when launching indicators
via systemd).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the dialog resized whenever the timer was shown or hidden.
We want to avoid this, but unfortunately, GTK doesn't provide a way to
hide a widget and retain its size in the parent (for instance, a
container).
To work around this, create a new private class FakeHideLabel,
subclassing Gtk.Label, that exposes a fake_hide () property. If the
property is set to true, the widget is "fake hidden" by changing the
draw () method to first draw normally, and then paint everything fully
transparent.
The usual hide () and show () methods are not used any longer (other
than at widget creation).
Additionally, a dummy text is inserted at widget creation, including
setting the widget to "fake hidden", so that text line actually has a
size.
While this should work fine visually, this WILL definitely create
accessibility issues, which we must fix at a later time.
Fixes: https://github.com/ArcticaProject/arctica-greeter/issues/58
|
|
|
|
| |
slightly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once the shutdown dialog is created/realized/shown, a new message will
show up at the bottom of the dialog signifying that the default action
will be triggered automatically in a configurable amount of seconds.
This message will be updated once per second, counting down.
Once the countdown reaches zero, the currently focused button (if any)
is automatically clicked.
The message will keep showing for another 10 seconds, just in case the
user removed the focus and no button is actually focused.
Multiple actions will cancel the timer:
- Pressing escape.
- Selecting a different button via (Shift +) Tab or the left or right
arrow keys.
- Clicking within the dialog (but not on any button).
- Closing the dialog.
Fixes: https://github.com/ArcticaProject/arctica-greeter/issues/39
|
|
|
|
|
| |
They are not GTK overrides and the only consumers have been removed, so
get rid of them. They only confused me.
|
|
|
|
|
| |
Defaulting to 60, this sets the amount in seconds until the focused
button is triggered in the shutdown dialog.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
3a5ca24831d1b4a74af6cfd5c5cc2a42b5787aeb backported a commit calculating
the really needed screen size more correctly as a prerequisite for
additional multi-display support (span and zoom modes) from Slick
Greeter (5d39cade1f70ffe0a9bc38ad0b405bb55d98a505), but unfortunately
missed crucial code in src/arctica-greeter.vala.
While the realize call on main_window should be harmless, calling
setup_window on it actually leads to the main window resizing to the
actual size that was queried via GDK.
While setup_window is being called as part of the main window creation,
the first call just skips resizing it (for some reason). Subsequent
calls, which are *mostly* triggered through changes in the actual
display configuration (hardware or software), then have main window
recalculate its size (and updating the background).
Honestly, we could just rip out the whole do_resize logic and always
resize, since with these changes, we're forcing a resize on startup
anyway. Not doing so leads to the nasty bug this commit fixes.
However, to keep Slick Greeter's and our code more in sync (to make
future backporting easier), let's keep it like this for now.
Fixes: https://github.com/ArcticaProject/arctica-greeter/issues/47
|
|
|
|
| |
Fixes: https://github.com/ArcticaProject/arctica-greeter/issues/21
|
| |
|
| |
|
|
|
|
| |
Relying on LightDM's signals is not enough - we do not get the guest user.
|
|
|
|
| |
fixes https://github.com/ArcticaProject/arctica-greeter/issues/48
|
| |
|
| |
|
|
|
|
| |
keyboard indicator
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This improves the contrast considerably for the new static white
background.
|
|
|
|
|
|
| |
While this might look ugly, it is important that error messages can be
read well and a transparent background might be a bad fit with a static
red text color, if the background is also quite red.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Long lines were previously truncated as part of the fading label. Since
PAM (error) messages are shown within the prompt box, truncating them is
a really bad idea, since the user might not understand what went wrong
and how it can be fixed.
Enabling line wrapping makes sure that the full message is always shown
- at least theoretically. Messages may still be truncated if they are
long enough to overflow the prompt box itself, but this is caused by the
prompt box not resizing itself correctly. Further work on that is
necessary.
|
| |
|