We update a few properties of ClutterText when the CSS changes via
_st_set_text_from_style() (which we call when receiving the
style-changed signal).
Right now we simply invalidate the text shadow every time we receive the
style-changed signal, but we're going to change that with the next
commits. To ensure the shadow still gets invalidated on CSS changed that
might affect the shadow, listen to a bunch of property changes that will
get notified when any property that affects the shadow changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
When text shadows are used, the cursor indicating the current position
also casts a shadow.
This means we have to regenerate the shadow texture after the cursor
position changed, so invalidate the shadow in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
We are now consistently calling notify() when a property does change.
With that we can opt out of g_object_set()'s implicit change notifications,
so that notify is only emitted when a property *actually* changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2168>
Just like the internal ClutterText, the icon actors are part of the
entry. It therefore makes sense for the icons to not react to clicks
when the entry itself is non-reactive; again, just like the text.
That behavior is also consistent with icons in GTK entries.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3138
Much of St is undocumented, aside from input/output arguments. This is
no doubt because a lot of it parallels Gtk closely, but is worth
improving since many new programmers are not familiar with Gtk.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2983
clutter_text_get_selection() creates a copy of the selected text which
gets passed to st_clipboard_set_text() which creates its own copy. The
copy returned by clutter_text_get_selection() however never got free'd.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1306
We currently always ignore the minimum width of the hint actor and
request/allocate the preferred width. This can be problematic with
labels with long text, where we should rather ellipsize the text
than allow the entry to grow indefinively.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2607
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
Commit 88ac339774 changed StEntry behavior so the text hint would
stay visible while focused, as long as the text buffer is empty.
However, IMs that use preedit still should count as "started typing",
while the text buffer is still officially empty.
To fix this, check on st_entry_update_hint_visibility() that there's
indeed no preedit buffer before showing the hint. We can't directly
listen to internal preedit buffer changes in ClutterText, so handle
preedit buffer updates through the ::cursor-changed signal that will
be indirectly emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1084
Notifying the "text" property inside `st_entry_set_text()` misses all
the text changes done by ClutterText itself, including those that happen
on key-presses. Fix that by notifying that property inside the
"notify::text" handler connected to the ClutterText.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/951
Also show the hint actor of an StEntry while the entry is focused but
has no text inside it. This is part of the new dialog and lock-screen
design where there are no labels before entries anymore and labels are
instead shown as a hint-text of the entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/944
This frees the entry's secondary icon that for other uses.
Caps-lock-warning feedback has been moved to be shown in
the various dialogs instead in the password-entries itself.
StPasswordEntry can now use a peek-password icon as the
secondary icon to show/hide the password present in the
entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Mutter and Clutter was changed to pass around the current target
framebuffer via the paint context instead of via the deprecated Cogl
framebuffer stack.
The framebuffer stack has also been removed from Cogl so change to use
the one in the paint context instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/652
In `st`, we can do this by using `ST_PARAM_*`. In the other code files,
just use `G_PARAM_STATIC_STRINGS` directly.
This is just a minor convenience to prevent a few unnecessary string
copies.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/646
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
This drops usage of Gtk/X11, replacing it with code that is dependent
of the Clutter backend in use. Another positive side effect is that
the keymap state will now be correct on wayland, since there were no
guarantees that X11 key state would reflect the current reality.
https://bugzilla.gnome.org/show_bug.cgi?id=762881
Same case of the previous patch; _st_paint_shadow_with_opacity()
uses cogl_get_draw_framebuffer(), and this patch makes it receive
a CoglFramebuffer as a parameter instead.
The cautious reader might notice that this commit apparently goes
against the long-term goal, for it introduces more instances of
cogl_get_draw_framebuffer(). This is not wrong, but these introduced
ones will be removed later on, when ClutterActor.paint() receives
a CoglFramebuffer as a parameter instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/283
The default get_paint_volume() implementation will do the union
of children, and the child ClutterText paint volume may expand
beyond StEntry size when text overflows.
We actually want all content to be clipped to the StEntry, so
implement get_paint_volume() and tell it so.
Call _st_set_text_from_style() when updating the entry's style, so
that CSS style properties such as text-decoration or letter-spacing
are applied over the internal ClutterText instance.
This allows a full ClutterActor to be used as hint in the entry, instead
of a simple string.
The string case has been now re-implemented on top of the hint actor.
https://bugzilla.gnome.org/show_bug.cgi?id=783484
This is the same as the previous commit, but for StEntry.
We don't have any need to explicitly destroy this actor in our dispose
implementation, and doing so breaks the assumption that we can access
the clutter_text from within destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=783483
Commit ffe4eaf00d broke the handler by fetching the instance private
from the wrong actor - as we don't use the ::primary-icon-clicked signal,
and the ::secondary-icon-clicked signal still works by accident, nobody
noticed until now ...
https://bugzilla.gnome.org/show_bug.cgi?id=782190
For shortcuts that involve a letter (like <ctrl>c), we currently only
accept the lower-case variant. This makes shortcuts awkward to use when
caps-lock is active, and is inconsistent with GTK+, so accept upper-case
variants as well.
https://bugzilla.gnome.org/show_bug.cgi?id=766325
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
