Description of problem: When right clicking inside the gnome-terminal the pop up context menu sometimes shows additional (debugging?) text at the top of the menu Version-Release number of selected component (if applicable): gnome-terminal-3.30.1-1.fc29.x86_64 How reproducible: Always when you right click on a number Steps to Reproduce: Right click on a number inside the terminal (eg 30) and the context menu will contain: 30 = 0x1e divider Copy etc Instead of just: Copy etc Where divider is just a thin grey line. I would include a screen shot but that's also broken, bug report to follow! Actual results: Debugging info Expected results: Normal menu Additional info:
This is not debugging information, but an intended behavior. When you click on a number, its value is shown grouping the digits by 3, converting to/from hex, and showing the magnitude using IEC prefixes (kibi, mebi etc.). This makes it significantly easier to quickly see the magnitude of large numbers, but the dec/hex conversion might be useful for small numbers too. This was designed and implemented in https://bugzilla.gnome.org/show_bug.cgi?id=741728.
Does it have to be the default, can it be disabled? When right clicking to get the context menu, if you accidentally click on a large number you get a massively wide menu, due to the long number. Cool new features, and doing things because iProduct does them is not always a good reason. It meets someones goal but not a general one. For instance it doesn't do octal or binary or any number of other things. So why bother. If you must have features like this the correct place is in a calculator app. Which I observe there isn't a really good one. The original gnome request of showing file sizes is already sorted by reading the manual page: ls -lh
> can it be disabled? No, the vast majority of applications out there, including gnome-terminal, don't offer a way to alter their menus. > When right clicking to > get the context menu, if you accidentally click on a large number you get a > massively wide menu, due to the long number. Somewhat wider: yes. Massively wide: I wouldn't say so. Does this really bother you? Why? > Cool new features, and doing things because iProduct does them is not always > a good reason. It meets someones goal but not a general one. We did not implement this feature because "iProduct" also did. Some similar ideas (further additional "magic" information) were rejected because we didn't find them general enough. Grouping the digits by three we considered generic enough to be worth it. > For instance it > doesn't do octal or binary or any number of other things. So why bother. The main goal is to help users read large numbers. Hex conversion is just secondary. As opposed to hex, octal is hardly ever used for denoting 2-byte values, and I don't think I've seen it used for even larger ones. Binary is not even worth mentioning in the context of large numbers. We could perhaps improve the current behavior by showing octal and/or binary too for values up to 255. They are problematic because if we convert to those bases, users might expect the conversion to work from those values too. Whereas the prefix "0x" is standard for hex, there are no standard ways of denoting octal or binary. Leading 0 would be pretty confusing: depending on the context, it might mean the number is octal, or it might mean it's a zero-padded decimal. The terminal emulator isn't aware of the context (like: is it a C source file, or a parameter to "seq" in a shell script?) to reliably tell the numeric base. By completely omitting octal from the game I think users can be more confident that numbers with leading zeros are still treated as decimal. "0b" for binary is very rarely seen. Or we could take multiple guesses, and interpret let's say the number 01111111 in three possible ways: decimal, octal and binary, and convert in all possible ways, resulting in an IMHO totally confusing 3 lines in the menu. > If you must have features like this the correct place is in a calculator > app. Which I observe there isn't a really good one. This isn't a "must have" but IMO a "really nice to have" feature. Even if there was such a good calculator app, even if it was open and visible all the time I happen to need it, right-clicking and immediately seeing the grouping by 3 digits would still be significantly more convenient than having to copy-paste the data there. > The original gnome > request of showing file sizes is already sorted by reading the manual page: > > ls -lh I made the mistake of choosing an example command that everyone's familiar with, rather the a much less well-known one I was actually using those days that produced the exact giant numbers spelled out. I'm sure you can also come up with hundreds of use cases where a huge number isn't printed by an "ls" command. Does it actually harm you to have this feature? If so, could you please elaborate? If you have ideas how to improve, please let me know! Thanks!
I'm not trying to be negative here. Does it harm, no. But there is a question of the Linux/Unix way of doing things. Everything does its one function and does it well. When you start adding lots of extra cool features things become cluttered and confusing (Windows 10 anyone). I was confused by what was happening, it was unexpected behaviour, others will be as well. It seems to me there are plenty of other gnome/terminal issues which are higher priority. Throughout Fedora 28, the terminals would randomly flicker while partially hidden under other windows for instance. There were also issues with copying lines of text out of the terminal, when sometimes a command line which was longer than one line would copy in its entirety, and other times it would copy with a CR in it. And don't even mention the hoops that have to jumped over to get desktop icons, a feature every man and his dog want, but can't get by default. Even though I now know how to enable the icons, it still took me half an hour of hair pulling to enable it on a new user account, before I remembered the last step (autostarting nemo-desktop). I'm a software engineer, and have worked throughout my life with other software engineers who spend there entire time chasing cool new UI features. If only we used the lastest widget, then it would be better. The problem is users don't know what the latest widget is, or care. The other gnome issue I've noticed in the latest release is scrollbars. They are now Windows 10 style minimizing scrollbars, which are incredibly annoying. Especially for people of limited dexterity/vision, or using a touch pad (which amounts to the same thing). If gnome apes Windows 10 or Apple, when people leave Windows 10 or Apple because the features annoy them, gnome isn't going to be any better. The Windows 10 UI is a trainwreck, so best not to copy it.
> But there is a > question of the Linux/Unix way of doing things. Everything does its one > function and does it well. It's never a black and white story. For example there's a relatively new terminal emulator that doesn't have a scrollback buffer, claiming it should be provided by tmux. Should we push this far? :) On a more serious note, how about features not strongly related to terminal emulation, such as e.g. being able to search in the buffer, or automatically recognizing URLs? Especially the latter one is an extremely important convenience feature present in most of the terminal emulators (and is being further improved in gnome-terminal right now by a passionate contributor by allowing user-defined regexes), would be an outrage if we removed in the name of "do one thing", wouldn't it? And it's technically and conceptually quite similar to the feature we're discussing now. > I was confused by > what was happening, it was unexpected behaviour, others will be as well. This feature has been out there for 2-3 years now, you're the first one I hear getting confused. > the terminals would randomly flicker > while partially hidden under other windows Probably a window manager, compositor or video driver issue. Possibly caused/triggered by downstream Fedora transparency patch. Irrelevant here. > There were also > issues with copying lines of text out of the terminal, when sometimes a > command line which was longer than one line would copy in its entirety, and > other times it would copy with a CR in it. The emulator preserves the newline or lack thereof exactly as it was printed by the application. If copy-pasted incorrectly, it's most likely a bug in the utility printing the given text. Again, irrelevant to this issue. > And don't even mention the hoops that have to jumped over to get desktop > icons Totally irrelevant here. > I'm a software engineer In that case I sincerely hope that now that you understand what's happening when you right-click on a number, you'll find it useful occasionally. :) > and have worked throughout my life with other > software engineers who spend there entire time chasing cool new UI features. If you take a look at the changelog of VTE, you'll find much-much more than just "chasing cool new UI features". (gnome-terminal itself is just the UI around the terminal emulation widget VTE, so gnome-terminal's changelog is of course by its very nature full of UI stuff.) > The other gnome issue > I've noticed in the latest release is scrollbars. Again, irrelevant here. Please file a new report for each individual issue you find. > If gnome apes Windows 10 or Apple This bugreport, or even this bugzilla is probably not the right forum for these kinds of generic discussions, and I personally don't have time or motivation to engage in such discussions, sorry. I'm afraid might have pushed a little bit too far the philosophical side of the story just by seeing one (!) tiny UI feature that confused you a bit. :)
(In reply to Andrew Roberts from comment #4) > I'm a software engineer You are aware that gnome-terminal comes with full source code, and the right to change it to your liking?
Really? Its starting to feel somewhat abusive now. Perhaps I have contributed to other open source projects. Perhaps I've been supporting open source software for 30 years or so. Please close the bug report.
Closing as per comment 7