Allow users to add color to history text

That would be really cool!

Using igor style color specifications is probably easiest for the user, although I'm personally also okay with ANSI color sequences.

You must mean something that I'm not getting. Igor 7 and later has syntax coloring in the command window.

I want to color arbitrary strings.

Let's say I want to output a warning string in yellow via print/printf. Is that already possible?

No, this isn't currently possible, but it's something we've considered adding.

Using the full Igor styled text codes would not be practical as the history window is drawn completely by Qt code (based on QPlainTextEdit). We might be able to easily use a limited subset of HTML, though I'm not sure about that. Otherwise, any text styling would need to be implemented by a custom QSyntaxHighlighter (http://doc.qt.io/qt-5/qsyntaxhighlighter.html). One of these is already used to do the Igor style syntax highlighting there. 

Currently the default in the history window is that lines that start with a bullet are highlighted using the regular Igor code syntax highlighter. Other lines are skipped. I thought there was a way to turn off syntax highlighting in the history window but I don't see it, so maybe there isn't. But so far that hasn't been a problem that we've heard about.

To implement this, we'd need to decide on a few things:

1. What markup format should be used?

2. How does the user specify that "history style" should be turned on? We could always enable it, but it is likely that whatever markup format we pick will conflict with history text that a user doesn't want highlighted. Otherwise we'd need to add either a global setting to enable/disable it for the history window, or each line that's printed to the history would need to have tags indicating that it is styled text (eg. <html></html> if we use html).

1) HTML, e.g. as <span ID="IgorStyle" color="red">...</span>

2) a button on the history bar immediately below the INFO/HELP button and/or a rule that ONLY elements within <span ID="IgorStyle" ...> </span> are to be parsed for styling

3) Do we allow users to create their own CSS for the history window? ... Why not?

I played around a bit to see whether this is practical to implement using HTML and I don't think it is. I've attached a screenshot (HistoryStyled.png).

Note that line 25 is displayed correctly, with Hello in bold and Qt! in italics. But then note that lines 26-29 are also in italics. That's not right--they should all be in plain text.

I don't think this editor we're using is designed to mix plain and HTML text like this.

The easiest way to implement this would be similar to a syntax highlighter, which doesn't actually change the text itself, it just changes the color or other characteristics of the text based on certain rules. I've done a quick sample implementation of this using a syntax based on Markdown. That's also attached below (HistoryStyled2.png). Note that, when printed, the formatter characters (in this case, *, _, and ~) are also printed, though I'm printing them in a lighter color to make them fade into the background some.

If we go with the later approach, I'm not sure how to best represent color.

In reply to by aclight

aclight wrote:

I played around a bit to see whether this is practical to implement using HTML and I don't think it is. I've attached a screenshot (HistoryStyled.png).

But does it have to be *this* way. I realize it is easier to write <b> and <i> and so on. With the issues though, I might wonder that it is better (more consistent) to insistent on the history window parser ONLY accepting <span ID="..."> as denotations for HTML output.

aclight wrote:

The easiest way to implement this would be similar to a syntax highlighter, which doesn't actually change the text itself, it just changes the color or other characteristics of the text based on certain rules.

But ... isn't this what HTML is doing ... changing the color or other characteristic of the text based on certain rules (often called style sheets in HTML)? IOW, what do you mean is to be the difference in implementation between these two?

<b>BOLD</b> and **BOLD**

Pardon but I am a bit lost here why one is actually "easier" than the other.

aclight wrote:

If we go with the later (markdown) approach, I'm not sure how to best represent color.

AFAIK, color is not within the span of markdown syntax. It reverts to HTML.

https://stackoverflow.com/questions/35465557/how-to-apply-color-in-mark…

 

In reply to by jjweimer

jjweimer wrote:

But ... isn't this what HTML is doing ... changing the color or other characteristic of the text based on certain rules (often called style sheets in HTML)? IOW, what do you mean is to be the difference in implementation between these two?

<b>BOLD</b> and **BOLD**

Pardon but I am a bit lost here why one is actually "easier" than the other.

 

HTML has the raw html source code (with all of it's ugly <xyz>...</xyz> tags), but the rendered version doesn't show the tags, just the rendered version. For example:

Raw:

<html><b>bold</b> not bold</html>

Rendered:

bold not bold

With a syntax highlighter, the text itself doesn't change, just how its displayed. With the simple test I put together, that's:

Raw:

**bold** not bold

"Rendered":

**bold** not bold

With the implementation I did in the example picture, the stars would be light grey, not regular black, but I can't set the color here. Note that the stars are in both the raw and rendered versions.

It's hackish but relatively easy to implement. But I'm not sure that the final result looks good enough to be worth implementing.

 

In reply to by aclight

aclight wrote:

HTML has the raw html source code (with all of it's ugly <xyz>...</xyz> tags), but the rendered version doesn't show the tags, just the rendered version. For example:

Raw:

<html><b>bold</b> not bold</html>

Rendered:

bold not bold

With a syntax highlighter, the text itself doesn't change, just how its displayed. With the simple test I put together, that's:

Raw:

**bold** not bold

"Rendered":

**bold** not bold

Got it. Thanks!

It's hackish but relatively easy to implement. But I'm not sure that the final result looks good enough to be worth implementing.

Yeah not very nice indeed.