This was used gala to implement hot corners, and the way the barrier API
works, there isn't really any practical reasons to not make it
derivable, since the backend is a separate type and object.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2626>
This one does proper error reporting. Via Javascript, barriers are
constructed directly via GObject construction, which currently can't
handle error reporting, but when calling from C we can. However, if we
initialize using GInitable, and use that in our constructor method, once
gjs gains support for construction using GInitable, including the error
reporting, we'll automatically get proper error reporting to Javascript.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
Prior to this commit, barriers were created with a MetaDisplay pointer,
despite being entities related and owned by the backend. In the X11
case, it was also not hooked up to the backend X11 connection, but the
clutter one, meaning for example that the logic was active (but dormant)
also for the Xwayland connection.
Fix this by moving X11 barrier management and event processing fully to
the backend. Also replace passing a display pointer with passing a
backend pointer. Keep the display pointer around for a release, but mark
it as deprecated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
The API allows for invalid barriers to be created; in an X11 session,
this could result in involutary early exit, so guard against those with
soft asserts. These will be logged in the journal as warnings, but will
avoid the crash unless compiled out.
Note that this doesn't fix the bug, it just makes it more detectable.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1901610
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1611>
When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.
Unfortunately, that backend object is never freed.
This commit ensures the implementation gets freed when
the barrier object is freed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.
Unfortunately, it fails to do this because of a misplaced early
return statement.
This commit removes the spurious return.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
In order to reuse some vector math for pointer confinement, move out
those parts to its own file, introducing the types old types
"MetaVector2" and "MetaLine2" outside of meta-barrier-native.c, as well
as introducing MetaBorder which is a line, with a blocking direction.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
When running as a dispay server pointer barriers are a server side
feature and requires no client interaction of any sort. This patch
implements pointer barriers that can be used when running as a display
server on the native backend. Running as a display server using the X11
backend is currently not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
This patch removes the X11 specific code from MetaBarrier and creates an
abstraction layer MetaBarrierImpl. The existing X11 implementation is
moved to a new GObject MetaBarrierImplX11 implementing the abstract
interface MetaBarrierImpl which is instantiated by MetaBarrier when
supported.
While at it, move it to backends/ and properly name the files.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
