From: Thomas Martitz <kugel_at_rockbox.org>
Date: Wed, 20 Feb 2013 12:34:32 +0100

Am 18.02.2013 00:50, schrieb Jonathan Gordon:
>
> OK, so its clear I (and wodz) misunderstood, do you mind please
> explaining exactly what you're doing again to clear it up? I
> don't understand what the point of having a (almost?) wrapper around
> lcd_puts* in apps/ if really the only place it is called is
> gui/bitmap/list.c in one place? Everywhere else which is is called (no
> major screens) wouldn't make use of whatever is being added?


I want to have a simpler, pixel based API that is not comprised of a
dozen or more functions like lcd_puts*. In the end I would like
lcd_puts* being mostly unused and all calls being converted to the new
API. The main motivation is to put it into apps, not firmware, to get
the line styling (and other stuff, like indent and multi line) out of
firmware and to have the line selector (and line separator) extend over
to the list icons and unused-scrollbar-space.

I start with list.c because that's the most extensive user, but other
screens can follow easily, e.g. various plugins. The API that I suggest
can print the whole line (indent, spacing, icon and text) in a single
call so it's generally attractive.

>
> If all you want is a line separator then why is it not a simple 1 line
> lcd_hline() call in the draw_list() loop?

This is what the current version on gerrit does. The problem is that
scrolling breaks it (the scroll engine redraws the line selector which
clears the separator). And it sucks from a software-architecture POV:
The line selector is currently drawn in firmware, the separator would be
drawn in apps (in this scenario). So two completely different places
although they are essentially very similar (style attached to each
line). I really want to clean up this mess for good before moving
forward with the separator.

>
> Thinking about it now, it would be pretty cool to register a callback
> (per viewport) for the scroll engine to call which would do the line
> drawing instead of the current code. (It would have to be per viewport
> because it is very likley to have a skin scrolling line and the list
> scrolling line both scrolling at the same time, though a generic one
> would be needed for default which should "just work").

I have the beginnings of a scroll engine rework which does a callback
(per line, and each line has a viewport associated). But even the
current scroll engine already stores a viewport pointer for each line,
that is set when the line is redrawn.

Best regards.
Received on 2013-02-20