gnome-terminal ignores the --geometry location requests

[Péter Prőhle]

The more gnome-specific and detailed bug description:

the gnome-terminal either ignores or misinterprets the

--geometry=+0+0 , --geometry=+0-0 , --geometry=-0+0 and --geometry=-0-0

requests, while mate-terminal executes the correct positioning in the same environment (display manager and window manager).

In case of Wayland, the gnome-terminal ignores the requests listed above, while mate-terminal is correctly positioned, in contrary to the urban legend, that under Wayland such a positioning is imposibble.

In case of Xorg, the gnome-terminal positions itself into the corners of the rectangle containing the physical screens, even if that corner is not inside any of the physical screens.

I.e.: in case of Xorg the gnome-terminal is ready to position itself into a not visible corner of the virtual space contaning the physical screens instead of do the same as the mate-terminal can do: to position itself into a corner of the visible physical screen.

=== The bug of gnome-terminal is that it is not able to position intself into visible corners, while the mate-terminal can do it, ... and in general the usual graphical programs can do it since the 80's.

*** The original bug description:

The example "gnome-terminal --geometry=80x24+200+200" from the man page of gnome-terminal, does not work: while the 80x24 part of the geometry request is executed, the location +200+200 is overridden by the automatic positioning of new windows by the "Gnome Shell".

"--geometry=GEOMETRY Set the window size as COLSxROWS+X+Y. For example, 80x24 or 80x24+200+200."

The "+X+Y" part is ignored since I upgraded from 20.10 to 21.04 yesterday, just 4 hours after the official release.

[Daniel van Vugt (vanvugt)]

Please try logging into 'Ubuntu on Xorg' and tell us if that fixes the problem.

If the problem only happens in the default Ubuntu (which is Wayland) session then this is expected because windows only have control over their size, and never their position, in Wayland.

[Péter Prőhle (prohlep)]

"... this is expected because windows only have control over their size, and NEVER THEIR POSITION, in Wayland"

This is really a tragedy.

One significant benefit for me of the linux world over the micro and soft world, that I can POSITION the windows of a project from my shell script starting that project or during the project.

This is a design bug of Wayland, what needs to be fixed, regardless of the outcome of the test with "Xorg" (I will do after the funeral today).

If there was no other protocol, if the Wayland was the only protocol, even in that case this is a very serious design bug.

Hence I suggest to add "Wayland" to the "affects" list.

Do I have to leave the Wayland world, and switch back to Xorg?

But it was told, that Wayland is more advanced, that is the new direction.

Is the new direction in 2021 that I can not control the location of a new windows from script?

Then why it STILL is allowed, that we can control the location of a new window using a mouse?

Is it possibble --- as a further enhancement --- to disable also the window positioning by the mouse?

I do not find how to add "Wayland" to the "affects" list, help please. Thanks.

[Péter Prőhle (prohlep)]

I do not find how to add "Wayland" to the "affects" list, help please. Thanks.

"wayland-protocols (wayland-protocols) (Choose another project) wayland-protocols doesn't use Launchpad to track its bugs. If you know this bug has been reported in another bug tracker, you can link to it; Launchpad will keep track of its status for you."

[Daniel van Vugt (vanvugt)]

I think it's more of a security feature than a bug, so no I don't think it's appropriate to open a bug against the protocol itself. And Ubuntu was not involved in the design of Wayland, so complaining about it here won't achieve much.

As a workaround you can:

* Use Xorg sessions instead; or

* Find a gnome-shell extension that will remember window positions for you; or

* Just place windows manually.

[Péter Prőhle (prohlep)]

"* Find a gnome-shell extension that will remember window positions for you;"

Thanks, perhaps this is the best direction for me to proceed.

Hence I suggest to close this bug report as "successful".

[Péter Prőhle (prohlep)]

If the "GNOME shell" is able to ask Wayland to position the diverse elements of the destop, then the cooperation of the "GNOME shell" and "gnome-terminal" should be able to do the same.

Wayland can be asked to position the top bar to the top of the screen, to position the side bar to the left of the scereen, ... then "GNOME shell" and "gnome-terminal" should be able to request at Wayland the top-right or top-left positioning according to the original request of gnome-terminal --geometry=-0+0" or "gnome-terminal --geometry=+0+0" respectively.

To position someting into one of the 4 corners is so common request, that there shuld be a solution for that, --- hence this bug report is anyways

>>>> a real problem of the cooperation of "gnome-terminal" and "GNOME shell" with "Wayland".

Yet another issue:

"I think it's more of a security feature than a bug, ..." --- If Wayland doesn't support the positioning request due to security concerns, then even the size requests shuold be forbidden and make that features obsolote as weel, since a request for maximal possibble size implies the dangerous request of positioning, namely into the upper left corner, what positioning request is considered a security threat.

[Daniel van Vugt (vanvugt)]

I don't know enough about the Wayland protocol to comment further. You should find a way to contact the protocol authors instead.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

On second thoughts, client-side decoration means that Wayland apps do in a way set their own position when being dragged. So maybe there is a solution.

[Daniel van Vugt (vanvugt)]

