Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: updating the gui for viewports

updating the gui for viewports

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 31 Dec 2007 18:41:56 -0800

So we had a very quick discussion in irc before and I want to get some
discussion happening before major work starts to update the gui for
viewports.

what I'd like is every "screen" (or at least the major ones,
wps/lists/rec/fm/etc) be split into a drawing function and a logic
function, basically the idea is to be able to let people really
experiment with the gui so we can have custom builds which really
don't look anything like rockbox. The other reason to do it like this
is because I want to get a "window manager" going (come up with a
better phrase and I'll use it) where on the targets with suitable
screens it would allow us to really go nuts with viewports. I want to
be able to have an updating wps, a visualisation going and the menu
all on the screen at once, all updating correctly, which isn't going
to be easy if we dont use some sort of manager to do it.

On targets without suitable screens, the window manager would act
exactly like the root menu does now.

I'm not exactly sure how the button loops would work for each screen,
but I'm thinking they wouldnt loop, they would just call
action_get(timeout?), do something with the button then return one of
the current GO_TO_ values. a few values would need to be added so
windows can return say if the screen has been exited, or if not, dont
sleep before retuning into the button function, (others?).

The drawing function for each screen should be something like void
some_drawer(sturct screens *display, struct viewport *vp, void *data)
to make storing and calling them easy.

the rest is just brain dump...
- need a function to draw a nice border around the viewport to make it
obvious which "screen" has focus
- screens can be popup-up and added by anything, but a background
screen cant steal focus (by focus, I mean the key input)

OH, before I forget, anyone redoing the screen drawing.. we want to
remove the _SYSFONT_ langs, so the aim is to always draw the screen
with the current font, if it doesn't fit, then draw it as best as it
can. (I don't think there are going to be objections to this?)

Bah, I've forgotten half the stuff I wanted to say... OH well...

Any comments, arguments before I start coding?

Happy new year all.
Jonathan
Received on 2008-01-01

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy