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>
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>
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>
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>
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>
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>
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>
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>
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>
Florian Müllner
Jakub Steiner
robxnano