concept frame: truncate overly long titles

[wez]

Previously, if the text was too wide to fit in the header we
would simply not render any title.

This changes the logic to a simplistic attempt to truncate the
text to fit, by repeatedly removing the last character and
re-measuring the width.

[elinorbgr]

Thanks, that looks like a sensible approach overall 👍

I have mostly two points / questions:

• I think it'd be nice to append … to the title if it is truncated, to have a visual indication that this is not the full title
• How does it behave, in terms of performance, on very long titles? Would it make sense to add some kind of shortcut to quickly remove a large part of the title if it is way too long?

[wez]

Cheaply dealing with long titles nicely is a bit awkward given the limitations of the simple API exposed by the andrew crate; ideally we'd get the individual glyph metrics and reason about those to decide where to insert the ellipsis and then render the text. That would make the code in this crate more complex and I'm not sure if that is desirable.

Assuming that you don't want to bring too much font/layout related complexity into this crate, simply clipping the render seems like a cheap and effective approach, if you don't mind not having the ellipsis. andrew doesn't seem to have an explicit clipping function, so the text renders over the buttons in the titlebar if I remove the length check. However, moving the button rendering after drawing the text seems to work just fine; I'll update this PR with that change.

[wez]

The ellipsis could be implemented on top of this clipping approach in the case where the text wasn't centred; logic could be added to measure the width of the ellipsis glyph (or just ...), clear the rightmost rectangle and render that text in over there. There are a number of edge cases with that sort of thing though; if the width of the ellipsis is longer than eg: a partially truncated final glyph then it will look weird and to make it render well requires more reasoning about the glyph metrics... and I think that is probably a bit more complex than is needed or desirable in this crate!

[elinorbgr]

However, moving the button rendering after drawing the text seems to work just fine; I'll update this PR with that change.

I'd agree with this on the principle, but having just tested your PR it appears the buttons are drawn on top of the text but still with their transparent background (when using the default color scheme), so the button images are mixed with the text behind it, rather than overwriting it.

BTW, we're currently kind of stuck wrt to andrew, which seems to no longer be maintained. So I'd be open to replacing it with an other crate if there is a nice one available somewhere.

[wez]

I'd agree with this on the principle, but having just tested your PR it appears the buttons are drawn on top of the text but still with their transparent background (when using the default color scheme), so the button images are mixed with the text behind it, rather than overwriting it.

Hmm, I was testing in mutter nested in X. I'll take a look at this on a real wayland system tomorrow.

BTW, we're currently kind of stuck wrt to andrew, which seems to no longer be maintained. So I'd be open to replacing it with an other crate if there is a nice one available somewhere.

Hmm. I have some of that functionality (bitmaps, line drawing, a little bit of avx acceleration for some operations) in https://github.com/wez/wezterm/blob/master/window/src/bitmaps/mod.rs and some much more advanced font shaping stuff for ligatures and emoji in a different layer in that repo. Some of that could be extracted out to be used here if there isn't a compelling alternative. The font stuff is harder because the harfbuzz dep requires some more intrusive build machinery, which seems undesirable in client-toolkit.

As a slight aside from this PR, but on that topic: I would like to be able to render my own titlebar contents in my application and eliminate the use of font-config and system freetype that is currently pulled in via andrew. I know that I could provide my own frame implementation but there is a lot of code to replicate from conceptframe.

I think I'd like to see an extension trait for concept frame that allows the embedding application to receive the bitmap slice and state for each UI element and let the application render those for itself.

It's getting late here now and I haven't fully thought this out... I'll put some more thought into this in the new few days.

[kchibisov]

As a slight aside from this PR, but on that topic: I would like to be able to render my own titlebar contents in my application and eliminate the use of font-config and system freetype that is currently pulled in via andrew. I know that I could provide my own frame implementation but there is a lot of code to replicate from conceptframe.

If that's the thing you want you can do that right now by implementing Frame trait on your own with whatever things you want in it. Plugging custom drawing into concept frame is making it missing a point of created frame for you that you can use right away, though it has slight theming, I guess due to winit, but that it.

[elinorbgr]

Closing this as since #183 the frame provided by SCTK no longer provides a title writing. This is left for custom implementations of the Frame trait.