Although dragging could be done by relative movements. Setting an absolute position does appear to be impossible in Wayland.

https://bugzilla.redhat.com/show_bug.cgi?id=1314967
https://askubuntu.com/questions/1104827/how-can-i-get-the-geometry-option-working-with-the-gnome-terminal-command-in-a-t

[Péter Prőhle (prohlep)]

Sorry to oppose the opinion of those who probaly know the system much better than me, but it is simply NOT TRUE that neither Ubuntu nor especially Mutter is responsible for the huge step backward, the missing positioning of windows on the screen what was always possible since the 80's. AND it is neither true, that USING Wayland becomes impossible to handle the positioning.

Wayland side: now I am in Mutter over Wayland w/o Xorg, and the top bar on the screen is NOT appearing randomly depending on the situation, but it is always aligned on the top of the actual screen, and it never extends to the other screen. HENCE the location of top, the location of top-left corner and the location of the top-right corner CAN BE handled, --- and I need exactly that:

        gnome-terminal --geometry=+0+0 == I wish a terminal into the top-left corner

        gnome-terminal --geometry=-0+0 == I wish a terminal into the top-right corner

Ubuntu side: it is not Wayland but Ubuntu who made DEFAULT this Wayland w/o Xorg any warnings at the login screen, and even the fact that "the current login will fall into Wayladn w/o Xorg OR there will be Xorg services" IS HIDDEN, NOT SHOWN rigth where the account name and the password is due. HENCE Ubuntu as a strategic decider IS involved in the case.

Mutter side: it is not true that Mutter is not capable to handle the positioning w/o Xorg, there are PLENTY evidences and indications, that Muter DOES EXACLTY KNOW where the edges of my two physical screens are.

HENCE in spite of the backward downgrading of the Wayland protocol, Mutter is NOT behindered in knowing the rectangles of my two physical creens.

Therefore Mutter IS also responsible, that the positioning of a gnome-terminal dos not work any longer if the default of Ubuntu is Wayland w/o Xorg.

Sorry, I understand, that I could invoke the Xorg services which are now considered obsolote by Ubuntu, ...

... but I use computers since 1972, I was an active adult in parallel with the development of computer systems. HENCE my experience, that better not to deviate from the defaults, otherwise I will have more trubles, than to stand out somehow the defaults.

That is why so interesting for me, that the traditional standard positionings of windows should work even over raw Wayland w/o Xorg services.

This is the derivation, why I think that it is proven that the categorisation of "invalid" is wrong.

Since I am the first reporter, therefore I can not switch this "invalid" back to the previous "confirmed", henc my only possibility now to change it back to "new", SORRY for that, but the "invalid" is not true, and it would behinder the handling of the problem if I leve it "invalid".

I changed only at "mutter", since the gnome-terminal looks forwarding the positioning requests.

Hence I have choosed "opinion" for the terminal, since there is no better choice for the situation, that the proper use of the gnome-terminals are behindered, actually that was the reason why we descovered the problem around Wayland and the default decison of Ubuntu, but the gnome-terminal looks not responsible for it's insufficient behaviour in the daily use.

[Péter Prőhle (prohlep)]

A very personal comment: the main reason why I use linux exclusively since 1994 is that I can work in character terminal using the unix command line programming environment for my everyday goals (teaching and researching math and computational math). This is the reason why I am so sensitive for the missing positioning of my terminals, since I frequently invoke and kill terminals, depending on the actual needs, I have never abandoned windows waiting for nothing. Sorry for this very personal comment, but I wanted to explain why I wish not to consider "invalid" ...

[Péter Prőhle (prohlep)]

The bug is clearly stated, reproducible and confirmed by others as well.

Hence it can not be ONLY "invalid + opinion + opinion" at 3 packages, and no package is mentioned with "new" or "confirmed".

It is acceptable, if someone's opinion is that "mutter is not new but opinion only".

But it is not acceptable, if the same person does not mark any other package or the Ubuntu as a whole as "new" or "confirmed", --- since if all the packages mentioned already becomes either "invalid" or "opinion", then the bug report is rejected in fact, what would be a wrong decision since the bug is there confiredly.

In fact, if wayland protocol is not advanced enough to provide the original standard facility to handle the positioning of windows, then ALL the packages that wish to use this original standard instead of the new facilities, all of them have the bug, because it is a buggy behaviour to rely on something what is not offerd by the underlying wayland.

Therefore the releases 21.04 as a whole has this bug: makes something defuault what brakes the all the packages which wish to position the main window of it's own applications. A disturbing exampe:

$ wmctrl -d
Cannot get current desktop properties. (_NET_CURRENT_DESKTOP or _WIN_WORKSPACE property)
$ wmctrl -l
$

wmctrl -d does not "List all desktops managed by the window manager."

wmctrl -l does not "List the windows being managed by the window manager."

While the same "wmctrl" packages works fine with Xorg.

However the "wmctrl" can not be added to the affected packages, since the bugs.launchpad does not accept "wmctrl" as an existing package!

[Péter Prőhle (prohlep)]

