256-color support was added a long time ago in bug 107487. Even there it was noted that the separator should have been ':' instead of ';' according to the standard, yet this never got fixed. Not sure if truecolor was added in that patch or at a later step, but it was at least mentioned there and then added at some point. VTE developer Christian has just discovered that not only the separator character, but also the parameters of truecolor was misread and implemented incorrectly by pretty much all terminal emulators (probably due to copying each other). According to ITU Recommendation T.416, the correct separator (for 256-color and truecolor subparameters) is the colon (and not semicolon), plus the parameters for truecolor go like: CSI 38:2:[color_space_id]:R:G:B[:unused:tolerance:color_space_for_tolerance]m That is, at truecolor, there's an extra parameter at the beginning before the three color components, plus optional parameters at the end. For example, to get red=255, green=128, blue=64 (an orange-ish color), the sequence could be CSI 38:2::255:128:64m Most apps that support truecolor emit sequences like CSI 38;2;R;G;Bm, because not too many terminal emulators support ':' as the delimiter (konsole doesn't either), and understandably app developers take the easy path which works everywhere. So I wouldn't touch the parameters of the semicolon-based sequence, it'd break existing truecolor support at many places, and there's no way to inject that missing parameter without breaking compatibility with existing implementations. I think we should say this format has become the de facto standard. It would be nice though to implement the de jure standard, too. That is, allow colons as separators, and with colons used for truecolor mode watch out that there's another parameter before the red channel, plus optional ones after blue. For backwards compatibility with the colon-based format with the color_space_id omitted, you _may_ want to still accept only 3 additional parameters after "38:2:" and treat them as R, G and B. But as soon as 4 or more parameters follow "38:2:", the first one should be the color_space_id, then the three color channels, then perhaps further additional ones. Given that konsole doesn't support colons yet, I don't see too much point in implementing another misinterpretation of the standard though. The end of the optional parameters is obviously denoted either by the trailing 'm', or the semicolon ';' which allows further independent SGR attributes to follow. See https://gist.github.com/XVilka/8346728#gistcomment-2008553 for my opinion about why colon (as stated by the documentation) is a good choice for subparameters and semicolon (in widespread use) is a bad one. For more details about the whole story, please see https://bugzilla.gnome.org/show_bug.cgi?id=791456 https://gist.github.com/XVilka/8346728#gistcomment-2285644
Egmont thanks for the information. If this is still an issue, would you be interested in submitting a patch to fix this to https://invent.kde.org/utilities/konsole/-/merge_requests/
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
> would you be interested in submitting a patch No, sorry, not. Let me tell you: I'm honestly disappointed in the attitude I'm seeing in bulk nowadays from Konsole's bugtracker. First, I don't understand why this question justified the NEEDINFO state. You do not _need_ information from me. You could just go ahead and fix this bug. There are situations that justify NEEDINFO, e.g. when you cannot reproduce the bug, or don't understand what the reporter says. Apparently this is not the case here. You are not blocked in any way. Second, this Janitor bot auto-closing bugs. You, dear KDE developers, often leave a bug unanswered for _years_. You even leave _patches_ lying around for years without commenting on them. I understand, you are all humans, you have finite capacity, you probably all volunteer to do this. I also used to walk in these shoes for a long time, and probably will do again. But you really should not combine this with giving 45 days for OP to respond. There are hundreds of reasons why the poster does not respond within this time frame, none of those make the bugreport any less accurate. You should seriously reconsider your workflow. The current one hardly leads to better quality software in the long run. After all, why wouldn't you want to address bugs whose reporter is no longer here? The reporter is surely not the only person infected. Why wouldn't you want future Konsole developers to find those bugs and potentially address them? Why would you want to close your eyes and pretend that the bug doesn't exist, rather than actually fixing it? But most importantly, your current workflow is utterly unfair and disrespectful.
... and me submitting a comment doesn't even automatically set back the bug's state to... to what state exactly do _I_ have to _manually_ set it back, to make sure it doesn't fall through the cracks?
(In reply to Egmont Koblinger from comment #3) > > would you be interested in submitting a patch > > No, sorry, not. > > > Let me tell you: I'm honestly disappointed in the attitude I'm seeing in > bulk nowadays from Konsole's bugtracker. > > > First, I don't understand why this question justified the NEEDINFO state. > You do not _need_ information from me. You could just go ahead and fix this > bug. > My apologies, I accidentally selected the wrong status for this bug report. > There are situations that justify NEEDINFO, e.g. when you cannot reproduce > the bug, or don't understand what the reporter says. Apparently this is not > the case here. You are not blocked in any way. > > > Second, this Janitor bot auto-closing bugs. > > You, dear KDE developers, often leave a bug unanswered for _years_. You even > leave _patches_ lying around for years without commenting on them. I > understand, you are all humans, you have finite capacity, you probably all > volunteer to do this. I also used to walk in these shoes for a long time, > and probably will do again. > > But you really should not combine this with giving 45 days for OP to > respond. There are hundreds of reasons why the poster does not respond > within this time frame, none of those make the bugreport any less accurate. > > > You should seriously reconsider your workflow. > > The current one hardly leads to better quality software in the long run. > After all, why wouldn't you want to address bugs whose reporter is no longer > here? The reporter is surely not the only person infected. Why wouldn't you > want future Konsole developers to find those bugs and potentially address > them? Why would you want to close your eyes and pretend that the bug doesn't > exist, rather than actually fixing it? Please let me assure you, we are all striving towards better quality software at KDE. We use these products on a daily basis and so are also invested in making sure they are of the highest quality. > But most importantly, your current workflow is utterly unfair and > disrespectful. I'm sorry you feel this way, no disrespect was meant at all. (In reply to Egmont Koblinger from comment #4) > ... and me submitting a comment doesn't even automatically set back the > bug's state to... to what state exactly do _I_ have to _manually_ set it > back, to make sure it doesn't fall through the cracks? Unfortunately this is a limitation in Bugzilla. Many discussions have been taking place recently around moving to a more flexible solution with better workflows. If you can confirm this bug is still plaguing Konsole please change the status to CONFIRMED, then a developer will take a look at the issue and work towards a possible solution.
Thanks a lot for the clarification, Justin! Since I'm the original reporter, I don't think it would be fair for me to CONFIRM my own bug, would it? I'd leave this up to you guys.
Fair enough, I'm happy to mark is as confirmed as it's affected you through multiple iterations of the application.