[Desktop-packages] [Bug 2064073] Re: gnome-terminal display lags on keypresses
*** This bug is a duplicate of bug 2059847 *** https://bugs.launchpad.net/bugs/2059847 It's a bug in the mutter package; a fix is on the way. See bug #2059847. ** This bug has been marked a duplicate of bug 2059847 Input lag or freezes on Nvidia desktops with X11 after logging "MetaSyncRing: Sync object is not ready -- were events handled properly?" -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2064073 Title: gnome-terminal display lags on keypresses Status in gnome-terminal package in Ubuntu: New Bug description: For a few weeks now my terminal has had an odd hang of up to nearly a second. Usually on the first character I type in a line. I'd say it happens on at least one out of 5 times. At first I thought that maybe it was something that bash was doing in the background, but I went to a bare Linux VT (Ctrl+Alt+F5) and there is never any hangup there. I also installed and tried stterm, and that doesn't appear to have the same problem at all either. I tried using the X.org display driver, rather than the Nvidia one (I have an RTX 2770) and that seemed to make the problem go away in gnome-terminal. But oddly, there aren't any similar hangs in games or anything else, just gnome-terminal. Although I think I also experienced something similar in the Ubuntu settings app in text input fields. So maybe there's something in common between those apps? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-28.29~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-28-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Apr 28 22:38:23 2024 InstallationDate: Installed on 2021-05-05 (1089 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2064073/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper with Ambiance/Radiance
> .background.decorated:backdrop {
This still doesn't feel entirely good. The background can be applied to
a window, in which case it needs to be restricted to the .decorated
property; but I presume it can also be applied to many other GTK widgets
in which case it shouldn't be restricted, at least in order not to
change the current behavior because I don't know how to test any change.
So if I'd like to perform the smallest possible change, the smallest
possible impact of the change (preferably: no other change than fixing
this bug) then I'd need to select for "either window.decorated or
something non-window", which I'm not sure how to express in CSS (at
least not in a single step).
Maybe leave the first block untouched, and then revert its effect in the
next rule for undecorated windows (effectively moving the above-proposed
user workaround into the main theme, restricted to the element being a
window).
So the theme itself would go like (the first block is unchanged, the
second one is newly added):
.background:backdrop {
color: @backdrop_fg_color;
box-shadow: inset -1px 0 shade (@bg_color, 0.94);
}
window.background:not(.decorated):backdrop {
box-shadow: none;
}
Dunno how much it makes sense. Would really love to get it reviewed by a
CSS expert :)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1986450
Title:
Visual artifact 1px vertical white line right side of the wallpaper
with Ambiance/Radiance
Status in gnome-shell package in Ubuntu:
New
Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu:
New
Status in ubuntu-themes package in Ubuntu:
New
Bug description:
After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that
there is a 1px wide vertical white line on the desktop that appears
whenever an application has focus. It is on the right side of the
monitor, covering the background wallpaper but not the menu.
Workaround: in Displays, change scale to something else than 100% and then
change back to 100%. That white vertical line will stay at the former 100%
window size location until the Settings window is closed. It disappears when
the Settings is closed.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2018-04-27 (1570 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: gnome-shell 42.2-0ubuntu0.2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39
RelatedPackageVersions: mutter-common 42.2-0ubuntu1
Tags: wayland-session jammy
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper with Ambiance/Radiance
DING developer's response is basically that they clear the "decorated"
property of the window, and the theme should handle that.
Based on this, I think the correct solution for the Ambiance/Radiance
themes is to further restrict the offending block with the ".decorated"
selector, i.e.
.background.decorated:backdrop {
color: @backdrop_fg_color;
box-shadow: inset -1px 0 shade (@bg_color, 0.94);
}
or for the user's own gtk.css to select for its negated
":not(.decorated)" for the workaround:
.background:not(.decorated):backdrop {
box-shadow: none;
}
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1986450
Title:
Visual artifact 1px vertical white line right side of the wallpaper
with Ambiance/Radiance
Status in gnome-shell package in Ubuntu:
New
Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu:
New
Status in ubuntu-themes package in Ubuntu:
New
Bug description:
After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that
there is a 1px wide vertical white line on the desktop that appears
whenever an application has focus. It is on the right side of the
monitor, covering the background wallpaper but not the menu.
Workaround: in Displays, change scale to something else than 100% and then
change back to 100%. That white vertical line will stay at the former 100%
window size location until the Settings window is closed. It disappears when
the Settings is closed.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2018-04-27 (1570 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: gnome-shell 42.2-0ubuntu0.2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39
RelatedPackageVersions: mutter-common 42.2-0ubuntu1
Tags: wayland-session jammy
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper with Ambiance/Radiance
Let's see what DING devs think: https://gitlab.com/rastersoft/desktop- icons-ng/-/issues/315 ** Bug watch added: gitlab.com/rastersoft/desktop-icons-ng/-/issues #315 https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/315 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1986450 Title: Visual artifact 1px vertical white line right side of the wallpaper with Ambiance/Radiance Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in ubuntu-themes package in Ubuntu: New Bug description: After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu. Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2018-04-27 (1570 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: gnome-shell 42.2-0ubuntu0.2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 RelatedPackageVersions: mutter-common 42.2-0ubuntu1 Tags: wayland-session jammy Uname: Linux 5.15.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
> Wow, I didn't realize that people were still trying to use Ambiance and Radiance (from source package ubuntu-themes) with Ubuntu 24.04 LTS. I'd love to switch to Adwaita or Yaru, but I prefer to have dark window header and light window contents, and I haven't found yet how to do it in those. (I'm also in the process of evaluating whether I want to leave Unity behind and switch to GNOME or its Ubuntu desktop flavor... that's how I came across this issue.) > Would you like to submit a patch and subscribe ubuntu-sponsors? The thing is, I'm not confident that I'm doing the right thing and not causing side effects elsewhere. I'm even unsure at this moment whether the fix needs to go into the theme, or the extension should ship the override. I'd much rather prefer if someone familiar with GTK theming/CSS could take over from here. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1986450 Title: Visual artifact 1px vertical white line right side of the wallpaper Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in ubuntu-themes package in Ubuntu: New Bug description: After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu. Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2018-04-27 (1570 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: gnome-shell 42.2-0ubuntu0.2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 RelatedPackageVersions: mutter-common 42.2-0ubuntu1 Tags: wayland-session jammy Uname: Linux 5.15.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
Without root access (or being worried of an update overwriting the
changes), this is how I could fix it as a user.
I've placed this in my ~/.config/gtk-3.0/gtk.css file:
window.desktopwindow.background:backdrop {
box-shadow: none;
}
Don't ask why it's gtk-3.0 and not 3.20 or 4.0, I have no clue.
The "window.desktopwindow" selector is something I've found in gnome-
shell-extension-desktop-icons-ng's source. It's a more specific selector
than the one in the theme, hence takes precedence over that. Without
this selector they would be of the same precedence, and for some reason
the one in the theme is used, the one in the user's config is ignored.
And GTK doesn't seem to support "!important".
This extra selector luckily gives some confidence that the rule probably
doesn't have an effect on others. (However, the disclaimer from my
previous comment still applies.)
In extension-manager toggle the said extension back and forth to apply
the change.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1986450
Title:
Visual artifact 1px vertical white line right side of the wallpaper
Status in gnome-shell package in Ubuntu:
New
Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu:
New
Status in ubuntu-themes package in Ubuntu:
New
Bug description:
After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that
there is a 1px wide vertical white line on the desktop that appears
whenever an application has focus. It is on the right side of the
monitor, covering the background wallpaper but not the menu.
Workaround: in Displays, change scale to something else than 100% and then
change back to 100%. That white vertical line will stay at the former 100%
window size location until the Settings window is closed. It disappears when
the Settings is closed.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2018-04-27 (1570 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: gnome-shell 42.2-0ubuntu0.2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39
RelatedPackageVersions: mutter-common 42.2-0ubuntu1
Tags: wayland-session jammy
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
It's /usr/share/themes/{Amb,Rad}iance/gtk-3.20/gtk-widgets.css line 18:
.background:backdrop {
color: @backdrop_fg_color;
box-shadow: inset -1px 0 shade (@bg_color, 0.94);
}
Change that to 0 (or I guess you could remove the entire line or even
the entire segement).
(I'm not a gtk css expert by any means, I don't know if this is _the_
proper way to solve this issue, nor whether it causes problems
elsewhere.)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/1986450
Title:
Visual artifact 1px vertical white line right side of the wallpaper
Status in gnome-shell package in Ubuntu:
New
Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu:
New
Status in light-themes package in Ubuntu:
New
Bug description:
After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that
there is a 1px wide vertical white line on the desktop that appears
whenever an application has focus. It is on the right side of the
monitor, covering the background wallpaper but not the menu.
Workaround: in Displays, change scale to something else than 100% and then
change back to 100%. That white vertical line will stay at the former 100%
window size location until the Settings window is closed. It disappears when
the Settings is closed.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2018-04-27 (1570 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: gnome-shell 42.2-0ubuntu0.2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39
RelatedPackageVersions: mutter-common 42.2-0ubuntu1
Tags: wayland-session jammy
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
I've modified /usr/share/themes/Ambiance (recursively), search-replacing all the "1px" to "10px", and (after logging out and back in) the line at the desktop's right edge looks about 10px wide. So we're on the right track. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1986450 Title: Visual artifact 1px vertical white line right side of the wallpaper Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in light-themes package in Ubuntu: New Bug description: After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu. Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2018-04-27 (1570 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: gnome-shell 42.2-0ubuntu0.2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 RelatedPackageVersions: mutter-common 42.2-0ubuntu1 Tags: wayland-session jammy Uname: Linux 5.15.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
Looks remotely related: https://askubuntu.com/questions/927893/white- line-on-left-of-ubuntu-launcher-when-desktop-icons-enabled -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1986450 Title: Visual artifact 1px vertical white line right side of the wallpaper Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in light-themes package in Ubuntu: New Bug description: After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu. Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2018-04-27 (1570 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: gnome-shell 42.2-0ubuntu0.2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 RelatedPackageVersions: mutter-common 42.2-0ubuntu1 Tags: wayland-session jammy Uname: Linux 5.15.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1986450] Re: Visual artifact 1px vertical white line right side of the wallpaper
I can reproduce the problem on two computers, both running fully-updated 24.04 beta. For me, the bug appears if all of these circumstances are met: - /org/gnome/desktop/interface/gtk-theme is Ambiance or Radiance - one of the windows is focused - the Desktop Icons NG (DING) extension is enabled in extensions-manager The first two matches earlier observations here, the third one looks like new information. As you toggle the DING extension, this vertical 1px wide bar quickly rushes to/from the right edge of the screen. It suggests that it's not that the background isn't drawn properly, it's rather that DING explicitly draws this line on top of it (and shows a brief animation when getting enabled/disabled). This also aligns with the observation that a window needs to be focused -- probably if focus is taken away from windows by clicking on the background then DING receives the focus, and apparently it's DING's unfocused state combined with Ambi/Radi themes that results in this glitch. I'm almost certain that this is a bug either in DING or in the Ambi/Radi themes. It's probably not related to the graphics card. One of these computers has an NVidia (nouveau driver), the other one has ATI Radeon. Scaling is probably unrelated, too. The glitch is seen on both Xorg and Wayland. ** Tags added: noble ** Also affects: light-themes (Ubuntu) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1986450 Title: Visual artifact 1px vertical white line right side of the wallpaper Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in light-themes package in Ubuntu: New Bug description: After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu. Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DisplayManager: gdm3 DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2018-04-27 (1570 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Package: gnome-shell 42.2-0ubuntu0.2 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 RelatedPackageVersions: mutter-common 42.2-0ubuntu1 Tags: wayland-session jammy Uname: Linux 5.15.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1986450/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2061306] Re: gnome-terminal is super laggy
*** This bug is a duplicate of bug 2059847 *** https://bugs.launchpad.net/bugs/2059847 Duplicate of bug 2059847. See also: https://askubuntu.com/questions/1509058/input-delay-on- terminal-ubuntu-22-04-4 ** This bug has been marked a duplicate of bug 2059847 Input lag or freezes on Nvidia desktops with X11 after logging "MetaSyncRing: Sync object is not ready -- were events handled properly?" -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2061306 Title: gnome-terminal is super laggy Status in gnome-terminal package in Ubuntu: New Bug description: Whenever I type something in the terminal, or when I edit files within vi/emacs I see the output show-up on the screen after some time, like few seconds. Also, when I use other sw, like htop, it works really slow. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-27.28~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-27-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Apr 14 19:37:44 2024 InstallationDate: Installed on 2024-04-14 (0 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2061306/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2059847] Re: Input lag or freezes on Nvidia desktops with X11 after logging "MetaSyncRing: Sync object is not ready -- were events handled properly?"
> Upstream Gnome 46 made a lot of changes recently to improve performance and input lag in Gnome-Terminal. Those changes are separate from this bug. Exactly. > I don't know whether those changes were backported to Ubuntu 22.04, which ships Gnome 42. They weren't, and almost certainly won't be. > the graphs are only talking about lag in the neighborhood of 40-50ms, which is probably just barely perceptible. Exactly. If anyone's having latency problems big enough that make them follow this bug and try mutter packages from a PPA, then upgrading the terminal won't fix them. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2059847 Title: Input lag or freezes on Nvidia desktops with X11 after logging "MetaSyncRing: Sync object is not ready -- were events handled properly?" Status in Mutter: Fix Released Status in mutter package in Ubuntu: Fix Committed Status in mutter source package in Jammy: In Progress Status in mutter source package in Mantic: In Progress Status in mutter source package in Noble: Fix Committed Bug description: [ Impact ] Input or the entire screen may freeze at times on systems using the Nvidia Xorg driver with GNOME. [ Test Plan ] 0. Set up a desktop with Nvidia driver 545 or 550. 1. Log into Ubuntu, ensuring it's a Xorg session. 2. Open a Terminal, resize it vigorously, and type several lines of text. 3. Run: journalctl -b0 | grep MetaSyncRing 4. Verify the above command does NOT show "MetaSyncRing" messages such as: Window manager warning: MetaSyncRing: Sync object is not ready -- were events handled properly? Window manager warning: MetaSyncRing: Sync object is not ready -- were events handled properly? Window manager warning: MetaSyncRing: Sync object is not ready -- were events handled properly? Window manager warning: MetaSyncRing: Too many reboots -- disabling [ Where problems could occur ] Anywhere in Nvidia (proprietary driver) Xorg sessions since the code being modified is only used with that driver. [ Original Description ] There is a noticeable delay in input while using the native terminal. I belive it was caused by a recent software update, as this issue is relatively new. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Mar 30 19:57:13 2024 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- InstallationDate: Installed on 2024-03-30 (0 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) SourcePackage: ubiquity Symptom: installation UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2059847/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2059847] Re: Input lag in native terminal on Nvidia desktops with X11
@ Daniel van Vugt, The faulty change has a timestamp of 22 Feb, and the package began to arrive at users probably on 29 Mar. That's a difference of 5 weeks. I'm not familiar with Ubuntu's internal procedures, I don't know how things work, which component (e.g. building packages, QA, somewhat wider testing in -proposed etc.) took how long, but overall 5 weeks is pretty long. As I understand from comments in upstream mutter#3384, it's not immediately obvious to you guys what and why exactly goes wrong and how to properly fix all this. It needs investigation first. This means that my rough guess is that, if everything goes well, it could take maybe 1-2 weeks to develop a fix and another 5 weeks for the regular release prodecure? Do you have any wild estimate on how many people were affected by the old bug that this update fixed, and how many are affected by the new one? The old one seems to be about software rendering, i.e. when running inside a virtual machine. The new one seems to affect people using an NVidia video card with its proprietary driver. Sounds to me that the new issue probably affects way more people. I'm wondering: Is there some guideline, best practice, runbook rule etc. describing how to handle such a situation? If so, what does it say? Wouldn't the right thing be to release new updated packages that revert this change ASAP (like, in a day or two at most, skipping QA and -proposed etc.), and then start to work on the proper fix that fixes both issues at the same time? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2059847 Title: Input lag in native terminal on Nvidia desktops with X11 Status in Mutter: New Status in mutter package in Ubuntu: In Progress Bug description: There is a noticeable delay in input while using the native terminal. I belive it was caused by a recent software update, as this issue is relatively new. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Mar 30 19:57:13 2024 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- InstallationDate: Installed on 2024-03-30 (0 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) SourcePackage: ubiquity Symptom: installation UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2059847/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2059847] Re: Input lag in native terminal on Nvidia desktops with X11
> [amirsalarsafaei] I downgraded my mutter to 45.0-3ubuntu3 but the issues persists Mentioning just in case: You should downgrade all the packages built from mutter's source that you have installed, including libmutter-13-0, mutter-common, mutter- common-bin etc. (Or at least I don't know which one really matters.) And then you need to log out of your graphical session and log back in, otherwise the previous mutter keeps running. I'm pointing these out because this suspected mutter change is the only relevant that has a reasonable chance of causing the issues, and multiple people have reported that downgrading fixed the issue for them, yet you report that it didn't for you. At this point we have to consider that you might have made a mistake during downgrading, rather than the bug being somewhere else. > how to downgrade my mutter to specific version without apt? I'd download these older packages from packages.ubuntu.com (as you presumably already did with mutter), install them with `dpkg -i`, and put them on "hold" (something like: `echo "mutter hold" | sudo dpkg --set-selections`, and repeat for the other packages). > an interesting thing is that the gnome-console is fine but other vte based terminals have severe lag. gnome-console uses gtk4 (and in turn the gtk4 variant of vte), others use gtk3 (and in turn the gtk3 variant of vte). (I'm just stating this as a fact. Don't ask how it triggers the bug to manifest with one but not with the other, I don't know.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2059847 Title: Input lag in native terminal on Nvidia desktops with X11 Status in Mutter: Unknown Status in mutter package in Ubuntu: Triaged Bug description: There is a noticeable delay in input while using the native terminal. I belive it was caused by a recent software update, as this issue is relatively new. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Mar 30 19:57:13 2024 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- InstallationDate: Installed on 2024-03-30 (0 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) SourcePackage: ubiquity Symptom: installation UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2059847/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2059847] Re: Input lag in native terminal
Seems to be reported upstream at https://gitlab.gnome.org/GNOME/mutter/-/issues/3384. The upstream bug unfortunately also made it into Ubuntu update packages in https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2054510. ** Also affects: mutter (Ubuntu) Importance: Undecided Status: New ** Bug watch added: gitlab.gnome.org/GNOME/mutter/-/issues #3384 https://gitlab.gnome.org/GNOME/mutter/-/issues/3384 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2059847 Title: Input lag in native terminal Status in gnome-terminal package in Ubuntu: Confirmed Status in mutter package in Ubuntu: New Bug description: There is a noticeable delay in input while using the native terminal. I belive it was caused by a recent software update, as this issue is relatively new. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13 Uname: Linux 6.5.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Mar 30 19:57:13 2024 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- InstallationDate: Installed on 2024-03-30 (0 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) SourcePackage: ubiquity Symptom: installation UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2059847/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2054510] Re: Incomplete screen redraws in virtual machines running Xorg
Another most likely duplicate: https://github.com/gnome- terminator/terminator/issues/899 And yet another most likely duplicate: https://bbs.archlinux.org/viewtopic.php?id=294164. Here a user claims that downgrading gnome-shell and mutter fixes the issue, and points to upstream issue https://gitlab.gnome.org/GNOME/mutter/-/issues/3384. Based on that report, some non-VTE-based apps are also affected. It really looks like the bug is in upstream Mutter, and made it into downstream updates as well. ** Bug watch added: github.com/gnome-terminator/terminator/issues #899 https://github.com/gnome-terminator/terminator/issues/899 ** Bug watch added: gitlab.gnome.org/GNOME/mutter/-/issues #3384 https://gitlab.gnome.org/GNOME/mutter/-/issues/3384 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2054510 Title: Incomplete screen redraws in virtual machines running Xorg Status in Mutter: Fix Released Status in mutter package in Ubuntu: Fix Committed Status in mutter source package in Jammy: Fix Released Status in mutter source package in Mantic: Fix Released Status in mutter source package in Noble: Fix Committed Bug description: [ Impact ] When using software rendering on Xorg (so usually just in VMs), some parts of app windows may fail to redraw. https://gitlab.gnome.org/GNOME/mutter/-/issues/2880 [ Test Plan ] 1. Set up a virtual machine without graphics acceleration. 2. Log into 'Ubuntu on Xorg'. 3. Open Settings > About and verify Graphics = llvmpipe (or "Software Rendering"), and Windowing System = X11. 4. sudo snap install chromium 5. Open Chromium and find a web page with lots of text. Plain text without any links and staying at the top of the page will work best because you don't want to trigger any scrolling. 6. Start selecting text with the mouse and while holding the button move the mouse up and down rapidly. Avoid triggering any page scrolling. 7. Release the mouse button in roughly the middle of the area of text that was selected. 8. Verify the remaining text selection is contiguous and not broken into multiple disconnected text selections (the bug). 9. Repeat steps 7 and 8 several times to be sure. [ Where problems could occur ] The fix adds a new synchronization point between the compositor and X server. This should be inconsequential, although there is a "sync ring" in mutter used for this, and if a mistake occurs there then other parts of the desktop could appear to stop responding in Xorg sessions. [ Other Info ] This is a regression that started in 3.37.3 due to https://gitlab.gnome.org/GNOME/mutter/-/commit/551101c65cda. To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2054510/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2054510] Re: Incomplete screen redraws in virtual machines running Xorg
During the last barely more than 24 hours, at least 4 people have reported/confirmed heavy latencies newly appearing in their GNOME Terminal. One person with Ubuntu 23.10 and two people with Ubuntu 22.04 (one of which comments has just been removed). https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8070 https://askubuntu.com/questions/1509058/input-delay-on-terminal- ubuntu-22-04-4 GNOME Terminal, and its underlying VTE terminal emulator widget, did not receive any updates recently in Ubuntu, so it's highly suspected that the bug sneaked in into some other component (or maybe a valid change in some other component triggered a yet undiscovered bug in VTE / GNOME Terminal). Even though I cannot reproduce the issue myself, I went through the log of my recent apt updates, and this mutter change is the only one seemingly relevant (see https://gitlab.gnome.org/GNOME/gnome- terminal/-/issues/8070#note_2067801 onwards); in fact, the summary showing a suspiciously high correlation with the new problem. At this point I don't have anything concrete, and it might just be a random coincidence, but I highly suspect that this recent mutter update introduces severe lagging in GNOME Terminal (and other terminal emulators using VTE's GTK3 version). ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #8070 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8070 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2054510 Title: Incomplete screen redraws in virtual machines running Xorg Status in Mutter: Fix Released Status in mutter package in Ubuntu: Fix Committed Status in mutter source package in Jammy: Fix Released Status in mutter source package in Mantic: Fix Released Status in mutter source package in Noble: Fix Committed Bug description: [ Impact ] When using software rendering on Xorg (so usually just in VMs), some parts of app windows may fail to redraw. https://gitlab.gnome.org/GNOME/mutter/-/issues/2880 [ Test Plan ] 1. Set up a virtual machine without graphics acceleration. 2. Log into 'Ubuntu on Xorg'. 3. Open Settings > About and verify Graphics = llvmpipe (or "Software Rendering"), and Windowing System = X11. 4. sudo snap install chromium 5. Open Chromium and find a web page with lots of text. Plain text without any links and staying at the top of the page will work best because you don't want to trigger any scrolling. 6. Start selecting text with the mouse and while holding the button move the mouse up and down rapidly. Avoid triggering any page scrolling. 7. Release the mouse button in roughly the middle of the area of text that was selected. 8. Verify the remaining text selection is contiguous and not broken into multiple disconnected text selections (the bug). 9. Repeat steps 7 and 8 several times to be sure. [ Where problems could occur ] The fix adds a new synchronization point between the compositor and X server. This should be inconsequential, although there is a "sync ring" in mutter used for this, and if a mistake occurs there then other parts of the desktop could appear to stop responding in Xorg sessions. [ Other Info ] This is a regression that started in 3.37.3 due to https://gitlab.gnome.org/GNOME/mutter/-/commit/551101c65cda. To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2054510/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1493964] Re: Gnome terminal scrollbars background is not themable
The downstream patch added by Ubuntu to address this issue is suspected to cause a crash, see lp:2049923. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1493964 Title: Gnome terminal scrollbars background is not themable Status in GNOME Terminal: Won't Fix Status in gnome-terminal package in Ubuntu: Fix Released Bug description: This is related to bug #1451924, however upstream proposed fix is not yet ready to use. Basically gnome-terminal provides a scroll bar which is boxed horizontally with the terminal itself, and currently the scrollbar background is not inherited from terminal itself, leading to a white background. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-terminal/+bug/1493964/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2049923] Re: gnome-terminal freezing, then crashing
H trying to make sense of it...
There's hardly any code from gnome-terminal itself in the stack trace,
most of them is from GTK.
#10 is from update_color_scheme():
if (gdk_rgba_hash (>bg_color) != gdk_rgba_hash ())
{
priv->bg_color = bg;
g_object_notify (G_OBJECT (screen), "bg-color"); < this line
}
#0 gtk_widget_queue_draw() is called by #1 g_closure_invoke(), so the
former is called as a callback registered earlier. The only place where
this method can be registered as a callback is in
terminal_screen_container_constructed():
g_signal_connect_swapped (priv->screen, "notify::bg-color",
G_CALLBACK (gtk_widget_queue_draw),
priv->vscrollbar);
and it's indeed about the same "bg-color" signal, so I'm quite sure this
is where we are.
Now, this is not part of upstream gnome-terminal. It's added by Ubuntu's
"scrollbar-background-theming.patch", as per lp:1493964, which tries to
theme the scrollbar to match the terminal screen's main background
color.
I suspect that toggling the scrollbar's visibility might eliminate this
bug for you. Also, if you're familiar with recompiling Ubuntu packages
with tiny modifications, I'm fairly confident that dropping this patch
should fix the problem. Installed packages, modules, settings, whatnot
related to GTK scrollbars (e.g. choosing whether to use an overlay or
traditional one, etc.) might easily be relevant to whether this bug
occurs.
I'm not an Ubuntu developer, and I'm not affiliated with Ubuntu or
Launchpad. I'm a GNOME Terminal developer. At this point, I suspect with
99%+ certainity that upstream GNOME Terminal is not affected by the bug,
it's introduced by Ubuntu (or maybe Debian). Therefore I'm sorry but I'm
afraid I won't be able to help any further, the investigation and fixing
should be continued by Ubuntu devs.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/2049923
Title:
gnome-terminal freezing, then crashing
Status in gnome-terminal package in Ubuntu:
New
Bug description:
First: It's very hard to reproduce, but it happens to me about once per week.
If often open new windows or split windows out from tabs. And then it
happens. First it becomes unresponsive, and then after about 2-3 seconds it
simply closes all instances.
[328830.780749] gnome-terminal-[117706]: segfault at 460742 ip
7fdb2fb45611 sp 7ffdb8c5fda0 error 4 in
libgtk-3.so.0.2406.32[7fdb2f883000+38f000] likely on CPU 4 (core 4, socket 0)
[328830.780761] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89
44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85
c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6
48 89
[329377.925310] gnome-terminal-[120116]: segfault at 2f0774 ip
7f86af745611 sp 7ffc9943c5c0 error 4 in
libgtk-3.so.0.2406.32[7f86af483000+38f000] likely on CPU 2 (core 2,
socket 0)
[329377.925324] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89
44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85
c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6
48 89
unfortunately, apport isn't automatically creating a crash report.
ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: gnome-terminal 3.49.92-2ubuntu1
ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3
Uname: Linux 6.5.0-14-generic x86_64
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Fri Jan 19 16:48:43 2024
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to mantic on 2023-10-17 (94 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2049923/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2049923] Re: gnome-terminal freezing, then crashing
> change to that new tab This is a no-op because the new tab is automatically swithed to, correct? --- Are you on Wayland or X11? This command should answer it: echo $XDG_SESSION_TYPE --- I cannot reproduce the crash. The steps to reproduce are very simple, so I believe we should have received more crash reports. There must be something weird, unique going on in your machine, at least that's what I suspect. Have you customized your shell prompt, for example? It might be relevant. Or do you have unusually large or unusually small gnome- terminal windows, or anything nontypical in the terminal's default config? --- I'd like to see a stack trace of the crash. Could you please do the following? Open two terminals that are _not_ gnome-terminal. For example xterm. Make sure gnome-terminal is _not_ running. In the first xterm, execute two: ulimit -c unlimited /usr/libexec/gnome-terminal-server In the second xterm, within 10 seconds, execute: gnome-terminal You should see a gnome-terminal window appear as usual. Make it crash according to the aforementioned steps. In the first window you should see a brief message including "core dumped". In the directory /var/lib/apport/coredump you should see a freshly created file, mentioning gnome-terminal-server in its name. Verify its timestamp that it's indeed a freshly created one. Run this command gdb /usr/libexec/gnome-terminal-server /var/lib/apport/coredupmp/[the new filename of that core dump] You might then need to press Enter a few times until you get a "(gdb)" prompt. There execute the command bt full You might again need to press Enter a few times to continue its output (if it asks to "Type for more"), until you get a "(gdb)" prompt again. Then please copy-paste gdb's output here. (There might be an easier way of getting this info using apport, but I'm not familiar with that. If you are then you can do that.) Thanks in advance! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2049923 Title: gnome-terminal freezing, then crashing Status in gnome-terminal package in Ubuntu: New Bug description: First: It's very hard to reproduce, but it happens to me about once per week. If often open new windows or split windows out from tabs. And then it happens. First it becomes unresponsive, and then after about 2-3 seconds it simply closes all instances. [328830.780749] gnome-terminal-[117706]: segfault at 460742 ip 7fdb2fb45611 sp 7ffdb8c5fda0 error 4 in libgtk-3.so.0.2406.32[7fdb2f883000+38f000] likely on CPU 4 (core 4, socket 0) [328830.780761] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85 c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6 48 89 [329377.925310] gnome-terminal-[120116]: segfault at 2f0774 ip 7f86af745611 sp 7ffc9943c5c0 error 4 in libgtk-3.so.0.2406.32[7f86af483000+38f000] likely on CPU 2 (core 2, socket 0) [329377.925324] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85 c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6 48 89 unfortunately, apport isn't automatically creating a crash report. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: gnome-terminal 3.49.92-2ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Jan 19 16:48:43 2024 SourcePackage: gnome-terminal UpgradeStatus: Upgraded to mantic on 2023-10-17 (94 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2049923/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2051371] Re: Backspace in gnome-terminal often deletes cluster
Maybe the bug you _really_ wanted to report is that gnome-terminal doesn't use the "surrounding text" feature of input methods? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2051371 Title: Backspace in gnome-terminal often deletes cluster Status in gnome-terminal package in Ubuntu: New Bug description: If I have ខែ្ (U+1781 U+17c2 U+17d2) in the terminal and press backspace, the first backspace deletes U+17c2 U+17d2 so that I'm left with ខ (U+1781). Instead it should only delete the last codepoint, U+17d2. If I have ខែ (U+1781 U+17c2) a backspace deletes only U+17c2, similarly if I have ខ្ (U+1781 U+17d2) where the backspace deletes U+17d2. Further investigations show that backspace often deletes the entire cluster, i.e. diacritic(s) plus the base character, for example with x̣́ (U+0078 U+0301 U+0323) where a backspace deletes all three codepoints. gnome-terminal should only delete the last codepoint [1]. A real live example where this behavior is problematic is when using ibus-keyman with the Khmer Angkor keyboard [2]. When typing xEjmr the expected output is ខ្មែរ (U+1781 U+17d2 U+1798 U+17c2 U+179a). Keyman does some reordering while typing to put the codepoints in a standardized order. Because gnome-terminal lacks support for surrounding text, the codepoints have to be deleted by emitting several backspace keypresses. Because of the deletion of the cluster the result in gnome-terminal is ្មែរ (U+17d2 U+1798 U+17c2 U+179a). [1] https://github.com/keymanapp/keyman/wiki/Backspace-and-cluster-deletion [2] https://github.com/keymanapp/keyman/issues/10481 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 [modified: usr/libexec/gnome-terminal-server] ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jan 26 12:21:42 2024 InstallationDate: Installed on 2022-04-12 (653 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Beta amd64 (20220329.1) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2051371/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2051371] Re: Backspace in gnome-terminal often deletes cluster
By the way... absolutely independently from terminals... U+17d2 is a combining accent. When I checked (many years ago), major graphical toolkits (e.g. GTK and QT) disagreed whether the backspace keypress should delete only the combining accent, or the entire glyph (base character + combining accents) at once. GTK did one, QT did the other (I can't recall which one did which). I don't know if the world has changed since and has settled with one of these behaviors, having found out that one of these behaviors is clearly superior to the other. I would _guess_ that not much has changed. That is, both possible behaviors are reasonable, both have their pros and cons, and probably you cannot claim that the behavior _must_ be the one you're looking for. If your input method cannot generate the symbols you need, and you need to press backspace as a workaround to get that, moreover, you need to rely on one particular behavior of backspace, then I'd argue that it's all the fault of your input method, it should be able to produce straight away whatever you wish to end up with. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2051371 Title: Backspace in gnome-terminal often deletes cluster Status in gnome-terminal package in Ubuntu: New Bug description: If I have ខែ្ (U+1781 U+17c2 U+17d2) in the terminal and press backspace, the first backspace deletes U+17c2 U+17d2 so that I'm left with ខ (U+1781). Instead it should only delete the last codepoint, U+17d2. If I have ខែ (U+1781 U+17c2) a backspace deletes only U+17c2, similarly if I have ខ្ (U+1781 U+17d2) where the backspace deletes U+17d2. Further investigations show that backspace often deletes the entire cluster, i.e. diacritic(s) plus the base character, for example with x̣́ (U+0078 U+0301 U+0323) where a backspace deletes all three codepoints. gnome-terminal should only delete the last codepoint [1]. A real live example where this behavior is problematic is when using ibus-keyman with the Khmer Angkor keyboard [2]. When typing xEjmr the expected output is ខ្មែរ (U+1781 U+17d2 U+1798 U+17c2 U+179a). Keyman does some reordering while typing to put the codepoints in a standardized order. Because gnome-terminal lacks support for surrounding text, the codepoints have to be deleted by emitting several backspace keypresses. Because of the deletion of the cluster the result in gnome-terminal is ្មែរ (U+17d2 U+1798 U+17c2 U+179a). [1] https://github.com/keymanapp/keyman/wiki/Backspace-and-cluster-deletion [2] https://github.com/keymanapp/keyman/issues/10481 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 [modified: usr/libexec/gnome-terminal-server] ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jan 26 12:21:42 2024 InstallationDate: Installed on 2022-04-12 (653 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Beta amd64 (20220329.1) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2051371/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2051381] Re: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset()
Correct me please if I'm wrong, but it looks to me that you have studied the relevant source code and even located the problem in one of the ibus related package. So I'm wondering, shouldn't you have filed this bug against that component, rather than gnome-terminal? Is there anything gnome-terminal's developers could and should do to fix this crash? As far as I understand you, it doesn't look the case to me. Could you please re-assign this bug to the software package where the bug actually is and whose developers thus have a chance of fixing it? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2051381 Title: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset() Status in gnome-terminal package in Ubuntu: New Bug description: When I'm using ibus-keyman with the IPA (SIL) keyboard in gnome- terminal and type n> (or just backspace after the n), gnome-terminal crashes. The reason is that in text_input_delete_surrounding_text() (modules/input/imwayland.c:253) before_length doesn't get checked. If we don't have surrounding text (as in this case) cursor_pointer is NULL and thus (cursor_pointer - before_length) results in an invalid pointer. The other question is why we don't have surrounding text, but that's a different problem. In any case we shouldn't crash in text_input_delete_surrounding_text(). I believe this is a different bug from #2036647 because of the different callstack and that we shouldn't call g_utf8_pointer_to_offset with invalid pointers. ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-terminal 3.49.92-2ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-15.15-generic 6.5.3 Uname: Linux 6.5.0-15-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Fri Jan 26 17:43:54 2024 ExecutablePath: /usr/libexec/gnome-terminal-server InstallationDate: Installed on 2024-01-23 (3 days ago) InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1) JournalErrors: Jan 26 17:43:53 hostname gnome-terminal-[4907]: g_atomic_ref_count_dec: assertion 'old_value > 0' failed Jan 26 17:43:53 hostname gnome-terminal-[4907]: g_atomic_ref_count_dec: assertion 'old_value > 0' failed Jan 26 17:44:00 hostname systemd[1623]: gnome-terminal-server.service: Main process exited, code=dumped, status=11/SEGV Jan 26 17:44:00 hostname systemd[1623]: gnome-terminal-server.service: Failed with result 'core-dump'. ProcCmdline: /usr/libexec/gnome-terminal-server ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash XDG_RUNTIME_DIR= SegvAnalysis: Segfault happened at: 0x7f884099c180 : movzbl (%rsi),%ecx PC (0x7f884099c180) ok source "(%rsi)" (0x) not located in a known VMA region (needed readable region)! destination "%ecx" ok SegvReason: reading NULL VMA Signal: 11 SourcePackage: gnome-terminal StacktraceTop: g_utf8_pointer_to_offset () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-wayland.so ?? () from /lib/x86_64-linux-gnu/libffi.so.8 ?? () from /lib/x86_64-linux-gnu/libffi.so.8 ffi_call () from /lib/x86_64-linux-gnu/libffi.so.8 Title: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users vboxsf modified.conffile..etc.apport.crashdb.conf: [modified] mtime.conffile..etc.apport.crashdb.conf: 2024-01-26T17:42:28.299334 separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2051381/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2051371] Re: Backspace in gnome-terminal often deletes cluster
It's never the terminal emulator (whether GNOME Terminal or any other terminal app) that decides what to print on a backspace. The only thing it does is that it tells over the tty line that the backspace key has been pressed. It's the remote party, which could be the application running inside (such as "bash", "vim" etc.), or the kernel's cooked mode handler code (e.g. if you're running "cat") that decides what to tell to the terminal how to update its canvas (such as e.g. retreat the cursor by one, print a space, and retreat the cursor again -> to achieve the visual effect of deleting the last single-cell character). The terminal emulator has no other choice than to blindly execute these instructions and update its canvas accordingly. (It cannot even tell if this requested display update was in any way connected to the backspace keypress or not, nor should it care.) That's just the way this whole architecture looks like. You have to file a bugreport against whichever applications where backspace doesn't work as you'd expect it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2051371 Title: Backspace in gnome-terminal often deletes cluster Status in gnome-terminal package in Ubuntu: New Bug description: If I have ខែ្ (U+1781 U+17c2 U+17d2) in the terminal and press backspace, the first backspace deletes U+17c2 U+17d2 so that I'm left with ខ (U+1781). Instead it should only delete the last codepoint, U+17d2. If I have ខែ (U+1781 U+17c2) a backspace deletes only U+17c2, similarly if I have ខ្ (U+1781 U+17d2) where the backspace deletes U+17d2. Further investigations show that backspace often deletes the entire cluster, i.e. diacritic(s) plus the base character, for example with x̣́ (U+0078 U+0301 U+0323) where a backspace deletes all three codepoints. gnome-terminal should only delete the last codepoint [1]. A real live example where this behavior is problematic is when using ibus-keyman with the Khmer Angkor keyboard [2]. When typing xEjmr the expected output is ខ្មែរ (U+1781 U+17d2 U+1798 U+17c2 U+179a). Keyman does some reordering while typing to put the codepoints in a standardized order. Because gnome-terminal lacks support for surrounding text, the codepoints have to be deleted by emitting several backspace keypresses. Because of the deletion of the cluster the result in gnome-terminal is ្មែរ (U+17d2 U+1798 U+17c2 U+179a). [1] https://github.com/keymanapp/keyman/wiki/Backspace-and-cluster-deletion [2] https://github.com/keymanapp/keyman/issues/10481 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 [modified: usr/libexec/gnome-terminal-server] ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jan 26 12:21:42 2024 InstallationDate: Installed on 2022-04-12 (653 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Beta amd64 (20220329.1) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2051371/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2050908] Re: Prefences does not work properly on new profiles
It looks to me that you still don't understand how it's all meant to work. You found a possibility that we did not intend to have, involving dragging. This unexpected behavior that you found will be disallowed in future versions. Here's how it's supposed to work: In the Colors tab of the Preferences window, there are 23 color buttons. (Some might only be enabled subject to some preceding checkboxes.) 16 of them are the color palette. Traditionally terminal-based apps can choose from these 16 colors to use (in addition to the default foreground/background colors). Most of the terminal-based apps still limit themselves to these 16 basic colors (although extensions exist to use many-many more), therefore by modifying the exact shade of these 16 palette entries, most (not all) of the colorful terminal-based apps will have their colors adjusted to whatever your personal preference is. The default, cursor etc. colors can also be set to any colors, independently from this palette, they don't have to be picked from this set of 16 (although you surely can repeat a color if you wish to). If you want to change any of the 23 colors, click on that color, choose the new desired value in the newly opened window, and select that. Want to change the default background? Click on default background. Solely in this newly opened window titled "Choose Terminal Background Color", without touching the previous Preferences window, choose a color to your liking. Click Select to accept this new color (or Cancel to cancel) and close this window. Want to change one of the 16 colors that terminal-based applications have easy access to? Click on the corresponding color (e.g. light green). In this newly opened window titled "Choose Palette Color 10", without touching the big Preferences window, pick your preferred shade of light green. Then close this window. Once a color picker window is opened, the main Preferences window should be inactive and not react to mouse clicks. You are not meant to have multiple color picker windows open at a time. You are not meant to be able to drag and drop colors. Future versions will enforce this desired behavior. If you need to set the exact same color for two purposes (e.g. you want the cursor color to be the exact same shade of light green as the corresponding palette color), you can use regular text copy-paste operation on their hex values, or manually select the same color or type in the same hex value. There's no particular order in which you're supposed to set the values. Set the 23 values in any order you wish to. If the documentation is lacking or is not as great as it could be, it should be updated to the desired (and soon enforced) behavior, not the unexpected (and indeed counterintuitive and broken-looking) one that you happened to have found. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2050908 Title: Prefences does not work properly on new profiles Status in gnome-terminal package in Ubuntu: New Bug description: After creating a new profile, "preferences" does not work correctly. I want to have a selection of profiles as I log in to a variety of systems and want the background colours to quickly distinguish as to which host server a given terminal is connected to. For example I have an entry on my desktop "Window to UH" which invokes: Exec=gnome-terminal --profile=UH -e 'ssh -X -l jcollins -e none star.herts.ac.uk' I want UH profile to hack a background of light blue and use a distinctive font and size. However after creating the profile and setting about changing the font and colours, I find that the font selection is greyed out and attempts to change the colour selections fail. I can work around this by using "dconf-editor", working through to the profile and changing the font and colours "by hand" but this is unwieldy. There would seem to be a bug in the preferences menu entry introduced between 20.10 and 22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jan 23 12:40:19 2024 InstallationDate: Installed on 2024-01-04 (18 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2050908/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe :
[Desktop-packages] [Bug 2050908] Re: Prefences does not work properly on new profiles
We just made the actual behavior a bit cleaner. Can you point out any particular piece of text in the help that you think mislead you and could be improved? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2050908 Title: Prefences does not work properly on new profiles Status in gnome-terminal package in Ubuntu: New Bug description: After creating a new profile, "preferences" does not work correctly. I want to have a selection of profiles as I log in to a variety of systems and want the background colours to quickly distinguish as to which host server a given terminal is connected to. For example I have an entry on my desktop "Window to UH" which invokes: Exec=gnome-terminal --profile=UH -e 'ssh -X -l jcollins -e none star.herts.ac.uk' I want UH profile to hack a background of light blue and use a distinctive font and size. However after creating the profile and setting about changing the font and colours, I find that the font selection is greyed out and attempts to change the colour selections fail. I can work around this by using "dconf-editor", working through to the profile and changing the font and colours "by hand" but this is unwieldy. There would seem to be a bug in the preferences menu entry introduced between 20.10 and 22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jan 23 12:40:19 2024 InstallationDate: Installed on 2024-01-04 (18 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2050908/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2050908] Re: Prefences does not work properly on new profiles
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8050 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #8050 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8050 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2050908 Title: Prefences does not work properly on new profiles Status in gnome-terminal package in Ubuntu: New Bug description: After creating a new profile, "preferences" does not work correctly. I want to have a selection of profiles as I log in to a variety of systems and want the background colours to quickly distinguish as to which host server a given terminal is connected to. For example I have an entry on my desktop "Window to UH" which invokes: Exec=gnome-terminal --profile=UH -e 'ssh -X -l jcollins -e none star.herts.ac.uk' I want UH profile to hack a background of light blue and use a distinctive font and size. However after creating the profile and setting about changing the font and colours, I find that the font selection is greyed out and attempts to change the colour selections fail. I can work around this by using "dconf-editor", working through to the profile and changing the font and colours "by hand" but this is unwieldy. There would seem to be a bug in the preferences menu entry introduced between 20.10 and 22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jan 23 12:40:19 2024 InstallationDate: Installed on 2024-01-04 (18 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2050908/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2050908] Re: Prefences does not work properly on new profiles
The bottom 16 "palette" pictures are not the colors to choose from. They are the 16 basic slots whose colors you can also configure. Click on any of these: either default fg/bg, bold colors etc. or one of the bottom 16 ones. Pick a color in the color cube or enter a hex value. Close this window by selecting the new color (or canceling it). The way you're trying to use it is a misunderstanding of how this UI behaves and was intended to be used. Arguably it's a bug that multiple color pickers can be opened at a time. I'll forward it upstream. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2050908 Title: Prefences does not work properly on new profiles Status in gnome-terminal package in Ubuntu: New Bug description: After creating a new profile, "preferences" does not work correctly. I want to have a selection of profiles as I log in to a variety of systems and want the background colours to quickly distinguish as to which host server a given terminal is connected to. For example I have an entry on my desktop "Window to UH" which invokes: Exec=gnome-terminal --profile=UH -e 'ssh -X -l jcollins -e none star.herts.ac.uk' I want UH profile to hack a background of light blue and use a distinctive font and size. However after creating the profile and setting about changing the font and colours, I find that the font selection is greyed out and attempts to change the colour selections fail. I can work around this by using "dconf-editor", working through to the profile and changing the font and colours "by hand" but this is unwieldy. There would seem to be a bug in the preferences menu entry introduced between 20.10 and 22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jan 23 12:40:19 2024 InstallationDate: Installed on 2024-01-04 (18 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2050908/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2050908] Re: Prefences does not work properly on new profiles
I have to start by asking the obvious: Did you notice the checkbox in front of the grayed out options and toggled them? If so: How do you create the new profile: by creating a fresh one (the "+" sign next to "Profiles") or by cloning an existing one? I don't think anything of importance changed in the Prefs dialog between 20.10 and 22.04 (or in fact between 18.04-ish and today). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2050908 Title: Prefences does not work properly on new profiles Status in gnome-terminal package in Ubuntu: New Bug description: After creating a new profile, "preferences" does not work correctly. I want to have a selection of profiles as I log in to a variety of systems and want the background colours to quickly distinguish as to which host server a given terminal is connected to. For example I have an entry on my desktop "Window to UH" which invokes: Exec=gnome-terminal --profile=UH -e 'ssh -X -l jcollins -e none star.herts.ac.uk' I want UH profile to hack a background of light blue and use a distinctive font and size. However after creating the profile and setting about changing the font and colours, I find that the font selection is greyed out and attempts to change the colour selections fail. I can work around this by using "dconf-editor", working through to the profile and changing the font and colours "by hand" but this is unwieldy. There would seem to be a bug in the preferences menu entry introduced between 20.10 and 22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jan 23 12:40:19 2024 InstallationDate: Installed on 2024-01-04 (18 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2050908/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2049923] Re: gnome-terminal freezing, then crashing
What do you mean by "split windows out from tabs"? Do you mean right- clicking on the tab and choosing "Detach Terminal"? Do I understand correctly that the freeze and crash always happens right after opening a new window or detaching a tab? Does the new window appear before the freeze or not? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2049923 Title: gnome-terminal freezing, then crashing Status in gnome-terminal package in Ubuntu: New Bug description: First: It's very hard to reproduce, but it happens to me about once per week. If often open new windows or split windows out from tabs. And then it happens. First it becomes unresponsive, and then after about 2-3 seconds it simply closes all instances. [328830.780749] gnome-terminal-[117706]: segfault at 460742 ip 7fdb2fb45611 sp 7ffdb8c5fda0 error 4 in libgtk-3.so.0.2406.32[7fdb2f883000+38f000] likely on CPU 4 (core 4, socket 0) [328830.780761] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85 c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6 48 89 [329377.925310] gnome-terminal-[120116]: segfault at 2f0774 ip 7f86af745611 sp 7ffc9943c5c0 error 4 in libgtk-3.so.0.2406.32[7f86af483000+38f000] likely on CPU 2 (core 2, socket 0) [329377.925324] Code: fb 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 e8 bf 6d ff ff 48 85 db 74 7a 48 89 c6 48 8b 03 48 85 c0 74 05 <48> 39 30 74 0c 48 89 df e8 a2 c2 d4 ff 85 c0 74 5e 48 89 e6 48 89 unfortunately, apport isn't automatically creating a crash report. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: gnome-terminal 3.49.92-2ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Jan 19 16:48:43 2024 SourcePackage: gnome-terminal UpgradeStatus: Upgraded to mantic on 2023-10-17 (94 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2049923/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2048569] Re: rightclick->open link doesn't work on file://full/path/filename.cpp:linenumber links
What we _could_ perhaps do (because detecting a URI in a text flow is undefined territory, with already quite a few quirks in place, such as stripping off the trailing dot) is to strip off the trailing ":linenumber". That is, the trailing ":" if it's followed by numbers only. That way you could easily and quickly open the desired file "filename.cpp". Not at the desired position, though. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2048569 Title: rightclick->open link doesn't work on file://full/path/filename.cpp:linenumber links Status in gnome-terminal package in Ubuntu: New Bug description: TLDR: I want to be able to open links like file:///full/path/to/filename.cpp:linenumber with rightclick open link video explanation: https://youtu.be/PmQAx7HF7_c ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.2.0-39.40~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Jan 8 14:05:15 2024 InstallationDate: Installed on 2022-05-05 (612 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2048569/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2048569] Re: rightclick->open link doesn't work on file://full/path/filename.cpp:linenumber links
The problem is: according to the URI specification, there is no way to denote the line number. In fact, the URI "file:///full/path/to/filename.cpp:linenumber" refers to a file whose name is literally "filename.cpp:linenumber". Correspondingly, the entire stack that handles the opening of a URI (the gtk_show_uri() method and anything that's underneath it) doesn't know the concept of line number either. Think of all the .desktop and similar files shipped by text editors and similar software, currently they are unable to specify how to pass on the line number to them. Getting it modified to support line numbers would require to modify GTK, modify the .desktop file specification, and _all_ the software out there that ship such a .desktop file, that is, practically all the text viewers/editors out there, to conform to a nonstandard (and backwards incompatible!) extension of the URI specification. This is clearly not going to happen. In order to move forward, first the URI specification would have to be modified to introduce the concept of line number. In a backwards compatible way, that is, the ':' character is out of question, it would need to go to '?query' or '#fragment', probably the latter. Also figure out what to do if the file is in any other format than plain text (what would the given field mean for pdf (page number?), png, music/video (time offset?) etc.) How to distinguish opening an html file as a rendered page (when '#fragment' jumps to the corresponding 'a name' or 'id') vs. opening an html file as raw text (and then jumping to the given line number)? Then the remaining software components would one by one need to be updated to this spec. This was also discussed in the user comments in the gist page of the explicit hyperlink feature for terminals, and was similarly inconclusive. Unfortunately, it's practically a WONTFIX. You can probably use the nonstandard wrapper that you created for Qt Creator for GNOME Terminal as well. Just have a wrapper script that opens your file that handles this ':' and translates to the line number command line parameter of your preferred text viewer/editor. Unfortunately the world is not ready to standardize this personal hack into a mainstream solution, and such a change cannot begin at GNOME Terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2048569 Title: rightclick->open link doesn't work on file://full/path/filename.cpp:linenumber links Status in gnome-terminal package in Ubuntu: New Bug description: TLDR: I want to be able to open links like file:///full/path/to/filename.cpp:linenumber with rightclick open link video explanation: https://youtu.be/PmQAx7HF7_c ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.2.0-39.40~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Jan 8 14:05:15 2024 InstallationDate: Installed on 2022-05-05 (612 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2048569/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2036647] Re: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset()
Looks the same as https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1052172. If it's indeed the same, and if the analysis over there was correct, then this was a bug in package libvte-2.91-0 version 0.74.0-1 and is already fixed in version 0.74.0-2. ** Bug watch added: Debian Bug tracker #1052172 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052172 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2036647 Title: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset() Status in gnome-terminal package in Ubuntu: Confirmed Bug description: Gnome terminal just crashed, was moving pointer across window. ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-terminal 3.49.92-2ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Sep 19 22:39:00 2023 ExecutablePath: /usr/libexec/gnome-terminal-server InstallationDate: Installed on 2023-09-18 (1 days ago) InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230918) ProcCmdline: /usr/libexec/gnome-terminal-server SegvAnalysis: Segfault happened at: 0x7f58c3c30180 : movzbl (%rsi),%ecx PC (0x7f58c3c30180) ok source "(%rsi)" (0x5646400b2000) not located in a known VMA region (needed readable region)! destination "%ecx" ok SegvReason: reading unknown VMA Signal: 11 SourcePackage: gnome-terminal StacktraceTop: g_utf8_pointer_to_offset () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 ??? () at /lib/x86_64-linux-gnu/libvte-2.91.so.0 ??? () at /lib/x86_64-linux-gnu/libvte-2.91.so.0 ??? () at /lib/x86_64-linux-gnu/libvte-2.91.so.0 ??? () at /lib/x86_64-linux-gnu/libgtk-3.so.0 Title: gnome-terminal-server crashed with SIGSEGV in g_utf8_pointer_to_offset() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2036647/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1429584] Re: gnome-terminal doesn't set $COLORTERM from 3.14 onwards
I've just found a link to this ancient bugreport in https://en.wikipedia.org/wiki/ANSI_escape_code. Unfortunately this discussion here contains two confusing mistakes. I'd like to correct them for future reference purposes. No action necessary, other than perhaps closing this bug, and fixing the Wiki page (I might do the latter). In comment #1 I was mistakenly talking about the COLOR*FGBG* variable, not about COLOR*TERM*. This can be seen by the link pointing to an issue that actually (correctly) talks about COLORFGBG, and from my words over here not making any sense. I probably made the same mistake in #4 too (but I'm not sure). I must have had that other environment variable in mind and talked about that, incorrectly typing the name of the one this bugreport was talking about, not realizing the difference. My bad, apologies for this mistake. (I'm not editing the earlier posts here because then the thread will make even less sense.) COLORTERM used to be set to the terminal emulator's name, "gnome- terminal" in our case. This was removed from GNOME Terminal version 3.14, released in 2014, the commit is linked from comment #2 here. This version of GNOME Terminal (or rather, the corresponding VTE version) also implemented truecolor support. Around this time the de facto use of this environment variable across various terminal emulators shifted for it to contain the "truecolor" string if the emulator supported this feature. So VTE 0.44, corresponding to GNOME Terminal 3.20, released in 2016 brought back this environment variable with the new value in https://github.com/GNOME/vte/commit/1dea919b9aa4b55e2c5c07bf2022769cbac365b5. Since the setting now occurs in VTE rather than GNOME Terminal, it is set in all VTE-based emulators. It has stayed ever since and is likely to stay as long as this variable is in widespread use. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1429584 Title: gnome-terminal doesn't set $COLORTERM from 3.14 onwards Status in gnome-terminal package in Ubuntu: Opinion Bug description: Gnome terminal has dropped the $COLORTERM workaround for invalid terminfo/termcap. References: https://github.com/GNOME/gnome-terminal/commit/1d5c1b6ca6373c1301494edbc9e43c3e6a9c9aaf https://bugzilla.redhat.com/show_bug.cgi?id=1165439 https://bugzilla.redhat.com/show_bug.cgi?id=1173688 https://bugzilla.redhat.com/show_bug.cgi?id=1166428 This affects release: Vivid Vervet Workaround I currently use is `.bashrc`: if [ -z "$COLORTERM" ] && cat /proc/$PPID/exe 2> /dev/null | grep -q gnome-terminal; then export COLORTERM=gnome-terminal fi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1429584/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2011727] Re: Seemingly random crashes of all terminal windows
As far as I can see, VTE did not change. However, any external circumstance might have accidentally made it occur much less frequently. Please get back to me if it crashes again, knowing what action triggered the crash might be a big clue for us. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2011727 Title: Seemingly random crashes of all terminal windows Status in gnome-terminal package in Ubuntu: New Status in vte2.91 package in Ubuntu: New Bug description: Typically this happens when I have 4 windows open. This seems to be a new issue for me, dating back perhaps a couple of weeks. I've used this particular 4 terminal setup for years without issues. When the issue occurs, all terminal windows vanish instantly, and I need to restart all of them. Other applications seem unaffected. Details are: log 1005=> lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 log 1006=> apt-cache policy gnome-terminal gnome-terminal: Installed: 3.36.2-1ubuntu1~20.04 Candidate: 3.36.2-1ubuntu1~20.04 Version table: *** 3.36.2-1ubuntu1~20.04 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.1.1-1ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages And in /var/log/syslog I'm seeing the following - (Server ID removed from log): Mar 15 10:16:19 gnome-terminal-server[96577]: VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:19 gnome-terminal-server[96577]: Bail out! VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Main process exited, code=dumped, status=6/ABRT Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Failed with result 'core-dump'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2011727/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2011727] Re: Seemingly random crashes of all terminal windows
I'm starting to wonder whether it's really https://gitlab.gnome.org/GNOME/vte/-/issues/2577, or perhaps the change done there covers up this bug (prevents a crash) but might still result in slightly incorrect behavior (e.g. not recognizing whatever needs to be recognized as being under the mouse), since the root cause is probably not yet fixed. I've filed https://gitlab.gnome.org/GNOME/vte/-/issues/2637 for this very issue. Mark, the 4 terminal setup is most likely irrelevant; however, can you please describe what you did immediately before the crash? E.g. scrolled in the window (with mouse wheel or touchpad?), or maximized/unmaximized/resized the window, or clicked, or moved the mouse, or typed, etc.? Also, does this crash still occur to you? How often? We can't reproduce the crash, your input might help locate the bug. Thanks! ** Bug watch added: gitlab.gnome.org/GNOME/vte/-/issues #2637 https://gitlab.gnome.org/GNOME/vte/-/issues/2637 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2011727 Title: Seemingly random crashes of all terminal windows Status in gnome-terminal package in Ubuntu: New Status in vte2.91 package in Ubuntu: New Bug description: Typically this happens when I have 4 windows open. This seems to be a new issue for me, dating back perhaps a couple of weeks. I've used this particular 4 terminal setup for years without issues. When the issue occurs, all terminal windows vanish instantly, and I need to restart all of them. Other applications seem unaffected. Details are: log 1005=> lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 log 1006=> apt-cache policy gnome-terminal gnome-terminal: Installed: 3.36.2-1ubuntu1~20.04 Candidate: 3.36.2-1ubuntu1~20.04 Version table: *** 3.36.2-1ubuntu1~20.04 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.1.1-1ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages And in /var/log/syslog I'm seeing the following - (Server ID removed from log): Mar 15 10:16:19 gnome-terminal-server[96577]: VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:19 gnome-terminal-server[96577]: Bail out! VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Main process exited, code=dumped, status=6/ABRT Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Failed with result 'core-dump'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2011727/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
alainpannetier, You show how to rebuild the terminal emulator widget (not exactly the version shipped by Ubuntu, without the patches and configurations shipped by Ubuntu), with one patch that is utterly irrelevant to this topic here. I don't have the slightest idea how that could fix the truly unfortunate coloring. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Invalid Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Invalid Status in readline package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted [[Workaround]] * On 22.04, add 'set enable-bracketed-paste off' to /etc/inputrc * Starting 22.10, add 'set enable-active-region off' to /etc/inputrc ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
> EDIT: THIS IS THE WORKAROUND: > bind 'set enable-bracketed-paste off' It's absolutely unclear to me what you're referring to here. You mention a workaround that wasn't mentioned earlier in this thread, the word "bind" first appears in your comment (so: where did you take it from?) then you say it doesn't work for you. What do you do with this line? Do you execute it once, as a command? Before or after ssh'ing? Or execute in every terminal? Or place it in a file (which)? If you're looking for help, you should at least tell us step by step what you're doing. (By the way, this is an issue tracking forum and not a user support one. User support questions should much rather go to sites like askubuntu.com or answers.launchpad.net. Your comment does not in any way help developers get closer to fixing the issue.) > It could be due to the fact that it is over ssh? Sure it could be. So, have you experimented with it, have you tried to perform the said action on both computers? > I CANNOT work with this 'feature' enabled. This sounds like an obvious exaggeration. You're crying wolf. I believe it annoys you, but it's sure untrue that you in all-caps "CANNOT" work due to this (especially more than 1 year after the release of this annoying behavior). > And this security argument makes no sense to me... why would I paste text into a terminal which I didn't select? Follow the link from comment 11 (that is: yes, it was already shown in this thread). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Invalid Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Invalid Status in readline package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted [[Workaround]] * On 22.04, add 'set enable-bracketed-paste off' to /etc/inputrc * Starting 22.10, add 'set enable-active-region off' to /etc/inputrc ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2024628] Re: gnome-terminal paste long list jumbled
I assume you paste this to the shell (command line). I can reproduce the same problem in xterm with the bash shell. Not with zsh, though. Therefore it's a bug in bash (shell), not gnome-terminal. ** Also affects: bash (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2024628 Title: gnome-terminal paste long list jumbled Status in bash package in Ubuntu: New Status in gnome-terminal package in Ubuntu: New Bug description: Reproduce: Paste long list in terminal gets jumbled at the bottom. sudo apt install \ autoconf \ automake \ gcc \ debhelper \ glslang-dev \ ladspa-sdk \ libasound2-dev \ libarchive-dev \ libbluray-dev \ libbs2b-dev \ libcaca-dev \ libcdio-paranoia-dev \ libdrm-dev \ libdav1d-dev \ libdvdnav-dev \ libegl1-mesa-dev \ libepoxy-dev \ libfontconfig-dev \ libfreetype6-dev \ libfribidi-dev \ libgl1-mesa-dev \ libgbm-dev \ libgme-dev \ libgnutls28-dev \ libgsm1-dev \ libharfbuzz-dev \ libjack-jackd2-dev \ libjpeg-dev \ libbrotli-dev \ liblcms2-dev \ liblircclient-dev \ liblua5.2-dev \ libmodplug-dev \ libmp3lame-dev \ libopenal-dev \ libopus-dev \ libopencore-amrnb-dev \ libopencore-amrwb-dev \ libpulse-dev \ librtmp-dev \ librubberband-dev \ libssh-dev \ libsoxr-dev \ libspeex-dev \ libtool \ libuchardet-dev \ libv4l-dev \ libva-dev \ libvdpau-dev \ libvorbis-dev \ libvo-amrwbenc-dev \ libunwind-dev \ libvpx-dev \ libvulkan-dev \ libwayland-dev \ libx264-dev \ libx11-dev \ libxext-dev \ libxinerama-dev \ libxkbcommon-dev \ libxpresent-dev \ libxrandr-dev \ libxss-dev \ libxv-dev \ libxvidcore-dev \ meson \ nasm \ ninja-build \ pkg-config \ python3 \ python3-docutils \ x11proto-core-dev \ zlib1g-dev \ wayland-protocols \ libpipewire-0.3-dev \ libgnutls28-dev \ libass-dev \ libfdk-aac-dev \ libfreetype-dev \ libmp3lame-dev \ libopus-dev \ libsvtav1enc-dev \ libdav1d-dev \ libvpx-dev \ libx264-dev \ libx265-dev \ libunistring-dev \ libnuma-dev \ libsdl2-dev ProblemType: Bug DistroRelease: Ubuntu 23.04 Package: gnome-terminal 3.48.0-1ubuntu1 ProcVersionSignature: Ubuntu 6.2.0-23.23-generic 6.2.12 Uname: Linux 6.2.0-23-generic x86_64 ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Thu Jun 22 02:31:46 2023 InstallationDate: Installed on 2023-03-27 (86 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Alpha amd64 (20230326) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/2024628/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2022019] Re: Control sequence '\e]104; x\a' hangs in libvte
Thanks for the report. Forwarded upstream:
https://gitlab.gnome.org/GNOME/vte/-/issues/2631
** Bug watch added: gitlab.gnome.org/GNOME/vte/-/issues #2631
https://gitlab.gnome.org/GNOME/vte/-/issues/2631
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to vte2.91 in Ubuntu.
https://bugs.launchpad.net/bugs/2022019
Title:
Control sequence '\e]104;x\a' hangs in libvte
Status in vte2.91 package in Ubuntu:
New
Bug description:
The command:
$ printf '\e]104;x\a'
will cause either gnome-terminal or xfce4-terminal to enter an infinite loop
inside libvte-2.91.so.0.
I believe the problem is in src/vteseq.cc in the Terminal::reset_color
function:
while (token != endtoken) {
int value;
if (!token.number(value))
continue;
int index;
if (get_osc_color_index(osc, value, index) &&
index != -1) {
reset_color(index, VTE_COLOR_SOURCE_ESCAPE);
}
++token;
}
When token doesn't point to a valid number, then "continue" bypasses
the ++token line and will just re-parse the same token over again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/2022019/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2011727] Re: Seemingly random crashes of all terminal windows
Most likely it's upstream bug https://gitlab.gnome.org/GNOME/vte/-/issues/2577. ** Bug watch added: gitlab.gnome.org/GNOME/vte/-/issues #2577 https://gitlab.gnome.org/GNOME/vte/-/issues/2577 ** Also affects: vte2.91 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2011727 Title: Seemingly random crashes of all terminal windows Status in gnome-terminal package in Ubuntu: New Status in vte2.91 package in Ubuntu: New Bug description: Typically this happens when I have 4 windows open. This seems to be a new issue for me, dating back perhaps a couple of weeks. I've used this particular 4 terminal setup for years without issues. When the issue occurs, all terminal windows vanish instantly, and I need to restart all of them. Other applications seem unaffected. Details are: log 1005=> lsb_release -rd Description: Ubuntu 20.04.5 LTS Release: 20.04 log 1006=> apt-cache policy gnome-terminal gnome-terminal: Installed: 3.36.2-1ubuntu1~20.04 Candidate: 3.36.2-1ubuntu1~20.04 Version table: *** 3.36.2-1ubuntu1~20.04 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.1.1-1ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages And in /var/log/syslog I'm seeing the following - (Server ID removed from log): Mar 15 10:16:19 gnome-terminal-server[96577]: VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:19 gnome-terminal-server[96577]: Bail out! VTE:ERROR:../src/ringview.cc:299:const vte::base::BidiRow* vte::base::RingView::get_bidirow(vte::grid::row_t) const: assertion failed (row >= m_start): (10011 >= 14401) Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Main process exited, code=dumped, status=6/ABRT Mar 15 10:16:20 systemd[2497]: gnome-terminal-server.service: Failed with result 'core-dump'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2011727/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
Re "cat" (which should rather be "ls -1") with LTR vs. autodetected directionality: Let's use the convention here that uppercase letters are fake Arabic, e.g. imagine that the word [written as LTR here] "ARABIC" is a valid Arabic word which is supposed to visually appear as "CIBARA". Let's have two files, called "english.pdf" and [written as LTR here] "ARABIC.pdf". Let's run "ls -1". First, let's run it in a fully LTR environment. "english.pdf" should appear like this, left-aligned, it's obvious. What's the best rendering of the other filename? Should it look like "CIBARA.pdf" or "pdf.CIBARA"? Should it be aligned to the left or right edge of the terminal? Why? I, who can't read Arabic, would argue that a left-aligned "CIBARA.pdf" would be the least confusing for me (i.e. I prefer the look in your LTR screenshot), but others, especially those who do read Arabic, might disagree with me and prefer some other rendering. What is your take on this? Now, let's run it in a fully RTL environment, e.g. the user has set up as much as reasonable to RTL, most of the filenames are RTL, however, an English one, and an Arabic one with an English extension, have sneaked in. What output would you prefer from "ls -1" and why? Should the English filename appear as "english.pdf" or "pdf.english", should it be aligned to the left or the right edge of terminal? And the same question as in the previous paragraph: Should the Arabic filename look like "CIBARA.pdf" or "pdf.CIBARA", and should it be aligned to the left or right edge? What output format would you expect from regular "ls" (using multiple columns), given a mixture of plenty of similarly crafted filenames? What output format would you expect from "ls -l"? Plenty of questions, plenty of possible answers. E.g. for "ls -1" in RTL environment, I asked two questions, 4 possible answers for each, that's 16 possible combinations. Many of them are obviously bad, but still, probably there won't be a clear winner, I'd guess there will be 2 or 3 candidates, with some subjective weighting between them. Once we have an answer to these questions, the next question should be: whose responsibility is it to implement that behavior? Is it the terminal's, or ls's, or a cooperation between the two? Finding the good answer will require deep understanding of the problem space and examining many other utilities as well. You can't just conclude from the output of 1 particular utility using 1 particular command line switch that enabling autodetection would be an overall win across thousands of use cases. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: Fix Released Status in vte2.91 package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic text and an Arabic text are displayed together in the same line, then the entire line will be missed up and you won't be able to understand what is being said. Both of these bugs can be seen from the image I attached. I reported both of these bugs together because it's unlikely they can be fixed separately, probably they are related to each other. Problem can be seen in any VTE-based terminal. Here I am using GNOME Terminal 3.44.0 on Ubuntu 22.04, but it can be seen in any Ubuntu version and in any terminal version as well (it has been there since forever). I reported the bug here instead of upstream because that's what they said at the page: https://wiki.gnome.org/Apps/Terminal/ReportingBugs, but this bug is not related to Ubuntu only; it happens on all Linux distributions. Happy to provide any information you need, or any do tests or experiments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2002290/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
Re "nano" with LTR vs. autodetected directionality: The LTR screenshot is more obviously "broken" (or at least undesireable). The autodetected directionality's brokenness is less obvious, maybe no breakage is visible in this particular screenshot, but is still broken. Maybe it looks pretty much okay with fully RTL text. But try to edit some BiDi text where the text sporadically contains some English words, or numbers. Scroll the long lines horizontally, so that these words and numbers just scroll in or out, or just cross the terminal's edge. You'll see it breaking here and there. Combine it further with nano showing the line numbers (Alt-N), I expect more breakages. Edit some file that contains pairs of ( ) or < > characters, you'll see that the way they are mirrored or not is occasionally broken, and (I think although I haven't tried) even nano's reverse video < > signs at the margin that denote that the line continues might join this game in faulty ways. In my BiDi proposal, in the section "Why terminals are a truly special story" I argue that fullscreen text viewers/editors (such as nano, vi, emacs, mcedit, joe...) only send partial information to the terminal (only parts of the entire text) and it's impossible to run the BiDi algorithm on partial data. I prove that it's literally impossible to achieve proper BiDi text editing user experience if performing BiDi is the job of the terminal emulators. Hence, in accordance with ECMA TR/53, in such cases it has to be the application (e.g. nano) that runs the BiDi algorithm and the terminal must not shuffle the characters. The terminal can be programatically switched to this so-called "explicit mode" using the BDSM escape sequence. The only way to have a proper BiDi-editing experience in nano is if nano adds BiDi support, meaning that on one hand it runs the Unicode Bidirectcional Algorithm [UBA] itself, on the other hand it asks the terminal not to do that. In "implicit mode", where the terminal runs the UBA, even if combined with automatic detection of paragraph direction and alignment, if you try to have the typical text editing user experience then there will be numberous fundamentally unfixable bugs. The only way to fix them is to use the terminal's "explicit mode" instead. The single most important bit from my BiDi work is (reinforcing ECMA TR/53's realization) that it's either the terminal (and not the application) or the application (and not the terminal) that needs to perform the UBA, and that both of these modes are required (for some utilities like "apt" only the "impicit mode" is reasonably viable, for some other apps like "nano" only the "explicit mode" is usable), and that it has to be programatically switchable. Prior to this work from me (both the spec and the implementation in VTE) all the terminals I'm aware of either only implemented "this" mode (making it impossible to run BiDi apps that required "that" mode), or only implemented "that" mode (making it impossible to run BiDi apps that required "this" mode), or asked the user to choose the behavior (an utterly unacceptable user experience to have to manually switch back and forth, let alone so extremely frequently), and due to this utterly messy situation application developers had absolutely no clue how they needed to send RTL text to the terminal. Whether autodetection is enabled or disabled is a property within the "implicit mode", in "explicit mode" this setting plays no role. The only way to have proper BiDi support in nano is to go ahead and implement BiDi support in nano, relying on the terminal's "explicit mode". There's no way the terminal could do it on its own, without nano's help. It's substantially different from let's say "apt" or "ls" because those utilities tell the entire text to the terminal (therefore the terminal can run UBA), whereas nano by its very nature only sends partial text to the terminal (therefore the terminal has no chance whatsoever to property figure out the rest and do the BiDi shuffling). Therefore, the argument that autodetection should be enabled for the sake of a better (but still quite broken) BiDi experience in nano (using the terminal's "implicit mode") is completely invalid. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: Fix Released Status in vte2.91 package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
Hi M.Hanny, Thanks a lot for spreading the word about BiDi support in VTE! Really no need to apologize about your English! I'm not a native English speaker either, and your English is at least as good as mine. We have no communication issues at all! --- > Ideally, there shouldn't be a text in other languages when the system language is set to Arabic. E.g the output of "apt" should be fully translated to Arabic [...] This is a very long journey and it may take many years until we reach that point. I disagree with you in this point. There will always be English text in the output of "apt", such as package names, I don't think they will ever be translatable (and would arguably be a mistake to go in this direction). For rapidly changing data, such as package descriptions, it's practically impossible for all translations to be fully up-to-date all the time. Think of software like dmesg printing system logs, software printing hardware information (such as identification strings of various components), think of software showing system directories' and files' names etc. Think of commands that print whois data, show a mysql table along with the column names, show source code etc. Think of ssh'ing to a remote host. Think of the long tail of utilities you find on the web that someone quickly hacked together but there's no demand to get translated to languages other than English. Although not relevant to the world of terminal emulation, I've just checked the completeness of the Arabic translation of the GNOME desktop at https://l10n.gnome.org/teams/ar/, and it's very very far from being fully green. You'll never have a terminal emulation experience that is fully in a foreign (I mean non-English, not necessarily RTL) language, for two reasons. One is that due to the very nature of things there'll always be tons of English stuff in the terminal, the second is that it's a utopic and reasonably unreachable dream to have all software's UI strings be fully translated to all languages. A 100% fully Japanese, or fully Hungarian, or fully Arabic experience in terminal emulators, no English word whatsoever, is neither "ideal" nor in my opinion is reachable in our lives. > However, in order to get there, we need to start somewhere. [...] this could open the door for a wide range of CLI-based computing for RTL languages speakers [...] I agree with this one, and I hope I could make an important step here. > The political factor is also important. I don't want to talk about politics here of course I don't want to talk about politics either. My work was driven by getting closer to equality for people, no matter if I agree or disagree with certain things they do; as well as by the technical challenge itself. That being said, you raised excellent points here. > The dominant majority of Arabic users at least are using English as a system-wide language. When I made polls asking them why, they say that there are many bugs and problems in Arabic support in general on Linux [...] I fully understand this. Prior to my work, nobody had an idea how to do BiDi in terminals, nobody saw the whole picture. As I show in my document, everyone who thought they knew how to do it made fundamental mistakes, proving that they only saw a fraction of the story -- except for ECMA TR/53 which at least saw the big picture correctly, but that one also made big mistakes elsewhere, and is an old piece of work preceding the UBA, not suitable for straight adoptation. I believe my work is the first and only one so far that shows how BiDi can actually be done in terminals in a way that it really works. But again, it's not a magic wand solution for all the problems, it's a platform for app developers to build upon. Funny story, perfectly rhyming with what you experienced here, and maybe pushing it a little bit further. I gained my BiDi knowledge and experience in 2009-2010 when for half a year I worked on porting the (now discontinued) iGoogle webpage to RTL. Those days Internet Explorer 6 was the market leader, IE7 was gaining some popularity, and IE8 was brand new. IE6, as we all know, was a terrible browser. But when you tried to do RTL in it, it was even magnitudes worse! IE7 was significantly better, but nowhere near perfect when it came to RTL. In IE8 I could not find a single RTL bug. (In all cases: asking the browser to use its latest rendering engine, rather than some compatibility mode.) Working around the IE6 RTL layout issues (and even crashes!) took a whole lot of development effort. IE7 caused less pain. With IE8 there was no pain at all (apart from the necessary migration and layout fixes as we asked the browser to use its new rendering engine rather than compat mode). At one point I suggested that we just add a banner asking users to upgrade to IE8, saving us tons of development effort. The idea was rejected because market share of IE6 was even bigger in RTL areas than at the rest of the world. Why? Because RTL in IE6 was so bad that
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
> The only thing that remains is related to bug 2 and the RTL text auto- detection in VTE. I am yet to hear from Egmont on anything we can do in this regard. Both the autodetection "on" and "off" values have pros and cons. I don't think either one is better per se than the other. One is better in some circumstances, the other is better in others. For complete sentences that are of mostly in a single direction, occasionally with an embedded word in foreign directionality, usually autodetection is better. For a list of items, some of which might be of a foreign directionality (e.g. "ls -1"), aligning all of them in the same way (autodetection is off) is the better. For users who input some text in their native language, occasionally containing a foreign directionality text, autodetection might mess things up if that word happens to be at the beginning, and again, a fixed overall directionality (autodetection off), matching the main language, is presuabmly better. When it comes to designing a graphical app or a webpage, these are decided on a case-by-case basis. I can't see how a terminal could magically _solve_ this and provide a solution that's good enough for everyone. It provides a _platform_ where apps can pick which of the two behaviors they wish to have. To make it more complicated, terminal emulation is an utter mixture of English vs. one's native language. Some pieces of text are English by their nature, some apps are not (or not fully) translated to Arabic (Persian, Hebrew...), etc. Also, there are multiple use cases to take into account. One using their system in Arabic and encountering quite a few English words, or fully English utilities, is one thing. One using their system in English and encountering a few embedded Arabic words is another. -- I'm afraid at this point we don't have anywhere near enough data to justify flipping the default, even despite that admittently picking the default was a somewhat arbitrary decision from me, with my overall impression being that this current default behavior might be better for users on average. Since I cannot speak/read/write any of the RTL languages/scripts, the decision might have been biased towards pure LTR environments (i.e. not to have random lines which happen to contain an RTL piece of text be right-aligned). After months of research and work on the topic of RTL in terminals, I did not have a strong stance on this. Technically, you can flip the default, or create that shell script snippet that does this. Would this be a good solution? I'm afraid not, it would just probably make things more complicated, as the implementation would diverge from the proposed standard, multiple implementations would diverge from each other, app developers wouldn't be sure what to do. The topic needs further research. It should evaluate which behavior is better under which circumstances, taking into account a wide range of apps, use cases. It should study both when a basic LTR environment has scattered RTL words in it (including the case of dumping binary data), and when a basic RTL environment has occasional LTR words (and numbers etc.). Very importantly, the decision should heavily take into account which pieces of software can be more reasonably expected to switch to the other behavior. Ideally the need of the simplest tools (e.g. cat) should be the default, since they are the ones that cannot reasonably switch and later restore the behavior. Apps that do formatting for the terminal (e.g. ls for multi-column listing) will probably do have to do some BiDi anyway to preserve the columnar layout even in case of mixed directionality filename, so it's fair to request ls to switch to its preferred mode of operation and later switch back. Shells with their powerful interactive line editing also belong to this group: they already do a couple of things when presenting the prompt and when starting to execute the command (e.g. toggle bracketed paste mode back- n-forth), asking them to toggle some BiDi mode (in order to have the best BiDi experience when editing the command line) and restore when launching the command is a fair game. Asking the simplest tools, like cat, head, grep etc., and ad-hoc utilities, to switch back and forth is not that reasonable at all, so if there's a strong tendency which mode these utilities prefer then most likely that needs to be the terminal's default. It could be that my proposed default behavior was poorly chosen and the other one would've been the better choice for the terminal (although I see no strong evidence for this yet). If this is the case, the way to fix it is first to study and understand the topic thoroughly, then if there are compelling reasons to change the terminal's default in the proposed spec (rather than fixing the problem elsewhere, like in those particular apps, including the shell itself; or in some shell script gluing) then update the spec, and finally (the trivial bits) adjust the upstream implementation.
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
** Package changed: vte (Ubuntu) => vte2.91 (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: New Status in vte2.91 package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic text and an Arabic text are displayed together in the same line, then the entire line will be missed up and you won't be able to understand what is being said. Both of these bugs can be seen from the image I attached. I reported both of these bugs together because it's unlikely they can be fixed separately, probably they are related to each other. Problem can be seen in any VTE-based terminal. Here I am using GNOME Terminal 3.44.0 on Ubuntu 22.04, but it can be seen in any Ubuntu version and in any terminal version as well (it has been there since forever). I reported the bug here instead of upstream because that's what they said at the page: https://wiki.gnome.org/Apps/Terminal/ReportingBugs, but this bug is not related to Ubuntu only; it happens on all Linux distributions. Happy to provide any information you need, or any do tests or experiments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2002290/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
Hi M.Hanny,
I'm so glad that you're way more familiar with fontconfig quirks as well
as Ubuntu processes than me. I wish you good luck in getting some better
config accepted and made default in Ubuntu!
-
Re lam-alif:
As far as I remember, and
https://en.wikibooks.org/wiki/Arabic/LearnRW/laam-alif tells me: The situation
is:
- The first (right) letter is a Lam (or Laam), U+0644, which looks similar to
English J.
- The second (left) letter is an Alif, U+0627, which looks similar to English I
(vertical bar); or some accented variant thereof (U+0622, U+0623, U+0625, maybe
more, I don't know).
In the terminal, this shows up as if you'd imagine English "IJ" with the
two letters connected at the bottom, i.e., similar to a U. As in the top
row of your screenshot in comment 12.
In gedit, browser etc. they show up in a way that either more resembles
as an "y", or as a shape that reminds me of an upside-down ribbon ,
something like an "8" but with the upper segment cut off. As in the
second row of your screenshot.
I'm glad you confirm what my consultant also said, namely that it's not
terribly bad to go with the not properly ligated version.
At least, it's good enough for now. My BiDi work focused on way more
fundamental things, namely to get the proper (non-reversed) ordering of
letters done. Rendering of Lam-Alif can always be further improved in
the terminal.
-
Re making the RTL paragraph direction (and right alignment) the default:
Unfortunately the locale subsystem (according to my latest memories)
does not specify whether the script is LTR or RTL. One way is to check
the language part of the locale, pretty much like you did, but listing
all the known RTL scripts ("he", and I guess there are some languages
that are somewhat related to Arabic that have their own code, maybe Urdu
and some more??). One caveat, though, is that locale-related env vars
(LANG, LANGUAGE, LC_MESSAGES, LC_ALL) override each other in a certain
order of priority, so probably it's wiser to invoke the `locale` utility
and find the resolved value in its output. (Fun fact: some projects use
gettext as a workaround for the lack of such a field in locales.
Translators have to create a "translated" string containing "ltr" or
"rtl", or "1" or "0", whatever choice of the programmers, to denote the
default direction.)
Another problem is that as the proposal says, no autodetection is the
default, and if an app switches to the other mode it should revert that
setting upon quitting. Which would revert what you do in the shell
startup files. (I'm not aware of any app using these control codes yet,
but we should think in the long term and a few steps ahead.)
I'm not absolutely certain that an autodetected default direction is
better in RTL locales. I'd guess there will be places where it's an
improvement (like "apt" obviously) and places where it's less desired.
At this moment I'm afraid we don't have enough knowledge and experience
to see the pros and cons, more data should be collected first.
Note that according to the BiDi proposal, there are 2x2 possible values for
paragraph direction (in case the terminal is asked to perform BiDi shuffling):
- LTR base dir (no autodetect)
- RTL base dir (no autodetect)
- Autodetect, falling back to LTR base dir
- Autodetect, falling back to RTL base dir
You should also test the other two possibilities, although they will
probably result in more inconsistencies at e.g. shell prompts which may
or may not have Arabic words (e.g. an Arabic path component) in them, or
some might make it outright a pain to type typical Unix commands.
I think further evaluation needs to happen on this topic, it's way too
early to jump into conclusions which mode is the better one. (It should
also be evaluated which apps it's more reasonable to ask to modify their
behavior and switch to the other mode.) Also, if it becomes clear that
it's a big overall advantage to flip the default, IMO it should happen
in the spec and in existing implementations before proper BiDi in
terminals gets too widespread.
Glad to see someone finally actually cares about this BiDi work :)
Thanks a lot for pushing it forward!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-terminal in Ubuntu.
https://bugs.launchpad.net/bugs/2002290
Title:
Poor Arabic rendering in VTE
Status in gnome-terminal package in Ubuntu:
New
Status in vte package in Ubuntu:
New
Bug description:
VTE has a number of issues when it comes to rendering Arabic letters
in the terminal, which could affect a number of languages (Arabic,
Urdu, Persian... etc).
Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed
with spaces between its letters, making readability hard and sometimes
not possible. Sometimes the letters are crushed together very closely
making reading impossible too.
Bug 2: If a non-Arabic text and an Arabic text are displayed together
in the same
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
Hi M.Hanny, Re bug 1 (rendering): Thanks for attaching screenshots, I was lazy to do that. Indeed this is also how the letters look to me. It would indeed be great if Ubuntu could change its default font choice, at least for Arabic locales. I don't know what would be the best place to bring it up with Ubuntu developers (I'm not one of them), maybe a dedicated bugreport here, filed against the relevant font or i18n projects, or perhaps an i18n mailing list (I'm afraid very little attention is being paid to bugreports here). According to my memories from many-many years ago, I think fontconfig (or some other component in picking a font) can also behave differently depending on the locale. I definitely do remember that some piece of software, probably some terminal emulator, but I can't recall which, with the same settings except for the locale, picked different fonts depending on the locale (wider one for CJK locales). So _maybe_ one way to address the problem is to modify the configuration of fontconfig or some similar underlying font component, and still calling it "Ubuntu Mono" from the terminal. Anyway, I'm not familiar enough with the topic to propose how to solve it. Once this is fixed, I believe there's one more prominent rendering issue, and that's the lack of the lam-alif ligature. VTE doesn't support ligatures in general, maybe this one should be handled by some one-off code as an exception, but it's still unclear how to handle some corner cases (e.g. when a color change, the cursor, or a linebreak comes in between). According to my memories, the conclusion with my consultant about the Arabic language family was that the lack of lam-alif ligature is not terribly bad on typewriter-like machines, my impression was that it's frowned upon but sort of acceptable. It can be further improved at any time. Re bug 2 (order of words): One more important thing that didn't occur to me yesterday was the nasty issue with the "paragraph direction". It's a generic issue with RTL handling, not related to terminals per se. The problem and its consequences (different ordering of words) is breafly explained and demonstrated with the simplest possible example in my BiDi proposal under "RTL and BiDi Introduction" -> "RTL and BiDi text handling in general". As your gedit and browser screenshots show, they most likely auto-detect the paragraph direction, which ends up being RTL. The overall right alignment suggests that this is most likely the case. The terminal, on the other hand, assumes LTR paragraph direction until explicitly told otherwise. Try the following command: printf '\e[?2501h' to enable auto-detection of the paragraph direction in VTE, and then re- run "apt". Does this fix the order of the words for you in VTE? (Plus it should also right-align the affected lines, just as in the browser and gedit screenshots.) You might create a wrapper script around your "apt" that sets this, and resets (letter "l" instead of "h", as in low/high) afterwards. Or enable it for your entire shell session, bearing in mind that it will affect the behavior of other RTL tools as well, some for better, some for worse. To be honest, it was a tough choice to pick the default value whether autodetection of the paragraph direction should be enabled or disabled in terminals by default. Both possibilities have their pros and cons. I'm not entirely certain that I managed to pick the better one; given sufficiently large amount of data points (which I don't have), the decision might need to be revised in the future. Handling the paragraph direction properly in RTL or mixed direction text (e.g. while building up a mixed language homepage) always requires plenty of manual work, and I can't imagine this being different in terminals either. Apps just need to tell the terminal which behavior they need at the given location. So again, I'd argue that "apt" (and plenty others) should instruct the terminal accordingly. (In practice I know it's pretty unlikely for many-many apps to invest this amount of work in proper BiDi support, unfortunately leaving us with a less-than- ideal final result.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: New Status in vte package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic text and an Arabic text are displayed together in the same line, then the entire line will
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
To be absolutely fair, I have to add this: One thing, namely the handling of BiDi _control_ characters at the very beginning of a paragraph (logical line), remains as a TODO item both in the spec and in VTE's implementation (both of which are really nontrivial). I just ran out of motivation and time, so it's probably waiting for someone else to fix it. In the unlikely case that "apt"'s given message begins with such a character, and VTE chopping it off is the reason for the wrong order, then it's my fault :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2002290 Title: Poor Arabic rendering in VTE Status in gnome-terminal package in Ubuntu: New Status in vte package in Ubuntu: New Bug description: VTE has a number of issues when it comes to rendering Arabic letters in the terminal, which could affect a number of languages (Arabic, Urdu, Persian... etc). Bug 1: Any Arabic word in any VTE-based terminal is choppily displayed with spaces between its letters, making readability hard and sometimes not possible. Sometimes the letters are crushed together very closely making reading impossible too. Bug 2: If a non-Arabic text and an Arabic text are displayed together in the same line, then the entire line will be missed up and you won't be able to understand what is being said. Both of these bugs can be seen from the image I attached. I reported both of these bugs together because it's unlikely they can be fixed separately, probably they are related to each other. Problem can be seen in any VTE-based terminal. Here I am using GNOME Terminal 3.44.0 on Ubuntu 22.04, but it can be seen in any Ubuntu version and in any terminal version as well (it has been there since forever). I reported the bug here instead of upstream because that's what they said at the page: https://wiki.gnome.org/Apps/Terminal/ReportingBugs, but this bug is not related to Ubuntu only; it happens on all Linux distributions. Happy to provide any information you need, or any do tests or experiments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2002290/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2002290] Re: Poor Arabic rendering in VTE
(I am the one who designed [1] and implemented RTL (right-to-left) and BiDi (bidirectional) text support in VTE.) The two issues you report here are totally independent. Re bug 1: Terminal emulators, by their very nature and their legacy of maybe ~50 years, _have to_ operate in a strict rectangular grid of character cells. If you try to break out of this grid, you break pretty much everything. Sticking to such a grid has quite a few advantages and quite a few disadvantates. The visual disadvantages are more prominent with scripts that do connect the letters to each other, such as Arabic. I'm sure that there's room for improvement in rendering, but it probably doesn't belong to VTE. Or maybe belongs to the VTE to the extent of switching to a different font rendering engine (e.g. from freetype to harfbuzz; there's an upstream bug about it). However, by the very nature of the grid layout, no rendering engine could perform magic and end up with a beautiful rendering if it starts with a font that doesn't have the letters of the desired width. Long story short: You'll need to find a high quality monospace Arabic font. Or, in fact, one where the English and the Arabic letters all have the same width (or somehow merge two such fonts, an English and an Arabic one, via fontconfig; I'm not at all familiar with how to do that). For testing, I happened to use a font where the Arabic text didn't look anywhere as bad as your screenshot. I probably used "Monospace 9", but I don't know if this font itself contains Arabic, or if they were substituted from another font, and if so then which one. Comparing the layout to the layout of let's say web browsers (which don't have the fixed with constraint), bearing in mind that I cannot read Arabic, I am confident to say that the rendering was way better than the one in your screenshot. At the very least, letters were connected or not connected exactly as in the browser, and the overall look was also reasonably close. So keep finding the right font for you. Re bug 2: This one is not about joining or not joining adjacent letters; this one is about figuring out how to shuffle the order of the character cells to make sure that words and sentences aren't "sdrawkcab" (backwards). Pretty much every terminal behaves differently when it comes to RTL or BiDi text. That is, unfortunately it is literally impossible for an app to emit RTL or BiDi text and expect to appear correctly in the terminal. Also, some applications have different requirement from the terminal than others. Overly simplified story: Some apps need to emit logical order and expect the terminal emulator to rearrange the cells. If the terminal doesn't rearrange, the output will be "nekorb" (broken). Some other apps need to reorder the cells themselves, and if the terminal also reorders them then the output will be, again, "nekorb". No matter which approach a terminal emulator picks (i.e. to rearrange or not to rearrange according to the BiDi algorithm), one set of the applications has no chance of implementing RTL. Or, rather, no application could ever implement proper RTL, because they could not tell which kind of terminal they operate on. (Fun: I've also come across an app where half of the strings were in logical order and half were in visual, making it absolutely certain that no terminal would ever display correctly the entire app.) The only proper attempt to fix RTL for terminals dated back to ~30 years earlier, preceding the Unicode BiDi Algorithm, and contained many flaws (let alone that it's a document with no known implementation). All the other attempts were much more fundamentally broken (like forcing the terminal to rearrange the cells, making it literally impossible to implement e.g. BiDi-aware terminal-based text editors). I elaborate on this in my BiDi proposal. I gathered information, studied the subject thoroughly, evaluated earlier "solutions", and then come up with a proposal that would address all the issues. This is a ~50 page document, referring to the also quite enormous Unicode BiDi Algorithm as one of its building blocks. Then I implemented it in VTE. It's important to understand that no RTL behavior for terminals could ever magically fix the output of all the existing utilities (such as "apt" as seen in your screenshot), it would just be literally impossible to do that. My RTL/BiDi proposal makes confirming terminals a _platform_ capable of properly handling the RTL/BiDi needs of every kind of application. But as a next step, applications on top of them have to use the provided features wisely. So VTE is the first, and perhaps still only (I'm not sure about that) terminal whose RTL / BiDi capabilities make it possible for all of "apt", "vim", "tmux" etc. (insert thousands of other apps here) to implement RTL / BiDi, despite their vastly different needs. Now it's the applications' turn to use the available RTL / BiDi features as they require. (By the way, if you copy the given
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
Freshly released bash-5.2 allows to disable the highlighting of pasted text (while keeping the "bracketed paste mode" functionality enabled), or even to define custom highlighting. You need to place something like this in your .inputrc: set enable-active-region off or set active-region-start-color "\e[42m" # change it to whatever you wish set active-region-end-color "\e[m" -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Invalid Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Invalid Status in readline package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978979] Re: Text on the screen gets multiplied on resizing the window.
*** This bug is a duplicate of bug 1927063 *** https://bugs.launchpad.net/bugs/1927063 ** This bug has been marked a duplicate of bug 1927063 Terminal prompt got strangely replicated when resizing terminal horizontally -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1978979 Title: Text on the screen gets multiplied on resizing the window. Status in gnome-terminal package in Ubuntu: New Bug description: When you reduce the width of the Terminal window below the default width to the minimum width and then resize it to the normal width the text on the screen gets multiplied many folds. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-terminal 3.44.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-37.39-generic 5.15.35 Uname: Linux 5.15.0-37-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jun 16 21:28:00 2022 InstallationDate: Installed on 2022-06-07 (9 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_IN SHELL=/bin/bash SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1978979/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1927063] Re: Terminal prompt got strangely replicated when resizing terminal horizontally
(Former VTE developer here) A terminal emulator's job is to execute the precise instructions it receives from the connected application (e.g. bash), and in this case, VTE does that correctly. It's bash (or some other readline app) that asks the terminal to print the prompt over and over again, and VTE does so. There's one thing that VTE does differently than some other terminal emulators, though. Upon resizing the width, it rewraps the contents. I'd argue that this "rewrap on resize" is the single best improvement VTE received during the last decade, it improves the experience of using the terminal so much... well, improves the experience except for the shell prompt. What happens is: The terminal rewraps the existing lines on a resize, and then the shell (which is notified by the resize) assumes that the terminal did not rewrap the lines and it reprints the prompt according to this assumption. Unfortunately this assumption is false, the cursor is not where bash believes it to be, and thus reprinting the prompt goes wrong. (Note: This feature was released in VTE in spring 2014. Since then, there was one particular bash version (4.3 or 4.4, can't recall) that didn't reprint its prompt when the window got resized, therefore the bug didn't occur there.) What could be done to fix this situation? In GNOME Terminal you can disable rewrapping on resize. In dconf-editor navigate to /org/gnome/terminal/legacy/profiles: followed by the Profile ID, there you'll find the config option. While it fixes the prompt's behavior, you'll notice that it also modifies the behavior on earlier lines to a less fortunate one. In case anyone would suggest that VTE should do some "magic": try to figure out if the last line is a shell prompt, and rewrap everything except that last line: No, any approach like this would lead to an utter chaos that is fragile, somewhat working (but there'd always be cases that are still handled incorrectly), different in every terminal, unmaintainable... No, not going to happen. So, what would be the real solution? The only real solution is for bash/readline to introduce the possibility (config option) to assume that the terminal has already rewrapped the lines, thus it doesn't need to reprint the prompt (or if it wishes to reprint then takes into account the rewrapping that has already happened). VTE is not the only terminal out there rewrapping the lines on resize. It wasn't the first one to do this, and wasn't the last one to add this feature either. More and more terminals can do this, and for every newly appearing terminal emulator engine this behavior is pretty much the expectation nowadays. bash needs to catch up with this widespread change that happened in the terminal world. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1927063 Title: Terminal prompt got strangely replicated when resizing terminal horizontally Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Confirmed Status in mate-terminal package in Ubuntu: Confirmed Status in readline package in Ubuntu: Confirmed Status in tilix package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu installed 2. Launch MATE Terminal 3. Navigate to some folder with long name - `cd /usr/share/doc/ayatana-indicator-application` 4. Resize terminal horizontally Expected results: * terminal shows the same "user@host:/usr/share/doc/ayatana-indicator-application$" with single occurrence Actual results: * terminal shows multiple occurrencies of "user@host:/usr/share/doc/ayatana-indicator-application$" (see attached screencast) ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue May 4 10:54:59 2021 InstallationDate: Installed on 2021-04-23 (10 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1927063/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
> I see the benefit to the change in bash from a security perspective, so > perhaps gnome-terminal needs to adapt to this new feature. You missed the possibility of keeping bracketed paste mode (the functionality) enabled (as I, for one, have had it enabled ever since bash added this feature, which was like version 4.3 or 4.4 or so), but configuring (patching?) bash not to use inverse colors for pasted text. Use regular colors as it used to do, or some actual coloring (e.g. magenta), or underlining etc. > This is one option, but it may have implications for accessibility If it's good enough for text highlighting in all GTK apps, including the Firefox browser, then I doubt there would suddenly be a11y considerations arising in the terminal. But of course I might be missing something. > There may also be other things that gnome-terminal cold do to adapt to > this change. I can't think of any other easy way. I mean, for example Terminology uses fancy diagonal shading and stronger contour for the highlighted area, but I highly doubt gnome-terminal (vte) would do anything similar any time soon; especially if GTK doesn't have such a feature either. Also don't forget that presumably about a dozen other terminal emulators suffer from the same problem. If you choose to adjust terminals to bash, rather than the other way around, you'll have to do it with many-many terminals. I don't believe it's the preferred approach. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
> h. Bracketed paste mode is enabled by default. > If so, it looks like this "feature" can be disabled. How? The way to disable bracketed paste mode is presumably to place this in .inputrc: set enable-bracketed-paste off But DON'T do this! Bracketed paste mode is an important safety measure against malicious or accidental pastes that contain embedded newlines. See https://thejh.net/misc/website-terminal-copy-paste . What you should be looking for is to preserve bracketed paste mode, yet revert to no highlighting, or customize the highlighting colors. I don't know how to do that because I haven't studied this new bash "feature" yet. If you look it up and find it, please post the answer here :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
...patch its source or ask its developers... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
> You mean it will always be like this going forward? I don't know. This was a change in the default shell "bash". I'm not involved in bash's development, nor in Ubuntu's. I don't know what their plans are. I don't know if this feature can be disabled in bash (but I know that it's bash's documentation to consult). I don't know if Ubuntu plans to disable it by default. > Is this the feature you are referring to?... > ..or, is it this one?... I'm not aware of the exact details of bash's change, and I haven't tried bash-5.1 yet. Both of these look relevant, probably one of them is exactly this one. > I find there is an inconsistency with this new approach: > If you've just pasted text, then highlight the text, the text looks > unhighlighted. > This is visually confusing. This is a good observation. gnome-terminal by default inverts the colors of each cell (I mean: swaps the background and the foreground color) when you highlight with the mouse. Now, if an application also does this (like bash now when pasting, or that one row of "top", etc.), and then you highlight with the mouse, these two operations cancel out each other and you're back to your regular colors. Both components do something that's reasonable on its own, yet the two don't work together nicely. One possible workaround is to configure your terminal to use some fixed colors for highlighting. I, for one, have configured gnome-terminal to use the same orange-ish background that Ubuntu uses anywhere else in GTK when highlighting text. You can configure it in profile settings -> colors, or emit the OSC 17 & 19 escape sequences to achieve the same effect, e.g. «echo -ne '\e]17;#f18458\e\\'». Presumably most other terminal emulators also support this feature. This might even be something for Ubuntu to consider doing globally for all the users by default. Alternatively, you should be able to disable this feature of bash, or configure it to use different colors rather than inverse video. I don't know if these possibilities are implemented in bash, if not then you might need to patch its source or its the developers to add such features. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1926256] Re: Pasted text in the terminal is always highlighted and selected
This is not an issue with the terminals, this is a new feature of bash-5.1. Search for the word "highlight" at https://lists.gnu.org/archive/html/info-gnu/2020-12/msg3.html . --- This could not theoretically be a bug in gnome-terminal/vte. Terminals don't directly paint a letter as a consequence of the user pressing that letter, or pasting something. I'm certain you can think of plenty of cases where pressing a certain letter does not cause that letter to be painted on the canvas, but some other action (larger repaints), or perhaps nothing at all. When you press a letter, or paste some text, it is forwarded towards the kernel over the tty line, but is not displayed. The kernel then might handle it itself, or forward further towards some application (e.g. bash in this case). Then that application may or may not decide to paint something. Whatever it decides to paint may or may not be the same as the typed letter or pasted text. But even if it's the same, the terminal has no way of making this connection. "The user pressed the letter X, I've forwarded it, 100 milliseconds later I received a letter X to be painted, it must be the «same» X" -- it cannot work like this. What happens in this particular case is that you paste "foo", and in response bash instructs the terminal to print "foo" in inverse colors. The terminal does what it must do: obeys this instuction (without having the slightest idea that it's related to the paste). --- Two more things to mention to complete the picture: There is a so-called "bracketed paste mode", where special markers are inserted at the beginning and end of pasted data. This is how applications (bash in this case) can distinguish it from data typed by the user, without relying on timing heuristics. Also, some terminals have a legacy "local echo" mode where pressed keys immediately appear on the screen. I'm fairly certain it's not used anywhere nowadays. Most terminals don't support it, and VTE removed it in version 0.60, see https://gitlab.gnome.org/GNOME/vte/-/issues/69 . ** Bug watch added: gitlab.gnome.org/GNOME/vte/-/issues #69 https://gitlab.gnome.org/GNOME/vte/-/issues/69 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1926256 Title: Pasted text in the terminal is always highlighted and selected Status in bash package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Invalid Status in mate-terminal package in Ubuntu: Confirmed Status in vte2.91 package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 21.04 installed 2. Launch terminal 3a. Execute some command, select this command to copy it, then paste command 3b. Paste some command from clipboard to terminal Expected result: * pasted command is not highlighted and is not selected Actual result: * pasted command is selected and highlighted ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: mate-terminal 1.24.1-1 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: MATE Date: Tue Apr 27 09:43:56 2021 InstallationDate: Installed on 2021-04-23 (3 days ago) InstallationMedia: Ubuntu-MATE 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: mate-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1926256/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609342] Re: Gnome-terminal sets directory to HOME for ctrl-shift-n and custom shell command
For setting: vte-2.91.sh is intended to do that... the ".sh" extension was missing, sorry. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1609342 Title: Gnome-terminal sets directory to HOME for ctrl-shift-n and custom shell command Status in gnome-terminal package in Ubuntu: Confirmed Bug description: With Ubuntu 14.04 I could Ctrl-Shift-N in my gnome-terminal and another terminal window came up with the same working directory. When I upgraded to 16.04.1, the new terminal window now always uses $HOME as working directory. I want the 14.04 behavior. This has nothing to do with sourcing /etc/profile.d/vte.sh. Fish does this correctly as I can observe directory changes in the title bar. If I uncheck the custom command box in my gnome-terminal profile, the new terminal window correctly uses the current directory. However, it uses my system default shell: bash. For some reason gnome-terminal does not set the working directory if I use a custom command. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: gnome-terminal 3.18.3-1ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 Uname: Linux 4.4.0-31-generic x86_64 NonfreeKernelModules: openafs nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Aug 3 12:32:22 2016 InstallationDate: Installed on 2013-02-13 (1266 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) JournalErrors: Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. No journal files were opened due to insufficient permissions. SourcePackage: gnome-terminal UpgradeStatus: Upgraded to xenial on 2016-08-01 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1609342/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1609342] Re: Gnome-terminal sets directory to HOME for ctrl-shift-n and custom shell command
gnome-terminal 3.36, which is included in Ubuntu 20.04, added a config option Preferences -> -> Command -> Preserve working directory. Older versions preserved the directory only when launching a shell, not when launching a custom command. This behavior was frowned upon by some folks, understandably. The change is at https://gitlab.gnome.org/GNOME/gnome- terminal/-/commit/79b2291 , the two bugtracker entries are linked from the commit message. Now, in order for this to work, two more things have to happen: Whichever application (presumably your shell) is running in the source window has to set the desired value, and whichever application is starting up in the new window has to respect it (not intentionally override it). For setting: vte-2.91 is intended to do that, see its __vte_osc7() method. Now there's a chance that some fragment in your shell profile overrides it. To debug I recommend to manually issue the given escape sequence and then not give back control to the shell, not to give it a chance to override from PS1 or PROMPT_COMMAND or so: printf "\e]7;file:/etc\e\\" ; sleep 1000 A newly opened tab should be in /etc now. If this fixes the problem then try it without the sleep. If that still fixes then your shell just doesn't emit it. If removing the sleep breaks it again then there's something in your prompt overriding the value. To debug the other side: Set up a custom command of "sleep 2000", open a new window, from another terminal locate the pid of this sleep, and check its working directory at /proc//cwd. If this is set correctly, yet it doesn't work your shell or custom command, then it's that command intentionally switching to some other directory. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1609342 Title: Gnome-terminal sets directory to HOME for ctrl-shift-n and custom shell command Status in gnome-terminal package in Ubuntu: Confirmed Bug description: With Ubuntu 14.04 I could Ctrl-Shift-N in my gnome-terminal and another terminal window came up with the same working directory. When I upgraded to 16.04.1, the new terminal window now always uses $HOME as working directory. I want the 14.04 behavior. This has nothing to do with sourcing /etc/profile.d/vte.sh. Fish does this correctly as I can observe directory changes in the title bar. If I uncheck the custom command box in my gnome-terminal profile, the new terminal window correctly uses the current directory. However, it uses my system default shell: bash. For some reason gnome-terminal does not set the working directory if I use a custom command. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: gnome-terminal 3.18.3-1ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 Uname: Linux 4.4.0-31-generic x86_64 NonfreeKernelModules: openafs nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Aug 3 12:32:22 2016 InstallationDate: Installed on 2013-02-13 (1266 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) JournalErrors: Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. No journal files were opened due to insufficient permissions. SourcePackage: gnome-terminal UpgradeStatus: Upgraded to xenial on 2016-08-01 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1609342/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1876768] Re: Terminal mouse went berserk after lost ssh connection
The same applies not just for the mouse mode, but a whole lot of other terminal modes (e.g. keypad modes, alternate charset, alternate scroll mode, bracketed paste mode, colors, attributes and many many more...). The problem cannot be fixed in the terminal: The terminal, by design, only sees a single continuous stream of instructions to execute. It has no idea where they come from, e.g. remote or local, ssh or not. It cannot figure out when is the time to override those instructions. A reasonable place to fix this would be the shell prompt (or a hardwired behavior of the shell, to reset these modes whenever it prints the prompt). You can customize your PS1 to include the escape sequence that switches off mouse mode, and whatever else you wish. (Don't forget to wrap these in \[ \] as per the PROMPTING section in bash's manual.) I agree that either upstream bash, or downstream distributions by configuring PS1 accordingly, should do their best to minimalize the risk of such situations, i.e. reset as many of the terminal modes as reasonable. I myself used to do it in my personal PS1 until I got bored of maintaining it and stopped caring, the problems are so rare that I just execute "reset" or close the terminal and open a new one :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1876768 Title: Terminal mouse went berserk after lost ssh connection Status in gnome-terminal package in Ubuntu: New Bug description: I'm not sure I assigned this issue to the correct package. The bug is either in bash, or in Ubuntu's application terminal, the one that provides a terminal window to run bash in, which I think is xterm but I'm not sure. Also this could be triggered by either an issue in ssh or in vim which is run on the remote server (see steps to reproduce below), BUT no matter whether or not there's actually a bug in either of them, the shell itself (or the terminal wrapper window) is almost certainly at fault for not being robust against that. So let's get to the issue. What reproduced it for me: 1. I opened a terminal in Ubuntu on my laptop 2. In that terminal, I connected to a remote server using ssh 3. Within ssh, on the remote server I ran vim 4. Several hours passed and I suspended my local laptop 5. I resumed from suspend and went back to the terminal At this point the connection with the remote server was obviously lost, so as soon as I typed something, I was outside of ssh and in my local shell. 6. I ran some commands locally in the terminal (obviously starting with "clear" to clean up the mess left from quitting ssh while vim was open on the remote server) 7. I clicked and dragged within the terminal to select some text EXPECTED: the mouse should behave normally as it usually does when you click and drag to select stuff in a terminal OBSERVED: the terminal went berserk and for every movement of the mouse while the mouse button was pressed, a bunch of gibberish characters appeared. Now, I understand that while I was connected to the remote server via ssh, and running vim on it, the mouse had a certain behavior, which implies that somehow information about the interaction of the mouse with the terminal is sent over to the server where vim reacts to it. And I understand that both vim on the server and ssh on the local machine exited abruptly when I suspended and resumed my computer, and/or because of the hours of inactivity. So, I understand that something about the way the terminal window, or bash itself, handles mouse input, ramained in some unexpected status. However, that that can happen is a bug. A ssh connection can be lost, and this possibility must be taken into account. The responsibility of this cannot by definition belong to vim or any other software on the remote machine, because if the connection is broken there's nothing the remote machine can do to prevent bad stuff from happening on the local machine. And I think the responsibility shouldn't fall on the ssh client either, because any program launched by the shell (such as in this case ssh) can die unexpectedly, or even behave malitiously, and once you exit from it, the shell itself (or the terminal window that hosts it) MUST restore its normal interaction with keyboard, mouse and whatever else. However, if ssh is exiting gracefully after detecting a break in the connection, then of course it should do its best to not leave its parent shell in a mess of a state (even if the shell has a responsibility to not be left in a mess of a state by a misbehaving ssh that doesn't do its job properly when exiting). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xterm 322-1ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-173.203-generic 4.4.208 Uname: Linux 4.4.0-173-generic x86_64 NonfreeKernelModules:
[Desktop-packages] [Bug 1876113] Re: Gnome terminal omits cmake bootstrap command from bash history
Yes the space could be relevant, search for "ignorespace" in bash's manual. Also, it's the shell (bash) handling the history, not the terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1876113 Title: Gnome terminal omits cmake bootstrap command from bash history Status in gnome-terminal package in Ubuntu: New Bug description: I only had one window opened, and that opened when I went into the cmake build directory and clicked "Open in terminal". Terminal opened, and I ran the bootstrap command, only to find there was an error because I did not install libssl-dev. I ran sudo apt install libssl- dev, and then I pushed the up button to run the bootstrap again, however, the terminal went straight to the last command I ran in terminal's history BEFORE the " ./bootstrap -- -DCMAKE_BUILD_TYPE:STRING=Release" command, which means terminal omitted the bootstrap command from history when it should have kept it. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-terminal 3.36.1.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-28.32-generic 5.4.30 Uname: Linux 5.4.0-28-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Thu Apr 30 10:09:49 2020 InstallationDate: Installed on 2020-04-29 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-04-29 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Package: gnome-terminal 3.36.1.1-1ubuntu1 PackageArchitecture: amd64 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 5.4.0-28.32-generic 5.4.30 Tags: focal Uname: Linux 5.4.0-28-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1876113/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1872377] Re: No menus in Unity after upgrading to 20.04
See also bug #1859123.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1872377
Title:
No menus in Unity after upgrading to 20.04
Status in firefox package in Ubuntu:
Won't Fix
Bug description:
In Ubuntu 19.10, the Firefox menus appeared as normal. After upgrading
to Ubuntu 20.04 beta, with Firefox 75.0+build3-0ubuntu1, the Firefox
menus no longer appear either on the window or the title bar. This
happens both when the window is maximised and when it isn't.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: firefox 75.0+build3-0ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
AddonCompatCheckDisabled: False
ApportVersion: 2.20.11-0ubuntu26
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: alistair 2490 F pulseaudio
BuildID: 20200403170909
CasperMD5CheckResult: skip
Channel: Unavailable
CurrentDesktop: Unity:Unity7:ubuntu
Date: Mon Apr 13 09:55:56 2020
ForcedLayersAccel: False
IfupdownConfig:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
dns-search integrics.com
IncompatibleExtensions:
English (GB) Language Pack - langpack-en...@firefox.mozilla.org
English (South Africa) Language Pack - langpack-en...@firefox.mozilla.org
Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
InstallationDate: Installed on 2017-08-16 (970 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
IpRoute:
default via 10.12.0.1 dev enp0s31f6 proto dhcp metric 100
10.12.0.0/21 dev enp0s31f6 proto kernel scope link src 10.12.3.219 metric
100
169.254.0.0/16 dev enp0s31f6 scope link metric 1000
MostRecentCrashID: bp-3d145359-2f62-4b35-a046-86be50191125
PrefErrors: Unexpected character ',' before close parenthesis @
/usr/lib/firefox/omni.ja:greprefs.js:733
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=75.0/20200403170909 (In use)
RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: Upgraded to focal on 2020-04-12 (0 days ago)
dmi.bios.date: 11/29/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N1WET57W (1.36 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20HFCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrN1WET57W(1.36):bd11/29/2019:svnLENOVO:pn20HFCTO1WW:pvrThinkPadT470s:rvnLENOVO:rn20HFCTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T470s
dmi.product.name: 20HFCTO1WW
dmi.product.sku: LENOVO_MT_20HF_BU_Think_FM_ThinkPad T470s
dmi.product.version: ThinkPad T470s
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1872377/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1859123] Re: No global menus (panel-appmenu / dbus) in Firefox 72.0.1
I was severely annoyed by the new behavior of the Alt key (FF 75, Ubuntu 20.04, Unity 7). If I move the window using Alt + mouse drag (which I frequently do), the menu opens up. Subsequent letters I type aren't sent to the webpage, but navigate the menu. Another lone Alt keypress doesn't close it either (well, pressing it closes, but then releasing the key opens the menu bar again), so I have to reach out to Esc to close it. This behavior was unacceptable for me. I first found the workaround of enabling View -> Toolbars -> Menu bar. This way the menu bar is always visible, and the super annoying behavior of Alt is gone. Alas, there's a price to pay in terms of wasted screen real estate. After a bit more searching I found an even better workaround. Instead of the previous one, go to about:config and set ui.key.menuAccessKey to -1. Then the browser needs to be restarted. A lone Alt key (or Alt + moving the window) no longer opens up the menu bar. However, Alt+F, Alt+E etc., as well as F10 still open it up, so all the functionality, in their familiar layout is still conveniently available. It's not as good as Unity integration used to be, but almost as good; to me it's an acceptable minor inconvenience. I hope I could help some people with this comment. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1859123 Title: No global menus (panel-appmenu / dbus) in Firefox 72.0.1 Status in firefox package in Ubuntu: Won't Fix Bug description: No global menus are displayed in latest Firefox 72.0.1 (possibly in a slightly earlier version). This issue was observed on three different systems all running Ubuntu MATE 20.04 Focal (development), and I first noticed it on each system upon updating to 72.0.1 today. The symptoms are identical to https://bugs.launchpad.net/ubuntu- mate/+bug/1743687 , but running `env UBUNTU_MENUPROXY=0 firefox` does not resolve the issue. `env UBUNTU_MENUPROXY=1 firefox` does not resolve the issue either. My first guess is that the issue is a change in Firefox, due to how the previous solution with the environment variable no longer works. (Perhaps a change to the Unity menu patch?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1859123/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1871807] Re: Installed fonts are not available for selection
gnome-terminal lists the fonts that are monospace according to pango_font_family_is_monospace(). The font as well as Pango should be examined why this one isn't believed to be a monospace one. That being said, you can still set this font using dconf-editor, by setting /org/gnome/terminal/legacy/profiles:/:/font. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1871807 Title: Installed fonts are not available for selection Status in gnome-terminal package in Ubuntu: New Bug description: I have installed the following font from nerd fonts using gnome-fonts by double clicking the file and selecting install. https://github.com/ryanoasis/nerd-fonts/blob/master/patched-fonts/FiraCode/Medium/complete/Fura%20Code%20Medium%20Nerd%20Font%20Complete%20Mono.otf The font doesn't appear in gnome terminal custom font selector. I'm running the following system Linux admin2-ThinkPad-X1-Carbon-7th 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux And using gnome terminal 3.28.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1871807/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1872053] Re: Local mail is never checked
I'd take one step back and ask the question: Why would anyone one a graphical system need to run a terminal emulator in order to get notified about new mail? What if someone uses all kinds of other applications (web browser, document editor, photo viewer, music player...), just not a terminal, why wouldn't they be notified? The right approach is not to fix whatever happens inside the terminal emulator, the right approach is to have a graphical indicator on the desktop. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1872053 Title: Local mail is never checked Status in gnome-terminal package in Ubuntu: New Bug description: Description: Ubuntu 19.10 Release: 19.10 gnome-terminal: Installed: 3.34.2-1ubuntu1 Candidate: 3.34.2-1ubuntu1 Context : In a typical daily use scenario, a Ubuntu user is not expected to use a console login with "Ctrl-Alt Fx". Instead it is expected to use gnome-terminal for command-line interaction. That being said : What I expect to happen when I launch gnome-terminal : I expect the bash shell started by gnome-terminal to check local mail (in /var/mail/$USER ) and reports accordingly "You have new mail" if there is new mail. What happens instead : gnome-terminal invokes bash with $MAIL variable not set. So mail is not checked, and the user is never informed about new local mail. Workaround : Put export MAIL=/var/mail/$USER in ~/.bashrc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1872053/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1872053] Re: Local mail is never checked
It is really, really not the terminal emulator's job to set basic environment variables. It should either be done by the environment in which gnome-terminal is started (e.g. systemd --user), so that the terminal just transparently passes this on; or should be done by the shell initialization files, as in your workaround. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1872053 Title: Local mail is never checked Status in gnome-terminal package in Ubuntu: New Bug description: Description: Ubuntu 19.10 Release: 19.10 gnome-terminal: Installed: 3.34.2-1ubuntu1 Candidate: 3.34.2-1ubuntu1 Context : In a typical daily use scenario, a Ubuntu user is not expected to use a console login with "Ctrl-Alt Fx". Instead it is expected to use gnome-terminal for command-line interaction. That being said : What I expect to happen when I launch gnome-terminal : I expect the bash shell started by gnome-terminal to check local mail (in /var/mail/$USER ) and reports accordingly "You have new mail" if there is new mail. What happens instead : gnome-terminal invokes bash with $MAIL variable not set. So mail is not checked, and the user is never informed about new local mail. Workaround : Put export MAIL=/var/mail/$USER in ~/.bashrc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1872053/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1869769] Re: gnome-terminal regularly becomes corrupted
https://weechat.org/files/doc/devel/weechat_user.en.html#option_weechat.look.eat_newline_glitch: "[eat_newline_glitch] is disabled by default because it can cause serious display bugs" Try the behavior in xterm, too. If it's buggy there too then it clearly has nothing to do with gnome-terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1869769 Title: gnome-terminal regularly becomes corrupted Status in gnome-terminal package in Ubuntu: New Bug description: I regularly run weechat inside gnome-terminal, and it routinely becomes corrupted. It's hard to say whether this is a gnome-terminal bug, but I've seen it on different machines. The problem is perhaps best shown through a screenshot (attached). You can see the statusbar in the second to last row incorrectly contains the words "I would" that were displayed elsewhere in the terminal but weechat at some point. Normal usage of weechat results in tabs that have corruption in other rows, but I wasn't readily able to find an example with non-sensitive information. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.2-1ubuntu1~18.04.1 Uname: Linux 5.5.0-050500rc6-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.12 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Mon Mar 30 13:25:03 2020 InstallationDate: Installed on 2020-01-03 (86 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1869769/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1868116] Re: QEMU monitor no longer works
Thanks for this investigation so far! We've opened an upstream VTE issue at https://gitlab.gnome.org/GNOME/vte/issues/222 . We'd appreciate if QEMU developers joined us there. Apparently QEMU uses the "commit" signal in a way that it was not meant to be used, and thus it's unclear what the best solution would be. ** Bug watch added: gitlab.gnome.org/GNOME/vte/issues #222 https://gitlab.gnome.org/GNOME/vte/issues/222 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1868116 Title: QEMU monitor no longer works Status in QEMU: New Status in qemu package in Ubuntu: Triaged Status in vte2.91 package in Ubuntu: New Bug description: Repro: VTE $ meson _build && ninja -C _build && ninja -C _build install qemu: $ ../configure --python=/usr/bin/python3 --disable-werror --disable-user --disable-linux-user --disable-docs --disable-guest-agent --disable-sdl --enable-gtk --disable-vnc --disable-xen --disable-brlapi --disable-fdt --disable-hax --disable-vde --disable-netmap --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-seccomp --disable-glusterfs --disable-tpm --disable-numa --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-vxhs --disable-slirp --disable-blobs --target-list=x86_64-softmmu --disable-rdma --disable-pvrdma --disable-attr --disable-vhost-net --disable-vhost-vsock --disable-vhost-scsi --disable-vhost-crypto --disable-vhost-user --disable-spice --disable-qom-cast-debug --disable-vxhs --disable-bochs --disable-cloop --disable-dmg --disable-qcow1 --disable-vdi --disable-vvfat --disable-qed --disable-parallels --disable-sheepdog --disable-avx2 --disable-nettle --disable-gnutls --disable-capstone --disable-tools --disable-libpmem --disable-iconv --disable-cap-ng $ make Test: $ LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH ./build/x86_64-softmmu/qemu-system-x86_64 -enable-kvm --drive media=cdrom,file=http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso - switch to monitor with CTRL+ALT+2 - try to enter something Affects head of both usptream git repos. --- original bug --- It was observed that the QEMU console (normally accessible using Ctrl+Alt+2) accepts no input, so it can't be used. This is being problematic because there are cases where it's required to send commands to the guest, or key combinations that the host would grab (as Ctrl-Alt-F1 or Alt-F4). ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: qemu 1:4.2-3ubuntu2 Uname: Linux 5.6.0-rc6+ x86_64 ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 CurrentDesktop: XFCE Date: Thu Mar 19 12:16:31 2020 Dependencies: InstallationDate: Installed on 2017-06-13 (1009 days ago) InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND qemu-system-x86 Sl+ 1000 1000 34275 25235 29.2 qemu-system-x86_64 -m 4G -cpu Skylake-Client -device virtio-vga,virgl=true,xres=1280,yres=720 -accel kvm -device nec-usb-xhci -serial vc -serial stdio -hda /home/usuario/Sistemas/androidx86.img -display gtk,gl=on -device usb-audio kvm-nx-lpage-re S0 0 34284 2 0.0 [kvm-nx-lpage-re] kvm-pit/34275 S0 0 34286 2 0.0 [kvm-pit/34275] MachineType: LENOVO 80UG ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc6+ root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 i915.enable_gvt=1 i915.fastboot=1 cgroup_enable=memory swapaccount=1 zswap.enabled=1 zswap.zpool=z3fold resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M usbhid.quirks=0x0079:0x0006:0x10 config_scsi_mq_default=y scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 nbd.max_part=63 SourcePackage: qemu UpgradeStatus: Upgraded to focal on 2019-12-22 (87 days ago) dmi.bios.date: 08/09/2018 dmi.bios.vendor: LENOVO dmi.bios.version: 0XCN45WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: Toronto 4A2 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40679 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 310-14ISK dmi.modalias: dmi:bvnLENOVO:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: dmi.product.family: IDEAPAD dmi.product.name: 80UG dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK dmi.product.version: Lenovo ideapad 310-14ISK dmi.sys.vendor: LENOVO mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240 To manage notifications
[Desktop-packages] [Bug 1691678] Re: Scrollbars escape the bottom and right side of the Terminal window by 1px
> but dropping the change creates a regression on the Ubuntu session/theme So the situation is: Unpatched gnome-terminal looks perfect on the default GTK theme and on many others, except Ubuntu's. Conclusion: Let's patch gnome-terminal! Wow. I'm wondering: Has anyone considered fixing the Ubuntu theme(s) instead? Oh, sure, in comment 16: "there's a workaround hacked into Yaru" Why is that a workaround, and not a fix? Any why Yaru only and not Ambiance or any other affected Ubuntu theme? Move forward please in this direction, fix (or workaround, whatever) the affected themes so that then you can drop the broken gnome-terminal patch. Or, again: If you believe that your themes as well as your gnome- terminal patch are correct, and other themes are buggy, please provide evidence. If that's not the case, adding a workaround to (and thus breaking) gnome-terminal instead of fixing the broken themes was clearly the wrong thing to do, and should be properly fixed ASAP. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1691678 Title: Scrollbars escape the bottom and right side of the Terminal window by 1px Status in GNOME Terminal: Fix Released Status in gnome-terminal package in Ubuntu: Confirmed Status in gtk+3.0 package in Ubuntu: Confirmed Status in ubuntu-themes package in Ubuntu: Confirmed Status in yaru-theme package in Ubuntu: Fix Released Bug description: Ubuntu's orange overlay scrollbars escape the bottom of the window during resizing. To reproduce try gnome-shell on artful using the Ambiance theme. Open a Terminal window and resize it vertically, quickly. Notice the bottom of the overlay scrollbar overruns the bottom of the window. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-shell 3.24.2-0ubuntu3 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.5-0ubuntu3 Architecture: amd64 Date: Thu May 18 15:28:33 2017 DisplayManager: lightdm GsettingsChanges: b'org.gnome.shell' b'app-picker-view' b'uint32 1' b'org.gnome.shell' b'favorite-apps' b"['firefox.desktop', 'org.gnome.Terminal.desktop', 'rhythmbox.desktop', 'org.gnome.Nautilus.desktop', 'org.gnome.Software.desktop', 'yelp.desktop']" b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'" b'org.gnome.desktop.interface' b'scaling-factor' b'uint32 1' InstallationDate: Installed on 2017-05-03 (15 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502) SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-terminal/+bug/1691678/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1691678] Re: Scrollbars escape the bottom and right side of the Terminal window by 1px
> It appears we would need a new upstream bug to track this because the old one didn't go anywhere. This is not true. The old one did go somewhere: It examined the behavior and clearly concluded that upstream gnome-terminal is NOT buggy here, it never was. It's one of the Ubuntu patches that introduces the bug. This conclusion was also stated in this thread here. Could you please clarify how you expect upstream gnome-terminal to fix this situation? Meanwhile, this bug is almost 3 years old, and I haven't seen any worthwile comment from any Ubuntu developer trying to track down which of its patches, and which part within that is the culprit. Or if you believe that upstream gnome-terminal is indeed buggy, this bug just doesn't happen to trigger anywhere else, except with your perfect innocent patches, then this claim should be justified with technical arguments, something I haven't seen in this thread yet. And I can't help to notice that this is not the only issue where Ubuntu introduces a regression to the overall gnome-terminal user experience, and then really doesn't care about fixing it. Bug 1770507 is another prominent example, you guys broke something during the feature freeze period(!) of the previous LTS, and still til this day haven't cared about fixing. I'm sad and disappointed to see that the software I've been co- developing for years, putting my passion, heart, and lots and lots of time into, is broken in multiple ways by perhaps the most popular Linux distribution, and its developers just don't care. I don't even know what to think about you pointing fingers at us. Instead, maybe could you Ubuntu devs finally please, pretty please get yourself together and fix at the very least these two bugs that YOU introduced, in time for the just-around-the-corner LTS release? If simply by dropping the patches that introduces the bugs, along with then dropping whatever features those patches add, so it be. Thanks! I firmly believe that Ubuntu should revise its bug prioritizing policy, and handle with much-much higher priority if one of its changes introduces a regression from mainstream. It should be something like: if a regression is found, and not fixed within a week, the patch is automatically dropped. Think about it... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1691678 Title: Scrollbars escape the bottom and right side of the Terminal window by 1px Status in GNOME Terminal: Fix Released Status in gnome-terminal package in Ubuntu: Confirmed Status in gtk+3.0 package in Ubuntu: Confirmed Status in ubuntu-themes package in Ubuntu: Confirmed Status in yaru-theme package in Ubuntu: Fix Released Bug description: Ubuntu's orange overlay scrollbars escape the bottom of the window during resizing. To reproduce try gnome-shell on artful using the Ambiance theme. Open a Terminal window and resize it vertically, quickly. Notice the bottom of the overlay scrollbar overruns the bottom of the window. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-shell 3.24.2-0ubuntu3 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.5-0ubuntu3 Architecture: amd64 Date: Thu May 18 15:28:33 2017 DisplayManager: lightdm GsettingsChanges: b'org.gnome.shell' b'app-picker-view' b'uint32 1' b'org.gnome.shell' b'favorite-apps' b"['firefox.desktop', 'org.gnome.Terminal.desktop', 'rhythmbox.desktop', 'org.gnome.Nautilus.desktop', 'org.gnome.Software.desktop', 'yelp.desktop']" b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'" b'org.gnome.desktop.interface' b'scaling-factor' b'uint32 1' InstallationDate: Installed on 2017-05-03 (15 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502) SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-terminal/+bug/1691678/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1865326] Re: extra spaces on right and bottom border of gnome terminal's scrollbar
*** This bug is a duplicate of bug 1691678 *** https://bugs.launchpad.net/bugs/1691678 ** This bug has been marked a duplicate of bug 1691678 Scrollbars escape the bottom and right side of the Terminal window by 1px -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1865326 Title: extra spaces on right and bottom border of gnome terminal's scrollbar Status in gnome-terminal package in Ubuntu: New Bug description: On Ubuntu 19.10, On certain themes including the default adwaita theme which is used in vaniall gnome session, there are some extra ugly spaces around the scrollbar of the gnome terminal at right and bottom. I've checked other linux versions with same GNOME version, they don't have it. I've attached a screenshot of that I've asked a question on AskUbuntu site and many suggested to file a bug report https://askubuntu.com/q/1206023/61218 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1865326/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1856438] Re: auto suggest previously used commands
This should be a feature request against the command line shell, not the terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1856438 Title: auto suggest previously used commands Status in gnome-terminal package in Ubuntu: New Bug description: 1) Ubuntu 19.10 2) 3.34.2-1ubuntu1 3) If a user types part of a previously used command, display the suggested command. A user could press the right arrow key to accept the suggested command. 4) No auto suggestion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1856438/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1850621] Re: zoom sets wrong window size in fullscreen mode
*** This bug is a duplicate of bug 1849285 *** https://bugs.launchpad.net/bugs/1849285 This is fixed in official gnome-terminal 3.34.1, which is on its way to appear as an eoan update. So let me mark this as duplicate. ** This bug has been marked a duplicate of bug 1849285 [SRU] 3.34.2 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1850621 Title: zoom sets wrong window size in fullscreen mode Status in gnome-terminal package in Ubuntu: New Bug description: Using eoan 19.10 and wayland and the following package versions * gnome-shell 3.34.1ubuntu1 * gnome-terminal 3.34.0-1ubuntu2 * mutter 3.34.1-1ubuntu1 * libmutter-5-0 3.34.1-1ubuntu1 How to reproduce: * I open up gnome-terminal and switch to fullscreen (F11). * Then I decrease font-size / zoom (CTRL+-). * The gnome-terminal window no longer fills the display. The window size is reduced proportionally to the reduction in font size. The same applies for zooming in / increasing font size. The window is then larger than the display and the cursor is outside of the viewport. What I expect: * No matter the font size, the gnome-terminal window should cover the whole display (not more, not less) as long as gnome-terminal is in fullscreen mode. As far as I remember, this was working before in Ubuntu 19.04 disco. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1850621/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1849090] Re: Autocompletion does not work correctly with special signs
Autocompletion is done by the shell and its configs, not by the terminal. ** Also affects: bash-completion (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1849090 Title: Autocompletion does not work correctly with special signs Status in bash-completion package in Ubuntu: New Status in gnome-terminal package in Ubuntu: New Bug description: The autocompletion of the terminal does not work correct for some special signs, e.g. if I edit a file by vim "A123\$B123#_asd" it is not possible to get it for autocompletion afterwards. If I enter cat `A123\$B123#` and then hit tab two times, the file is display correctly, but if I then enter `<` and hit tab, it is completed to cat `A123\$B123#_asd` which does not exist (so the full file is appended after `<`, not only the additional part. I am using Ubuntu 18.04 with newest updates, including gnome-terminal 3.28.2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1849090/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1847850] Re: Update vte2.91 to 0.58.2
Filed bug #1848156, thanks! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1847850 Title: Update vte2.91 to 0.58.2 Status in vte2.91 package in Ubuntu: Fix Released Status in vte2.91 source package in Eoan: Fix Released Bug description: I'm filing a bug since we are now in Final Freeze for Ubuntu 19.10 vte 0.58.2 is a new release in the stable 0.58 series aligned with GNOME 3.34. There is a standing microrelease exception for GNOME. https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/vte/compare/0.58.0...0.58.2 This update is required to update gnome-terminal to 3.34.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1847850/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1847850] Re: Update vte2.91 to 0.58.2
Filed #1848156, thanks! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1847850 Title: Update vte2.91 to 0.58.2 Status in vte2.91 package in Ubuntu: Fix Released Status in vte2.91 source package in Eoan: Fix Released Bug description: I'm filing a bug since we are now in Final Freeze for Ubuntu 19.10 vte 0.58.2 is a new release in the stable 0.58 series aligned with GNOME 3.34. There is a standing microrelease exception for GNOME. https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/vte/compare/0.58.0...0.58.2 This update is required to update gnome-terminal to 3.34.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1847850/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1848156] [NEW] Update gnome-terminal to 3.34.1
Public bug reported: Please update to gnome-terminal 3.34.1 (or .2) for eoan. Or, at least, cherry-pick this trivial fix: https://gitlab.gnome.org/GNOME/gnome- terminal/commit/2cbc9e6b9be7f4d6b2d92b40e37ec687d36ce98d A change in GTK triggered a bug in Terminal causing a pretty bad user experience. A fullscreened terminal under Wayland doesn't retain its fullscreen status at certain operations, such as opening/closing a second tab, or zooming. Opening a second tab actually further grows the window as the tab bar appears, so that the bottom 1 or 2 text rows become invisible (out of screen). This issue was fixed in 3.34.1, along with two other minor issues and many translation updates. 3.34.2 brings another translation update only. Ubuntu usually aims to ship GNOME x.y.1. I assume there was no particular reason for not updating GNOME Terminal to .1 in this cycle, other than probably lack of time. I sincerely hope that the aforementioned UX regression convinces you to release a last minute fix for 19.10, or an update shortly afterwards. Thanks a lot! ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-terminal 3.34.0-1ubuntu2 [modified: usr/bin/gnome-terminal usr/libexec/gnome-terminal-server usr/share/applications/org.gnome.Terminal.desktop usr/share/glib-2.0/schemas/org.gnome.Terminal.gschema.xml usr/share/icons/hicolor/scalable/apps/org.gnome.Terminal.svg usr/share/metainfo/org.gnome.Terminal.appdata.xml] ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Tue Oct 15 10:42:06 2019 InstallationDate: Installed on 2016-11-09 (1069 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) SourcePackage: gnome-terminal UpgradeStatus: Upgraded to eoan on 2019-09-08 (36 days ago) ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug eoan -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1848156 Title: Update gnome-terminal to 3.34.1 Status in gnome-terminal package in Ubuntu: New Bug description: Please update to gnome-terminal 3.34.1 (or .2) for eoan. Or, at least, cherry-pick this trivial fix: https://gitlab.gnome.org/GNOME/gnome- terminal/commit/2cbc9e6b9be7f4d6b2d92b40e37ec687d36ce98d A change in GTK triggered a bug in Terminal causing a pretty bad user experience. A fullscreened terminal under Wayland doesn't retain its fullscreen status at certain operations, such as opening/closing a second tab, or zooming. Opening a second tab actually further grows the window as the tab bar appears, so that the bottom 1 or 2 text rows become invisible (out of screen). This issue was fixed in 3.34.1, along with two other minor issues and many translation updates. 3.34.2 brings another translation update only. Ubuntu usually aims to ship GNOME x.y.1. I assume there was no particular reason for not updating GNOME Terminal to .1 in this cycle, other than probably lack of time. I sincerely hope that the aforementioned UX regression convinces you to release a last minute fix for 19.10, or an update shortly afterwards. Thanks a lot! ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-terminal 3.34.0-1ubuntu2 [modified: usr/bin/gnome-terminal usr/libexec/gnome-terminal-server usr/share/applications/org.gnome.Terminal.desktop usr/share/glib-2.0/schemas/org.gnome.Terminal.gschema.xml usr/share/icons/hicolor/scalable/apps/org.gnome.Terminal.svg usr/share/metainfo/org.gnome.Terminal.appdata.xml] ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Tue Oct 15 10:42:06 2019 InstallationDate: Installed on 2016-11-09 (1069 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) SourcePackage: gnome-terminal UpgradeStatus: Upgraded to eoan on 2019-09-08 (36 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1848156/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1847850] Re: Update vte2.91 to 0.58.2
Just wondering, Jeremy, in the opening report you said > This update is required to update gnome-terminal to 3.34.2 but there's no gnome-terminal update in progress, is there? gnome-terminal 3.34.1 fixes a problem with fullscreen terminals not staying fullscreen at certain operations like font size change. 3.34.2 is nothing (just a translation update). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1847850 Title: Update vte2.91 to 0.58.2 Status in vte2.91 package in Ubuntu: Fix Released Status in vte2.91 source package in Eoan: Fix Released Bug description: I'm filing a bug since we are now in Final Freeze for Ubuntu 19.10 vte 0.58.2 is a new release in the stable 0.58 series aligned with GNOME 3.34. There is a standing microrelease exception for GNOME. https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/vte/compare/0.58.0...0.58.2 This update is required to update gnome-terminal to 3.34.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1847850/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1847850] Re: Update vte2.91 to 0.58.2
0.58.1 and 0.58.2 each fix a crash. So indeed it would be great if you could make an exception and update these packages, thanks! ** Summary changed: - Update vte2.91 to 2.58.2 + Update vte2.91 to 0.58.2 ** Description changed: I'm filing a bug since we are now in Final Freeze for Ubuntu 19.10 - vte 2.58.2 is a new release in the stable 2.58 series aligned with GNOME + vte 0.58.2 is a new release in the stable 0.58 series aligned with GNOME 3.34. There is a standing microrelease exception for GNOME. https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/vte/compare/0.58.0...0.58.2 This update is required to update gnome-terminal to 3.34.2 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1847850 Title: Update vte2.91 to 0.58.2 Status in vte2.91 package in Ubuntu: New Bug description: I'm filing a bug since we are now in Final Freeze for Ubuntu 19.10 vte 0.58.2 is a new release in the stable 0.58 series aligned with GNOME 3.34. There is a standing microrelease exception for GNOME. https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/vte/compare/0.58.0...0.58.2 This update is required to update gnome-terminal to 3.34.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1847850/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1846255] Re: No cursor in gnome-terminal 3.34.0-1ubuntu2 (eoan)
> Cursor color: checked, same colors Well, if cursor color is the same as the default color then it is requested to be invisible. What you need for the cursor color is something very different from the defaults (e.g. the two colors swapped). Nitpicking: You shouldn't need to restart gnome-terminal, it should pick up the preference changes immediately. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1846255 Title: No cursor in gnome-terminal 3.34.0-1ubuntu2 (eoan) Status in gnome-terminal package in Ubuntu: New Bug description: There is no cursor in gnome-terminal. Issue persists after reboot. Must have happened after some recent update as I use gnome-terminal not all the time but regularly and it is immediately noticeable when editing. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-terminal 3.34.0-1ubuntu2 ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0 Uname: Linux 5.3.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 1 20:34:14 2019 InstallationDate: Installed on 2018-09-13 (382 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180912) SourcePackage: gnome-terminal UpgradeStatus: Upgraded to eoan on 2019-09-06 (24 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1846255/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1846255] Re: No cursor in gnome-terminal 3.34.0-1ubuntu2 (eoan)
Could you please execute this command? Do you see a cursor while it is running? echo -ne '\e[?25h\e]112\e\\'; sleep 1000 If not, then while the previous command is still running: Please open gnome-terminal's preferences, click on your profile in the left-side bar. Disable cursor blinking, and try all three available cursor shapes. Does any of them appear? Still while that command is running: Go to the Colors tab of this preference, is Cursor color enabled here? (Is it perhaps set to the same color as your background?) Does changing that setting make any difference? What if you set a custom cursor background color? Can you recall when was the last time the cursor showed up correctly for you? (Like, about 1 day ago, about 1 week ago...?) Was that on disco, or eoan beta? Thanks! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1846255 Title: No cursor in gnome-terminal 3.34.0-1ubuntu2 (eoan) Status in gnome-terminal package in Ubuntu: New Bug description: There is no cursor in gnome-terminal. Issue persists after reboot. Must have happened after some recent update as I use gnome-terminal not all the time but regularly and it is immediately noticeable when editing. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-terminal 3.34.0-1ubuntu2 ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0 Uname: Linux 5.3.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 1 20:34:14 2019 InstallationDate: Installed on 2018-09-13 (382 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180912) SourcePackage: gnome-terminal UpgradeStatus: Upgraded to eoan on 2019-09-06 (24 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1846255/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 562130] Re: Selecting an RTL language should install RTL capable terminal emulator
GNOME Terminal 3.34 (as well as all other terminals using VTE 0.58) support RTL. These versions appear in Ubuntu 19.10 Eoan Ermine. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to language-selector in Ubuntu. https://bugs.launchpad.net/bugs/562130 Title: Selecting an RTL language should install RTL capable terminal emulator Status in language-selector package in Ubuntu: Triaged Bug description: Binary package hint: language-selector the default terminal gnome-terminal which is using vte is not able to display RTL text like Arabic,Farsi, Urdu or Hebrew and it's a known bug that is not likly to be fixed at all as vte developer said. see bug #263822 How ever Mlterm is ready to support variant of scripts including Arabic ,Hebrew and even Chinese. see https://wiki.ubuntu.com/Mlterm problem: no terminal with RTL support fix: installing Mlterm for RTL by default ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: language-selector 0.5.4 ProcVersionSignature: Ubuntu 2.6.32-20.29-generic-pae 2.6.32.11+drm33.2 Uname: Linux 2.6.32-20-generic-pae i686 Architecture: i386 CheckboxSubmission: 4190bdfb1b8df71969b6cbad70f1beb6 CheckboxSystem: 9c26adf6eed2f681ba41f94dd24c07e4 Date: Tue Apr 13 11:38:45 2010 EcryptfsInUse: Yes InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Alpha i386 (20100113) PackageArchitecture: all ProcEnviron: LANG=ar_SA.utf8 SHELL=/bin/bash SourcePackage: language-selector To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/562130/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843880] [NEW] GtkSpinButton's context menu changes the width of '+'
Public bug reported: GtkSpinButton consists of a (typically numeric) input field, followed by a '-' and finally a '+' sign. The width of the '+' sign shrinks a little bit when you open the right-click context menu of the input field. It shouldn't, it should have a constant width. Happens with Ubuntu's old default Ambiance and Radiance themes. Does not happen with Ubuntu's new default Yaru, or with GTK's default Adwaita. Example: Open gnome-terminal, right click on its terminal canvas, choose Preferences. You're taken to the profile's Text tab which contains four such widgets. Right-click on one of these input fields, e.g. on "80" for the initial number of columns. In addition to the context menu appearing, the '+' button becomes narrower, and thus the label on its right (e.g. "columns") shifts to the left. For some of the spinbuttons (the ones that stretch the window) the entire window also shrinks. Dismiss the context menu and it goes back to its previous width. (This is similar to former bug 1740709.) ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: light-themes 19.04-0ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Fri Sep 13 11:48:51 2019 InstallationDate: Installed on 2016-11-09 (1037 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: ubuntu-themes UpgradeStatus: Upgraded to eoan on 2019-09-08 (4 days ago) ** Affects: ubuntu-themes (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug eoan visual-quality ** Tags added: visual-quality -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1843880 Title: GtkSpinButton's context menu changes the width of '+' Status in ubuntu-themes package in Ubuntu: New Bug description: GtkSpinButton consists of a (typically numeric) input field, followed by a '-' and finally a '+' sign. The width of the '+' sign shrinks a little bit when you open the right-click context menu of the input field. It shouldn't, it should have a constant width. Happens with Ubuntu's old default Ambiance and Radiance themes. Does not happen with Ubuntu's new default Yaru, or with GTK's default Adwaita. Example: Open gnome-terminal, right click on its terminal canvas, choose Preferences. You're taken to the profile's Text tab which contains four such widgets. Right-click on one of these input fields, e.g. on "80" for the initial number of columns. In addition to the context menu appearing, the '+' button becomes narrower, and thus the label on its right (e.g. "columns") shifts to the left. For some of the spinbuttons (the ones that stretch the window) the entire window also shrinks. Dismiss the context menu and it goes back to its previous width. (This is similar to former bug 1740709.) ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: light-themes 19.04-0ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Fri Sep 13 11:48:51 2019 InstallationDate: Installed on 2016-11-09 (1037 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: ubuntu-themes UpgradeStatus: Upgraded to eoan on 2019-09-08 (4 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1843880/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843872] Re: libexec migration incomplete
> What the script does, since you ask, Sorry for the loose phrasing. I was aware of the global picture, just wasn't sure (and was lazy to investigate) when exactly a bug would be triggered, i.e. when that code would be reached, which you answered: > It is broken if you pass --app-id Thanks for the libexec migration by the way, it's one less thing for me to worry about (Ubuntu doing something differently than mainstream, and if I forget to pass --libexec= then I end up with a server here and a server there and who knows if the right one is started up, it's a source of all kinds of confusions... you must know the feeling. Anyway, it's probably just me, most users don't care about this change :) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1843872 Title: libexec migration incomplete Status in gnome-terminal package in Ubuntu: New Bug description: Debian/Ubuntu package of gnome-terminal 3.34.0 moved the server binary from /usr/lib/gnome-terminal to /usr/libexec. The Ubuntu package ships a wrapper script as /usr/bin/gnome-terminal. This one still looks for the server at its old location in spawn_terminal_server(). It's unclear to me what this wrapper script exactly does, and how/why it still manages to successfully start up gnome-terminal (probably in a different way than it intends to). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1843872/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843872] [NEW] libexec migration incomplete
Public bug reported: Debian/Ubuntu package of gnome-terminal 3.34.0 moved the server binary from /usr/lib/gnome-terminal to /usr/libexec. The Ubuntu package ships a wrapper script as /usr/bin/gnome-terminal. This one still looks for the server at its old location in spawn_terminal_server(). It's unclear to me what this wrapper script exactly does, and how/why it still manages to successfully start up gnome-terminal (probably in a different way than it intends to). ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1843872 Title: libexec migration incomplete Status in gnome-terminal package in Ubuntu: New Bug description: Debian/Ubuntu package of gnome-terminal 3.34.0 moved the server binary from /usr/lib/gnome-terminal to /usr/libexec. The Ubuntu package ships a wrapper script as /usr/bin/gnome-terminal. This one still looks for the server at its old location in spawn_terminal_server(). It's unclear to me what this wrapper script exactly does, and how/why it still manages to successfully start up gnome-terminal (probably in a different way than it intends to). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1843872/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 310053] Re: Devanagari text rendered incorrectly in VTE apps
VTE (libvte-2.91-0) version 0.56 mostly addresses this issue, spacing marks are now combined as desired with the preceding base letter. (Dotted circles still might be displayed around line wraps, as well as under the rectangle cursor. For the latter problem, a workaround is to choose a different cursor shape.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/310053 Title: Devanagari text rendered incorrectly in VTE apps Status in Gnome Virtual Terminal Emulator: New Status in vte package in Ubuntu: Confirmed Bug description: Binary package hint: libvte-common Under Ubuntu 8.10 Gnome-terminal and xfce-terminal incorrectly render devanagari script. Gedit (with the same font) renders the same text correctly. See example in screenshot. Using libvte 0.17.4-0ubuntu1. (Font is Liberation Mono in both applications). http://acm.jhu.edu/~me/devanagari-err.png To manage notifications about this bug go to: https://bugs.launchpad.net/vte/+bug/310053/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1835224] Re: gnome-terminal drops pam_group config
> Starting a gnome-terminal from this terminal Even executing "gnome-terminal" from an xterm goes through dbus/systemd. "gnome-terminal" is just a controlling client that asks systemd to start up a server which then displays the window and does all the rest. Don't ask why the architecture is like this, I don't know. But gnome- terminal definitely doesn't do anything with groups, nor asks dbus/systemd/whatever to tamper with the groups. The issue is probably in systemd, starting up gnome-terminal (and presumably any other app that it starts up) with the wrong groups. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1835224 Title: gnome-terminal drops pam_group config Status in gnome-terminal package in Ubuntu: New Bug description: If you use pam_group to add users to a group and open gnome-terminal the dynamic group is lost. How to reproduce: enable pam_group add "*;*;*;Al-2400;dialout" to /etc/security/group.conf log in with a user which is not in the dialout group open gnome-terminal check with id if you in the dialout group ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.2-1ubuntu1~18.04.1 ProcVersionSignature: Ubuntu 4.15.0-54.58-generic 4.15.18 Uname: Linux 4.15.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 Date: Wed Jul 3 14:52:29 2019 SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1835224/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1835224] Re: gnome-terminal drops pam_group config
gnome-terminal itself doesn't do any authentication / PAM stuff. It's probably an issue with `systemd --user` which launches gnome-terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1835224 Title: gnome-terminal drops pam_group config Status in gnome-terminal package in Ubuntu: New Bug description: If you use pam_group to add users to a group and open gnome-terminal the dynamic group is lost. How to reproduce: enable pam_group add "*;*;*;Al-2400;dialout" to /etc/security/group.conf log in with a user which is not in the dialout group open gnome-terminal check with id if you in the dialout group ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.2-1ubuntu1~18.04.1 ProcVersionSignature: Ubuntu 4.15.0-54.58-generic 4.15.18 Uname: Linux 4.15.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 Date: Wed Jul 3 14:52:29 2019 SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1835224/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 263822] Re: RTL (right to left) support in terminal (BiDi)
GNOME Terminal 3.33.3 (VTE 0.57.3) implements BiDi support, according to the proposal at https://terminal-wg.pages.freedesktop.org/bidi/ . In alignment with Diego's comments and my responses to them, it implements multiple modes. Shuffling the characters according to the BiDi algorithm is enabled by default, this is required for simple utilities such as "echo", "cat" and friends. An escape sequence can turn off BiDi in the terminal, to be used if BiDi is performed by the application running inside. As mentioned, this won't magically make fullscreen apps (e.g. "mc") BiDi-aware, it's impossible without adding this feature to all those applications. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/263822 Title: RTL (right to left) support in terminal (BiDi) Status in Gnome Virtual Terminal Emulator: Confirmed Status in vte package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-terminal The program fails to display bi-directional text correctly. For example, the Arabic word Went (راح) should be spelled raa (ر) Alif (ا) haa (ح) from right to left. The program displays the Arabic text in the opposite direction. examples: ا ب ج become ج ب ا if the problem with numbers (and it's not) it will look like: 123 become 321 that makes many translated terminal applications messages unreadable like dpkg & apt-get ProblemT ype: Bug Architecture: i386 Date: Tue Sep 2 04:44:06 2008 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/bin/gnome-terminal Package: gnome-terminal 2.22.1-0ubuntu2 PackageArchitecture: i386 ProcEnviron: PATH=/usr/locusernamel/sbin:/usr/locusernamel/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/gusernamemes LANG=en_US.UTF-8 SHELL=/bin/busernamesh SourcePackage: gnome-terminal Uname: Linux 2.6.24-19-generic i586 To manage notifications about this bug go to: https://bugs.launchpad.net/vte/+bug/263822/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1691678] Re: Scrollbars escape the bottom and right side of the Terminal window by 1px
I confirm the previous suspicion: This is _not_ an upstream bug. Upstream gnome-terminal draws the scrollbar perfectly. This bug is introduced by one of the Ubuntu patches. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1691678 Title: Scrollbars escape the bottom and right side of the Terminal window by 1px Status in gnome-terminal package in Ubuntu: Confirmed Status in gtk+3.0 package in Ubuntu: Confirmed Bug description: Ubuntu's orange overlay scrollbars escape the bottom of the window during resizing. To reproduce try gnome-shell on artful using the Ambiance theme. Open a Terminal window and resize it vertically, quickly. Notice the bottom of the overlay scrollbar overruns the bottom of the window. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-shell 3.24.2-0ubuntu3 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 ApportVersion: 2.20.5-0ubuntu3 Architecture: amd64 Date: Thu May 18 15:28:33 2017 DisplayManager: lightdm GsettingsChanges: b'org.gnome.shell' b'app-picker-view' b'uint32 1' b'org.gnome.shell' b'favorite-apps' b"['firefox.desktop', 'org.gnome.Terminal.desktop', 'rhythmbox.desktop', 'org.gnome.Nautilus.desktop', 'org.gnome.Software.desktop', 'yelp.desktop']" b'org.gnome.desktop.interface' b'gtk-im-module' b"'gtk-im-context-simple'" b'org.gnome.desktop.interface' b'scaling-factor' b'uint32 1' InstallationDate: Installed on 2017-05-03 (15 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170502) SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1691678/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1829377] [NEW] Remove this package
Public bug reported:
Please remove the ancient GTK2-based vte aka. libvte9{,-common} from
Eoan.
Upstream version has been unmaintained for about 8 years, development
continued in the GTK3 branch (vte2.91 aka. libvte-2.91-0).
Geany is the only package referring to it, and it also does incorrectly
since it already uses GTK3, see bug 1829375.
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: libvte9 1:0.28.2-6
ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6
Uname: Linux 5.0.0-15-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
Date: Thu May 16 13:41:04 2019
InstallationDate: Installed on 2016-11-09 (917 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
SourcePackage: vte
UpgradeStatus: Upgraded to disco on 2019-04-10 (35 days ago)
** Affects: vte (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug disco
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to vte in Ubuntu.
https://bugs.launchpad.net/bugs/1829377
Title:
Remove this package
Status in vte package in Ubuntu:
New
Bug description:
Please remove the ancient GTK2-based vte aka. libvte9{,-common} from
Eoan.
Upstream version has been unmaintained for about 8 years, development
continued in the GTK3 branch (vte2.91 aka. libvte-2.91-0).
Geany is the only package referring to it, and it also does
incorrectly since it already uses GTK3, see bug 1829375.
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: libvte9 1:0.28.2-6
ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6
Uname: Linux 5.0.0-15-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
Date: Thu May 16 13:41:04 2019
InstallationDate: Installed on 2016-11-09 (917 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
SourcePackage: vte
UpgradeStatus: Upgraded to disco on 2019-04-10 (35 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/1829377/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1824438] Re: libvte: syntax error in /etc/profile.d/vte-2.91.sh
What problem did you experience at the first place? What's your goal when you execute the mentioned command? vte-2.91.sh was written for bash and zsh. You execute it with sh (dash). Due to -n, the commands are not executed and thus it skips the bash/zsh check and continues. Then it fails on a bash/zsh specific syntax. This script is not meant to be executed manually, especially not with -n. As such, I see no problem whatsoever. > I believe that this problem leads to the creation of a file called 'config-err' in my /tmp folder. I find it pretty unlikely. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1824438 Title: libvte: syntax error in /etc/profile.d/vte-2.91.sh Status in vte2.91 package in Ubuntu: New Bug description: etc/profile.d $ sh -n vte-2.91.sh vte-2.91.sh: 61: vte-2.91.sh: Syntax error: word unexpected (expecting ")") I believe that this problem leads to the creation of a file called 'config-err' in my /tmp folder. Linux Mint 19.1 x64 Cinnamon Kernel: 5.0.7-050007-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1824438/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1792544] Re: demotion of pcre3 (8.x) a.k.a pcre (without the 3) in favor of pcre2 (10.x)
Please do not forget to remove the pcre patch from Tilix, see https://bugs.launchpad.net/ubuntu/+source/tilix/+bug/1818991 - thanks! ** Also affects: tilix (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1792544 Title: demotion of pcre3 (8.x) a.k.a pcre (without the 3) in favor of pcre2 (10.x) Status in aide package in Ubuntu: Incomplete Status in anope package in Ubuntu: Incomplete Status in apache2 package in Ubuntu: Triaged Status in apr-util package in Ubuntu: Fix Released Status in clamav package in Ubuntu: Fix Released Status in exim4 package in Ubuntu: Incomplete Status in freeradius package in Ubuntu: Incomplete Status in git package in Ubuntu: Fix Released Status in glib2.0 package in Ubuntu: Incomplete Status in grep package in Ubuntu: Incomplete Status in haproxy package in Ubuntu: Fix Released Status in libpam-mount package in Ubuntu: Fix Released Status in libselinux package in Ubuntu: Triaged Status in nginx package in Ubuntu: Incomplete Status in nmap package in Ubuntu: Incomplete Status in pcre3 package in Ubuntu: Confirmed Status in php-defaults package in Ubuntu: Triaged Status in php7.2 package in Ubuntu: Won't Fix Status in postfix package in Ubuntu: Incomplete Status in python-pyscss package in Ubuntu: Incomplete Status in quagga package in Ubuntu: Invalid Status in rasqal package in Ubuntu: Incomplete Status in slang2 package in Ubuntu: Incomplete Status in sssd package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Triaged Status in tilix package in Ubuntu: New Status in ubuntu-core-meta package in Ubuntu: New Status in vte2.91 package in Ubuntu: Fix Released Status in wget package in Ubuntu: Fix Released Status in zsh package in Ubuntu: Incomplete Bug description: https://people.canonical.com/~ubuntu- archive/transitions/html/pcre2-main.html demotion of pcre3 in favor of pcre2. These packages need analysis what needs to be done for the demotion of pcre3: Packages which are ready to build with pcre2 should be marked as 'Triaged', packages which are not ready should be marked as 'Incomplete'. -- For clarification: pcre2 is actually newer than pcre3. pcre3 is just poorly named. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aide/+bug/1792544/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1817438] Re: Error displaying icon for preference menu in title bar
Most likely a duplicate of bug 1770507. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1817438 Title: Error displaying icon for preference menu in title bar Status in gnome-terminal package in Ubuntu: New Bug description: Ubuntu 18.10 gnome-terminal 3.30.1-1ubuntu1 When setting gnome to display the preferences menu in the title bar, the icon is shown in a wrong way. Application icon is displayed too big and not centred within the event hitbox. (Doesn't happen in different applications and happens with every gnome theme.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1817438/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1816171] Re: Show menubar by default in new terminals has no effect
Thanks for the report! I can confirm this; forwarded to: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/81 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1816171 Title: Show menubar by default in new terminals has no effect Status in gnome-terminal package in Ubuntu: Confirmed Bug description: I open a terminal window. No menubar is displayed. From the 'amburger' menu I select Preferences and 'Show menubar by default in new terminals' nothing happens and next time I open a terminal i have no menubar. If i right click on the terminal window and select 'Show menubar' i see the menubar but this option is not remembered next time i open a terminal. corrado@corrado-p6-dd-0215:~$ apt policy gnome-terminal gnome-terminal: Installed: 3.31.90-1ubuntu1 Candidate: 3.31.90-1ubuntu1 Version table: *** 3.31.90-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status corrado@corrado-p6-dd-0215:~$ inxi -SCGx System: Host: corrado-p6-dd-0215 Kernel: 4.19.0-13-generic x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: Gnome 3.30.2 Distro: Ubuntu 19.04 (Disco Dingo) CPU: Topology: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP arch: Kaby Lake rev: 9 L2 cache: 3072 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31296 Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 Graphics: Device-1: Intel HD Graphics 630 vendor: ASRock driver: i915 v: kernel bus ID: 00:02.0 Display: x11 server: X.Org 1.20.3 driver: i915 resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.3.2 direct render: Yes corrado@corrado-p6-dd-0215:~$ ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: gnome-terminal 3.31.90-1ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20 Uname: Linux 4.19.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 15 19:39:13 2019 ExecutablePath: /usr/lib/gnome-terminal/gnome-terminal-server InstallationDate: Installed on 2019-02-15 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190215) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1816171/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1797744] Re: Mouse scrolling no longer moves between tabs in gnome-terminal 3.30
** Summary changed: - Mouse scrolling no longer moves between tabs in gnome-terminal 2.30 + Mouse scrolling no longer moves between tabs in gnome-terminal 3.30 ** Description changed: - In gnome-terminal 2.28 and earlier, scrolling with the mouse cursor over + In gnome-terminal 3.28 and earlier, scrolling with the mouse cursor over the tab bar switched between tabs. This seems to be broken in cosmic's - 2.30. + 3.30. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1797744 Title: Mouse scrolling no longer moves between tabs in gnome-terminal 3.30 Status in gnome-terminal package in Ubuntu: New Bug description: In gnome-terminal 3.28 and earlier, scrolling with the mouse cursor over the tab bar switched between tabs. This seems to be broken in cosmic's 3.30. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1797744/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1807773] [NEW] Crash in set_blink_settings()
Public bug reported: vte 0.54.0 to 0.54.2 suffers from a potential crash if the user closes a terminal tab/window in gnome-terminal (or any other vte-based app) and then modifies the cursor blinking settings. Mainstream release 0.54.3 fixes this issue. See https://gitlab.gnome.org/GNOME/vte/issues/77 and https://bugzilla.redhat.com/show_bug.cgi?id=1657512 for details. Could you please release a fix for Cosmic? (And while at it, consider addressing bug 1804457 too?) Thanks! ** Affects: vte2.91 (Ubuntu) Importance: Undecided Status: New ** Tags: cosmic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1807773 Title: Crash in set_blink_settings() Status in vte2.91 package in Ubuntu: New Bug description: vte 0.54.0 to 0.54.2 suffers from a potential crash if the user closes a terminal tab/window in gnome-terminal (or any other vte-based app) and then modifies the cursor blinking settings. Mainstream release 0.54.3 fixes this issue. See https://gitlab.gnome.org/GNOME/vte/issues/77 and https://bugzilla.redhat.com/show_bug.cgi?id=1657512 for details. Could you please release a fix for Cosmic? (And while at it, consider addressing bug 1804457 too?) Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1807773/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1790100] Re: unable to write ~ and ^ chars in the terminal
Please understand: It's not that we (vte and gnome-terminal developers) don't want to hear about it. We've heard about it and we are pretty certain that this is a bug somewhere elsewhere. Vte's and gnome- terminal's source code has absolutely no sign of treating ^ or any other similar simple character specially. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1790100 Title: unable to write ~ and ^ chars in the terminal Status in vte2.91 package in Ubuntu: Fix Released Bug description: Hello, I am using Ubuntu 18.10 and since the last update, I am unable to write ~ and ^ chars in the terminal, in both gnome-terminal and Geany (both using libvte2.91). I don't have this issue with other applications (terminator, xterm, Firefox, Gedit, etc.). But note that now, when I type ^ for the first time in Gedit for example, I see this char but underlined. If I type it a second type (or press space), it is transformed in ^ without line under it. This is a new behaviour that can cause this bug in libvte. Please tell me if I need to join other info! Thanks! ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: libvte-2.91-0 0.52.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.17.0-9.10-generic 4.17.17 Uname: Linux 4.17.0-9-generic x86_64 ApportVersion: 2.20.10-0ubuntu9 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Aug 31 11:17:43 2018 InstallationDate: Installed on 2015-08-10 (1116 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: vte2.91 UpgradeStatus: Upgraded to cosmic on 2016-04-29 (854 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1790100/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1798481] Re: org.gnome.desktop.interface.cursor-blink-timeout not honored
Thanks for the investigation! In the mean time I've tried xfce, icewm and windowmaker – /org/gnome/desktop/interface/cursor-blink* weren't used by VTE in any of them, some hardcoded defaults were used. I guess some dconf or gsettings daemon needs to be running to have the required binding in place (not sure). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to vte2.91 in Ubuntu. https://bugs.launchpad.net/bugs/1798481 Title: org.gnome.desktop.interface.cursor-blink-timeout not honored Status in vte2.91 package in Ubuntu: New Status in xfconf package in Ubuntu: New Bug description: Xubuntu desktop 18.04.1 $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 gnome-terminal: 3.28.2-1ubuntu1~18.04.1 libgtk-3-0: 3.22.30-1ubuntu1 dconf-editor: 3.28.0-1 Per workaround instructions in comment #8 on bug 838381 (of which this is not a duplicate), I set /org/gnome/desktop/interface/cursor-blink-timeout to a large value, less than the stated maximum of 2^31 - 1. I saved the change, exited dconf-editor and restarted the computer. What I expected to happen: Cursor in GTK-based terminal emulators will no longer stop blinking after 10 seconds. What happens instead: Cursor in GTK-based terminal emulators continues to stop blinking after 10 seconds. Of note, the cursor-blink-time *is* honored. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vte2.91/+bug/1798481/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
