Tilix: Badge

[egmontkob]

Similarly to background image support (#298), you could implement something like iterm2's badge (large pale text in the corner).

At this moment you couldn't alter it via escape sequences yet, but it could be quickly settable via a menu entry.

[gnunn1]

I've thought about this one as well, unlike the background image it's actually a useful feature IMHO :)

[gnunn1]

This is also covered in #86

[gnunn1]

@egmontkob After looking at this, I'm tending to think this is something which is better implemented in VTE. The issue is that I can only get this to work with transparency in order to draw the badge "underneath" the characters since VTE will erase anything I draw on the background.

For me to do this, it would use the same technique as the background image but unlike the background image I think it would benefit from being independent of transparency. Since VTE has full control of it's drawing cycle (Captain Obvious statement there) it can draw it in a way that is completely independent of transparency.

Thoughts?

[egmontkob]

I'm not following you, sorry. What is the scenario that cannot be solved right now and would be solveable with some VTE help? Or do you just think it would be cleaner design?

VTE used to contain background image support and then the main developer dropped it. He had his reasons I guess, I'm not aware of them. How would an official badge support look like? An API of adding a text like this would take way too many parameters. Alignment (e.g. top right), font, size, color, justificaiton, where to wrap text, how to clip overlong text etc. and probably it still wouldn't be flexible enough to handle cool new ideas. I can't be sure what his opinion would be, but I'm pretty certain he would be against such a feature (and I don't think VTE is the right place to address it either).

Should VTE add anything like this, I believe it should revive the most generic background image support (and leave it up to you to give it a background image that happens to contain the badge text) rather than this very specific badge text API. But I'm quite certain it won't.

I cannot comment on VTE's drawing cycles, I still don't quite understand how this stuff (and the drawing underneath) works, you have a way better understanding of this topic than I do.

[gnunn1]

The problem is for terminix to make it work, the badge always has to be layered underneath VTE, this has a number of problems including:

• Transparency is required, if someone sets the slider to no transparency they won't be able to see the badge
• At less then 100% transparency the badge is obscured by the transparency and VTE color in the sense it will look dimmer then it could, terminix can't draw the badge unimpeded unless the user sets the transparency slider to 100%.
• Like background images, badges require that the double buffering technique be used where the VTE first has to be drawn to an off-screen ImageSurface and then rendered against the widget's Context from the draw event. Since I know background image support was dropped from VTE and it's not coming back there is no other way to do it. However for badges I was wondering if it makes sense to be re-visited.

In terms of an API, I believe iterm2 exposes pretty limited control over the badge. I'd suggest text, position (topleft, topright, bottomleft, bottomright) and color and that'd be it. The font would be a nice to have but not essential if that's getting too out of control as the font would use the same font already set in VTE.

In terms of size, adopt the same approach as iterm2 where it automatically selects the size that gets the text to fit in the quandrant.

[egmontkob]

I guess I got a feeling of the problem now :)

I'm not sure if it's doable, but I'm wondering: Would it be possible to always use the double buffering technique and always make VTE 100% transparent, and make the underlying ImageSurface transparent/translucent/whatever according to the user's prefs (e.g. the transparency slider would change the alpha value of this ImageSurface)? Then e.g. you could use totally opaque color for the badge text only and something translucent for the rest.

I believe iterm2 exposes pretty limited control over the badge.

IMO for an app it's okay to offer such a limited choice, for a library it is not. If it does it at all, it needs to do it in a generic enough way, whatever that means. (And, again, in my opinion a "generic enough" would probably mean background picture support, rather than badge text support.)

[gnunn1]

It is possible to make the VTE 100% transparent, I considered that as well but there are a few points against as well:

• I'm not sure anti-aliased fonts would look very nice since anti-aliasing typically depends on the background color being set to blur/blend appropriately
• I'd have to implement some sort of cooperative rendering between the session and the terminals so the terminal could render the background color and badge separately from the draw cycle. It's not impossible, just feels kludegy and not the right spot to do it.

An alternative to a full blown badge API might be if VTE exposes an onDraw style signal that happens after the background is drawn but before the foreground (i.e. text is drawn). I'm not sure if the VTE maintainer would like that much either though.

[egmontkob]

I thought anti-aliasing would only use the font's color and varying alpha, leaving the rest to the compositor. I might be wrong of course.

I guess your alternative suggestion might work, sounds good to me (without knowing enough to tell whether it's actually feasible).

[egmontkob]

Actually, thinking about it a bit more... "legacy" ("black and white") antialiasing might work the simple way I had in mind, but subpixel rendering definitely needs to be aware of the background color, so you are right.

[gnunn1]

With regards to my alternate idea, I downloaded the VTE source code and started playing with it a bit as I figured implementing this might be a good first step towards learning things before getting into the custom OSC code.

Anyway, I decided the first step is to figure out where the appropriate spot would be to draw a badge where it wouldn't be erased but the text would overlay it as I described previously. It looks like it is fairly straightforward, I modified the VteTerminalPrivate::widget_draw method to draw a small blue rectangle as an initial test and it seems to work well, see the screenshot below:

I tried a few obvious things, like scrolling the text up and down, selected text, etc and it seems to work reasonably well. When selecting text, the background square I draw gets overwritten by the block highlight, presumably because the _vte_draw_fill_background is called in these cases. As well if you use escape sequences to set text to have background colors these will overwrite the blue block as well. I think these are acceptable scenarios though, see screenshot below:

The code is below, I just inserted it after the call to _vte_draw_clear at line 9736. Obviously a proper solution would be to create a signal (draw-background?) and emit it here instead.

    // GBN - Test painting background to see if it would stick
    cairo_rectangle (cr, 50, 50, 100, 100);
    cairo_set_source_rgba (cr, 0.0, 0.0, 0.8, 1.0);
    cairo_fill(cr);

@egmontkob Does this seem a viable approach to you? If so, I'll open a bug report on bugzilla to ask the maintainer if you would be willing to accept a patch for this.

[egmontkob]

SGTM, yes please go ahead, file a bugreport, let's see what the vte boss says :) Thanks a lot!

[gnunn1]

Thanks, opened bug https://bugzilla.gnome.org/show_bug.cgi?id=767575

[gnunn1]

I made some good progress on this tonite. I patched the VTE to add a new property to disable the background draw rather then an event. After thinking about it a bit more, I realized that all that was needed was to tell VTE not to paint the background, the application can then handle drawing the background in the normal draw signal. This eliminates the complexity of introducing a new signal which is a bit painful and hopefully addresses VTE maintainers concern about performance of nested draw signals.

Here's a screenshot with the word "Testing" as the badge in the background. Note this feature isn't very useable at the moment, I need to spend a lot of time optimizing how the text gets drawn. Right now it's using a hard coded font size and position.

[gnunn1]

This has been completed, note that it requires the vte patch /experimental/vte/disable-bg-draw.patch to be applied to work.

@egmontkob if you have time, feel free to test and let me know how it goes. The patch has been tested against both 0.44 and 0.46 versions of the VTE.

[gnunn1]

Also, here's an updated screenshot with the badge using the ${title} variable:

[egmontkob]

if you have time, feel free to test and let me know how it goes

I'm blocked by #507 (in addition to lack of time :P)