We currently track window creation to decide whether the new window
should be moved or not. In order for this to work, the window must
already have been matched to the correct application, which is only
the case when the properties used for app matching were supplied
during window creation.
This is usually the case on X11, but never on wayland. To avoid this
issue altogether, stop listening for raw window creations, and instead
track when a window is added to an application we are interested in.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
While reading the configuration, processing it and iterating over the
configured apps to find a match isn't terribly expensive, but caching
the configuration in a map does save a bit of work, and makes for much
cleaner code in findAndMove().
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
When overriding an upstream method, copying the original method code
should always be a last resort, as the two code bases tend to get
out of sync and it often becomes hard to spot the modifications done
by the override. Both those issues can be avoided when figuring out
a way to split out the modifications and call the unmodified upstream
method - we are in luck with our checkWorkspaces() override, as we
can trick the upstream method into not removing workspaces we want
to keep instead of copying the method altogether.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
Trying to dispose a proxy object before it has been properly
initialized triggers an "uncatchable exception", which gjs
treats as a fatal error since commit c7bdcaab4. We only have
anything to clean up once the proxy is initialized anyway, so
don't force dispose() before that.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/44
On wayland, the properties that are used for application matching
are generally set after the window has been created, so it is
normal that buttons start with the fallback icon. While we already
track the properties that are relevant for app matching, our signal
handler may run before the window is matched to its app.
Make sure the WindowTracker gets to process those signals first by
using connect_after() for our own handlers.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/10.
After replacing Lang.Class with ES6 classes and adopting arrow notation
for anonymous callbacks, we only use the Lang module to bind `this` to
named callbacks. However since ES5, this functionality is already provided
by Function.prototype.bind() - in fact, Lang.bind() itself uses it when
no extra arguments are specified.
So just use the built-in function directly instead of the wrapper.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
Arrow notation is great, but as we only started using it recently,
we currently have a wild mix of Lang.bind(), function() and () => {}.
To make the style consistent again, change all anonymous functions
to arrow notation.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
As a pure javascript project, building is really just a glorified
copy operation, so success doesn't even indicate that sources are
syntactically correct (a.k.a. "compile-tested"). We can at least
get some minimal testing by performing some basic syntax checking
when SpilderMonkey's JS shell is available.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/32
The steps for adding a new extension are clearly different in meson,
so update the instructions accordingly. Don't bother with keeping
the existing autotools steps - supporting both build systems in
parallel is just temporary, autotools is on its way out.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/31
"for each ... in" has been deprecated for a long time and won't be
supported in upcoming SpiderMonkey versions, so replace it with
"for ... of" instead.
Instead of copying a long function for a single changed line, wrap the
layout algorithm in a LayoutStrategy so the workspace code picks it
up without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=787934
Currently the injection to move title captions to the top depends on
the value of the setting at the time the extension is enabled.
Instead, do the injections unconditionally and query the setting
inside the function to pick up settings changes.
https://bugzilla.gnome.org/show_bug.cgi?id=787934
title._spacing is no longer defined, so we end up with bogus positions
when window-captions-on-top is set to true. Adjust the positioning to
do without that for now, though the whole extension could use a rewrite
to not copy everything-and-the-kitching-sink, or be killed off as yet
another extension from the original random collection that turned out
too expensive to keep dragging along ...
https://bugzilla.gnome.org/show_bug.cgi?id=787604
In short, gjs complains that octal escape sequences are deprecated
and advises to use the "0o" prefix for octal literals. Do that to
fix the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=787294
The REVERSES flag was removed from Meta.KeyBindingFlags a while ago, as
gnome-control-center doesn't recognize it and the corresponding "magic"
shift handling. That is, nowadays reversible keybindings need to
provide an explicit reversed binding.
https://bugzilla.gnome.org/show_bug.cgi?id=784079
The window context menu contains minimize, maximize and close items
that are currently enabled unconditionally, regardless of whether
the window indicates support. Respect those hints by updating the
items' sensitivity every time the popup is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=783601
The top bar now uses a translucent style when no windows are in its
proximity. As translucency looks odd in some situations (in particular
with maximized windows), we don't want to pick it up unconditionally.
If someone fancies to integrate with the top bar's proximity tracking,
they are welcome to have a go, but for now we just restore the former
solid style unconditionally.
When we try to launch an application for an uri where the enclosing
mount is not yet mounted we might need information from the user
such as passwwords. Using a MountOperation makes this possible.
https://bugzilla.gnome.org/show_bug.cgi?id=781788
When launching an application for an uri we detect the case that
the volume is not mounted and try to mount it. If this fails we
don't report any error, so there is no feedback for the user.
Use the async version of Gio.AppInfo.launch_default_for_uri so
we don't hang or block if the uri we are trying to launch the
application for is on slow or dead network connections.
https://bugzilla.gnome.org/show_bug.cgi?id=781831
