Michael, can you attach a screenshot?

In my vm it seems quite centered...

Screenshot

No, looks like it's not currently possible to attach screenshots to pagure: nothing happens when I try. Anyway, suffice to say it's not centered horizontally, and has not been since we switched to Wayland.

I see many unacceptable TLS certificate errors in the web inspector. It's caused because pagure.io:8088 is presenting a certificate that's only valid for pagure.io. Port is significant. That may or may not be related.

Another try at attaching a screenshot:

Is there some kind of macro that can center this for any size screen? Default virt-manager console is square, most anything else it's left of center.

Is there some kind of macro that can center this for any size screen? Default virt-manager console is square, most anything else it's left of center.

Well windows cannot control their position under Wayland. I guess mutter will need to have a special case to center this one particular window?

Well windows cannot control their position under Wayland. I guess mutter will need to have a special case to center this one particular window?

Why is this window special?

This window presents two options only. That makes me wonder whether it really needs to be a dedicated window for that.

What if these two options would be presented by GNOME Shell somewhere in its UI?

Besides, choosing "Try Fedora" is the same as simply closing/ignoring the window.

IMO this could be simplified to a single option/notification that leads to the installation process.

This window is a poor emulation of the user experience that Ubuntu and similar offer, where you get a lightweight prompt asking if you want to install or boot into the live environment before the desktop is loaded. We never implemented this properly.

What if these two options would be presented by GNOME Shell somewhere in its UI?
...

There's a whole bunch of reasons why it would be better to present the choice between installation and the live session before the session begins (I think I even did mockups for it at some point). However, that would be a bigger change that we'll obviously need to coordinate with the Anaconda team - something to include in #124.

There's a whole bunch of reasons why it would be better to present the choice between installation and the live session before the session begins (I think I even did mockups for it at some point). However, that would be a bigger change that we'll obviously need to coordinate with the Anaconda team - something to include in #124.

In this case, #85 would be related to this issue too. :)

Why is this window special?

It's clearly broken and looks amateurish for the first thing the user sees to be off-center. It's been broken since Fedora 25, when we switched to Wayland by default. Prior to Fedora 25, it was always centered.

Why is this window special?

It's clearly broken and looks amateurish for the first thing the user sees to be off-center. It's been broken since Fedora 25, when we switched to Wayland by default. Prior to Fedora 25, it was always centered.

I mean, why would we center this window and not others?

Well I don't have a great answer to that. Wouldn't it look really weird if we centered every window that the user opens? Also would be pretty awkward, since each window would be opening either on top of or below the other ones.

But this is the first thing you see after starting Fedora for the first time. It just looks really weird for it to be way off to the left side of the window. I think a reasonable user is likely to realize this is a bug (it is a bug; we have code that tries and fails to center it).

Well I don't have a great answer to that. Wouldn't it look really weird if we centered every window that the user opens?

It could, but the current default positioning is a bit weird too. Maybe there's a generic solution...

And then there's the question of whether this is specific to the Fedora welcome. One would imagine that something like gnome-initial-setup would be in the same boat.

What about turning this window into a dialog?

This blog entry references "GNOME Shell’s CSS engine". Is that a generic solution available to windows or just icons and dialogs?

What about turning this window into a dialog?
This blog entry references "GNOME Shell’s CSS engine". Is that a generic solution available to windows or just icons and dialogs?

Only internal child widgets, no windows.

Following up in my suggestion of making it a Shell extension, I wrote a little demo/prototype to show what I meant.

The code is quite simple https://gitlab.gnome.org/snippets/1032

And we can position the widget wherever we want on the screen.

I'm not sure that it's really worthwhile reimplementing the UI if we're not going to move the try/install question outside of the user session.

For reference, this is the code for the existing UI: https://github.com/rhinstaller/anaconda/tree/master/data/liveinst/gnome

On wayland, windows can only position themselves relative to a parent, otherwise their placement is up to the compositor.

That means off-hand I see two options:

• flip the center-new-windows setting in org.gnome.mutter for the live image; of course that will affect all windows, the compositor will make no effort to make windows as visible as possible and just pile them all up in the center
• do some giant hack and add a maximized and fully transparent parent window (I only expect that to somewhat work)

