There are other window types that should be excluded from workspace
previews, including more common ones like menus. Instead of checking
for a variety of window types, delegate the decision to mutter by
checking for the `skip-taskbar` property.
(The internal `skip-pager` property would be more apt in this case,
but as it only differs from `skip-taskbar` for X11 clients that
explicitly set one and not the other, it shouldn't matter in practice)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/537
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/363>
(cherry picked from commit 77a11fd9cd)
Uncaught errors in async functions don't provide a good stack, because
the unhandled promise rejection masks the error that triggered it.
While we already handle *expected* errors inside the function, make
sure we catch all errors to get useful stack information for unexpected
errors as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/361>
(cherry picked from commit e0b68a319e)
PopupImageMenuItems used to position the icon after the label,
so we ended up with our own icon+label items.
However the icon position was changed years ago in the shell, so
inherit from PopupImageMenuItem instead.
This does not only simplify the code a bit, but also pulls in
features we are currently missing, like a11y labelling.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/542
(cherry picked from commit 568826e489)
In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/324>
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/324>
Pipelines for non-protected branches are set to 'manual', and
thus cheap. However they may still get picked by `@marge-bot`,
meaning that the bot waits for the completion of a pipeline that
never starts.
Avoid that by not creating pipelines for branches with open
merge requests.
Credit to Jordan, who came up with this for gst.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/300>
A long time ago, we used to include a system monitor extension,
that added CPU/memory graphs to the (long gone) message tray.
However demand for this type of extensions hasn't died down, to the
point where RHEL includes a revived version of the old extension.
Account for that demand by adding a newly written system-monitor
extension that has been properly designed, and hopefully does not
bring back the CPU/memory issues of the previous one (unlikely
without the graphs) …
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/277>
To avoid continuous height changes while browsing through categories,
we let the list of categories determine the overall height, and rely
on scrolling for the list of apps within a category.
We currently achieve this by assigning a fixed height via the
`style` property. This has been found to trigger a crash when
running headless, as we end up querying an actor's height request
before a valid resource scale is available.
Instead, use a custom layout manager, which seems more elegant anyway.
Close: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/472
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/290>
Ever since gnome-shell stopped using a stippled separator in the
calendar menu, the styling required by the separator has been
missing.
There haven't been any complaints about the invisible separator,
so we can just as well drop it altogether.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/290>
Since we disabled the overview in the classic session, gnome-shell
switched to a horizontal workspace layout and replaced the activities
button with an indicator.
Those are big enough changes to reevaluate the decision, so remove
the delta with the regular session and turn it back on.
This reverts commit 82d2011061.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/287>
It is considered bad practice, and mainly a lazy way of disconnecting
signal handlers without tracking individual handler IDs.
We can do better by using connectObject(), which provides the same
level of convenience without the dodginess of getting behind the
garbage collector's back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/275>
Provide all licenses used in the project in a LICENSES folder and
add SPDX license and copyright information for all files in
accordance with the Reuse Software[0] specification.
The copyright information is based on the file's git history,
using a fairly generous definition of "non-trivial".
As of the spec recommendation, the information is generally added
as comments in the files themselves, except for
- NEWS, README and similar top-level standard files, so that
a SPDX code isn't the first thing people encounter
- files that don't support comments (json) or where they'd
be a bit awkward (.desktop, .service)
- anything under po/, to not interfere with translation teams
Those are covered by a .reuse/dep5 files, except for image assets,
where separate .license files are used (It would be possible to
add comments to SVG files, but I don't trust image editors to
preserve them).
[0] https://reuse.software/
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/224>
Once the shell is ported to ESM, it will no longer be possible
to replace entire classes (even when exported). Prepare for that
by overriding methods of the regular classes, instead of creating
custom subclasses.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/268>
The eslint job report its results as artifacts in junit format,
so that gitlab can present them in its UI.
However many psople miss that, and unsuccessfully check the logs
instead.
Address this by using a simplified version of gnome-shell's eslint
wrapper, so we can report results both on stdout and in a file
without re-running the linter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/262>
We no longer have a separate classic theme that could(*) use
custom assets, so the file is now very officially a left-over.
(*) spoiler alert: The made-up property where the image was
used has been ignored by gnome-shell for years
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/260>
As gnome-shell is moving to ESM, it will now load extensions as
standard modules instead of using legacy imports. The change boils
down to exporting the Extension class as default, but we can also
start using standard imports for introspected modules now, so do
that at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/259>
Disable() should restore the scheme preference that was used when
the extension was enabled, not when it was first initialized.
Even if it's unlikely to be relevant in practice, let's make sure
we save the correct state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/257>
Now that gnome-shell supports a light style, people may want to
use it without forcing all apps to be light.
Add a small extension that switches the default to light, so the
shell follows the regular "dark style" preference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/256>
Now that classic styling is based on color scheme instead of
a dedicated "classic" stylesheet, we should do the same for
extension styling, with the bonus that it also works with the
regular appearance setting outside the classic session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/254>
gnome-shell now includes a light variant, and supports switching
between dark- and light styling at runtime.
That means we no longer have to build our own stylesheet, and can
instead just instruct gnome-shell to always use the light style
in the classic session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/254>
gnome-shell started transitioning to gjs' object spacing rule,
i.e. `{foo: 42}` instead of `{ foo: 42 }`.
We have a much smaller code base than the shell and aren't using
a secondary "allowed-but-deprecated" configuration that allows a
gradual transition, so just pull the switch and update to the new
style.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/240>
Currently, the visibility of the window list on a given monitor is set
according to the fullscreen status of the primary monitor. When a
fullscreen application is on a secondary monitor (but not on the primary
monitor), entering and exiting the overview will lead to the window list
incorrectly being visible on the monitor with the fullscreen
application.
Instead, determine the visibility based on the fullscreen status of the
monitor being evaluated.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/230>
gnome-shell dropped the separate us/intl handling back in 2019.
That includes adding the corresponding style classes, so the
style and assets are completely unused now.
Nobody noticed because gnome-shell itself includes assets for
a light variant, so we can simply drop the unused stuff.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/222>
Limiting the action to the row that changed instead of the list as
a whole makes it easier to only update the changed value and not
recreate the entire list.
This doesn't make a difference right now, because we carefully sync
the list to reuse existing rows, but we are about to back the list
with a GListModel instead of updating it manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/218>
Limiting the action to the row that changed instead of the list as
a whole makes it easier to only update the changed value and not
recreate the entire list.
This doesn't make a difference right now, because we carefully sync
the list to reuse existing rows, but we are about to back the list
with a GListModel instead of updating it manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/218>
As a side-effect of supporting class fields, regular constructors
now work in GObject subclasses. Using _init() still works and
there's no functional difference, but it's simply much nicer
to use the same syntax for all classes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/215>
Provided we use the correct version of the SpiderMonkey shell, we
can perform checks using the same engine that is used by gjs.
However some engine features are opt-in, so the set of features enabled
by gjs and js91 may differ. The obvious option for avoiding this is
replacing js91 with gjs for tests.
Switch to the newly added gjs-check-syntax script, which does precisely
that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/215>
The CallbackAction's callback must return true to stop the event
from propagating to the dialog, where it will trigger the close
binding.
It makes sense to still allow closing the dialog with Escape while
not editing a row. The easiest way to achieve that is by moving the
controller to the entry.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/208>
The reveal animation moved from Main.layoutManager.keyboardBox to
the keyboard itself, so instead of applying an additional translation
for the bottom panel, we override the translation that would reveal
the keyboard (and thus prevent it from showing altogether).
Fix this by moving our translation to the keyboardBox instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/199>
The window-picker padding was causing it to become smaller in the
overview resulting in a jump when opening it and caused sizing issues
with the workspace view in the app picker. However it is not needed
anymore with the new overview, so this can be fixed by simply removing
it.
The horizontal- and vertical-spacing properties got replaced with a
spacing property a while ago. However this is only used in
WorkspaceLayout::_createBestLayout() which gets overridden by this
extension which does not use it. So they can simply be removed.
The shell-caption-spacing property got removed when the window captions
got changed to always use the full length and has not been doing
anything since.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/301
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/309
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/189>
Extensions review guidelines enforces extensions to
don't create objects in the constructor of the class
that init() returns. so creating settings object in enable()
can make the extension compatible with the ego review guidelines.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/197>
The regular GNOME session ships with three options:
* GNOME
* GNOME on Wayland (available when GDM starts in X11)
* GNOME on Xorg (available when GDM starts in Wayland)
The main GNOME session is set up so it works to match how GDM starts,
so GNOME is on Wayland if GDM is (or GNOME is on X11 if GDM is).
For GNOME Classic, we are missing this setup, so port this behavior
over from the GNOME session setup.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/195>
GDM has supported sessions registering with it for a few years now so
it can know when to shut down the greeter. Having the GNOME Classic
session declare that it will register itself allows GDM to avoid
executing a fallback codepath.
This has been supported with the regular GNOME session for a while,
and this session was likely forgotten about when it was added there.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/195>
Passing arguments to dist scripts was only introduced after 0.44,
so bump the requirement to shut up the corresponding warning.
Meson 0.53 is the same version requirement as gnome-shell, so that
shouldn't be an issue for distributors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/191>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/186>
We currently use a setup modelled after the flatpak CI workflow,
where we produce extension bundles and expose them as artifacts
for easy testing.
It still makes sense to test a regular build though, in particular
as that can include classic mode support.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/186>
Mutter uses an undefined initial in-fullscreen state, so it will
always emit the `in-fullscreen-changed` signal when it determines
the actual initial state.
This didn't use to be an issue when the shell started in the session,
but now results in the window list ending up visible in the overview
on startup.
Work around this by hiding ourselves again when the in-fullscreen
state changes in the overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/185>
The helper functions date back to a time when AppButton and WindowButton
were unconnected classes. But nowadays they share a common base class, so
we have a better place for them than external helper functions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/180>
Since commit a6ee142f21, the extension archives that are uploaded
to extensions.gnome.org only contain strings that are relevant for
the extension, not all translations from all extensions.
Unfortunately all extensions still share a common gettext domain,
so the extension with the last bind_textdomain() call wins and
leaves the others without translations.
We'll address this by using distinct domains when not installed
system-wide. That becomes easier if there is a canonical place
for the text domain, with the existing metadata key being the
natural choice.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/335
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/179>
The panel-button introduces some horizontal padding which is insensitive
to scroll events. Without this change, there is a small dead zone in the
corner that cannot be used to switch workspaces with the mouse wheel.
For useMenu mode, this has the effect of removing all of the horizontal
space to the edge of the screen, so I add some back with the
status-label-bin margin.
This a is similar change to 8bad8a3b63.
Fixes#315.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/171>
With the new version scheme, only the major version is relevant as
far as gnome-shell is concerned. However the extension website does
not handle that at the moment, so always append a ".0".
On request of GNOME Classic users, we add GNOME2-like workspace previews
when using a horizontal workspace layout. The previews scale a lot worse
than the menu though, with the risk that they take up all the available
width in extreme cases.
Address this by also taking the number of workspaces into account, and
switch to the menu when we have more than six.
This is particularly important now that we switched to a horizontal
layout by default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/165>
On request of GNOME Classic users, we add GNOME2-like workspace previews
when using a horizontal workspace layout. The previews scale a lot worse
than the menu though, with the risk that they take up all the available
width in extreme cases.
Address this by also taking the number of workspaces into account, and
switch to the menu when we have more than six.
This is particularly important now that we switched to a horizontal
layout by default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/165>
More unsurprising breakage:
- the workspace layout/strategy relation has been cleaned up
- window previews now include an icon that influences the
title position
- window previews scale up on hover, which again influences
the title position
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/164>
Visibility changes are now handled internally, without an easy way
for us to hook into. We can resort to a hack though, as the gesture
action to bring up the keyboard is only enabled while the keyboard
is hidden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/160>
This fixes a particular case of mutter#992.
Although gnome-shell will also be softened to not crash in future, it's
also a good idea for the extension to explicitly decide how it wants to
handle windows that are already on all workspaces.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/157>
GTK4 removes the generic GtkWidget API for accessing an inserted
action group, so we need an alternative for tracking the currently
selected theme.
Using the underlying GSettings object looks like the easiest option,
so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/148>
We follow the rule of not putting generated files under version
control, but that means drawing in additional build-time dependencies.
We can reduce those when building from a released tarball by
generating the stylesheets at dist time though, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/150>
I messed up and released 40.alpha at the same time as 3.38.2, when it's
supposed to be in January. In order to re-align with the schedule, change
the upcoming version to 40.alpha2 so we don't have to skip a release and
will be back on track in time of 40.beta.
If a user is in the middle of a drag in the window list and the
window list associated with the drag gets destroyed, the drag
monitor gets leaked.
Later when the drag motion is processed, spew goes to the log:
clutter_actor_contains: assertion 'CLUTTER_IS_ACTOR (self)' failed
Examples of triggers for this bug:
- The monitor topology changes
- The screen gets locked during the drag
This commit fixes the spew and the leak by ensuring any pending
drag monitoring is disabled when the window lists are destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/145>
only/except keywords where deperecated in favor of rules.
Since we started using GNOME/gnome-shell!1492 it introduced
a second pipeline being run for each commit.
Detached pipelines are the only way to access CI_MERGE_REQUEST_*
variables, and if we disable normal pipelines you will need to
create wip/spam MRs in order to run the tests.
This reworked rules makes it so, the normal pipeline needs manual
interaction to be started, and the detached/MR pipleines is always
run.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/144>
We modify gnome-shell's workspace tracker to only remove empty
workspaces from the end. However we currently don't take into
account that sticky windows appear on all workspaces, so those
are preventing any workspace from getting removed at the moment.
Exclude them when determining whether a workspace is empty to
get the expected behavior.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/135
The current code positions window previews explicitly using a fixed
layout manager. For that it relies on a valid parent allocation,
which is error-prone and frequently results in warnings.
Address this by moving the positioning code into a custom layout
manager, and only update the visibility from the window preview.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/260
The current code positions window previews explicitly using a fixed
layout manager. For that it relies on a valid parent allocation,
which is error-prone and frequently results in warnings.
Address this by moving the positioning code into a custom layout
manager, and only update the visibility from the window preview.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/260
Although window-list checks the 'skip-taskbar' property when a
window is added to the desktop to decide wether it should be
shown in the bar or not, it doesn't honor that when the property
is changed after a window has already been added. Since the new
WaylandClient API allows to change this property for already
mapped windows, supporting this is a good idea.
This patch fixes this.
Fix https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/130
Originally the classic session replaced `gnome-shell.desktop` with
`gnome-shell-classic.desktop` (to add the --mode=classic parameter)
and added `nautilus-classic.desktop` (to force on desktop icons).
Neither is the case anymore (and hasn't been for years): Nowadays the
only expected difference is the GNOME_SHELL_SESSION_MODE variable and
the DesktopNames field, which are both set from the session .desktop
file rather than the gnome-session session definition.
Any difference in the latter - like not starting the USBProtection
plugin and missing systemd user session support - are bugs. The
easiest way to avoid those in the future is by removing the obsolete
duplication that enables them, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/126
Since PanelMenu.Button started to inherit from St.Widget, the custom
_allocate() function isn't called anymore.
Simply changing the function to vfunc_allocate() doesn't work as other
changes happened in the meantime, so for now just remove it altogether.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/124
The current widget uses UI patterns that are reminiscent of GNOME 2.
It doesn't take a lot to make it look more modern: Simply giving the
radio group a distinct background and border allows us to move the
whole UI to the center, making the dialog more balanced and visually
pleasing.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/121
While we don't endorse or support 3rd party theming, the extension
exists and is actively used. However right now the most convenient
way of setting it up is by installing Tweak Tool; give users an
alternative by providing a simple settings dialog ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/117
The buttons currently appear more as an attachment to the label
than as distinct controls. Address that by:
- applying .button styling
- increasing spacing between label and button
- aligning buttons at the end
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/223
eslint requires a file/directory, and will fail when the parameter
is not specified. Unfortunately it only indicates the failure by
printing its help output, but not via its return value, so our test
still completes successfully.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/105
While window titles really really shouldn't contain newline characters,
they are under application control and therefore may very well do.
Force the corresponding labels to be single line, to prevent offending
applications from messing up the whole window list layout.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/202
When cycling through window sizes, we should skip any sizes that are
bigger than the available area. We do that, but the current code
assumes that the possible sizes are sorted, which is no longer the
case since the addition of "phone" sizes in commit 5b43d4733c.
As a result, we may now skip sizes that would fit perfectly fine.
Address this by filtering out invalid sizes beforehand instead of
assuming a certain order (wich no longer work due to the addition
of a portrait format).
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/97
While nautilus removed its desktop support a while ago in favor of an
extension, it's still possible that some external X11 desktop icon app
is used. As DESKTOP windows cannot be moved between workspaces or stacked,
and aren't perceived as regular windows, it doesn't make sense to show
them as previews in the workspace switcher.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/93
While nautilus removed its desktop support a while ago in favor of an
extension, it's still possible that some external X11 desktop icon app
is used. As DESKTOP windows cannot be moved between workspaces or stacked,
and aren't perceived as regular windows, it doesn't make sense to show
them as previews in the workspace switcher.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/93
Filtering errors by changed lines in a merge request means some
errors can slip through, for example when an import becomes unused
but isn't removed.
That's more common than rules changing behind our back, so revert
to running eslint directly again.
This reverts commit 119da3291b.
We mostly use the regular == and != comparison operators over their
type-safe === and !== counterparts. This is about to change, but there
are some places where we don't care whether a value is null, undefined
or 0; just check for falsiness there instead of using operators, so
we can start to consistently use the type-safe operators everywhere
else in a follow-up commit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Array destructuring has been supported by gjs/mozjs for quite some time,
so we are already using it heavily where it makes sense.
However one place still sneaked through where using destructuring makes
sense, as the element's position has semantic meaning (instead of just
making it the first, second, ... element).
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redundant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
eslint has a rule to prohibit unnecessary parentheses. While this is
generally a good idea stylistically, the parentheses in a calculation
of (a / b) * c add more clarity, as a / b * c lacks the unambiguity of
proper math notation:
a a
--- * c vs -------
b b * c
We can still follow the style rule by rearranging to the unambiguous
c * a / b.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Invoking functions via Function.prototype.apply() and .call() is
less performant than a regular function call, and makes code harder
to read.
Before ES6 there was no other way of writing a function with variadic
arguments, but since we now have the spread operator, we can use that
as the better alternative.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
This code has been commented out since it was added, presumably due to
difficulty in avoiding a cycle of reloading rows on settings changes
and writing settings on row changes.
Considering that the setting changing while the preference dialog is
up is extremely unlikely, don't bother with making it work and just
remove the dead code.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Since we dropped the legacy configuration, we run eslint directly
instead of via a script. However gnome-shell's variant of the script
also has special treatment of merge requests to only consider errors
in changed lines.
While we strive for zero errors, new errors can appear when we update
eslint or change the configuration. Not blocking merge requests due
to unrelated eslint errors is a good thing, run eslint through a
modified version of the gnome-shell script.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/90
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a virtual method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/84
Vertical workspaces are another defining characteristics of GNOME 3,
and thus rather un-classic. That switch was driven by the overall
layout of the overview, and now that we disable the overview in
GNOME Classic, we can just return to the traditional workspace
layout as well.
Add a small extension that does just that.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/72
Currently the new horizontal workspace switcher only shows a series of
buttons, with no indication of the workspaces' contents. Go full GNOME 2
and add tiny draggable preview rectangles that represent the windows
on a particular workspace.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/77
We are about to support a separate representation if horizontal
workspaces are used. To prepare for that, rename the handlers to
something more generic and split out menu-specific bits into a
dedicated helper function.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/71
Currently the new horizontal workspace switcher only shows a series of
buttons, with no indication of the workspaces' contents. Go full GNOME 2
and add tiny draggable preview rectangles that represent the windows
on a particular workspace.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/74
It makes some sense to allow using the workspace indicator for moving
windows between workspaces as well as for workspace switching. This
applies particularly in GNOME classic after we disabled the overview
there, so that there is again a non-shortcut way of moving windows
between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/74
Unlike in GNOME 2, the workspace indicator we display in the window list
isn't a workspace switcher, but a menu button that allows switching
workspaces via its menu. The reason for that is that a horizontal
in-place switcher would be at odds with the vertical workspace layout
used in GNOME 3.
However that reasoning doesn't apply when the layout is changed to a
horizontal one, so replace the button with a traditional workspace
switcher in that case.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/70
We are about to support a separate representation if horizontal
workspaces are used. To prepare for that, rename the handlers to
something more generic and split out menu-specific bits into a
dedicated helper function.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/70
We have an option to put a window list on each monitor, so we may have
more than one window picker toggle. We don't want each of those try to
toggle the window picker simultanuously, so move handling of the super
key directly into the picker.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/80
The overview is one of the defining features of GNOME 3, and thus
almost by definition at odds with the classic session, which
emulates a traditional GNOME 2 desktop.
Even with the less prominent placement inside the application menu
it never quite fit in - it doesn't help that besides the different
UI paradigma, the overview keeps its "normal" styling which differs
greatly with classic's normal mode.
So besides removing the "Activities" button via the session mode
definition, now that the apps-menu extension doesn't replace it anymore,
disable the overview completely in the classic session.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
Now that we no longer hide the overview when the menu is opened,
it is possible to activate menu entries from the overview. Start
hiding the overview in that case, which is consistent with app
launching elsewhere.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
We don't want the "Activities" button in GNOME Classic, but the current
way of handling it is confusing:
- the button is hidden, but the corresponding hot corner
sometimes works (when the application menu isn't open)
- the button is effectively moved inside the menu, although
it's clearly not an app or category
- the apps-menu can be used independent from classic mode, in
which case removing the "Activities" button may not be wanted
Address those points by removing any handling of the activities button
from the apps-menu extension. We will remove it again from the classic
session via a session mode tweak.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
The extension currently assumes that we have the "Activities" button
at the left of the top bar. This is currently true, not only in the
regular session, but also in GNOME classic where the button is hidden
(but still present).
However this is about to change: We will stop taking over the button
from the apps-menu extension, and instead disable "Activities" from
the session mode definition.
Prepare for this by adding the places menu before the application menu
instead of assuming a hardcoded position.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
PanelMenu.Button is a bit weird in that it also "contains" its parent
actor. That container is supposed to be destroyed with the button, but
as we currently don't chain up to the parent class' _onDestroy(), we
leave behind an empty container every time the extension is disabled.
Fix this by adding the missing chain-up.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/75
PopupMenuManager's grabHelper starting from gnome-shell@7bb84da must be
an actor, so pass it explicitly instead of expecting the shell to do it
for us.
This fixes an error during pushModal that was causing a grab not to be
released.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/68
gnome-shell moved to ES6 classes, which means the constructor is
no longer a regular method that we can swap out with an injected
version.
Instead, do our modifications in subclasses and use them to replace
the original classes.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/143
The coding style of using double quotes for translatable strings
and single quotes otherwise is unnecessarily complex and cannot
be enforced with an eslint rule.
Simply use single quotes consistently for all strings.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Instead of keeping the first property on the same line as the opening
brace and aligning the properties, use a four-space indent. This brings
us closer to gjs' coding style, and as a bonus helps keeping lines in
the soft 80 character limit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
We picked those up from Polari, which had those for
- object arrays:
let foo = [
{ bar: 42,
quz: true },
{ bar: 23,
quz: false }
];
- "enums":
let Options = {
ONE: 0,
TWO: 1,
THREE: 2
};
We don't have either of those, so drop the rules to minimise divergence
with gjs.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Commit messages should include the full URL to an issue or merge
request to keep associated information easily available in future
log digging.
Jonas came up with a script to enforce that policy for mutter and
gnome-shell. It's an excellent idea, so adopt it here as well.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/52
It doesn't make too much sense to declare parts of the existing style
"legacy", but then enforce it via CI. To allow for a gradual switch,
generate a report with all issues that eslint considers errors in both
configurations.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
More testing is always good, and the static analysis that eslint
provides goes well beyond what js60 offers, so run it as part of
the CI.
This will also ensure that new contributions comply with the style
rules we have set up.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
Unused variables or arguments can indicate bugs, but they can also
help document the code, in particular in case of signal handlers
and destructuring.
Account for this by keeping the error, but set up patterns that allow
us to opt out of if for individual variables/arguments. For arguments
we pick a '_' prefix, while for variables we go with a suffix instead,
to not accidentally exempt private module-scope variables.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
Regarding coding style, gjs is moving in a direction that departs quite
significantly from the established style, in particular when indenting
multi-line array/object literals or method arguments:
Currently we are keeping those elements aligned, while the gjs rules now
expect them to use the regular 4-space indentation.
There are certainly good arguments that can be made for that move - it's
much less prone to leading to overly-long lines, and matches popluar JS
styles elsewhere. But switching coding style implies large diffs which
interfere with git-blame and friends, so in order to allow for a more
gradual change, add a separate set of "legacy" rules that match more
closely the style we would expect up to now.
It also disables the rules for quotes and template strings - the former
because we cannot match the current style to use double-quotes for
translatable strings and single-quotes otherwise, the latter because
template strings are still relatively new, so we haven't adopted them
yet.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
That function will eventually be replaced with decorators, and we don't
want to re-indent all GObject classes when that happens, so allow class
declarations with no indent:
GObject.registerClass(
class Foo extends GObject.Object {
});
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
I simply cannot deal with multi-line trinary expressions where the
two "branches" don't align, so add an exception for them.
And while the strict 4-line indent for objects is growing on me for
"regular" objects:
let foo = new Foo({
bar: 42,
baz: 'bam'
});
I do prefer the current style of compact braces and aligned properties
for object lists:
let entries = [
{ name: 'foo',
visible: true },
{ name: 'bar',
halign: Gtk.Align.START }
];
So allow the latter style as well, at least for the time being.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
When using arrow functions, we only omit the braces when we are using
the return value:
this.get_children().filter(w => w.visible);
When braces are used, eslint by default enforces line breaks, but
there are cases where the expression is hardly less concise than
the above:
this.get_children().forEach(w => { w.destroy(); });
So change the default to allow this.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
All variables should be in camelCase, so configure the corresponding
rule to enforce this. Exempt properties for now, to accommodate the
existing practice of using C-style underscore names for construct
properties of introspected objects.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
gjs started to run eslint during its CI a while ago, so there is an
existing rules set we can use as a starting point for our own setup.
As we will adapt those rules to our code base, we don't want those
changes to make it harder to synchronize the copy with future gjs
changes, so include the rules from a separate file rather than using
the configuration directly.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
When destructuring multiple return values, we often use trailing commas
to indicate that there are additional elements that we are ignoring.
There isn't anything inherently wrong with that, but it's a style that's
too confusing for eslint - on the one hand we require a space after a
comma, on the other hand we require no space before closing brackets.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
String concatenation is considered bad style after ES6 added
template strings. The latter is the replacement we generally
want, except where the aforementioned xgettext bug would trip
over the backtick/slash combination.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
We currently use a consistent style of not adding spaces in catch
clauses, however that's inconsistent with the style we use for any
other statement. There's not really a good reason to stick with it,
so switch to the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
Since template strings were added in ES6, string concatenation is
considered bad style. There's a catch though: xgettext currently
has a nasty bug concerning the combination of backticks and slashes.
Avoid that issue by building filenames with the corresponding GLib
helper function.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
Now that PanelMenu.Button was made an StWidget subclass, the destroy()
method actually maps to the ClutterActor method, and overriding it
results in warnings when the extension is disabled. So instead, use
the existing ::destroy handler.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/113
Now that PanelMenu.Button was made an StWidget subclass, the destroy()
method actually maps to the ClutterActor method, and overriding it
results in warnings when the extension is disabled. So instead, use
the existing ::destroy handler.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/113
Now that PanelMenu.Button was made an StWidget subclass, the destroy()
method actually maps to the ClutterActor method, and overriding it
results in warnings when the extension is disabled. So instead, use
the existing ::destroy handler.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/113
Now that PanelMenu.Button was made an StWidget subclass, the destroy()
method actually maps to the ClutterActor method, and overriding it
results in warnings when the extension is disabled. So instead, use
the existing ::destroy handler.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/113
There are plenty of extension examples out there, no need to include
a sample extension that doesn't show-case any useful functionality
but puts additional burden on distributors to exclude it from packaged
extensions.
Ever since GNOME 3.8 when gnome-shell started to provide the window
switcher functionality itself, the extension has only existed to
change the default behavior of the alt-tab shortcut in the classic
session. Now that we achieve this behavior with a per-desktop override,
there's no longer a need for the extension, so remove it altogether.
Users who prefer the window switcher over the default app switcher
can use the regular keyboard settings to assign a shortcut to the
"Switch windows" action.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
Window lists are per-monitor, so workspaces are implemented by
simply hiding all buttons that correspond to windows/apps on
other workspaces. That means we need to take the visibility
into account when handling scroll-events to switch through the
list, or else we'll end up switching "randomly" between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/78
Per-desktop overrides aren't limited to keys in org.gnome.mutter, so
we can use them instead of the alternate-tab extension to default to
the window switcher in the classic session.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
GSettings now recognizes per-desktop overrides that can be used
to change schemas' default values for classic mode, so use that
instead of the separate override schema we currently use with
mutter's custom override mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
As of the libmutter API version 3 MetaScreen does no longer exist.
Functionality that previously depended on MetaScreen has been moved
elsewhere (e.g. MetaDisplay or MetaWorkspaceManager etc).
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This is a relatively recent addition to the standard we can use where we
don't care about the actual position of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
We can only know about override settings that are provided by the
upstream GNOME or GNOME Classic sessions, but not any custom sessions
created by admins, users or distributions. Handle that case by falling
back to the original settings.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/62
All we are really interested in is mozjs' js52 utility for running
syntax checks - gjs has significantly more dependencies, so cut
down on time and bandwidth spent on downloading and installing
unneeded packages.
This cuts down the number of packages we install from 202 to 13,
and the download size from 133M to 17M.
Meson has a strict separation of source- and build directory, and
expects anything generated in the latter. That means that in order
to maintain our current setup - shipping the generated CSS in the
repo while also optionally updating it automatically when sassc is
found - we have to fight the build system to some extent, which makes
it less reliable than we would like.
Since we switched to sassc which is a more acceptable build-time
dependency than the original ruby-based tool, just drop the CSS
from the repo and unconditionally generate it from SASS if classic
mode is enabled.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/28
Most buttons appear in modal dialogs which keep their normal
appearance in the classic theme, except for the calendar's
"Clear All" which needs a dark text color to be readable on
the light background.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/26
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.
The description of the `enable_extensions` was wrong since it
changed to the `array` type, because the extension separator
is now a comma instead of space.
meson 0.44 features a new option type called `array` that allows
more than one string to be passed.
This feature fits perfectly the `enable_extensions` option needs,
so it has been changed to be an `array` type. the option has not
been limited to a set of choices to avoid duplication.
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
Continuous integration is good, in particular when used before
merging a change to master as allowed by gitlab. And now that
we enabled some basic syntax checking of source files, we even
have something useful to test for ...
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/32
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
We currently do have some Makefile magic to export zip files suitable
for uploading to extensions.gnome.org. As this is not easily replicated
in meson, add a small non-magic script for the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/31
Over the years the list of extensions has become seriously outdated - a
number of extensions has long been removed, while others have been added.
With the switch to gitlab, the README is displayed prominently, so make
sure the list is accurate again.
"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
GTK+ switched from ruby-based sass to c-based sassc for performance
reasons. It makes sense to follow suit, if not to not require two
tools for the same job ...
https://bugzilla.gnome.org/show_bug.cgi?id=783210
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
The application can already be launched from the menu without further
confirmation from the user, so there is no security gain in asking the
user to trust it when launched from the desktop - just set the appropriate
attributes of the newly copied file to mark it as trusted to nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=781596
Someone mixed up add() and add_actor() - this has been present since the
the big rewrite based on the AxeMenu extension in commit 9211fa4409, so
there's little point in coming up with a replacement for something that
never had any effect to begin with ...
It's not very useful to allow dragging when there's no drop target,
so tie the functionality added in the previous commit to the presence
of a DESKTOP window.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
Back in the olden days, it used to be possible to drag items from
the application menu to the desktop to create a launcher shortcut.
Reimplement that "classic" functionality in the apps menu extension.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
The use of Array to keep track of inserted items is extremely
confusing, as no elements are ever added to the array. What
the code actually does is monkey-patching properties into an
empty object (that happens to be of type "Array"). While the
direct idiomatic replacement would be {}, update the code to
use a proper map instead.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
There's no need to show the workspace indicator at the right
corner of the window-list if there's just a single workspace
AND the workspace creation is static. This saves us a bit more
of space.
https://bugzilla.gnome.org/show_bug.cgi?id=777504
The original extension author really hated the app switcher with a
passion and took over all its uses, but there's really no reason
to replace the 'switch-group' shortcuts - not least because the
window switcher doesn't implement switching between windows of
a single application. So just keep the extension to making the
'switch-application' shortcuts behave as 'switch-windows' for the
"classic" session (and all users who rather install an extension
than change shortcut settings).
https://bugzilla.gnome.org/show_bug.cgi?id=771531
We currently assume that the application associated with a particular
window is fixed. While this holds true for almost every application,
there are some cases of multi-app-packages like LibreOffice where
windows may change the properties used for application matching at
runtime. Catch those cases to make sure we display the correct icon
when the window shifts applications.
https://bugzilla.gnome.org/show_bug.cgi?id=771731
.desktop files in non-standard locations are not handled by GIO,
so looking up apps for entries for such locations (e.g. a
directory added via the AppsDir directive) will fail. We can
still handle this case in the menu by creating the app directly
from the entry's AppInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=762206
The code de-duplication in commit bf8d30603e57b broke the extension,
fix by duplicating the code here now :-(
(It's not really that bad though ...)
https://bugzilla.gnome.org/show_bug.cgi?id=767077
The new logical dimensions are reported in the overlay, rather than the
pixel dimensions. That is: if scaleFactor is 2, a window might be
resized to 2400×1350 device pixels, which will be reported as 1200×675
in the overlay.
This is consistent with (for example) the DevTools in Chrome, which
reports the logical size of the viewport when you resize the window,
rather than the physical pixel size.
Tested with a freely-resizable window and with a constrained-geometry
window (GNOME Terminal), on a hidpi display.
https://bugzilla.gnome.org/show_bug.cgi?id=754607
2016-01-08 14:09:48 +00:00
222 changed files with 24584 additions and 21648 deletions
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and an idea of what it does. Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
[This is the first released version of the library GPL. It is numbered 2 because it goes with version 2 of the ordinary GPL.]
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
This license, the Library General Public License, applies to some specially designated Free Software Foundation software, and to any other libraries whose authors decide to use it. You can use it for your libraries, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library, or if you modify it.
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
Our method of protecting your rights has two steps: (1) copyright the library, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the library.
Also, for each distributor's protection, we want to make certain that everyone understands that there is no warranty for this free library. If the library is modified by someone else and passed on, we want its recipients to know that what they have is not the original version, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that companies distributing free software will individually obtain patent licenses, thus in effect transforming the program into proprietary software. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License, which was designed for utility programs. This license, the GNU Library General Public License, applies to certain designated libraries. This license is quite different from the ordinary one; be sure to read it in full, and don't assume that anything in it is the same as in the ordinary license.
The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such.
Because of this blurred distinction, using the ordinary General Public License for libraries did not effectively promote software sharing, because most developers did not use the libraries. We concluded that weaker conditions might promote sharing better.
However, unrestricted linking of non-free programs would deprive the users of those programs of all benefit from the free status of the libraries themselves. This Library General Public License is intended to permit developers of non-free programs to use free libraries, while preserving your freedom as a user of such programs to change the free libraries that are incorporated in them. (We have not seen how to achieve this as regards changes in header files, but we have achieved it as regards changes in the actual functions of the Library.) The hope is that this will lead to faster development of free libraries.
The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library.
Note that it is possible for a library to be covered by the ordinary General Public License rather than by this special one.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Library General Public License (also called "this License"). Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
c) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
d) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
13. The Free Software Foundation may publish revised and/or new versions of the Library General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the library's name and an idea of what it does.
Copyright (C) year name of author
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details.
You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in
the library `Frob' (a library for tweaking knobs) written
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
GNOME Shell Extensions is a collection of extensions providing additional
and optional functionality to GNOME Shell.
Since GNOME Shell is not API stable, extensions work only against a very
specific version of the shell, usually the same as this package (see
"configure --version"). The extensions in this package are supported by GNOME
and will be updated to reflect future API changes in GNOME Shell.
The GNOME wiki has more information about [GNOME Shell Extensions][project-page],
as well as some general information about [GNOME Shell][shell-page].
Bugs should be reported to the GNOME [bug tracking system][bug-tracker].
## Extensions
* alternate-tab (**OBSOLETE**)
Lets you use classic Alt+Tab (window-based instead of app-based) in GNOME Shell.
This extension is obsolete since GNOME 3.30, see [this blogpost][alternatetab-post]
for further details.
* apps-menu
Lets you reach an application using gnome 2.x style menu on the panel.
* auto-move-windows
Lets you manage your workspaces more easily, assigning a specific workspace to
each application as soon as it creates a window, in a manner configurable with a
GSettings key.
* drive-menu
Shows a status menu for rapid unmount and power off of external storage devices
(i.e. pendrives)
* launch-new-instance
Changes application icons to always launch a new instance when activated.
* native-window-placement
An alternative algorithm for layouting the thumbnails in the windows overview, that
more closely reflects the actual positions and sizes.
* places-menu
Shows a status Indicator for navigating to Places.
* screenshot-window-sizer
Adds a shortcut for resizing the focus window to a size that is suitable for GNOME Software screenshots. Ctrl + Alt + s cycles forwards through the available sizes and Ctrl + Alt + Shift + s cycles backwards.
* user-theme
Loads a shell theme from ~/.themes/<name>/gnome-shell.
* window-list
Adds a bottom panel with a traditional window list.
* windowsNavigator
Allow keyboard selection of windows and workspaces in overlay mode.
* workspace-indicator
Adds a simple workspace switcher to the top bar.
## Default branch
The default development branch is `main`. If you still have a local
"description":"Substitute Alt-Tab with a window based switcher that does not group by application.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME Bugzilla instead.",
"description":"Add a category-based menu for applications.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME Bugzilla instead.",
"name":"Apps Menu",
"description":"Add a category-based menu for apps.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME's GitLab instance instead.",
"description":"Always launch a new instance when clicking in the dash or the application view.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME Bugzilla instead.",
"description":"Always launch a new instance when clicking in the dash or the application view.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME's GitLab instance instead.",
// testing settings for natural window placement strategy:
constWINDOW_PLACEMENT_NATURAL_FILLGAPS=true;// enlarge windows at the end to fill gaps // not implemented yet
constWINDOW_PLACEMENT_NATURAL_GRID_FALLBACK=true;// fallback to grid mode if all windows have the same size and positions. // not implemented yet
constWINDOW_PLACEMENT_NATURAL_ACCURACY=20;// accuracy of window translate moves (KDE-default: 20)
constWINDOW_PLACEMENT_NATURAL_GAPS=5;// half of the minimum gap between windows
constWINDOW_PLACEMENT_NATURAL_MAX_TRANSLATIONS=5000;// safety limit for preventing endless loop if something is wrong in the algorithm
constPLACE_WINDOW_CAPTIONS_ON_TOP=true;// place window titles in overview on top of windows with overlap parameter
constWORKSPACE_BORDER_GAP=10;// minimum gap between the workspace area and the workspace selector
constWINDOW_AREA_TOP_GAP=20;// minimum gap between the workspace area and the top border. This keeps window captions and close buttons visible. 13px (26/2) should currently be enough.
* Returns clones with matching target coordinates and scales to arrange windows in a natural way that no overlap exists and relative window size is preserved.
* This function is almost a 1:1 copy of the function
* PresentWindowsEffect::calculateWindowTransformationsNatural() from KDE, see:
"description":"Add a menu for quickly navigating places in the system.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME Bugzilla instead.",
"description":"Add a menu for quickly navigating places in the system.\nThis extension is part of Classic Mode and is officially supported by GNOME. Please do not report bugs using the form below, use GNOME's GitLab instance instead.",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.