gnome-terminal issueshttps://gitlab.gnome.org/GNOME/gnome-terminal/-/issues2024-03-21T11:27:22Zhttps://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8067[gtk4] Problem delivering scroll events to apps2024-03-21T11:27:22ZEgmont Koblinger[gtk4] Problem delivering scroll events to appsAs I two-finger scroll my touchpad up and down a couple of times, the terminal often stops delivering these to the app for many seconds. I have to wait sometimes a few seconds, sometimes maybe 10-20 seconds for touchpad scrolling to begi...As I two-finger scroll my touchpad up and down a couple of times, the terminal often stops delivering these to the app for many seconds. I have to wait sometimes a few seconds, sometimes maybe 10-20 seconds for touchpad scrolling to begin to work again. (The scroll events that weren't delivered are swallowed for good, not delayed.)
Affected: at least `less` (`man`) with the "alternate scroll mode" synthesizing of up/down keypresses, and `mc` with its real mouse handling. While in this buggy state, regular touchpad/mouse clicks (for selecting text in `less`, or delivering a click event to `mc`) work as expected.
I cannot trigger the stuck state using mouse wheel, but if I trigger it with the touchpad then mouse wheel events are also ignored while this buggy state lasts.
Scrolling the scrollback buffer on the normal screen always works.
Works fine in the `vte-2.91-gtk4` test app, only gtk4-based `gnome-terminal` is affected. (See update in comments: `./src/app/vte-2.91-gtk4 --scrolled-window` is also affected.)
Can only reproduce with Show scrollbar: `Regular` or `None`. Cannot reproduce with `Overlay`. Kinetic scrolling seems to be irrelevant.
Ubuntu 23.10, X11, Unity 7.7, gtk 4.12.3, vte 0.76.0 (with loosened gtk4 version requirement), gnome-terminal 0a22fe68b12d21d680546d9cf8fdb4fae7d8c9fc.
Can also reproduce on GNOME Shell w/ Wayland. It's a bit harder to trigger the problem there and lasts shorter (maybe 2-5 seconds tops).
Can also reproduce with self-compiled gtk 4.14.0.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8063[gtk4] Drop target highlight remains visible on Xorg2024-03-09T20:42:13ZEgmont Koblinger[gtk4] Drop target highlight remains visible on XorgFound at https://gitlab.gnome.org/GNOME/console/-/issues/363.
> When I drag and drop a file from Files to Console, the blue highlight that shows the drop target remains visible after I dropped the file into the console. It happens only ...Found at https://gitlab.gnome.org/GNOME/console/-/issues/363.
> When I drag and drop a file from Files to Console, the blue highlight that shows the drop target remains visible after I dropped the file into the console. It happens only on Xorg. On Wayland it works as expected, and the blue highlight disappears.
gtk4-based g-t is also affected (although it's a blue 1px outline for me, rather than an entire blue background).
MR for kgx over there, I think we need to do something like that, too.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8060POTFILES.in needs updating2024-02-27T11:55:17ZAnders JonssonPOTFILES.in needs updating The translation page at https://l10n.gnome.org/module/gnome-terminal/ pointed out some files that need to be added or removed from po/POTFILES.in:
There are some missing files from POTFILES.in:
src/terminal-accel-dialog.cc
sr... The translation page at https://l10n.gnome.org/module/gnome-terminal/ pointed out some files that need to be added or removed from po/POTFILES.in:
There are some missing files from POTFILES.in:
src/terminal-accel-dialog.cc
src/terminal-accel-dialog.ui
src/terminal-accel-row.cc
src/terminal-find-bar.ui
src/terminal-preferences-window.cc
src/terminal-preferences-window.ui
src/terminal-profile-editor.cc
src/terminal-profile-editor.ui
src/terminal-profile-row.cc
src/terminal-profile-row.ui
src/terminal-shortcut-editor.ui
src/terminal-window.ui
Following files are referenced in either POTFILES.in or POTFILES.skip, yet they don’t exist:
src/preferences.ui
src/profile-editor.cc
src/screen.ui
src/terminal-mdi-container.cc
src/terminal-menu-button.cc
src/terminal-menubar.ui.in
src/terminal-prefs.cc
src/terminal-tab-label.ccready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8059[gtk4] Port the large scrollback warning to gtk42024-02-24T18:35:59ZEgmont Koblinger[gtk4] Port the large scrollback warning to gtk4Port b964174bf25e067855bcb6ba384a21d612da7b32 - https://gitlab.gnome.org/GNOME/vte/-/issues/2504#note_2020552 to gtk4 (unless we come up with something even better :)).Port b964174bf25e067855bcb6ba384a21d612da7b32 - https://gitlab.gnome.org/GNOME/vte/-/issues/2504#note_2020552 to gtk4 (unless we come up with something even better :)).ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8055[gtk4] gnome-terminal opens new tab after 'paste' (using mouse)2024-02-16T15:11:31ZDominique Leuenberger[gtk4] gnome-terminal opens new tab after 'paste' (using mouse)After pasting any text inside a gnome-terminal (3.97.0) window using the mouse (right click,paste), followed by enter, opens a new tab instead of sending the enter to the current window (paste, follow by space also does it)
This is quit...After pasting any text inside a gnome-terminal (3.97.0) window using the mouse (right click,paste), followed by enter, opens a new tab instead of sending the enter to the current window (paste, follow by space also does it)
This is quite disruptive when working in terminalready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8044need to review all strings in the prefs dialogue and main UI2023-12-15T19:46:02ZChristian Perschneed to review all strings in the prefs dialogue and main UIReview all the visible strings in the preferences dialogue and the main UI, making sure they have the right capitalisation, mnemonics (if necessary), colon (or not), are consistent, are marked as translatable, and have translator comment...Review all the visible strings in the preferences dialogue and the main UI, making sure they have the right capitalisation, mnemonics (if necessary), colon (or not), are consistent, are marked as translatable, and have translator comment and/or translation context (if necessary).ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8032[gtk4] Update help pages2023-11-26T10:00:57ZEgmont Koblinger[gtk4] Update help pages#7804 continued, sort of
With the UI changes of the gtk4 version, especially in the Prefs dialog, the help pages need to be updated.
It's mostly the sentences like
> In the sidebar, select your current profile in the Profiles section....#7804 continued, sort of
With the UI changes of the gtk4 version, especially in the Prefs dialog, the help pages need to be updated.
It's mostly the sentences like
> In the sidebar, select your current profile in the Profiles section.
that need to be updated, plus the whole "Manage profiles" page.
Also any new or removed feature (let's say Pinned tabs).ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8029[gtk4] Crash when restarting a pinned tab's process2023-11-25T19:24:28ZEgmont Koblinger[gtk4] Crash when restarting a pinned tab's processHave a pinned tab. Exit its shell. Click "Relaunch". Repeat.
About 1 out of 10 times, g-t crashes.Have a pinned tab. Exit its shell. Click "Relaunch". Repeat.
About 1 out of 10 times, g-t crashes.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8028[gtk4] UI chrome elements can take focus away from terminal2023-11-25T22:52:43ZEgmont Koblinger[gtk4] UI chrome elements can take focus away from terminalClick on the active tab's label.
Or open the "New Tab" button's dropdown by clicking on the arrow, and close by clicking again or pressing Esc.
Or do the same with the Hamburger menu.
The said UI element grabs the focus away from the ...Click on the active tab's label.
Or open the "New Tab" button's dropdown by clicking on the arrow, and close by clicking again or pressing Esc.
Or do the same with the Hamburger menu.
The said UI element grabs the focus away from the terminal. You cannot type into the terminal until you click to focus it.
This behavior proved to be truly annoying, and was fixed in the gtk3 version in #7546.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8023use vte context menu setup2023-11-26T13:56:43ZChristian Perschuse vte context menu setupBranch: wip/context-menu
It's working, except that it causes an undebuggable crash in gtk (on X11) after the context menu has been shown a number of times (not reproducible in vte-2.91-gtk4):
```
Gdk:ERROR:../gdk/gdkkeys.c:463:gdk_...Branch: wip/context-menu
It's working, except that it causes an undebuggable crash in gtk (on X11) after the context menu has been shown a number of times (not reproducible in vte-2.91-gtk4):
```
Gdk:ERROR:../gdk/gdkkeys.c:463:gdk_keymap_get_cached_entries_for_keyval: assertion failed: (len <= 255)
Bail out! Gdk:ERROR:../gdk/gdkkeys.c:463:gdk_keymap_get_cached_entries_for_keyval: assertion failed: (len <= 255)
```ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8022[gtk4] Double focus in/out reports2023-11-25T09:51:55ZEgmont Koblinger[gtk4] Double focus in/out reports`printf '\e[?1004h'; cat`
As you focus from/to another window, you get doubled focus in/out reports, like `^[[O^[[O^[[I^[[I`.
It's paritally a VTE thing, I guess it should track internally if it has the focus (it surely already does so...`printf '\e[?1004h'; cat`
As you focus from/to another window, you get doubled focus in/out reports, like `^[[O^[[O^[[I^[[I`.
It's paritally a VTE thing, I guess it should track internally if it has the focus (it surely already does so, for cursor blinking, and for initial focus report), and then ignore requests that confirm the existing state.
But I'm filing it against g-t first, to see if there's something that the gtk4 branch does wrong.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8021Missing cursor in new tab when cursor blinking disabled2023-12-22T23:10:46Zdarkblaze69Missing cursor in new tab when cursor blinking disabled* OS: Arch Linux
* g-t on `main` (gtk4)
Missing cursor in new tab when Accessibility > Cursor blinking disabled
**Steps to reproduce:**
* Accessibility > Typing > Cursor blinking > off
* open gnome-terminal, verify there's cursor block...* OS: Arch Linux
* g-t on `main` (gtk4)
Missing cursor in new tab when Accessibility > Cursor blinking disabled
**Steps to reproduce:**
* Accessibility > Typing > Cursor blinking > off
* open gnome-terminal, verify there's cursor block visible
* new tab, cursor block is missing completely
![Screencast_from_2023-11-24_00-29-18](/uploads/4448d1fd3d1ad2f7194ecefa8e3d86c0/Screencast_from_2023-11-24_00-29-18.webm)ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8015g-t-p startup notification broken2024-02-21T09:40:06ZEgmont Koblingerg-t-p startup notification brokenUnity left land launchbar (but I guess it should be the same for GNOME).
Right-click on g-t's icon, choose Preferences.
The Prefs window apperas as expected, but for about 15 seconds the mouse pointer is a spinning wheel instead of the...Unity left land launchbar (but I guess it should be the same for GNOME).
Right-click on g-t's icon, choose Preferences.
The Prefs window apperas as expected, but for about 15 seconds the mouse pointer is a spinning wheel instead of the default pointer.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8012Disable cursor blink when holding terminal open after subprocess exit2023-11-25T10:16:36ZChristian HergertDisable cursor blink when holding terminal open after subprocess exitThe cursor blink somewhat indicates a liveness check of the subprocess, so when we hold open the `TerminalTab` to allow the user to respawn, it might be nice to stop that blinking. It's also a bit odd when it ends up halfway underneath t...The cursor blink somewhat indicates a liveness check of the subprocess, so when we hold open the `TerminalTab` to allow the user to respawn, it might be nice to stop that blinking. It's also a bit odd when it ends up halfway underneath the infobar, but we can probably deal with that elsewhere.
[0001-screen-disable-cursor-blink-while-holding-terminal-o.patch](/uploads/8d4b50c4273a010261ac0cd8372ef6c1/0001-screen-disable-cursor-blink-while-holding-terminal-o.patch)ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8007Modernize preferences design2023-12-15T19:59:08ZChristian HergertModernize preferences designWe need to get some mockups for how we might modernize the preferences dialog as Terminal moves to GTK 4. So lets get the design team to take a peek and see what their suggestions are.
/CC @aday @jimmac @bertob
I would just make one r...We need to get some mockups for how we might modernize the preferences dialog as Terminal moves to GTK 4. So lets get the design team to take a peek and see what their suggestions are.
/CC @aday @jimmac @bertob
I would just make one request, and that is to *assume* that all the preferences on the dialog are necessary, because I think they are. Contrast this with something like Console where you can probably get away with less options.
I did a super simple minimal port over a few hours, so everything is super trashy. But here is where I'm starting from. It is neither beautiful or coherent.
![Screenshot_from_2023-10-11_16-12-35](/uploads/b62aa822af9a2b864c4cfc9b66572e20/Screenshot_from_2023-10-11_16-12-35.png)
![Screenshot_from_2023-10-11_16-12-40](/uploads/cfd9be6b40699a7ad0dff1f42b300984/Screenshot_from_2023-10-11_16-12-40.png)
![Screenshot_from_2023-10-11_16-12-43](/uploads/b2256d05acd30b26232d853269170336/Screenshot_from_2023-10-11_16-12-43.png)ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/8006Port gnome-terminal to GTK 42023-12-12T22:30:10ZChristian HergertPort gnome-terminal to GTK 4Now that we have a bunch of performance updates landing in VTE, lets take a look at what it would take to get `gnome-terminal` to GTK 4 as well.
I've started a branch `wip/chergert/gtk4` which gets some of the rudimentary bits in place....Now that we have a bunch of performance updates landing in VTE, lets take a look at what it would take to get `gnome-terminal` to GTK 4 as well.
I've started a branch `wip/chergert/gtk4` which gets some of the rudimentary bits in place. There are all sorts of crashes and missing things in `TerminalScreen` and `TerminalWindow` still to handle. Particularly around DnD and clipboard.
I just wanted to have an issue here for tracking/discussion as necessary.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7974Insensitive area under the yellow Info Bar2023-11-25T10:09:30ZEgmont KoblingerInsensitive area under the yellow Info Bar(Super low priority)
Choose "When command exits: Hold the terminal open" and make the command exit. A yellow info bar appears about the exit status.
Below that yellow bar, with a height roughly twice the yellow bar's, the terminal area...(Super low priority)
Choose "When command exits: Hold the terminal open" and make the command exit. A yellow info bar appears about the exit status.
Below that yellow bar, with a height roughly twice the yellow bar's, the terminal area is insensitive. You cannot use the mouse wheel to scroll the contents, cannot start highlighting the text. The mouse cursor is a pointer instead of I-beam.
I guess that area also belongs to the Info Bar, but is left transparent.
Ideally the Info Bar shouldn't consume more real estate than its actual painted yellow stripe.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7953Misunderstanding of zoom options, value should be updated2023-11-25T10:17:59ZPaul MenzelMisunderstanding of zoom options, value should be updatedDebian sid/unstable with *gnome-terminal* 3.46.7-1
I first wanted to report a bug, that changing the Zoom value, the indicator/value (100 %) did not change/adapt accordingly, when zooming. Only now I noticed, that *100 %* is the reset b...Debian sid/unstable with *gnome-terminal* 3.46.7-1
I first wanted to report a bug, that changing the Zoom value, the indicator/value (100 %) did not change/adapt accordingly, when zooming. Only now I noticed, that *100 %* is the reset button.
At least in Firefox the value is updated in the hamburger menu, and clicking on it resets it back to 100 %.ready-gtk4https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7817Find -> Clear Highlight doesn't work2021-06-10T21:21:37ZBugzillaFind -> Clear Highlight doesn't work## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#792885)](https://bugzilla.gnome.org/show_bug.cgi?id=792885)**
## Description
.
Version: git master## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#792885)](https://bugzilla.gnome.org/show_bug.cgi?id=792885)**
## Description
.
Version: git mastergnome-3-28https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7787Destroy the search popup rather than hide2023-11-25T10:31:34ZBugzillaDestroy the search popup rather than hide## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#791712)](https://bugzilla.gnome.org/show_bug.cgi?id=791712)**
## Description
Continuing from [bug 771165](https://bugzilla.gnome.org/show_bug.cgi?id=771165):
C...## Submitted by Egmont Koblinger `@egmontkob`
**[Link to original bug (#791712)](https://bugzilla.gnome.org/show_bug.cgi?id=791712)**
## Description
Continuing from [bug 771165](https://bugzilla.gnome.org/show_bug.cgi?id=771165):
Closing the Find dialog should call gtk_widget_destroy() rather than gtk_widget_hide().
This would avoid a badly looking transitioning in Unity7, perhaps other WMs too.
Would need to manually save and restore the contents of the input field/checkboxes though.
Version: git masterready-gtk4