Console issueshttps://gitlab.gnome.org/GNOME/console/-/issues2024-02-20T21:35:41Zhttps://gitlab.gnome.org/GNOME/console/-/issues/357Focus lost after opening a link and trying to get back2024-02-20T21:35:41ZEduard TolosaFocus lost after opening a link and trying to get backHi,
If I click a URL in the terminal, and then Alt + Tab back to it and try to write something or send a key combo, the text doesn't appear immediately on the terminal (as if it were unfocused), but once I click on it, the text or key c...Hi,
If I click a URL in the terminal, and then Alt + Tab back to it and try to write something or send a key combo, the text doesn't appear immediately on the terminal (as if it were unfocused), but once I click on it, the text or key combos is shown.
Here's a video explaining the issue (please watch until the end):
![Kooha-2024-02-18-21-09-16](/uploads/307ed7fe7771d85c13d241161be3fe77/Kooha-2024-02-18-21-09-16.webm)https://gitlab.gnome.org/GNOME/console/-/issues/339Only show "Close Window?" dialogue when command would actually be killed by c...2023-12-13T05:10:08ZVictor EngmarkOnly show "Close Window?" dialogue when command would actually be killed by closing the windowTo reproduce:
1. Run any program (Git GUI, IDEA, you name it) in the background while in Console.
2. Try to close Console.
Actual behaviour: A "Close Window?" dialogue pops up:
![Screenshot_from_2023-11-17_14-32-06](/uploads/3dc6950ef...To reproduce:
1. Run any program (Git GUI, IDEA, you name it) in the background while in Console.
2. Try to close Console.
Actual behaviour: A "Close Window?" dialogue pops up:
![Screenshot_from_2023-11-17_14-32-06](/uploads/3dc6950efa971bf09d2cd086eb63155e/Screenshot_from_2023-11-17_14-32-06.png)
Expected behaviour: Console should close without any warning.
Reasoning for the expected behaviour: The "closing this tab will kill them" warning is *incorrect* - the process continues running after dismissing the warning and closing Console.
[Workaround for v44.0](https://gitlab.com/engmark/root/-/merge_requests/425/diffs?commit_id=a27f8cb2bed27747691dc7c7a111e61ba9fb539f): [disable-gnome-console-close-window-prompt.patch](/uploads/925f6cacd54a00b5574f525be87e8483/disable-gnome-console-close-window-prompt.patch)https://gitlab.gnome.org/GNOME/console/-/issues/337Close tab "some commands are still running" is incorrect, and goes off screen2023-11-07T16:43:08ZAlexander KoskovichClose tab "some commands are still running" is incorrect, and goes off screenIn GNOME console when you run git commands, then stop them, and attempt to close the tab, it says those commands are still running? But you're obviously not running them so it's confusing.
Also if you've been in that tab awhile, because...In GNOME console when you run git commands, then stop them, and attempt to close the tab, it says those commands are still running? But you're obviously not running them so it's confusing.
Also if you've been in that tab awhile, because of the sheer amount of commands "still running", it actually goes off screen.
![image](/uploads/c0ca0d44c38fdb798071f9482d0f8d3a/image.png)https://gitlab.gnome.org/GNOME/console/-/issues/336Console only showing the gnome-terminal colors in dark or light mode in Ubunt...2023-11-19T21:12:30ZKrushna JoshiConsole only showing the gnome-terminal colors in dark or light mode in Ubuntu 23.10I just upgraded Ubuntu to 23.10 from 23.04 and installed the Console application. I don't know if this is supposed to be the new colors or a change to the colors but the dark and light mode colors are not what they were supposed to be. T...I just upgraded Ubuntu to 23.10 from 23.04 and installed the Console application. I don't know if this is supposed to be the new colors or a change to the colors but the dark and light mode colors are not what they were supposed to be. They are always showing the original gnome-terminal colors. I may be missing something in the changelog if this is a feature but I would love a response here. And maybe due to that the light or dark mode switch does not work and it only changes the header colors.
![image](/uploads/c77c8053a5107c9b8bdd6ca35b971a01/image.png)
![image](/uploads/d0e9d00b30aec91a7c0df9df28809896/image.png)
![image](/uploads/34ca905257b4e5d613857e80c6b9938c/image.png)
Note: I have not made the console app the default terminal app.
I would love to provide any more information if needed.https://gitlab.gnome.org/GNOME/console/-/issues/335[enhancement] notification should bring to terminal2023-10-27T12:36:15Zmattia.b89[enhancement] notification should bring to terminalI think gnome-console is missing a right behaviour:
when I click on a notification, I'd like to be taken on _active_ Gnome-console window _(the one that produced the notification itself)_,
especially if I am in another workspace;
...I think gnome-console is missing a right behaviour:
when I click on a notification, I'd like to be taken on _active_ Gnome-console window _(the one that produced the notification itself)_,
especially if I am in another workspace;
I think this is the **only** reason why, one should click on it...
On the other side, if I just want to dismiss it, there is the **X** button in top-right corner of the notification itself.https://gitlab.gnome.org/GNOME/console/-/issues/330Using fish shell causes Console to throw popup warnings on close2024-01-22T01:26:14ZDalton NellUsing fish shell causes Console to throw popup warnings on close# Bug
Using fish as a shell and closing Console, either by typing `exit` or by clicking the x will erroneously warn me that a command is running.
![Closing by hitting x](/uploads/8eb6b93ab67b6310ac5008a43523170a/image.png)
![Closing b...# Bug
Using fish as a shell and closing Console, either by typing `exit` or by clicking the x will erroneously warn me that a command is running.
![Closing by hitting x](/uploads/8eb6b93ab67b6310ac5008a43523170a/image.png)
![Closing by running exit](/uploads/e2e453c4abfcaf612faedfe2050fcca5/image.png)
# Steps to reproduce
* Run fish either by executing it, or by adding `exec fish` to the bottom of your `~/.bashrc`
* Run a single command that ends easily, for example `echo hello`.
* Attempt to close Console by hitting the x or typing "exit".
# Expected outcome
Console should close quietly.
# Actual outcome.
Console warns me with a message saying that something is running and might lose progress.https://gitlab.gnome.org/GNOME/console/-/issues/328Preferences: terminal bell preferences lack explanatory text2023-10-19T01:28:54ZAutomeris naranjaPreferences: terminal bell preferences lack explanatory text## Affected version
gnome-console-45.0-1.fc39.x86_64
## Description
The terminal bell preferences have no explanatory text, they might look vague if an user isn't familiar with terminals.
![image](/uploads/7a62d2b90a53e772dba3914e1a2...## Affected version
gnome-console-45.0-1.fc39.x86_64
## Description
The terminal bell preferences have no explanatory text, they might look vague if an user isn't familiar with terminals.
![image](/uploads/7a62d2b90a53e772dba3914e1a2c5dbd/image.png)
BlackBox, for example, shows a explanatory text for the bell preference:
![image](/uploads/917be61af8d1025d873523e48025f0b2/image.png)
Maybe the "Terminal Bell" section could have a description for both preferences, some like "Control how Console indicates events" or something like that. Not sure what the design team thinks of this, though.https://gitlab.gnome.org/GNOME/console/-/issues/326Console doesn't respect system-wide "prefer-light" preference by default2023-11-19T21:18:15ZCalvin WaltonConsole doesn't respect system-wide "prefer-light" preference by defaultFor context, the GNOME "color-scheme" setting (`org.gnome.desktop.interface color-scheme`) has three possible values - "default", "prefer-light", and "prefer-dark". Present versions of GNOME Settings currently only expose the ability to ...For context, the GNOME "color-scheme" setting (`org.gnome.desktop.interface color-scheme`) has three possible values - "default", "prefer-light", and "prefer-dark". Present versions of GNOME Settings currently only expose the ability to set "default" (Labelled as "Default", [or possibly "No Preference" in the future](https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1884)) and "prefer-dark", but [it's possible that an option for "prefer-light" will also be added in the future](https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1948), likely when the GNOME Shell light theme work is more complete.
Right now, Console by default is dark when the system-wide color-scheme setting is "default". This is perfectly fine, and is done by many GNOME applications.
However, Console by default does not respect the "prefer-light" setting, which is the user expressing that they would like apps that are dark by default to become light - just like "prefer-dark" is the user expressing that they would like apps that are light by default to become dark.
There's a few other GNOME apps which don't follow the "prefer-light" setting, but that's mostly because of technical limitations - e.g. Totem's developers haven't figured out a way to make the controls work properly in light mode. This doesn't apply to Console, since Console has a fully supported light mode which can be selected manually in-app.
Please respect the system-wide user preference, and have Console switch to light when the user requests light mode - unless the user has *explicitly* and *manually* requested that their system-wide preference should be ignored, which they can do by configuring an application-specific preference.
This will probably require some collaboration from GNOME Design folks on figuring out a solution for the color switcher design. The current color switcher design does not support having an app which is dark when the user has expressed no system-wide preference (i.e. is using "default") but switches to light when the user sets the system-wide preference to "prefer-light".https://gitlab.gnome.org/GNOME/console/-/issues/323Wrong dimensions reported initially2023-12-16T05:56:35ZNorth -Wrong dimensions reported initiallyWhen the first window is opened for about half a second the $COLUMN and $LINES env variables are incorrect. Subsequent windows and tabs are correct.
To reproduce, add this to that start of your bashrc, zsrch, etc:
```
echo "$COLUMNS x ...When the first window is opened for about half a second the $COLUMN and $LINES env variables are incorrect. Subsequent windows and tabs are correct.
To reproduce, add this to that start of your bashrc, zsrch, etc:
```
echo "$COLUMNS x $LINES"
sleep 1
echo "$COLUMNS x $LINES"
```
You will find they don't match.https://gitlab.gnome.org/GNOME/console/-/issues/319"Command completed" notifications for short and foreground commands2023-10-21T21:41:12ZVictor Engmark"Command completed" notifications for short and foreground commandsThere are so many "Command completed" notifications with my usual workflow that they are swamping useful notifications from other applications. This decreases the utility of GNOME notifications significantly. Since people will have very ...There are so many "Command completed" notifications with my usual workflow that they are swamping useful notifications from other applications. This decreases the utility of GNOME notifications significantly. Since people will have very different opinions about this it should be configurable, but these are the main symptoms I find problematic:
- There should absolutely be a simple way to turn off notifications completely.
- ~The~ There should be a configurable timeout. For some people 1 second is a long command, for others a minute would be a short command.
- ~If the Console window with the running command is in focus for the entire duration of the command, it probably means the command is my sole focus at the time, so the notification is redundant. An option like "Only notify of completed commands in background/unfocused Console instances" might work.~ Update: It appears this issue is not Console's fault, but a still-active other notification mechanism which I'd just uninstalled.
- ~I don't understand the difference between the first and second icons in this screenshot: ![unclear notification icons](/uploads/9706ac822e7dd3623ac692c0d3c43b54/Screenshot_from_2023-08-30_11-54-56.png)~ Update: Also not Console's fault. Still, it might be better to include more detail in the notification text to clarify.https://gitlab.gnome.org/GNOME/console/-/issues/311[Feature Request] Give Flatpak Commands Red/Maroon Terminal Color like DNF2023-09-22T20:23:25ZScotty Trees[Feature Request] Give Flatpak Commands Red/Maroon Terminal Color like DNFGreetings Console Devs,
When you use dnf commands within Console, once the command is executed and running, Console will turn a red/maroon color to signal Console is "busy" and I personally love this feature (sorry not sure of the techn...Greetings Console Devs,
When you use dnf commands within Console, once the command is executed and running, Console will turn a red/maroon color to signal Console is "busy" and I personally love this feature (sorry not sure of the technical name at the moment). I also use flatpaks and use Console to update/install/remove them, however whenever I run any flatpak commands, the terminal does not display the 'busy red/maroon color' that I'd like to see when a terminal task is still in process.
Below I'm running dnf commands which produces the desired outcome, showing the 'busy color':
![Screenshot_from_2023-07-18_11-05-55](/uploads/a81165d22e92096a32e801225721ae05/Screenshot_from_2023-07-18_11-05-55.png)
Is there a way to make this possible with flatpaks? Not sure if this is more of a feature request, bug, or just a technical limitation(?), but I was hoping this could be implemented in the future.
One of the main reasons I'd like flatpak commands to include the busy red color is for when flatpak downloads new components, it sometimes can take minutes (5-10 mins) to download, making that terminal window busy the entire time, hence why I'd really like it to be included.
Running flatpak produces no effect showing Console is 'busy':
![Screenshot_from_2023-08-10_23-31-11](/uploads/30fd8ef12f5d9865546aeb3f7133134c/Screenshot_from_2023-08-10_23-31-11.png)
Right now I use an alias "yay" to update Fedora like so: `sudo dnf upgrade --refresh && flatpak update`
In the first part of the command, Console will turn red until dnf is finish, then Console color turns back to the normal Adwaita color as it runs through the flatpak update command next. It'd be nice to see this whole process have Gnome Console be using the 'busy' red/maroon color.
Please let me know if this is possible and also please let me know if you need any additional information. Thank you.https://gitlab.gnome.org/GNOME/console/-/issues/307Close Window/ Tab from Script (Feature Request)2024-02-28T10:29:04ZSimon MattesClose Window/ Tab from Script (Feature Request)Greetings,
while the behavior of keeping the console window open even after a command has finished is extremely nice, there are use cases where an **auto-closing window/ tab would be preferable**.
Request: either **add a setting to aut...Greetings,
while the behavior of keeping the console window open even after a command has finished is extremely nice, there are use cases where an **auto-closing window/ tab would be preferable**.
Request: either **add a setting to automatically close** the window/ tab when a script/ program exits **with return code = 0**, or create a programmatic way to **close the window from a script** (`kill $PPID` doesn't work because the window PID is shared between all instances).
Thanks for your consideration -- keep up the amazing work!https://gitlab.gnome.org/GNOME/console/-/issues/305"Close Window?" prompt should be able to disable in gsettings2023-08-25T18:01:25ZAdam Asper"Close Window?" prompt should be able to disable in gsettingsI have an alias that runs a command and quits the terminal. About 30% of the time, Console prompts with "Close Window?"
There should be a gsettings flag to disable that.
Doing that will keep the GUI config tidy for new users and allow ...I have an alias that runs a command and quits the terminal. About 30% of the time, Console prompts with "Close Window?"
There should be a gsettings flag to disable that.
Doing that will keep the GUI config tidy for new users and allow a higher amount of configuration for advanced users.https://gitlab.gnome.org/GNOME/console/-/issues/301GNOME Console crashes when a tab is dragged in then dragged out to the desktop.2023-11-25T14:13:37ZJamie ChamberlainGNOME Console crashes when a tab is dragged in then dragged out to the desktop.![Screencast_from_2023-06-30_18-16-49](/uploads/8c24f294079bcc02ad5b84f01831271b/Screencast_from_2023-06-30_18-16-49.webm) [message.txt](/uploads/a04f199601718f5f64aebc7b9ddfeca0/message.txt)![Screencast_from_2023-06-30_18-16-49](/uploads/8c24f294079bcc02ad5b84f01831271b/Screencast_from_2023-06-30_18-16-49.webm) [message.txt](/uploads/a04f199601718f5f64aebc7b9ddfeca0/message.txt)https://gitlab.gnome.org/GNOME/console/-/issues/297if sudo is within a script, does not turn red2023-05-28T17:49:41ZSteven Jay Cohenif sudo is within a script, does not turn red1. Put a **SUDO** command into a shell script.
2. Run shell script.
3. See [sudo] echoed back as it requests password.
4. Script runs but does **NOT** turn the terminal **RED**.
SUGGESTED FIX: Use the fact that [sudo] is echoed back to ...1. Put a **SUDO** command into a shell script.
2. Run shell script.
3. See [sudo] echoed back as it requests password.
4. Script runs but does **NOT** turn the terminal **RED**.
SUGGESTED FIX: Use the fact that [sudo] is echoed back to trigger turning the terminal RED.https://gitlab.gnome.org/GNOME/console/-/issues/293Feature Request: Rename tabs2023-10-25T00:52:04ZDouglasFeature Request: Rename tabsgnome-terminal lets you double-click a tab and quickly assign it a new display name, making it easier to distinguish between multiple tabs. I often keep at least 3 tabs open all the time, one for docker logs (renamed as "logs"), other fo...gnome-terminal lets you double-click a tab and quickly assign it a new display name, making it easier to distinguish between multiple tabs. I often keep at least 3 tabs open all the time, one for docker logs (renamed as "logs"), other for git (renamed as "git") and another for database access (renamed as "db").
Here's the current situation: :disappointed:
![image](/uploads/19a011fbdbdda53f10a2730c6be14734/image.png)https://gitlab.gnome.org/GNOME/console/-/issues/289make red highlighting for sudo only affect the one tab2023-05-16T10:13:58ZZbigniew Jędrzejewski-Szmekmake red highlighting for sudo only affect the one tabWhen I run a superuser command, Console makes the tab reddish, which is nice. But it's just the one tab that is executing the command, so only that one tab should have the highlight, not the full window. (Also, when I switch to another t...When I run a superuser command, Console makes the tab reddish, which is nice. But it's just the one tab that is executing the command, so only that one tab should have the highlight, not the full window. (Also, when I switch to another tab, the highlight is completely removed, even though the superuser program is still running in the other tab.)https://gitlab.gnome.org/GNOME/console/-/issues/286Incorrect key press order when typing keys with QMK home row modifiers2023-05-01T13:24:58ZdagIncorrect key press order when typing keys with QMK home row modifiersTyping any 2 key combination where exactly one of the keys is a home row modifier (key acting as a modifier when held, but as normal key when pressed normally) by rolling the keys (still holding the first key when pressing the second) al...Typing any 2 key combination where exactly one of the keys is a home row modifier (key acting as a modifier when held, but as normal key when pressed normally) by rolling the keys (still holding the first key when pressing the second) always results the normal key getting output first. regardless of the order of the key presses. For example, `fg` becomes `gf` on a qwerty layout if `f` is a home row modifier. I think it has to do with the fact that the keyboard will immediately output both keys when the modifier key is released (since it at that point knows that the key was not used as a modifier, a home row modifier is usually configured so that it needs to be held for a minimum amount of time in order to register as a modifier to allow for rolling the keys when typing) and Console for some reason gets the order wrong when it receives two key codes very close to each other.
I am only seeing this issue in Console, no other terminal emulators or other applications. I'm using Console 44.0.https://gitlab.gnome.org/GNOME/console/-/issues/282unable to copy paste long text with "sudo content" ("confirm/cancel" buttons ...2024-03-03T16:45:17Zdarkblaze69unable to copy paste long text with "sudo content" ("confirm/cancel" buttons appear below the visible screen)System: Arch, GNOME 43/44, Wayland.
Trying to copy paste long code with "sudo" in content, kgx warns with a long window "You are pasting а command that runs as an administrator" and no "confirm/cancel" buttons visible.
It should trunca...System: Arch, GNOME 43/44, Wayland.
Trying to copy paste long code with "sudo" in content, kgx warns with a long window "You are pasting а command that runs as an administrator" and no "confirm/cancel" buttons visible.
It should truncate text and actually show the full "You are pasting ..." warning window with all buttons visible.
![Screenshot_from_2023-04-03_02-03-33](/uploads/1e42954fd68917460f9bee50a6cdcd27/Screenshot_from_2023-04-03_02-03-33.png)https://gitlab.gnome.org/GNOME/console/-/issues/278Quit on Ctrl+Shift+Q2023-03-21T19:04:03ZkramoQuit on Ctrl+Shift+QAllow for quitting the application with Ctrl+Shift+Q to be consistent with the rest of the shortcuts.Allow for quitting the application with Ctrl+Shift+Q to be consistent with the rest of the shortcuts.