Florian Müllner authored Feb 12, 2019 and Georges Basile Stavracas Neto committed Feb 13, 2019

Here's a template string with '/' that escaped commit 94423151,
resulting in an xgettext warning when generating the .pot file.

Simply move it into the resource like the other interface descriptions
to make xgettext happy again.

!407

Taquin is org.gnome.Taquin.

gnome-2048 id is now set to
org.gnome.TwentyFortyEight.

Iagno is org.gnome.Reversi,
instead of org.gnome.Iagno.

Someone added those in the mists of time, likely by mistake.

Florian Müllner authored Feb 09, 2019 and Georges Basile Stavracas Neto committed Feb 10, 2019

Since commit deec0bf2, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.

Set up the actor to follow the content's size instead, to get closer
to the previous behavior.

!402

Florian Müllner authored Feb 05, 2019 and Florian Müllner committed Feb 10, 2019

It is too small to be really useful, and sticks out being the
only color icon.

#957

Jonas Dreßler authored Feb 09, 2019 and Florian Müllner committed Feb 10, 2019

The top drag gesture is not of any use if the topmost window is not
a fullscreen window and will only block events near the important top
screen edge (i.e. the panel). To fix this, only enable this gesture if
the focus window is a fullscreen window.

#552

Florian Müllner authored Feb 09, 2019 and Georges Basile Stavracas Neto committed Feb 10, 2019

If the user's real name is too long to fit the menu comfortably, we are
supposed to use the username instead. However since commit f8e5e3e4,
we no longer set a max-width on the menu as a whole, but instead base
the width request on only "unellipsizable" children. For some reason
the system menu ended up there, so the name is now allowed to grow
indefinitely.

Remove it from the list of size children to get the intended behavior
back.

!400

This was accidentally dropped in commit a1534dab.

Florian Müllner authored Sep 11, 2018 and Florian Müllner committed Feb 09, 2019

The menu grabs the key focus when opened, which takes focus away from
whichever actor triggered the keyboard. And as the menu doesn't have
any text entries, the keyboard is popped down as a result.

Prevent this by making the menu items unfocusable, so the keyboard
focus just stays where it is. Considering that the menu is part
of the on-screen keyboard itself, not being keyboard-navigatable
isn't a big deal here.

#171

Florian Müllner authored Sep 11, 2018 and Florian Müllner committed Feb 09, 2019

Menu items use a single 'active' state that follows both hover and
keyboard focus. It therefore makes sense for the active item to always
grab the focus, in particular as an item that is sensitive but not
focusable by keynav would be rather weird.

As it turns out, we do have a case that is weird enough where we want
exactly that, so only grab focus if the actor's :can-focus property
allows it.

#171

Until commit 467b7c1b, the import used to leak into the
eval() environment, but not anymore. Add it back (and remove
Gtk, as it's not *that* useful).

GNOME/gnome-shell!398

This is *much* nicer than repetitive "imports.gi" lines ...

!399

Spotted by eslint.

!399

Update NEWS.

The markup unit test currently fails with the following message:

  TypeError: class heritage MessageList.Message is not an object or null

This is because MessageList imports other modules that end up importing
MessageList themselves in order to inherit from one of its classes. But
as the MessageList imports hasn't finished yet (it's still processing
its own imports), that class hasn't been defined yet.

Work around that by importing Main first, so that the importer can
process imports in a proper order.

Those functions originated in gnome-shell-extension's Convenience
module which is copied by almost every extension out there. Let's
make people's life just a little bit easier by including the code
ourselves.

!150

Window titles aren't restricted in length, so the menu may end up unwieldily
width. Commit 0bec76b6 therefore limited the app context menus, but that
got accidentally dropped in commit 0ded0dbf. Add back the limitation and
extend it to the new app menu as well.

#624

Top bar icons are supposed to by symbolic, but not all applications
provide a symbolic icon. Make the stick out less by desaturating
the appmenu icon if a symbolic style is requested.

#624

It is now only used internally by ShellApp to track remote actions,
so there's no need to expose it to javascript code.

#624

It is now unused.

#624

It is now unused.

#624

As the app menu is being phased out, it is no longer a good indicator
for GtkApplications. Instead, base the check directly on the appropriate
D-Bus properties.

#624

With the app menu being phased out entirely, there's no good reason to
keep support for the fallback app menu in decorations either - the number
of applications that set an app menu and haven't embraced client-side
decorations is extremely small, and they should already have alternative
fallbacks for non-GNOME environment in place.

#624

Since the plans to retire the app menu were announced, nobody objected to
the removal of the menu content, however some concerns were raised about
the menu's secondary role as indicator.

Account for that by not removing the existing app menu, but replacing it
with a built-in menu similar to the existing app icon context menu.

#624

The GtkSettings was originally introduced to inform applications about
the desktop shell's capabilities, but users soon started to use it to
force GTK+ to show the app menu inside the application. We eventually
caved and also handled the setting ourselves to hide the in-shell app
menu to allow users to "move" it.

But now the remote app menu is in the process of being retired[0], and
will be replaced with a simple indicator that cannot be moved, so
stop following the GtkSetting.

[0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement

#624

#624