We currently use the :active pseudo class to mark the selected day
in the calendar. Whenever the selected date changes, the class is
added to the corresponding button and removed from all others.
However when the selected date doesn't change (i.e. when clicking
the already selected date), the buttons are not updated and the
use of the :active class conflicts with StButton's builtin handling
of the class - the class is removed on the button up event and the
button is deselected.
Fix this by simply using a different pseudo class.
https://bugzilla.gnome.org/show_bug.cgi?id=746867
The last patch fixed marking days in the calendar where all
events are ignored, but it doesn't pick up the change when
an event is hidden. Emit an appropriate change notification
to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Ignoring events is currently implemented in the message list's
event section, which means that the calendar does not consider
ignored events when marking days with events. In order to fix
this, move the handling of ignored events to the event source,
which is shared between both components.
https://bugzilla.gnome.org/show_bug.cgi?id=768538
Commit 9b07ce1d0d broke the code that keeps the OSD window square.
Use that opportunity to move away from the hack of setting the
min-height style property from code and adjusting the width on
allocate, and implement a proper constraint instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
ClutterActor:width is a floating point property, so it will not be
automatically rounded to non-fractional values that properly align
to pixels. To fix the resulting blurriness, add explicit rounding.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit 9b07ce1d0d changed the OSD window's level bar to be a regular
actor instead of a custom drawn bar. The bar actor's width depends on
both the configured level (e.g. 40%) and the available width, however
the width is currently only updated when the configured level changes.
Fix that by properly considering changes to the parent's width as well.
https://bugzilla.gnome.org/show_bug.cgi?id=768317
Commit c39ffa111 moved the signal handling from the controls- to the
background-group to enable scrolling on non-primary monitors.
However this broke scrolling on reactive overview elements as the
workspace switcher, as they're not descendants of the background.
To fix, move scroll-event handling to the overview group itself,
which is the common ancestor of all overview elements.
https://bugzilla.gnome.org/show_bug.cgi?id=768316
When we restart, we need to update the struts for the screen before
we enter the main loop, or maximized windows will get resized to the
size of the screen without struts, then resized back.
A workaround is needed for a Clutter bug that occurs when we get
the size of an actor before the first paint of the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=761566
The memory which MetaBackground resides is freed automatically, when its
wrapper object Background is freed by garbage collection. But because the
memory for MetaBackground is huge, changing the background or changing the
background mode repeatedly makes a lot of memory to be in use until garbage
collection runs.
This patch frees the MetaBackground object explicitly when its
MetaBackgroundActor is destroyed which is the moment that the memory in the
object is not used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=766353
Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
This isn't a performance critical actor and the NVIDIA driver discards
offscreen buffers in some cases which would require us to go through
extra hoops to handle here which isn't worth it.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
When running as a wayland compositor, MetaCursorTracker might
legitimately not have a displayed cursor because e.g. a client unsets
the cursor surface.
Note that, under an X session, the assumption that the tracker always
has a cursor texture is true because XFixesGetCursorImage() always
returns data even if the cursor isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=767001
It is odd to switch workspaces on the primary monitor when panning on
a monitor without workspaces, so reject the gesture on non-primary
monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
It is odd to switch workspaces using the scroll wheel when the pointer
is on a monitor without workspaces, so only handle scroll events on
non-primary monitors when workspaces-only-on-primary is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
We allow activating a workspace by clicking it when we know that
the user did not try to select a window and missed (namely: the
workspace is empty). However we currently always check for an
empty workspace on the primary monitor, which doesn't make sense
when the click happened on a different monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Both the Overview::scroll-event and actions added via addAction()
are meant to work anywhere in the overview, but for now only work
on the primary monitor. Move the handling to the background group
that is known to span all outputs to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
The stack was used to overlay a message indicator over the overview
group. That indicator is long gone, so there's no longer a need for
an intermediate actor in the hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
Initializing the upper bound to zero means that on panning we'd start
scrolling from the first workspace even if the current workspace when
entering the overview was different since StAdjustment clamps the
value to be inside bounds.
https://bugzilla.gnome.org/show_bug.cgi?id=766883
We're using an unitialized box resulting in an undefined shadow box
size.
_st_paint_shadow_with_opacity() already computes the shadow's bounding
box from the source actor's box so we just need to pass that along.
https://bugzilla.gnome.org/show_bug.cgi?id=767954
on_custom_stylesheet_changed() would set properties_computed to FALSE
without freeing the old properties, then the properties pointer would
be overwritten in ensure_properties().
https://bugzilla.gnome.org/show_bug.cgi?id=710230
