Hi NRK,
you make some interesting points. I am curious as to what your queueing
approach would look like.
I played around some more simplifying the ellipsis drawing and removing buf
as you suggested.
This would solve all of the aforementioned problems as far as I can tell,
but it can result in a partly drawn
emoji for example when the ellipsis cuts it off (which I think is a fair
tradeoff).
Thanks,
-Stein
On Mon, Mar 21, 2022 at 8:15 PM NRK <nrk_AT_disroot.org> wrote:
> On Mon, Mar 21, 2022 at 07:00:32PM +0600, NRK wrote:
> > The only "issue" is that it doesn't render the ellipsis in case font
> > changes, but current upstream dmenu doesn't seem to do it either.
>
> OK, I think I have a solution to this. The problem here, as far as I
> understand, is this:
>
> Let's say we have a maxwidth of 100, and printing the ellipsis takes 20.
> In this case as long as our string is below 80, we're fine; and if it's
> above 100 then we should print up to 80 and then print the ellipsis.
>
> The problem case is when we're between 80-100, and we need to change
> font. The current code always renders whatever is available when we
> change font, so if the text turns out to be bigger than 100 we've
> already rendered some of the text into the problem area where the
> ellipsis should've been.
>
> The solution I came up with is to simply not render anything if we're at
> the problem case, and instead put the problem cases into a queue and
> keep going forwards until either:
>
> 1) The text overflows, in which case we discard the queue and just print
> the ellipsis instead.
> 2) Encounter the end of text, which means the text barely fit into our
> maxwidth (this would happen with the prompt); in which case we just
> render the queue and don't print any ellipsis.
>
> I already have a patch that *roughly* does what I described above and
> with it applied I don't see any truncation problems anymore.
>
> However the patch is quite messy atm, and in order to do things cleanly
> and avoid special casing, I think a good portion of drw_text() will need
> to be overhauled to use a queue like this:
>
> struct { const char *str; int len; Fnt *fnt; } q[32] = {0};
>
> I'm not sure if such overhaul is going to be welcome or not, but if all
> of this sounds acceptable then I can proceed with cleaning things up and
> supplying the patch.
>
> - NRK
>
>
--
Stein Gunnar Bakkeby
OpenBet Developer
bakkeby_AT_gmail.com
Received on Mon Mar 21 2022 - 22:35:21 CET