st-adjustment: Mark all properties as EXPLICIT_NOTIFY
All adjustment setter functions take good care of avoiding emission of
notify:: when it's not needed. The set_property() implementation already
calls into the setter functions, so mark the properties as EXPLICITY_NOTIFY
in order to optimize notify:: emission away through g_object_set (rather
common from JS code).
(cherry picked from commit b1b455ff1a0e856149142747e77fb1c98df34c03)
dialog: Really set ellipsize mode in subtitle and body
Dialog's subtitle or body could not be properly wrapped, while it's ellipsized
when the text's width doesn't exceed the container size.
Clutter text has an `ellipsize` property, however in dialog's subtitle and body
we have been setting the `ellipsize-mode` property to Pango.EllipsizeMode.NONE
that is not present in the underlying GObject.
Not being an error in javascript, gjs didn't warn us about this, while at the
same time the St.Label's default Pango.EllipsizeMode.END was used.
b3045cb...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
closeDialog: Untrack chrome when window loses focus
On X11, reactive chrome must be added to the input region in order
to work as expected. However that region works independently from
any window stacking, with the result that the unresponsive-app dialog
currently blocks all input in the "covered" area, even in windows
stacked above the unresponsive window.
The correct fix would be to track the unobscured parts of the dialog
and set the input region from that, but that's quite cumbersome. So
instead, only track chrome when the corresponding window is focused
(or the dialog itself of course).
a0f1ac8...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
messageTray: Fix sloppy backport
Commit 8111286463b8 was cherry-picked without accounting for the
screen/display API difference between 3-30 and 3-28.
c41175a...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
closeDialog: Periodically check for window to become responsive again
The close dialog for non-responding windows is closed automatically
when we detect that the window is responding again. However as we
currently only ping the window in response to certain user actions
(like focusing the window or opening the window menu), this can
easily go undetected.
Address this by periodically pinging the window while the close
dialog is shown.
