After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768531 - wayland: Startup notification doesn't work on some apps (eg. gnome-terminal) and some circumstances
wayland: Startup notification doesn't work on some apps (eg. gnome-terminal) ...
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: wayland
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 766917 771639 772617 772737 773013 779829 (view as bug list)
Depends on:
Blocks: WaylandRelated
 
 
Reported: 2016-07-07 19:58 UTC by maxime.deroucy
Modified: 2021-07-05 13:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdkdisplay-wayland: Add API to set startup notification ID (3.00 KB, patch)
2016-10-20 18:01 UTC, Florian Müllner
committed Details | Review
wayland: Set startup ID from GApplication platform data (1.70 KB, patch)
2016-10-20 18:01 UTC, Florian Müllner
committed Details | Review
gtk-shell: Work around non-working startup notifications (1.87 KB, patch)
2016-10-20 18:03 UTC, Florian Müllner
none Details | Review
core: Make MetaStartupNotificationSequence a public object (8.43 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_x11_get_wmclass() (1.90 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
none Details | Review
core: Make get_sequences() return MetaStartupNotificationSequences (5.20 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_get_workspace() (3.84 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_get_application_id() (4.09 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_is_complete() (3.59 KB, patch)
2017-08-15 17:03 UTC, Carlos Garnacho
reviewed Details | Review
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED (909 bytes, patch)
2017-08-15 17:04 UTC, Carlos Garnacho
none Details | Review
shell: Drop API usage of SnStartupSequence (10.17 KB, patch)
2017-08-15 17:05 UTC, Carlos Garnacho
none Details | Review
core: Make MetaStartupNotificationSequence a public object (8.40 KB, patch)
2017-09-26 10:57 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_x11_get_wmclass() (1.91 KB, patch)
2017-09-26 10:57 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_get_workspace() (4.63 KB, patch)
2017-09-26 10:57 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_get_application_id() (3.98 KB, patch)
2017-09-26 10:57 UTC, Carlos Garnacho
none Details | Review
core: Make get_sequences() return MetaStartupNotificationSequences (9.70 KB, patch)
2017-09-26 10:58 UTC, Carlos Garnacho
none Details | Review
core: Add meta_startup_notification_sequence_has_completed() (3.66 KB, patch)
2017-09-26 10:58 UTC, Carlos Garnacho
none Details | Review
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED (909 bytes, patch)
2017-09-26 10:58 UTC, Carlos Garnacho
none Details | Review
core: Add public MetaStartupNotification getter from MetaDisplay (10.59 KB, patch)
2017-09-26 10:58 UTC, Carlos Garnacho
none Details | Review
shell: Drop API usage of SnStartupSequence (12.37 KB, patch)
2017-09-26 10:59 UTC, Carlos Garnacho
none Details | Review

Description maxime.deroucy 2016-07-07 19:58:51 UTC
Hello,

I will try to describe the problem as best as I can.

* brand new Archlinux (05/07/2016), updated today.

  notmux max@max-laptop % yaourt -Qs mutter         
  extra/mutter 3.20.3-1 (gnome)
      A window manager for GNOME
  notmux max@max-laptop % yaourt -Qs gnome-shell
  extra/gnome-shell 3.20.2-1 (gnome)
      The next generation GNOME Shell

* I am using gnome-shell on Wayland (launched via gdm).

Problem:

When I launch gnome-terminal (or some other apps, like tracker or dconf-editor ; epiphany doesn't suffer from this bug), gnome-terminal appear right away on the screen, usable, responsive, all good… but gnome-shell still consider it as starting : there is a waiting circle at the top left corner, at the right of the gnome-terminal logo.
Also gnome-terminal doesn't appear in the Alt+Tab list.
After approximately 30s the circle disappear and the app appear in the Alt+Tab list.
As there is already a gnome-terminal instance launched, other instance don't suffer from the problem.
If I close all gnome-terminal and launch a new gnome-terminal, it suffer from the problem.

I tried to set "StartupNotify=false" in the gnome-terminal .desktop: it works (but that's not a good solution)

I tried to watch "journalctl -f": nothing noticeable

I tried removing tracker: doesn't solve the problem

I watch "busctl --user monitor": lots of messages, nothing noticeable… I could have missed something. Do you need the output ?

When my cursor is on my main monitor (laptop, Dell XPS 13, HiDPI), so the app start on it, the problem appear.
When my cursor is on my second monitor (not HiDPI), so the app start on it, the problem **doesn't** appear.
When the app start on my main monitor and I move the app window to another workspace (or my second monitor), the app is considered started (problem disappear).
When the app start on my main monitor and I go to another workspace then get back, the problem is still present.

There is no problem under X.

I hope I detailed enough.

Do you need some other informations ?

Regards
Comment 1 Cédric Bellegarde 2016-07-08 14:40:26 UTC
This bug prevents me using wayland...
Comment 2 Stephen 2016-08-03 00:22:00 UTC
I can confirm the following behaviour from this bug on Fedora 24/GNOME Wayland:

* ~ 30 s spinner in top bar;
* not shown in Alt-Tab list until after that time;
* only happens under GNOME Wayland.

As far as I can tell, this affects (most) applications with .desktop files whose name is [DBus path].desktop

These are mostly DBusActivatable=true .desktop files, but that is not necessary to trigger this bug.

On my system I have the following .desktop launchers in /usr/share/applications with names that correspond to existent DBus paths:

Launchers containing DBusActivatable=true:

ca.desrt.dconf-editor.desktop
org.gnome.baobab.desktop
org.gnome.Books.desktop         *
org.gnome.Boxes.desktop
org.gnome.Builder.desktop
org.gnome.Calendar.desktop
org.gnome.Characters.desktop    *
org.gnome.Cheese.desktop
org.gnome.clocks.desktop
org.gnome.Contacts.desktop
org.gnome.Devhelp.desktop
org.gnome.DiskUtility.desktop
org.gnome.Documents.desktop     *
org.gnome.font-viewer.desktop
org.gnome.gedit.desktop
org.gnome.Logs.desktop
org.gnome.Maps.desktop
org.gnome.Nautilus.desktop
org.gnome.Photos.desktop
org.gnome.Polari.desktop        *
org.gnome.Screenshot.desktop
org.gnome.Software.desktop
org.gnome.Todo.desktop
org.gnome.Totem.desktop
org.gnome.Weather.Application.desktop

Launchers not containing DBusActivatable=true:

org.gnome.bijiben.desktop
org.gnome.SoundRecorder.desktop *
org.gnome.Terminal.desktop

Launchers marked with * are not affected by the bug.

Renaming a launcher to anything other than an existent DBus name (even for example org.gnome.test.desktop) results in the bug not manifesting when launching that application. This can only be done for the non-DBusActivatable launchers, since the others rely on the file name for DBus activation (as per https://wiki.gnome.org/HowDoI/DBusApplicationLaunching#Changes_to_the_desktop_file).

The bug is triggered when launching:

* from the app icon in the overview;
* via a pre-defined keyboard shortcut (e.g. the "Home folder" launcher shortcut).

The bug isn't triggered when launching:

* by opening the desktop launcher under /usr/share/applications via Nautilus; 
* by calling the executable directly (from the Run dialogue, a terminal, a custom keyboard shortcut etc.
* via gapplication launch, e.g. gapplication launch org.gnome.Cheese
Comment 3 Christian Stadelmann 2016-09-01 12:50:50 UTC
I can confirm this issue with Gnome-shell 3.18.x, 3.20.x and 3.21.90.

Can you please add "WaylandRelated" to the "Blocks:" field?
Comment 4 Kamil Páral 2016-09-16 07:02:34 UTC
Downstream report:
https://bugzilla.redhat.com/show_bug.cgi?id=1376471
Comment 5 Florian Müllner 2016-09-19 03:30:23 UTC
*** Bug 771639 has been marked as a duplicate of this bug. ***
Comment 6 Strangiato 2016-09-19 03:50:56 UTC
I can confim this on Arch running 3.22 beta 2. Annoying...
Comment 7 Florian Müllner 2016-10-08 17:26:56 UTC
*** Bug 772617 has been marked as a duplicate of this bug. ***
Comment 8 Florian Müllner 2016-10-11 09:55:06 UTC
*** Bug 772737 has been marked as a duplicate of this bug. ***
Comment 9 Florian Müllner 2016-10-16 07:35:53 UTC
*** Bug 773013 has been marked as a duplicate of this bug. ***
Comment 10 Florian Müllner 2016-10-20 18:01:47 UTC
Created attachment 338117 [details] [review]
gdkdisplay-wayland: Add API to set startup notification ID

For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
Comment 11 Florian Müllner 2016-10-20 18:01:55 UTC
Created attachment 338118 [details] [review]
wayland: Set startup ID from GApplication platform data

The GApplication platform data may contain a startup ID that on X11
is used to set the startup notification ID when activated. Do the
same on the wayland backend to make startup notifications work for
DBus-activated applications where the DESKTOP_STARTUP_ID environment
variable is not set.
Comment 12 Florian Müllner 2016-10-20 18:03:14 UTC
Created attachment 338120 [details] [review]
gtk-shell: Work around non-working startup notifications

GNOME Shell relies on the MetaScreen::startup-sequence-changed signal,
which is tied to (lib)startup-notification and therefore X11. As a result,
when we remove the startup sequence of a wayland client, GNOME Shell will
not be notified about this until startup-notification's timeout is hit.
As a temporary stop-gap, go through XWayland even for wayland clients,
so that the signal is emitted when expected.
Comment 13 Simón 2016-10-25 10:33:10 UTC
It affects too to another GTK applications: Gnome MPV, Audacious (GTK3 version), GRadio,... If it helps we could report failed programs when we detect them.

I think the easiest workaround for those who want to continue using Wayland normally is change the desktop files of conflictive programs manually changing "StartupNotify=false" or with an application like menulibre ( https://smdavis.us/projects/menulibre/ )
Comment 14 Florian Müllner 2016-10-25 13:27:44 UTC
(In reply to Simón from comment #13)
> It affects too to another GTK applications: Gnome MPV, Audacious (GTK3
> version), GRadio,... If it helps we could report failed programs when we
> detect them.

No, "some programs are broken" is a huge red herring. Startup notifications are broken for *all* wayland clients, there are just some cases where the regular window matching ends up producing the correct app state.
Comment 15 Matthias Clasen 2016-10-31 18:22:06 UTC
Review of attachment 338117 [details] [review]:

ok. I think we can bend the rules a little, and accept this in 3.22, since it is backend-specific and not going to be used outside of GTK+
Comment 16 Matthias Clasen 2016-10-31 18:22:38 UTC
Review of attachment 338118 [details] [review]:

sure
Comment 17 Michael Catanzaro 2016-11-06 20:13:18 UTC
Review of attachment 338117 [details] [review]:

::: gdk/wayland/gdkdisplay-wayland.c
@@ -799,0 +799,16 @@
+/**
+ * gdk_wayland_display_set_startup_notification_id:
+ * @display: (type GdkWaylandDisplay): a #GdkDisplay
... 13 more ...

I think it's important to provide an accurate Since tag:

Since: 3.22.3
Comment 18 Carlos Garnacho 2016-11-07 13:53:20 UTC
Alternatively, couldn't this go through GdkPrivateVTable ? We can't get rid of gdk_x11_display_set_startup_notification_id, but we could make this per-platform inside GDK and abtract it to a single GDK_PRIVATE_CALL in gtk/ without adding API that's just useful to GTK+.
Comment 19 Matthias Clasen 2016-11-08 17:03:47 UTC
sounds better to me. Who is going to write that patch ? Carlos ? Florian ?
Comment 20 Florian Müllner 2016-11-08 17:27:51 UTC
I'll look into it.
Comment 21 Matthias Clasen 2016-11-08 18:33:33 UTC
Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API to set startup notification ID
Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from GApplication platform data
Comment 22 Cédric Bellegarde 2016-11-08 19:04:12 UTC
Tested previous patches, not fixing issue with nautilus here...

Nautilus is a particular case: background process creating a new window...
Comment 23 Florian Müllner 2016-11-08 19:11:25 UTC
(In reply to Matthias Clasen from comment #21)
> Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API
> to set startup notification ID
> Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from
> GApplication platform data

Uhm, wasn't the consensus now to not go with those patches but implement Carlos' suggestion from comment #18 instead?
Comment 24 Florian Müllner 2016-11-08 19:13:41 UTC
(In reply to Cédric Bellegarde from comment #22)
> Tested previous patches, not fixing issue with nautilus here...
> 
> Nautilus is a particular case: background process creating a new window...

Did you include the mutter patch? The GTK+ patches only make DBus-activated clients set the startup notification ID when activated, they don't change the fact that startup notifications are currently broken for all wayland clients.

For what it's worth, I did include nautilus in my testing, and it works as expected with all patches applied ...
Comment 25 Cédric Bellegarde 2016-11-08 22:08:02 UTC
You're right, bug fixed, bye bye xorg ;)
Comment 26 Cédric Bellegarde 2016-11-09 07:03:32 UTC
May be related to startup notification stuff: https://bugzilla.gnome.org/show_bug.cgi?id=774130
Comment 27 Matthias Clasen 2016-11-09 18:58:42 UTC
(In reply to Florian Müllner from comment #23)
> (In reply to Matthias Clasen from comment #21)
> > Attachment 338117 [details] pushed as 75ee402 - gdkdisplay-wayland: Add API
> > to set startup notification ID
> > Attachment 338118 [details] pushed as 0bccddb - wayland: Set startup ID from
> > GApplication platform data
> 
> Uhm, wasn't the consensus now to not go with those patches but implement
> Carlos' suggestion from comment #18 instead?

I ended up pushing them as-is. Didn't seem like such a big deal to have some backend api, and I needed a fix right away to meet f25 deadlines.

If we come up with an api-less version for gtk4, thats still appreciated.
Comment 28 Cédric Bellegarde 2016-11-15 16:20:50 UTC
Has this patches been reverted? Can't find theme in mutter history.
Comment 29 Carlos Garnacho 2016-11-15 16:46:05 UTC
The patches marked as "committed" in this bug are for GTK+. A better fix is being worked out for mutter.
Comment 30 Marcos Mello 2016-12-12 12:16:49 UTC
Any news on this?

Can Fedora workaround be applied to Mutter until a better fix arises?

http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/startup-notification.patch?h=f25
Comment 31 Mark Blakeney 2016-12-28 22:14:11 UTC
Yay, this bug disappeared on stock Arch today due to mutter upgrade 3.22.2+5+gd9fc81e-1 -> 3.22.2+6+g06f5b6b3e-1 which includes the startup notification patch as seen at https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mutter&id=9b194c696d09ee1a2cf593993d6ad1979c436e65.
Comment 32 Strangiato 2016-12-29 00:11:52 UTC
Yes, I can confirm that this bug is solved on Arch now. \o/
Comment 33 Florian Müllner 2017-02-13 22:16:37 UTC
*** Bug 766917 has been marked as a duplicate of this bug. ***
Comment 34 Florian Müllner 2017-03-10 07:15:32 UTC
*** Bug 779829 has been marked as a duplicate of this bug. ***
Comment 35 Carlos Garnacho 2017-08-15 17:03:03 UTC
Created attachment 357651 [details] [review]
core: Make MetaStartupNotificationSequence a public object

It replaces the single public usage of SnStartupSequence we have
in place.
Comment 36 Carlos Garnacho 2017-08-15 17:03:12 UTC
Created attachment 357652 [details] [review]
core: Add meta_startup_notification_sequence_x11_get_wmclass()

This is only necessary in internal paths for X11 clients, so make it
private API.
Comment 37 Carlos Garnacho 2017-08-15 17:03:21 UTC
Created attachment 357653 [details] [review]
core: Make get_sequences() return MetaStartupNotificationSequences
Comment 38 Carlos Garnacho 2017-08-15 17:03:28 UTC
Created attachment 357654 [details] [review]
core: Add meta_startup_notification_sequence_get_workspace()

And fill that in for the X11 case.
Comment 39 Carlos Garnacho 2017-08-15 17:03:36 UTC
Created attachment 357655 [details] [review]
core: Add meta_startup_notification_sequence_get_application_id()

This is necessary on the gnome-shell side, so it can look up a ShellApp
from a startup sequence.
Comment 40 Carlos Garnacho 2017-08-15 17:03:59 UTC
Created attachment 357656 [details] [review]
core: Add meta_startup_notification_sequence_is_complete()

So listeners of startup-sequence-changed can check whether the sequence
is completed.
Comment 41 Carlos Garnacho 2017-08-15 17:04:07 UTC
Created attachment 357657 [details] [review]
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED

So listeners can check the sequence completion.
Comment 42 Carlos Garnacho 2017-08-15 17:05:01 UTC
Created attachment 357658 [details] [review]
shell: Drop API usage of SnStartupSequence

Mutter changed all public API usage of SnStartupSequence with
MetaStartupNotificationSequence. Change the src/shell* code to do the
same, and propagate these such objects forward on ::startup-sequence-changed
signals.

The only API used on javascript around these objects is
shell_startup_sequence_get_app(), which remains in src/shell-window-tracker.c
as helper API. So the Javascript code needed no changes. All the additional
API wrapping a ShellStartupSequence/SnStartupSequence was unused, so they
were deleted in this commit.
Comment 43 Jonas Ådahl 2017-08-16 03:21:28 UTC
Review of attachment 357651 [details] [review]:

::: src/core/screen.c
@@ +234,3 @@
                   0,
                   NULL, NULL, NULL,
+                  G_TYPE_NONE, 1, META_TYPE_STARTUP_NOTIFICATION_SEQUENCE);

This API change could be communicated better in the commit message.

::: src/core/startup-notification.c
@@ +598,3 @@
 {
   MetaStartupNotification *sn = user_data;
+  MetaStartupNotificationSequence *seq = NULL;

(Ugh, confusing naming, how to tell which one is the Sn one elsewhere? (note, just casual whining, please ignore).

@@ +654,3 @@
+    {
+      const gchar *id = sn_startup_sequence_get_id (sequence);
+      g_set_object (&seq,meta_startup_notification_lookup_sequence (sn, id));

space after ",". read this as &seq.meta_... at first :P

::: src/meta/startup-notification.h
@@ +21,3 @@
+
+typedef struct _MetaStartupNotificationSequence MetaStartupNotificationSequence;
+typedef struct _MetaStartupNotificationSequenceClass MetaStartupNotificationSequenceClass;

Shouldn't be needed right? The G_DECLARE_DERIVABLE_TYPE() does this for us IIRC.
Comment 44 Jonas Ådahl 2017-08-16 03:21:46 UTC
Review of attachment 357652 [details] [review]:

::: src/core/startup-notification-private.h
@@ +46,3 @@
 GSList * meta_startup_notification_get_sequences   (MetaStartupNotification *sn);
 
+const gchar *meta_startup_notification_sequence_x11_get_wmclass (MetaStartupNotificationSequence *seq);

nit: Space after "const gchar *" is the style used above.

::: src/core/startup-notification.c
@@ +392,3 @@
+
+  if (!META_IS_STARTUP_NOTIFICATION_SEQUENCE_X11 (seq))
+    return NULL;

Should this be g_return_if_fail (..) instead? Seems to be a programming error if this is used for non-x11 sequences.
Comment 45 Jonas Ådahl 2017-08-16 03:26:39 UTC
Review of attachment 357653 [details] [review]:

::: src/core/screen.c
@@ +2445,1 @@
+          wmclass = meta_startup_notification_sequence_x11_get_wmclass (seq);

Seems like this could be a

meta_window_matches_startup_notification_sequence() that is implemented as below in MetaWindowX11 only
?

::: src/core/startup-notification.c
@@ +766,3 @@
 meta_startup_notification_get_sequences (MetaStartupNotification *sn)
 {
+  return g_slist_copy (sn->startup_sequences);

Could we maybe now skip the copy, and just have whatever uses this sequence non-copy-get it every time? (i.e. remove it from MetaScreen)
Comment 46 Jonas Ådahl 2017-08-16 03:26:59 UTC
Review of attachment 357654 [details] [review]:

::: src/core/startup-notification.c
@@ +253,3 @@
                         G_PARAM_CONSTRUCT_ONLY);
+  seq_props[PROP_SEQ_WORKSPACE] =
+    g_param_spec_int64 ("workspace",

This looks rather like an "ID" of some kind, as I'd otherwise expect a "workspace" property refer to a MetaWorkspace.

::: src/meta/startup-notification.h
@@ +33,3 @@
 const gchar *meta_startup_notification_sequence_get_id        (MetaStartupNotificationSequence *seq);
 gint64       meta_startup_notification_sequence_get_timestamp (MetaStartupNotificationSequence *seq);
+gint64       meta_startup_notification_sequence_get_workspace (MetaStartupNotificationSequence *seq);

Same as the other comment, 'get_workspace()' sounds more like it should return a MetaWorkspace. If that is really to inconvenient, then seems to be better to make it clear this is an ID, so that we could later add a "get_workspace()" that gets return the actual workspace.
Comment 47 Jonas Ådahl 2017-08-16 03:27:31 UTC
Review of attachment 357655 [details] [review]:

lgtm.
Comment 48 Jonas Ådahl 2017-08-16 03:27:44 UTC
Review of attachment 357656 [details] [review]:

::: src/core/startup-notification.c
@@ +89,3 @@
   gint64 timestamp;
   gint64 workspace;
+  guint  completed : 1;

nit: s/completed/is_complete/.
Alternatively 'has_completed' everywhere, as 'is_complete' rather means that it is "complete" as in has all required data or something, not that it has completed its task (I think).
Comment 49 Jonas Ådahl 2017-08-16 03:28:07 UTC
Review of attachment 357657 [details] [review]:

Makes sense to me.
Comment 50 Carlos Garnacho 2017-09-26 10:57:25 UTC
Created attachment 360419 [details] [review]
core: Make MetaStartupNotificationSequence a public object

It aims to replace the public API where we directly use SnStartupSequence.
For starters, the MetaScreen::startup-sequence-changed signal has been
changed to be invoked with a MetaStartupNotificationSequence parameter.
Comment 51 Carlos Garnacho 2017-09-26 10:57:35 UTC
Created attachment 360420 [details] [review]
core: Add meta_startup_notification_sequence_x11_get_wmclass()

This is only necessary in internal paths for X11 clients, so make it
private API.
Comment 52 Carlos Garnacho 2017-09-26 10:57:43 UTC
Created attachment 360421 [details] [review]
core: Add meta_startup_notification_sequence_get_workspace()

And fill that in for the X11 case.
Comment 53 Carlos Garnacho 2017-09-26 10:57:52 UTC
Created attachment 360422 [details] [review]
core: Add meta_startup_notification_sequence_get_application_id()

This is necessary on the gnome-shell side, so it can look up a ShellApp
from a startup sequence.
Comment 54 Carlos Garnacho 2017-09-26 10:58:02 UTC
Created attachment 360423 [details] [review]
core: Make get_sequences() return MetaStartupNotificationSequences

Which also involves updating all the mutter code that uses these startup
sequences to use MetaStartupNotificationSequence API. In order to abstract
things a bit further, MetaWindow has been added a
matches_startup_notification_sequence() vmethod that X11 windows do
implement through wmclass matching.
Comment 55 Carlos Garnacho 2017-09-26 10:58:12 UTC
Created attachment 360424 [details] [review]
core: Add meta_startup_notification_sequence_has_completed()

So listeners of startup-sequence-changed can check whether the sequence
is completed.
Comment 56 Carlos Garnacho 2017-09-26 10:58:20 UTC
Created attachment 360425 [details] [review]
core: Mark sequence as complete on SN_MONITOR_EVENT_COMPLETED

So listeners can check the sequence completion.
Comment 57 Carlos Garnacho 2017-09-26 10:58:30 UTC
Created attachment 360426 [details] [review]
core: Add public MetaStartupNotification getter from MetaDisplay

This replaces (and removes) meta_screen_get_startup_sequences().
The MetaScreen::startup-sequence-changed signal is also useless since
the MetaStartupNotification has a ::changed signal itself, so it has been
removed as well.
Comment 58 Carlos Garnacho 2017-09-26 10:59:49 UTC
Created attachment 360427 [details] [review]
shell: Drop API usage of SnStartupSequence

Mutter changed all public API usage of SnStartupSequence with
MetaStartupNotification and its own sequence objects. Change the src/shell*
code to use the new API and also expose MetaStartupNotificationSequence
objects in the ShellWindowTracker signals/API.

The only additional API used on javascript around these objects is
shell_startup_sequence_get_app(), which remains in src/shell-window-tracker.c
as helper API, all other helpers are unnecessary and were removed.

The Javascript code had to receive minor updates where the API is actually
different (nominally workspace getters returning a MetaWorkspace instead
of its index), but the gist is pretty much API compatible.
Comment 59 Carlos Garnacho 2017-09-26 11:04:20 UTC
Thanks Jonas for the review! I've applied all comments (except the seq naming nits :). I went for removing the MetaScreen API call and signal in an additional patch, and updated the gnome-shell patch so it uses MetaStartupNotification directly.
Comment 60 Bjørn Lie 2018-07-09 22:46:35 UTC
Hi upstream 

I've just checked mutter in fedora, openSUSE, arch and debian, and all are shipping the "startup workaround patch" for this issue.

I'm doing this ping to ensure that this issue is not "forgotten" as it still sits in bugzilla and not in gitlab.
Comment 61 Strangiato 2018-07-09 23:03:50 UTC
Startup notification almost never works on Arch Linux running Gnome 3.28.2.
I hate when I double click a big file in nautilus to open it and cursor indicates no activity until the file opens.
Comment 62 Carlos Garnacho 2018-07-10 09:56:23 UTC
(In reply to Bjørn Lie from comment #60)
> Hi upstream 
> 
> I've just checked mutter in fedora, openSUSE, arch and debian, and all are
> shipping the "startup workaround patch" for this issue.
> 
> I'm doing this ping to ensure that this issue is not "forgotten" as it still
> sits in bugzilla and not in gitlab.

There are quite a few bugs in that state. Mutter devs normally run mutter/gnome-shell from git for daily use, so be sure we are aware :)

(In reply to Strangiato from comment #61)
> Startup notification almost never works on Arch Linux running Gnome 3.28.2.
> I hate when I double click a big file in nautilus to open it and cursor
> indicates no activity until the file opens.

The current internal protocol doesn't handle launching from applications, no wonder.

We just need an upstreamed wayland protocol that unifies:
1) User activity times
2) Startup notification, both the launcher and launchee sides
3) Focus stealing prevention

Implement it maybe in weston, definitely in mutter, and add support for it in GtkApplication. Wanna help?
Comment 63 Strangiato 2019-10-12 15:40:22 UTC
(In reply to Carlos Garnacho from comment #62)
> (In reply to Strangiato from comment #61)
> > Startup notification almost never works on Arch Linux running Gnome 3.28.2.
> > I hate when I double click a big file in nautilus to open it and cursor
> > indicates no activity until the file opens.
> 
> The current internal protocol doesn't handle launching from applications, no
> wonder.
> 
> We just need an upstreamed wayland protocol that unifies:
> 1) User activity times
> 2) Startup notification, both the launcher and launchee sides
> 3) Focus stealing prevention
> 
> Implement it maybe in weston, definitely in mutter, and add support for it
> in GtkApplication. Wanna help?

The issue mentioned in comment 61 persists on Gnome 3.34.1, but unfortunately I can't help.
I'm not a software developer. :(
Comment 64 Carlos Garnacho 2019-10-12 17:56:24 UTC
I FTR been idly working since comment #62 towards a protocol that does precisely that. I still need to make POC implementations, hopefully this 3.36 material but more realistically 3.38 since it should be discussed and agreed in the wayland ML first.
Comment 65 André Klapper 2020-10-06 18:01:30 UTC
Carlos: Did that materialize for 3.38, by any chance? :)
Comment 66 GNOME Infrastructure Team 2021-07-05 13:53:02 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.