A final and non-hacky option is adjusting the placement policy in mutter. IMHO it makes sense to center the first window that is opened on a workspace. We have all space available at that point, and as mentioned in this issue, a lone window looks weird when stuck in a corner.

I'll propose a MR in mutter's gitlab in a bit.

I'll propose a MR in mutter's gitlab in a bit.

Done: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1105

So it seems like the changing the window position policy in mutter was not well-received? That seems like overkill anyway; I like how mutter currently decides to position most windows. Opening regular applications in the center of the monitor seems weird... IMO only this first boot applications should be special, since it looks embarrassing for us to open these on the side of the screen.

Note that gnome-initial-setup always gets centered. Maybe so does gnome-tour? There must be existing code to make this work somewhere.

Action: Michael to investigate how GNOME Tour centers itself.

Action: Michael to investigate how GNOME Tour centers itself.

It does NOT center itself when I run it manually:

which looks pretty bad IMO. @ngompa, how confident are you that it really centers itself during the first boot process? It seems unlikely that the behavior there would be different?

@fmuellner could we just hardcode special behavior in mutter for gnome-tour, gnome-initial-setup, and the live application? IMO only "special" applications that are part of the install and first boot experience need to be centered like this. The existing behavior works well for everything else.

It seems unlikely that the behavior there would be different?

Unless it ends up in an X11 session for some reason, where the GTK hints to center the window work.

could we just hardcode special behavior in mutter for gnome-tour, gnome-initial-setup, and the live application?

Possible yes, but requires adding some rudimentary application matching to mutter first. It's certainly more involved than the previous patch, and not suitable for upstream.

The gnome-initial-setup and gnome-tour changes are desired upstream, though. Only the fedora welcome is a downstream thing.

I'm almost certain that gnome-initial-setup always launches centered in the gdm session. And I believe that is using Wayland. I wonder how that works.

Action: Michael to investigate how GNOME Tour centers itself.

Adding pending-action for this.

It does not center itself after all. See my screenshots above.

It does not center itself after all. See my screenshots above.

Sorry I missed that. I think that placement is due to the existing terminal window. If I use the run dialog on an empty workspace, I get this:

OK, I see it's definitely always centered if launched using the run dialog (nice trick), as is gnome-initial-setup, whereas other apps are never centered. So there must be some difference here somewhere. Action: Michael to investigate further.

OK well I found the code in gnome-initial-setup that attempts to center the window using gtk_window_set_position(), but it doesn't do anything since it doesn't work in Wayland (and has been removed in GTK 4). Turns out it is being centered by luck: it seems mutter centers bigger windows when they are the only window on the workspace, but not smaller windows.

I found source code for liveinst.js here. Then I added this at the bottom of WelcomeWindow._init:

      let geometry = new Gdk.Geometry();
      geometry.min_width = 1024;
      geometry.min_height = 768;
      this.window.set_geometry_hints(null, geometry, Gdk.WindowHints.MIN_SIZE);

That centers the window, at the cost of making it so big that it looks stupid. I next tried:

      let geometry = new Gdk.Geometry();
      geometry.min_width = 800;
      geometry.min_height = 600;
      this.window.set_geometry_hints(null, geometry, Gdk.WindowHints.MIN_SIZE);

which is too small to center the window.

So we need help from mutter one way or another: it should either hardcode something for the three apps that must be centered (liveinst.js, gnome-initial-setup, gnome-tour), or else provide us some way to request this behavior.

The gnome-tour window is 960x720. I think we could adapt the welcome window to work at that size:

Here's a screenshot to show what it looks like at 960x720:

Seems OK. But we need to understand the algorithm that mutter uses to decide whether to center the window to know whether this would really work or not. I bet the window size is being compared to monitor size, so this might not work with larger monitors. Florian would know.

BTW it's easy to modify and run the liveinst.js script since it's so simple. You only need to download it, make it executable, and then modify the default_width and default_height lines here in WelcomeWindow._init:

      this.window = new Gtk.ApplicationWindow({ application: application,
                                                type: Gtk.WindowType.TOPLEVEL,
                                                default_width: 600,
                                                default_height: 550,
                                                skip_taskbar_hint: true,
                                                title: _("Welcome to Fedora"),
                                                window_position: Gtk.WindowPosition.CENTER });

