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)
The name is a bit cleaner, and has been the preferred option(!)
since meson 1.1.
Mutter recently updated the name, so follow suite.
The meson version bump shouldn't be an issue, given that several
hard dependencies like mutter and glib already require higher
versions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/349>
(cherry picked from commit 1088435120)
A long time ago, the window list used to embed the bottom message
tray, which caused notifications to inherit the window-list's
font style.
Since that's no longer the case, we have no business in messing
with notification styling, so stop doing that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/338>
(cherry picked from commit f1671bc206)
The only intended difference from the regular session is that the
date menu moves to the right. However in the meantime, gnome-shell
added a couple more (usually hidden) indicators, but we never
updated the session mode definition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/339>
(cherry picked from commit 81aade6659)
For the window-list extension, it is important that the workspace
previews extend to the bottom edge for easier click targets.
That broke while merging the code with the workspace-indicator,
fix it again by moving the padding from the parent box into the
thumbnail children.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/327>
Buttons are currently added and removed from the list without
any transitions, which gives the list a "jumpy" feel. Instead,
do what we do elsewhere and smoothly animate additions and
removals by re-using the dash's ItemContainer class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/325>
We want all buttons in the window list to have the same size,
but that's already achieved via max/natural-width in the CSS.
Not enforcing the equal size via the layout manager will allow
buttons to temporarily have a different size when we start
animating additions and removals.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/325>
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>
Since the regular session also switched to horizontal workspaces,
using a vertical menu has been a bit awkward.
Now that our previews have become more flexible, we can use them
in the collapsed state as well as when embedded into the top bar.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/316>
Both the regular session and GNOME classic use a horizontal layout
nowadays, so it doesn't seem worth to specifically handle vertical
layouts anymore.
The extension will still work when the layout is changed (by some
other extension), there will simply be a mismatch between horizontal
previews and the actual layout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/316>
The space in the top bar is too limited to include the workspace
names. However we'll soon replace the textual menu with a preview
popover. We can use bigger previews there, so we can include the
names to not lose functionality with regards to the current menu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/316>
We currently avoid previews from overflowing in most setups by
artificially limiting them to a maximum of six workspaces.
Add some proper handling to also cover cases where space is more
limited, and to allow removing the restriction in the future.
For that, wrap the previews in an auto-scrolling scroll view
and add overflow indicators on each side.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/316>
We are now at a point where the code from the workspace-indicator
extension is usable from the window-list.
However instead of updating the copy, go one step further and
remove it altogether, and copy the required files at build time.
This ensures that future changes are picked up by both extensions
without duplicating any work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
The two extensions currently use a slightly different label
in menu mode:
The workspace indicator uses the plain workspace number ("2"),
while the window list includes the number of workspaces ("2 / 4").
The additional information seem useful, as well as the slightly
bigger click/touch target, so copy the window-list behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
Currently the same method is used to get the label text for the
indicator itself and for the menu items.
A method that behaves significantly different depending on whether
a parameter is passed is confusing, so only deal with the indicator
label and directly use the mutter API to get the workspace names
for menu items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
The indicator is located in the top bar, so tooltips are always
shown below the previews. However supporting showing tooltips
above previews when space permits allows the same code to be
used in the copy that is included with the window-list extension.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
In order to use a PanelMenu.Button in the bottom bar, we have
to tweak its menu a bit.
We currently handle this inside the indicator, but that means the
code diverges from the original code in the workspace-indicator
extension.
Avoid this by using a small subclass that handles the adjustments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
Apply the changes from the last commit to the workspace-indicator
copy, and override the base style class from the extension.
This will eventually allow us to share the exact same code between
the two extensions, but still use individual styling if necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
Shortly after the window-list extension was added, it gained a
workspace switcher based on the workspace indicator extension.
Duplicating the code wasn't a big issue while the switcher was
a simple menu, but since it gained previews with a fair bit of
custom styling, syncing changes between the two extensions has
become tedious, in particular as the two copies have slightly
diverged over time.
In order to allow the two copies to converge again, the indicator
code needs to be separate from the extension boilerplate, so
split out the code into a separate module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/307>
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
GMenu's TreeEntries return an AppInfo that is created from the
.desktop filename, not from a desktop ID as expected by the
AppSystem. As a result, g_app_info_get_id() will simply return
the file's basename, which only matches the desktop ID if no
prefix-to-subdirectory mapping as described in the menu spec
is involved.
Fix this by basing the app lookup on the entry's desktop ID instead
of the AppInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=759004
Category items grab the pointer to implement "triangle navigation", which
interferes with automatic hover tracking in other widgets. While this is
the correct behavior while we hold the grab (i.e. when crossing other
category items without switching), it can interfere with user expectation
when the grab is dropped, as the motion event that causes us to do so
doesn't necessarily occur before the "target"'s enter event - address this
by syncing up the hover state manually after dropping the grab.
https://bugzilla.gnome.org/show_bug.cgi?id=754959
Independent from the grouping mode, the window-list currently shows
up as a series of "push buttons" in screen readers, which is obviously
not useful, so point to the correct labels.
https://bugzilla.gnome.org/show_bug.cgi?id=755223
The user explicitly enabling desktop icons is a pretty good hint
that she intends to use the Desktop folder, so be consistent with
GTK+ and nautilus and include it when the corresponding setting
is true.
https://bugzilla.gnome.org/show_bug.cgi?id=754578
The indicator numbers workspaces starting from 1, while newly added
workspace names in the preference dialog start counting at 0.
Change the latter to be consistent with the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=753105
It is odd to consider windows that are not shown in the window list
for app sorting, in particular when switching between grouped and
ungrouped mode, and when a long-lived window like the DESKTOP is
present.
https://bugzilla.gnome.org/show_bug.cgi?id=753055
Just like the top bar, the window list should scale according to
the font scaling factor, so convert the existing pixel sizes into
font-relative ones.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window list position depends on both the monitor geometry and the
list height, however changes to the latter are currently ignored. For
the time being this doesn't matter due to the list's fixed height, but
we are about to scale the list with the text, so reposition the list
on height changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window-list's fixed height currently allows us to get away without
expanding buttons, however this won't be the case anymore once we start
adapting the list with the text scaling. So fix up the code to do what
was always the intention anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The function never had a timestamp parameter, the parameter that was
added at some point is a workspace index. Ouch, this has gone unspotted
since the original AxeMenu extension was adapted for the apps-menu ...
For a while now, gnome-shell has initialized extensions before
setting up its own keybinding handling. As a result, our taking
over of the panel-main-menu shortcut will be overwritten when
the extension is enabled at startup - work around this by setting
up the keybinding again on LayoutManager::startup-complete.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
Setting up signal handlers inside a class and rely on outside code
to disconnect them via global variables is utterly weird. Just
disconnect everything inside the class when the corresponding actor
is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
By default, PanelMenu.Button creates a popup menu with arrow side TOP
which is wrong in our case and can mess up BoxPointer's positioning.
We can work around that easily by creating the menu ourselves with the
correct arrow side.
https://bugzilla.gnome.org/show_bug.cgi?id=746365
Menus in the top bar have some margin at the bottom, to prevent
menus to extend all the way to the bottom edge as the expand; we
obviously don't want the same behavior in the window-list at the
bottom, so stop pretending to be a top bar menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745952
The systemMonitor extension extends the message tray with its UI, which
obviously broke when the bottom tray was removed. It has also been the
source for various performance/memory issues in the past and is part of
the semi-random collection that pre-dates the extension.gnome.org site
rather than the set of classic-mode/endorsed extensions, so just remove
it from the module.
Hopefully this will motivate someone who actually cares about it to pick
it up ...
https://bugzilla.gnome.org/show_bug.cgi?id=745195
Commit 2667b9f3e5 updated the extension for a shell change that
renamed _onActivate() to _activate, but forgot to also rename the
declaration of the variable that stores the original function.
Fix this to stop a warning about assignment to an undefined variable.
https://bugzilla.gnome.org/show_bug.cgi?id=745470
The point of that code is to keep the window-list underneath
modals' lightboxes if possible (i.e. unless the OSK is shown).
The trayBox was a natural pick back in the day, but the panel
will do just as well ...
https://bugzilla.gnome.org/show_bug.cgi?id=745304
MetaWindow.title might be NULL, particularly for Wayland clients where
setting the title is a request separate from window creation. We
shouldn't try to set StLabel's text prop in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=745064
While rare, it is possible to have a window not associated with any app
(not even a fake window-based one). We currently throw an error when
trying to set the icon for such a window, so handle this case and
use a fallback icon instead of the app icon.
https://bugzilla.gnome.org/show_bug.cgi?id=743401
Notification banners are now displayed at the top, and the summary
moved into the date and time drop down - the bottom is ours now,
no more special sauce needed to interact with it gracefully.
The sass sources now live in a project in GNOME, so they can
be used in multiple projects like gnome-shell-extensions.
Because of that, add gnome-shell-sass as a submodule and import the sass
sources from it.
Currently the window-list will be stacked above system modal dialogs,
which means it is not dimmed like the rest of the desktop and remains
accessible to interaction. We cannot do any better when showing the
on-screen keyboard, as we need to keep ourselves above to not end up
covered by the OSK, and the keyboard itself is stacked above modal
dialogs to allow its use for input. However we can at least fix the
case when not using the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=740722
Classic mode uses a different overrides schema, so make sure we use the
correct setting instead of hardcoding the usual org.gnome.shell.overrides
schema.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
A new setting "show-on-all-monitors" (false by default) is available to
show window lists on all connected monitors.
The Extension object monitors conditions that require the list of
windows to be rebuilt. The WindowList and Button classes have a new
"perMonitor" property that indicates they should handle windows on
their own monitor only.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
BaseButton is a new class that shares the common logic of WindowButton
and AppButton. AppButton is passed to AppContextMenu so that it can reuse
code from the now public getWindowList() method.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
The classic style is decidedly lower contrast than the default
style, so the high-contrast variant could prove really useful
here. However for now, just override the default icon style as
in the default session.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
setThemeStylesheet() stopped accepting %null to revert to the default
stylesheet. The issue is fixed in gnome-shell master, but work around
it for 3.15.2 to not ship broken (again).
Move messageTray patching form the Extension object to the WindowList
class. Moreover, only do the patching if the window list is on the bottom
monitor. This refactoring will make it easier to have several instances
of WindowList (one on each monitor).
https://bugzilla.gnome.org/show_bug.cgi?id=737486
Currently when using auto-grouping, the list is ungrouped each
time a window is closed, and then possibly re-grouped on the next
allocation - as a result, there is a brief "ungroup flash" if the
list is supposed to remain grouped.
Avoid this by computing the width the ungrouped list would have
rather than by actually ungrouping it.
https://bugzilla.gnome.org/show_bug.cgi?id=738286
Since commit 191c7ccc24, we check whether we already have a window
in the list before re-adding it on MetaWorkspace::window-added.
We can do something similar on MetaWorkspace::window-removed to
avoid some extra work when a window is moved between workspaces
rather than destroyed.
The list returned may contain windows that are being destroyed.
The ShellGlobal method filters those out, so use that instead; we
should eventually stop looking at window actors when we want windows,
but for now this is the easy and safe thing to do.
Rather than re-implementing the function (and risk missing improvements
like the launch animation), call the original one as if the user had
middle-clicked the launcher.
We do need to inject our own handler to treat application-switch
actions the same way as the corresponding window-switch ones;
we can actually express exactly this without re-implementing the
entire function, by calling the original handler with a tweaked
action parameter - the resulting code is not only more concise,
but should also be a bit more robust against changes in core.
https://bugzilla.gnome.org/show_bug.cgi?id=737457
Since shell commit dd85670f8b25, the handler got a return value to
determine whether Escape should be handled automatically; we do
want this for the window switcher, so add an appropriate return
value to restore the expected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737457
When a window's on-all-workspaces property changes to true, the
workspaces the window was not located on will emit the ::window-added
signal for the window; however we don't want multiple buttons for
the same window, so filter out the extra calls.
https://bugzilla.gnome.org/show_bug.cgi?id=736398
The workspace button used to extend to the bottom edge, which of
course is A Good Thing (tm) - commit ec8f269107 broke this when
it added an additional container to the hierarchy, expand the
button again to bring back the old mouse-friendly behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=708247
The defaults have been shifted around so that the normal session
uses the regular schema and classic mode overrides it, so the
key is no longer present in 'org.gnome.shell.overrides'.
- make tree view scrollable when list grows large
- add some borders
- use symbolic icons instead of (deprecated) stock items
- adjust spacing/alignment
- disable remove button when no item is selected
https://bugzilla.gnome.org/show_bug.cgi?id=730843
- make tree view scrollable when list grows large
- add some borders
- use symbolic icons instead of (deprecated) stock items
- adjust spacing/alignment
- disable remove button when no item is selected
https://bugzilla.gnome.org/show_bug.cgi?id=730843
The default in gsettings-desktop-schemas has changed to not include
minimize and maximize to match the default of client-side decorations
in GTK+, so start overriding the setting to bring them back in classic
mode.
Currently the initial set of buttons is in stack/MRU order. To
avoid shuffling around the list each time it is disabled/re-enabled
(lock screen) or the group-mode settings changes, sort it by the
stable sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=719933
The 'launching' signal and this._onActivateOverride callback were
removed from gnome-shell in 7ecb5af587af7ed892c6cfc5af0858a2acb04905
and 7ecb5af587af7ed892c6cfc5af0858a2acb04905 respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=721864
MetaWindowActor.get_workspace() was removed, however the now used
MetaWindow.get_workspace() returns a MetaWorkspace rather than an
index, so can't be used directly.
https://bugzilla.gnome.org/show_bug.cgi?id=728820
The message tray is moved to the bottom-most monitor when there are
monitors below the primary monitor; in that case, we need to leave
the tray alone.
https://bugzilla.gnome.org/show_bug.cgi?id=728288
This is something that gnome-panel supported, and apparently
some users would like to have it back, so restore this feature
on our window list too.
https://bugzilla.gnome.org/show_bug.cgi?id=723693
PopupBaseMenu provides a destroy() method that will destroy the menu
actor and make sure that the menu will be removed from the corresponding
PopupMenuManager (if any). We miss the latter when we destroy the menu
actor directly, so use the menu method instead.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
Depending on the number of windows, AppButtons use different right-click
menus ("Minimize" vs. "Minimize all").
As the menu for the multiple-windows case remains the same, it is created
and added just once. However this means that in the single-window case,
the corresponding PopupMenuManager will track two menus for the same
source actor, resulting in various misbehaviors.
Fix these issues by adding and removing the app context menu appropriately,
so that the PopupMenuManager tracks a single menu at any time.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
StButton takes the hover state into account to decide whether a
series of events should be considered a click. So when dismissing
a menu by clicking on a different window/app button, its menu
cannot be triggered before leaving and re-entering the button
(and thus syncing the hover state).
Fix this by always syncing the hover state after a grab is dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
Applications now track all their windows, not just the ones that are
expected to show up in the window list. So to restore the previous
behavior, we now have to filter out windows with the skip-taskbar
hint ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=724134
While the list of windows in the left-click menu is filtered by
workspace, the minimize/maximize/close actions in the right-click
menu apply to all application windows on all workspaces.
This is fairly confusing, so restrict the actions to only apply
to windows that do appear in the left-click list.
https://bugzilla.gnome.org/show_bug.cgi?id=724134
Animate showing and hiding the window list when toggling the
overview (with a translation on and off the screen). Don't actually
change the visible status of the actor, because we don't want
to change struts.
In case of shadowed mounts, mounts can become uninteresting
after they are added, according to whether our handler or gvfs
runs first, so we need to watch for changes. The easiest way
is to create an item for all mounts, and only show the interesting
ones.
Default _ is gettext from gnome-shell domain, which doesn't have
the strings we need.
We could use mutter's, but translators already did their job
on pretty much all supported languages, so...
Currently, we start gnome-shell in classic mode by passing
--mode=classic to the gnome-shell command line. This --mode=classic
gets stripped away when the session is saved, which breaks classic
mode on subsequent login attempts.
This commit changes the session file to set the
GNOME_SHELL_SESSION_MODE environment variable instead.
https://bugzilla.gnome.org/show_bug.cgi?id=720894
Shadow mounts are created by the GVolume infrastructure to wrap
daemon mounts managed by volume monitors, and are an implementation
detail that should not be exposed to the user.
gnome-panel's window list had context menus on buttons, that gave
easy access to common operations like close, minimize and maximize.
Add something similar to the window-list.
https://bugzilla.gnome.org/show_bug.cgi?id=699251
addActor() gone from PopupBaseMenuItem, arrows in menus,
SystemStatusButton gone.
The auto-move-windows cleanup is probably older, weird noone
noticed before.
Anyway, I need a pitch fork.
This can't work without a significant rework (because we can't
use GnomeRR in the mutter process, now that's DBus API implemented
by mutter itself, and the monitor config API is private to mutter
for now), and I doubt it's really useful to anyone.
Also, we have an orientation lock button, which kind of serves
a similar purpose
As part of the new unified status menu, the old status menu
was reworked considerably in 3.9.5, and the extension as it
was written does not make sense.
If hibernation is needed, it should be added (through another
extension) in the shutdown dialog.
This reverts commit e71d48853d.
The Assamese PO file does not exist in the repository. It should be
committed before modifying the LINGUAS file, to avoid breaking the
build.
Just like we look in XDG_DATA_DIRS, we should honor XDG_DATA_HOME
as well.
For compatibility reasons, we look in ~/.themes first, then ~/.local/share,
then /usr/share.
* remove unnecessary chromeHeight that breaks the system
* copy original _updateWindowPositions from 3.9
* use nativeWindowPlacement in update function
* tidy up NaturalWindowPlacement function
https://bugzilla.gnome.org/show_bug.cgi?id=699054
* use original realPositionWindows() and map _computeAllWindowSlots() to our function (_calculateWindowTransformationsNatural()).
* adapted _calculateWindowTransformationsNatural() to _computeAllWindowSlots()' behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=699054
Some default values differ between classic and normal sessions. We
used to implement this by overriding the shell's default values in
mini-extensions (or more precisely: reversing the shell's overrides).
Use a mode-specific overridesSchema instead, which has the advantage
that settings defaults will not change unexpectedly when extensions
are disabled/enabled (for instance during screen locks).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
When the number of workspaces changes, we clear the existing menu
and recreate it based on the screen::n-workspaces property, so it
is slightly more correct to track changes to the property directly
instead of using the workspace-added/workspace-removed signals.
This change also fixes a corner case, where changes to the property
before workspaces are initialized are missed and we end up with the
wrong number of workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=699350
In addition to "always" and "never", gnome-panel supported an "auto"
grouping mode, which only started to group items when running out of
available space. It makes sense for us to support the same option in
the window-list extension, so implement it.
https://bugzilla.gnome.org/show_bug.cgi?id=697157
-st-natural-width is useful to request a larger-than-usual width,
add back the max-width removed in commit 702cf52cfc to also request
a smaller-than-usual width as necessary.
Items in the window list should take up a fixed amount of space
unless the list is full and items need to shrink. To achieve this,
replace the max-width with the newly added -st-natural-width.
https://bugzilla.gnome.org/show_bug.cgi?id=695392
This is the most basic version of a workspace switcher, taken from
Frippery Bottom Panel and adapted. It handles clicks and scrolls,
and does not show window thumbnails or shapes.
Note that, differently from the frippery version, it won't change
the workspace layout, and actually assume a linear vertical layout,
which is then shown horizontally. This is to keep compatibility
with the overview, which uses a vertical layout.
https://bugzilla.gnome.org/show_bug.cgi?id=694914
PanelMenu.Button listens to key-press-events on the corresponding
menu to move focus to neighboring buttons on left/right arrow. In
order to allow keynav from the category list on the left to the
application list on the right and vice-versa, we may need to suppress
the parent behavior depending on the currently focused actor, so
overwrite the signal handler accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=693074
When setting GtkRadioButton's group property, its active property is
also set as a by-product. This means that setting these properties
isn't commutative which arguably is a bug in gtk+ but one that we can
easily work around by just switching the order here.
https://bugzilla.gnome.org/show_bug.cgi?id=697495
When grouping is enabled, items that are only have a single window
associated are still expected to behave like ungrouped items.
This includes activating windows by DND, which uses the metaWindow
property on the hovered actor's _delegate, so make sure it is set
on AppButtons in single-window mode as well.
https://bugzilla.gnome.org/show_bug.cgi?id=693561
Implement a keep-up triangle to keep submenus from changing if the
pointer strays a bit when mousing towards the application list on the
right. The keep-up triangle is only used if the mouse movement is more
horizontal than vertical.
This is similar to the behaviour of GtkMenu, but much more simple
because we are only dealing one specific kind of menu, and hence don't
need to be as generic.
https://bugzilla.gnome.org/show_bug.cgi?id=692913
LayoutManager will take care of our visibility, but we need to
adjust the message tray anchor point manually. Also, we must not
show ourselves when coming out of the overview if we're in fullscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=696929
After recent overview changes, we may end up with the message tray
showing partially in the overview when the window-list extension
is enabled. Adjusting the anchor explicitly when entering/leaving
the overview fixes the issue, requiring less code.
https://bugzilla.gnome.org/show_bug.cgi?id=695390
We switched from using the window icon to using the associated
application's icon; however when we create the window list item
from a handler to the 'window-added' signal, the association of
window and application might not exist yet, as WindowTracker uses
the same signal to create the association. Use connect_after()
for creating the window list item to make sure that WindowTracker's
signal handler has run already.
https://bugzilla.gnome.org/show_bug.cgi?id=695389
Directories that are not immediate children of the root should be merged
in the parent, to preserve the flat structure and to be consistent with
the Activities overview.
https://bugzilla.gnome.org/show_bug.cgi?id=693241
We currently use the application icon for items that are grouped
by application and the window icon otherwise. However with the
icon property being unused anywhere else in GNOME3, applications
have started to not set any window icon at all.
Rather than complaining to application authors, switch to using
the app icon everywhere, which improves consistency with the rest
of GNOME3 anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=694850
We use a logind inhibitor now, so we don't need to lock the screen before
calling logind. Also, the UPower path was removed, and suspension is not
available for ConsoleKit.
Sorry, Ubuntu users!
PopupMenu.PopupBaseMenuItem uses the natural width of its children to
set its own minimum and natural widths. We don't want that because
some of our children can be too wide. So, we override it.
We also set the span and expand parameters of the label to -1 and true
respectively. Otherwise we won't get to see the "...".
https://bugzilla.gnome.org/show_bug.cgi?id=693282
Currently we ended up ignore 'network' volumes that did not have a
mount associated with it. Instead we should behave like Nautilus and
still show them.
https://bugzilla.gnome.org/show_bug.cgi?id=693437
The empty array is created and inserted into the hashtable before
every call to _loadCategory. No need to check for it and create it
again inside the function.
Don't mix up negated if conditions with continue while skipping stuff
that should not be displayed. Follow one style for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=693346
Classic mode should be visually distinct from the normal session,
so provide a mode-specific stylesheet which looks closer to the
familiar GNOME2 default theme.
https://bugzilla.gnome.org/show_bug.cgi?id=693169
Update to the new way to layout window overlays, which requires
setting a slot on the clone, and update to the new padding setting
for the window picker, including a custom style to avoid placing titles
outside the clip area.
This is a severely toned down version of the original AxeMenu:
- the column on the left has been removed, because it duplicates
functionality provided by the places-menu and the user menu
- the application search functionality has been removed because it
is already provided by vanilla gnome-shell
- the "All" category ended up being too crowded and has been replaced
by "Favorites", so there is no separate page for it any more
https://bugzilla.gnome.org/show_bug.cgi?id=692527
After review from the design team, the following changes were requested:
- use a "Places" label instead of a symbolic icon in the top bar
(as in GNOME 2)
- move places icons in front of the name (as in Nautilus)
- use menu separators between sections instead of section titles
https://bugzilla.gnome.org/show_bug.cgi?id=692027
With new items being added on the left, the top bar gets a little
crowded with the dateMenu at the center, so move it to its "classic"
position on the right.
https://bugzilla.gnome.org/show_bug.cgi?id=692016
gnome-shell now provides its own traditional window switcher using
a dedicated keybinding, so update the extension to just take over
the default application-based switchers as well.
https://bugzilla.gnome.org/show_bug.cgi?id=689724
The Makefile had two rules by which it could possibly have generated the
intermediate .in file (on the way from .in.in to .session) and it picked
the one that didn't contain the substitution for @libexecdir@.
Consolidate the rules into one that does all the needed substitutions.
https://bugzilla.gnome.org/show_bug.cgi?id=689756
Adds minimize and maximize buttons to the titlebar by default. It
restores org.gnome.desktop.wm.preferences as the schema to be used for
the button-layout key.
It is included in classic-mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689275
As part of removing fallback mode, GNOME wants to support a subset of
gnome-shell-extensions that restore part of the GNOME 2 experience.
This commit introduces that distinction, and allows to build only the
supported "classic-mode" extensions.
Many people complained that they can't make hibernate visible. Given
that using gsettings with extensions is not easy (you need --schemadir etc.),
just flip the default, and tell people that don't want it to change it
(or just core shell)
Recently WindowsNavigator would just crash the shell upon entering
the overview. I'm not sure where the bug was, probably it was due to
the new window layout code.
Different GIO backends can fail in different ways trying to query
file infos. If that's the case, fail back to safe get_basename()
instead of crashing.
3.7 is brought some big changes in the window layout code, but I'm not
going to take advantage of them (as the assume some sort of row based layout).
Instead, just work around them in a way that makes the extension work
without major issues.
Under broken configurations, it is possible that a special directory
is configured but does not exist. In that case, just skip the menu item
altogheter.
Code was still refererring to the external screensaver instead of
activating the screenshield.
I feel like a genius for writing both modules and not noticing this
until after 3.6.0.
If apps-menu is enabled at the same time as places-menu, the right order
is activities, apps-menu, places-menu, app-menu. Previously we used the
extension activation order to obtain this, but it's not reliable enough,
so make it explicit in code.
Let's go GNOME 3 style, and make a places menu that looks like the sidebar
in Files, with for subsections corresponding to default places, devices,
bookmarks and network mounts.
Among other things, this should fix the duplicate home or duplicate desktop
bookmark problem (as now we don't bookmarks that are same as the default
locations), and it makes us future proof for the removal of PlacesManager
in core shell.
The panel changed the way it builds the buttons outside the system
status area.
- Update alternative-status-menu to the new way of accessing panel
contents.
- Update apps-menu to the new way of adding items to the panel.
- Move places-menu to the left now that it is possible without hacks.
Someone left this poor extension in the last century.
Port to GDBus, port to Lang.Class, port to addSettingsAction, port to new
symbolic icon handling.
The workspace management done by auto-move-windows is semi-dynamic,
in that it collects empty workspaces at the end, and ensures there
is always one free.
This is undesirable when the user explicitly choose static
workspaces in the tweak tool or in dconf-editor.
A dialog for which the parent application is closed may end up without
an app. In that case, show only the thumbnail, or if showing icons only,
show a missing icon.
Kill the mode switch distinction, and kill the old and unmaintained
Workspace&Icons mode.
Introduce instead configurability for the All&Thumbnails code, which
now independently allows choosing if only all windows or only those
from current workspace should be shown, and in which way (thumbnail,
icon, both).
All configuration settings changed, so the extension must be configured
again (although hopefully I chose reasonable defaults)
In All&Thumbnails mode, show an application icon above the thumbnail,
for easier recognition of the window.
The old behaviour can be restored in the preferences dialog.
Split the two modes in two different modules, for easier maintenance.
Refactor the AllThumbnails code completely, by copying relevant
or useful code for gnome-shell directly instead of hacking around
it.
This module is meant to be a copy-lib, and it is used all over the
place (including GPLv3, LGPL or BSD licensed extensions). I don't
want to block an extension for license incompatibility.
The rest of the repository is still GPLv2, as it is the tarball
distribution and individual extensions downloaded from the website.
Core shell changed the user menu so that Power Off is no longer at
the end, and it's no longer hidden by Alt. Update the extension
so that it blends nicely with the core behavior, while still exposing
Suspend/Hibernate/Power Off as separate menu items.
Desktop users rarely use suspend, and in general hibernate is
more trouble than it's worth to show at all times, so make their
visibility configurable in GSettings.
Supend defaults to true (since that's the GNOME 3 message anyway),
while hibernate is normally false. No UI is provided, since it's
unlikely that changing this is necessary.
Because the popup-menu min-width imposed by the theme was bigger
than the natural size of the menu, and because core shell code
cannot deal with that, the icon was not right aligned unless
"Removable devices" was showing.
Hack around that by setting span: -1, which pushes it to end of
the menu item.
To avoid manually adding the 3.4 stable version when doing the
release, check in configure if building a stable (even minor) version
and strip micro at that time.
This way, "make zip-file && ./local-install.sh" is not needed, you
just do "make local-install". Also, it allows to specify a different
prefix as a make variable.
This continues turning "example" in a real gnome-shell extension
tutorial, showing how to create GSettings using Convenience and
how to build a simple preference dialog by subclassing GtkGrid
and binding GObject properties to GSettings.
Since 3.3.5, gnome-shell offers an integrated configuration tool
for extensions, which can be used by adding a new "prefs" module.
Replace the old modal dialog with a new gtk dialog, which also allows
to configure the new highlight-selected setting.
Optionally, bring the selected window to front before dismissing
the popup, in a manner similar to cycle-windows keybinding (but
without the rendering artifacts, and without application grouping).
Based on a patch by Pallai Roland <dap@magex.hu>
A long due update, since this was merged in gjs and core shell.
We no longer need to mess with __proto__ and prototype, and can
use decent syntax for true object oriented programming.
(This affects all except xrandr-indicator, since I want to port
that to GDBus too, using the new bindings right from the start)
Modified to avoid global settings variables, that were updated
unpredictably. Removed the inital show effect and placing the dock
at primary.y at startup (causing a big and often unexpected jump).
Ported to the new class framework, which should mean cleaner code.
Mode selection was cleaned up, settings dialog was moved to a
separate file (in preparation for GTK replacement), all classes
were moved to Lang.Class. No big code changes though.
Retrieve Convenience from the extension helper object (Me), and
pass no arguments to initTranslations and getSettings (since the
metadata has all that is required)
Extension helper and metadata are now different objects, so the
first needs be retrieved from ExtensionUtils.
Also, reduce the number of required arguments (by using the new
metadata keys) and make generic enough for usage by other extensions.
Includes documentation.
Introduce a common settings.mk file, which is included in extensions
that need GSettings, to ensure that conventions are respected, and
necessary fixes can be applied from one place.
Add "gettext-domain", "extension-id" (containing the base part of the
UUID) and "gschemabase" (which, combined with "extension-id", gives
the GSettings schema) to metadata.json, autogenerated by the build
system.
This way it is clear what license covers these extensions, and to
what extent it is possible to reuse the code.
Also, fixed the rule to avoid calling `pwd` a bunch of times.
Instead of destroying the whole menu and recreating it, find the
right position and just destroy/recreate the items we care about.
Based on a patch by Andrea Santilli <andreasantilli@gmx.com>
Recently gnome-shell changed the code to handle the window overlays
(to fix some bugs aboud the overlay flashing), which resulted in
invisible overlay with this extension. Fix by reimporting some code
from gnome-shell core.
If one wants the extension, clearly he doesn't want the default
layout of windows, therefore it doesn't make sense to replicate
it and to keep settings for it.
Some keyboard layouts (in particular, azerty / french) require
pressing shift to obtain numerals. Therefore we should not cancel
the switch when shift is pressed.
Also, we should accept indifferently left or right modifiers.
After enabling, the user menu was keeping a reference to a
destroyed actor, and then was updating it from signals. Updating
this (a StEntry) caused g_criticals because of a NULL ClutterText.
Instead we can null out the actor entirely, which will stop
the signal handler from doing any harm.
It is not used anymore, now that translations are bundled with
the extension. Also, in the zip files it ended up with my home
folder, which is not nice.
Common code for retrieving translations and GSettings schemas has
been factored out into lib/convenience.js, which is part of
every extension installation.
Since that code relies on renames done at zip file creation time,
extensions can no longer be installed with "make install". Instead,
one should create the zip file and install it with the tweak-tool.
There is also a bash script, local-install.sh, that will install
everything in zip-files.
Also, since the GSettingsSchemaSource code is not yet in a stable
GLib release, extensions using GSettings have seen their stable
shell version removed.
Now, typing "make zip-file" will create a standard zip-file for each
extension, with everything necessary, including translations and GSettings schemas.
These files can then be installed with the tweak-tool or uploaded
at extensions.gnome.org
Based on an earlier patch by Jasper St. Pierre.
gnome-shell has been ported to GDBus, and this changed some of
its internal API.
Of course, this means that alternative-status-menu no longer works
with 3.2.0.
To go along GNOME Shell 3.2.1
Also, mark both alternate-tab and dock as generally "working with
3.2", since the most outstanding bugs seem to be fixed now.
gnome.org is temporarily forbidden in UUIDs, to avoid people copy-pasting
it around. For this reason, I setup a repo at github and modified
the UUID accordingly.
I still think that primary development will stay at gnome.org, although
I'll keep both updated.
We cannot return from show() without creating an AppSwitcher, as it
will subsequently crash in core shell code due to _appSwitcher being null.
We can prevent this by destroying the actor (which will prevent it
from being allocated and thus avoid the crash).
Prior to this fix, the variables 'enter_event' and 'leave_event' in the
handler for the 'changed' event for the
'/org/gnome/shell/extensions/dock/hide_effect' dconf key were
uninitialized. This made switching the hide effect at runtime throw an
error. By promoting these two variables to instance members and
assigning to them upon initialization, this problem should be fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=662389
The name property is supposed to be already a displayable string,
without any further work.
Also, that gettext call wouldn't have any effect, since we don't
have those strings in our catalogs.
By importing various stuff from core shell, now it works for me.
(In particular, what was missing was setting the modifierMask in
show()).
Also, remove the native mode. Users wishing to have it should just
disable the extension with the standard tools.
This is the stable release, so we support all of GNOME Shell
stable cycle without updates.
(As said earlier, dock and alternate-tab have issues, so they're
not marked 3.2 but just 3.2.0)
GNOME Shell has changed internal API here and there, and this
broke some extensions.
alternate-tab and dock still have issues, I'll try to solve them
post 3.2.0
In current GNOME Shell master, there are some more things that
we need to update on enable/disable. Also, the Do Not Disturb
item was changed to Notifications, and the meaning flipped.
TelepathyClient.Notification was renamed to ChatNotification, a
setChatState method was added in the Source API too and the timestamp
management changed a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=657475
I was planning to add global.stage_xwindow, back when this was
written for core. Then this became an extension, but the reference
staid there.
We could use clutter_x11_get_stage_window(), if that wasn't marked
(skip). For now, let's just 0 (it is correct anyway, as we want
the dialog to be system modal)
main() has been replaced by init(), enable() and disable()
I'm not sure it actually disables, it should unless you have more
extensions messing with the same methods.
main() has been replaced by init(), enable() and disable()
when disabling, all sources and notifications associated with gajim
contacts are automatically closed
main() has been replaced by init(), enable() and disable()
at the same time, ensure that all keybindings are correctly taken
(even though alt-tab and alt-shift-tab have the same effect right
now)
main() has been replaced by init(), enable() and disable()
not sure if it works, could cause memory leaks if disabling, because
of uncollectable cycles
Now alternate-tab shows a dialog on first usage, allowing to choose
between native behavior (app icons from all worskpaces), app icons
from current workspace only and window thumbnails only.
Patch written by Joachim Bargsten <dev@bargsten.org>
This extension shows a menu in the status area that indicates
current workspace and allows for quick switching, similar to the
workspace-indicator applet in GNOME 2.
Now it is possible to configure in GSettings if the dock should be
visible at all time or it should autohide when not needed. If
autohiding, it animates, and the effect is itself configurable, as
well as his duration.
Based on a patch by Miguel Aguilar <zodiac_es@yahoo.es>
Using the auto move window the overview is not shown when the last
window on the last workspace is closed, instead the workspace before is
activated. This differs from the core gnome-shell's behaviour. Fix the
extension to show the ovreview instead of changing workspace when the
last window is closed on the last workspace. The fix is basically merged
from gnome-shell master.
Summarizing, the behaviour is now:
- The last window is closed on any workspace but the last: do nothing
- The last window is closed on the last workspace: show the overview
instead of switching to the "upper" workspace
https://bugzilla.gnome.org/show_bug.cgi?id=651586
Using the auto move window the overview is not shown when the last
window on a workspace is closed, instead the workspace before is
activated. Fix the extension to show the ovreview instead of changing
workspace when the last window is closed. The fix is basically merged
from gnome-shell master.
https://bugzilla.gnome.org/show_bug.cgi?id=651586
This reverts commit 60bc404d95.
master branch is for master gnome-shell, which is 3.0.1 and unstable.
gnome-3-0 branch is for stable shell, and has 3.0 for everything
which is supported by shell developers.
Next time, please ask me before committing.
Rewrite to use similar code to that used by places-menu, and the
mounts shown by searching in the overview.
Should fix the issue in bug #650076 that prevented remounting the
drives after ejecting, and should be compatible with what Nautilus
does by default.
Use GSettings to store configuration and make the dock position
customizabile. Currently, supported are left and right of the
primary monitor; more could be added in the future.
(Commit message edited by Giovanni Campagna)
https://bugzilla.gnome.org/show_bug.cgi?id=647394
Signed-off-by: Giovanni Campagna <gcampagna@src.gnome.org>
Now it is possible to use GSettings to configure the placement
strategy (natural KDE-like or default grid) and whether to consolidate
the windows more tigthly, as well as the position of the window
captions.
This extension employs an algorithm (taken from KDE) for layouting
the thumbnails in the overview that more closely reflects the positions
and relative sizes of the actual windows, instead of using a fixed
grid.
xrandr-indicator makes the whole shell crash if the right gjs
features are missing, but instead of asking not to install it, we
can use gjs versioning.
Now if a required external package cannot be found, it doesn't fail
and instead prints a warning. This is to allow building with
--enable-extensions=all without the required libraries.
Also bump required libgtop version to the one with the typelib.
Now we enable by default only extensions that are unlikely to
conflict much with the shell experience (so no alternate-tab, no
auto-move-windows, etc.) and require no GSettings or external
packages.
If a theme cannot be found in the user directory, try in system
data dirs (XDG_DATA_DIRS, usually /usr/share and /usr/local/share)
Signed-off-by: Giovanni Campagna <gcampagna@src.gnome.org>
Previously null stylesheets were ignored, making it impossible to
reset the default. We still need to filter out invalid (non existing)
stylesheets, as no check is performed by shell code.
The hook to access the status menu was changed in panel.js. Also
replace the alternating menu item with two separate menu items (which
side-steps bug 643631) and use own translations instead of those
provided by gnome-shell (so Hibernate is translated)
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":"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's GitLab instance instead.",
* 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's GitLab instance instead.",
<pathd="m 550 182 c -0.351562 0.003906 -0.695312 0.101562 -1 0.28125 v 3.4375 c 0.304688 0.179688 0.648438 0.277344 1 0.28125 c 1.105469 0 2 -0.894531 2 -2 s -0.894531 -2 -2 -2 z m 0 5 c -0.339844 0 -0.679688 0.058594 -1 0.175781 v 6.824219 h 4 v -4 c 0 -1.65625 -1.34375 -3 -3 -3 z m 0 0"/>
<pathd="m 573 182.269531 v 3.449219 c 0.613281 -0.355469 0.996094 -1.007812 1 -1.71875 c 0 -0.714844 -0.382812 -1.375 -1 -1.730469 z m 0 4.90625 v 6.824219 h 2 v -4 c 0 -1.269531 -0.800781 -2.402344 -2 -2.824219 z m 0 0"/>
</g>
</g>
<pathd="m 7.984375 1 c -0.550781 0 -1 0.449219 -1 1 v 8.585938 l -2.292969 -2.292969 c -0.1875 -0.1875 -0.441406 -0.292969 -0.707031 -0.292969 s -0.519531 0.105469 -0.707031 0.292969 c -0.390625 0.390625 -0.390625 1.023437 0 1.414062 l 4 4 c 0.390625 0.390625 1.023437 0.390625 1.414062 0 l 4 -4 c 0.390625 -0.390625 0.390625 -1.023437 0 -1.414062 s -1.023437 -0.390625 -1.414062 0 l -2.292969 2.292969 v -8.585938 c 0 -0.550781 -0.445313 -1 -1 -1 z m 0 0"/>
<svgxmlns="http://www.w3.org/2000/svg"height="16px"viewBox="0 0 16 16"width="16px"><pathd="m 3 2 c -1.660156 0 -3 1.339844 -3 3 v 4 c 0 1.660156 1.339844 3 3 3 h 10 c 1.660156 0 3 -1.339844 3 -3 v -4 c 0 -1.660156 -1.339844 -3 -3 -3 z m 0 2 h 10 c 0.554688 0 1 0.445312 1 1 v 4 c 0 0.554688 -0.445312 1 -1 1 h -10 c -0.554688 0 -1 -0.445312 -1 -1 v -4 c 0 -0.554688 0.445312 -1 1 -1 z m 0 0"/><pathd="m 2 10 h 12 v 4 h -12 z m 0 0"/><gfill-opacity="0.501961"><pathd="m 4 5 h 2 v 4 h -2 z m 0 0"/><pathd="m 7 5 h 2 v 4 h -2 z m 0 0"/><pathd="m 10 5 h 2 v 4 h -2 z m 0 0"/></g></svg>
<svgxmlns="http://www.w3.org/2000/svg"height="16px"viewBox="0 0 16 16"width="16px"><pathd="m 5 5 h 6 v 6 h -6 z m 0 0"/><pathd="m 13 5 h 3 v 1 h -3 z m 0 0"/><pathd="m 13 7 h 3 v 1 h -3 z m 0 0"/><pathd="m 13 9 h 3 v 1 h -3 z m 0 0"/><pathd="m 0 6 h 3 v 1 h -3 z m 0 0"/><pathd="m 0 8 h 3 v 1 h -3 z m 0 0"/><pathd="m 0 10 h 3 v 1 h -3 z m 0 0"/><pathd="m 5 0 h 1 v 3 h -1 z m 0 0"/><pathd="m 7 0 h 1 v 3 h -1 z m 0 0"/><pathd="m 9 0 h 1 v 3 h -1 z m 0 0"/><pathd="m 10 13 h 1 v 3 h -1 z m 0 0"/><pathd="m 8 13 h 1 v 3 h -1 z m 0 0"/><pathd="m 6 13 h 1 v 3 h -1 z m 0 0"/><pathd="m 5 2 c -1.644531 0 -3 1.355469 -3 3 v 6 c 0 1.644531 1.355469 3 3 3 h 6 c 1.644531 0 3 -1.355469 3 -3 v -6 c 0 -1.644531 -1.355469 -3 -3 -3 z m 0 2 h 6 c 0.570312 0 1 0.429688 1 1 v 6 c 0 0.570312 -0.429688 1 -1 1 h -6 c -0.570312 0 -1 -0.429688 -1 -1 v -6 c 0 -0.570312 0.429688 -1 1 -1 z m 0 0"/></svg>
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.