The definition of "confirmed" is that "Verified by someone other than the
reporter.", hence in case of "gnome-terminal" it was wrong to remove the
"confirmed" tag, since someone other than me reported as well that the
"gnome-terminal" is affected, and hence it is totally right, that the
"gnome-terminal" is non the list named "Affects" with the status of
"Confirmed".

No one told, that "gnome-terminal" is mainly responsible for the bug, but the
title of the list is *not* "The responsible packages", *but* "Affects".

And it is "Confirmed" that "gnome-terminal" is "Affected".

Henc I ask someone else, especially who removed it, to put back the
"Confirmed" status. Since the "opinion" or "invalid" vould be missleading,
and simply the opposite of the real truth.

[Péter Prőhle (prohlep)]

"Although dragging could be done by relative movements. Setting an absolute position does appear to be impossible in Wayland."

If it was really impossibble, then how the Gnome shell or any window manager can position *itself*?

We see, that the diverse components of the diverse window managers does not float around in an uncontrolled way, but *somehow* they are able to tell to Wayland where to position that components.

The gnome-terminal should be able to do the same, either directly ask Wayland, or indirectly ask the window manager, in return of the --geometry argument.

Hence it is confirmed, that the problem in question is

1: either a severe bug of the windows manager itself

2: or a severe bug of the applications receiving the --geometry arguments.

I am extremly upset of keeping this bug report on the level of "opinion".

There are so uncomfortable problems around the terminal windowing since 21.04,

        https://bugs.launchpad.net/ubuntu/+bug/1925823

        https://bugs.launchpad.net/ubuntu/+bug/1928317

        https://bugs.launchpad.net/ubuntu/+bug/1916890

        https://bugs.launchpad.net/ubuntu/+bug/1888098

        https://bugs.launchpad.net/ubuntu/+bug/1288655

        or the too thick capture bar of a terminal wastes the vertical space

that I seriousely consieder to change to other distro. My work depends heavily on the comfort of character terminals I became used to in the late 80's, and since 21.04 the level of comfort reached a treshold of pain.

And now, I can not achieve that this serious bug is taken seriously.

This bug crosses the basics of the windowing standars hold already for decades.

Perhaps one of the iconic feature of a windowing system is that an application can position the other windows.

This was possibble already in the mid 80's!

I simply do not understand what is going here around the Wayland, while on the other hand it seems to be a very promising progress in the technology of the windowing system. But why it is a so big issue to position a window by an other application?

[Péter Prőhle (prohlep)]

OK, if you think that Wayland is responsible for the but, then:

1: this but must be upstreamed to the developers of the Wayland protocol

2: and this bug is also a bug of the "21.04 release as a whole", since it is a bug that it makes this buggy Wayland as default.

I understand that this bug reporting system is package oriented, ... ok, then the base package of "21.04 release as a whole" which defines what packages belong to the release and what are the default settings HAS this bug.

[Péter Prőhle (prohlep)]

I have just made a couple of tests, and the result is:

1: mate-terminal interprets correctly the --geometry over the both of Wayland and Xorg

** hence it was rigth when I derived "theoretically" from the behaviour of the Gnome Shell, that also over Wayland the client programs can position their windows! Now we see, that even the mate-terminal is capable to position it's window on the base of my --geometry requests

2: gnome-terminal misinterprets the --geometry over Xorg but does something (see below)

3: gnome-terminal ignores the --geometry over Wayland

** hence the gnome-terminal is the package which has serious difficulties to interpret the --geometry requests, ... in detail:

If the bottom of "left screen" is higher than the bottom of the "right screen" and the top of the "left screen" is also higher than the top of the "right screen", and the left bar is hidden, then IN XORG:

gnome-terminal --geometry=+0+0 is not at the left edge

gnome-terminal --geometry=+0-0 is neither at the left edge, but even worse: the bottom of the terminal, --- where we work usually, --- is below the left screen

gnome-terminal --geometry=-0+0 is also at a wrong location: the top of it is over the top of the right screen

gnome-terminal --geometry=-0-0 this is the only case, where it is at the right position: in the lower right corner, bravo!

BUG / 1: in case of Xorg, the gnome-terminal takes the smallest rectangle containing the two screens, subtractes the hidden left bar asif it was shown there, and regardles whether there is a proper physical screen at the corner in question, it puts the window there, even if the user can not see it.

BUG / 2: in case of Wayland, the gnome-terminal ignores the --geometry=-0+0 alike requests, while mate-terminal demonstrates, that all of these kind of requests can be correctly satisfied, even in spite of the urban legend, that it is imposibble over Wayland.

[Péter Prőhle (prohlep)]

tags:added: impish

[Péter Prőhle (prohlep)]

This bug is still there, I am interested in discussing it, but nobody assigned this bug to anybody.

[Köveshegyi László (koeves)]

It is annoying to see, that Linux applications are going be worse and worse!
I am using Linux since 1994, so I know, what I say!!

More than two years since this bug was reported, and the bug is still exists.

Just another example, copy/paste from firefox is not working, worse, the suggested workarounds sometimes
are working, but not always!