That's simpler than my above attempt to muck around with the window geometry hints.

Action: Michael to talk to @fmuellner

I asked about this in #gnome-shell. Florian, Matthias, and Jonas are discussing the best way to solve this.

@catanzaro , I think this was fixed for F34...?

No, this is still broken afaik. Needs help from the gnome-shell and mutter developers.

https://gitlab.gnome.org/GNOME/mutter/-/issues/2123

This is an issue opened in Mutter repo about centering new windows.

There's also https://gitlab.gnome.org/GNOME/mutter/-/issues/1662 which is what needs to be solved to fix this problem. Hey @fmuellner , when you get a chance, could you look at this again please?

The current (default) placement algorithm boils down to:
- if there's enough empty space, place the window there
- if there isn't, cascade windows (starting from the top left)

For example open a terminal on an empty workspace, then open a new window; the second window should be placed next to the first.

The problem with centering the first window is that it makes the first case much less likely, and we probably start cascading immediately.

Nobody has come up with an accepted design solution for that issue, and until that happens, there's not much that I can do.

What we need to close this issue is an exception whereby Fedora's liveinst and also gnome-initial-setup are both always centered. We don't need to care about other apps, and shouldn't need to wait for any designs.

The problem with centering the first window is that it makes the first case much less likely, and we probably start cascading immediately.

This may be a problem for centering applications in general, but it's not a problem for these two particular applications that typical users will run only once ever.

Would you accept a patch in WebKit that renders www.gnome.org differently than other sites?

This is fair and square in non-upstreamable downstream hack territory.

It looks obviously broken and wrong for the initial setup window to open in a corner of the screen instead of the center. These two applications will just have to be special.

If you insist, here is a scratch build with a distro-hack:
https://koji.fedoraproject.org/koji/taskinfo?taskID=94851170

But there is no way that this is going to be accepted upstream.

If you insist, here is a scratch build with a distro-hack:
https://koji.fedoraproject.org/koji/taskinfo?taskID=94851170

Thanks, I'll review it soon.

But there is no way that this is going to be accepted upstream.

For upstream, I would say only gnome-initial-setup needs to be special, and then only when it runs in its own special session. There's no need to center it when it's run under a normal gnome-shell session. Would tying the special behavior to session type rather than the application name feel less hacky?

For upstream, I would say only gnome-initial-setup needs to be special

Except that once we start hardcoding app-specific placement rules, everyone and their dog will queue up to argue why their app is special too and needs to be added to the list.

Would tying the special behavior to session type rather than the application name feel less hacky?

Not really, it would just make the hack more complex because we'd have to expose a hook for gnome-shell to inject the "special" apps.

If we want mode-specific behavior, I'd prefer to put the hack into an extension and enable it via the session mode.

Let's start by adding this hack to the Fedora package (after holiday season), so we can fix the immediate problem for F38. I couldn't figure out how to download the SRPM so I'm not sure exactly what you changed, but no doubt it's fine.

I think this merits further discussion upstream for how to ensure gnome-initial-setup and gnome-tour receive special treatment in a manner that would be suitable to upstream. I very highly doubt that upstream designers would be OK with either app launching off center in a corner of the screen, for example. They really are special.

Let's start by adding this hack to the Fedora package (after holiday season), so we can fix the immediate problem for F38. I couldn't figure out how to download the SRPM so I'm not sure exactly what you changed, but no doubt it's fine.

Hi @fmuellner, can you help with this please?

I think this merits further discussion upstream for how to ensure gnome-initial-setup and gnome-tour receive special treatment in a manner that would be suitable to upstream. I very highly doubt that upstream designers would be OK with either app launching off center in a corner of the screen, for example. They really are special.

Perhaps @aday could help with kicking off an upstream design discussion?

Hi @fmuellner, can you help with this please?

Sure: https://src.fedoraproject.org/rpms/mutter/pull-request/28

Landed this.