From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Wed, 28 Oct 2009 16:34:01 +0100

Jonathan Gordon schrieb:
> Firstly, Kugel, dont take this as a personal insult...
>
> I'm trying my best to see the logic in the current implementation of
> the UI viewport and how it mixes with themes and custom statusbar
> (sbs) and the wps and well, imo it's broken...
>

I don't take it personally. But there seems to be indeed some
misunderstanding.

> This is how it currently works:
> * The UI (lists/menus/etc) can be told where to draw in... there are
> two ways that gets done now, with the "ui viewport" setting (which is
> a "secret" setting in that it can only be set in the .cfg file), and
> using the %Vi tag in the sbs
> * If the setting is there, then %Vi is ignored by the lists which will
> draw into the viewport set by the setting... if the setting doesn't
> exist then the viewport set by %Vi is used
> * In the WPS, the setting is *always* ignored, if no sbs is loaded
> (and the built in statusbar is disabled) then the default viewport
> (where stuff gets drawn in before the first %V line) is the full
> screen (0,0,LCD_WIDTH, LCD_HEIGHT)... If a sbs *is* loaded then the
> default viewport will be the viewport from the sbs's %Vi tag (!)
> * In the WPS again, the %we (enable statusbar) tag right now is hard
> coded to only work with the "classic" inbuilt statusbar, so full width
> and 8 pixels at the top or bottom of the screen
>


You're mixing up UI vp and %Vi. They have different intentions and have
a different meaning.

- UI vp is the ultimate viewport for the UI excluding skins (plugins
override use it currently, but I'm planning to fix that). It's the
viewport that has the top priority for the UI. That's what it has been
committed for.
It's described in the manual as such, and is a user setting. Skins are
excluded since they can be customized separately.
It's what you get by calling viewport_set_defaults().

- %Vi is just the "viewport that doesn't interfere with the status bar.
That doesn't imply anything priority other than it's useful to respect
that viewport if screens that don't specify a viewport (i.e. don't use
the UI vp OR every screen if no UI vp is set). It's by no means a
general purpose UI vp.
It's described on CustomWPS as such, and is what you get by
viewport_set_fullscreen(), the function that gave always gave you the
maximum viewport dimensions minus status bar area.
Additionally, %Vi is a property of the sbs. It's completely theme
independent, it's just and only that very viewport that does not
interfere with the sbs. That's the intention, changing it to get a UI vp
renders that purpose obsolete.

No screen which can be customized by the user using viewports guarantees
that it doesn't draws over the sbs. Neither the WPS does not do that
(you can easily draw into status bar area with specifying viewports),
nor the UI vp enabled lists if a UI vp is set. Actually, even without
sbs you are able to draw over the classic statusbar with the UI vp.
That's because a user setting is ought to be respected.

Therefore, %Vi is just the backup for themes/WPSes that (intentionally)
omit custom viewports. It is not meant to override any other *user
specified* viewports.

PS: I can agree to fixing the UI vp against the %Vi boundaries since
that's doable quite easily. It's not easily doable for WPSes though.


And again, UI vp is a separate feature. UI vp and sbs shouldn't be mixed
up. UI vp is a feature to define custom list dimensions (and that's what
it really should do). And the sbs is a feature to draw some nice
graphics next to the menu.

> My problem is that there doesn't seem to be any consistency there.
>
> My proposal is the following:
> * The "ui viewport" setting is *only* used when no sbs is loaded (or
> the sbs doesnt specify a %Vi), otherwise %Vi is always used, including
> in the wps (where you could have the sbs and the wps being displayed
> together)
>

That breaks the purpose of UI vp. And it breaks the purpse of %Vi. And
it doesn't add any consistency. In contrary, loading a sbs from a UI vp
enabled theme will magically change the list's viewport radically. The
same goes for simply toggling between sbs and classic status bar. I
don't see any consistency here.
Changing list layout because of a totally separate, even unrelated
feature, is highly inconsistent.

If a UI vp is set, then lists are using that. Otherwise lists are drawn
so that they don't overlap with statusbars (both classic and sbs). That
is totally consistent in my eyes.
The WPS always uses %Vi for the default (implied) viewport, since you
cannot specify that in any way.

> * %we in the would force the sbs enabled, and if one isnt loaded, then
> it would use the "ui viewport" setting.
>

That adds even more confusion. %we already forces the status bar.
Currently the default value of status bar is "status bar at top".
Also, the UI vp is *not* meant to be used in skins. See my first
sentence. It's the viewport for everything _but_ skins.
> My reasoning is this:
> 1) The sbs knows where it draws into and where the UI should sit so it
> doesnt overlap
> 2) The wps knows where it wants to draw in, and can easily work with a
> sbs, or disabled it and have the whole screen
> 3) The UI/lists are designed to draw in any viewport and know nothing
> about any other viewport...
>

UI/lists are meant to be drawn fullscreen (excluding status bar area) or
within the UI vp, since a while already.
> Apparently the argument against this (other than "dont change the
> current behaviour") is sbs' and wps' shouldn't be linked to themes..
> Fine, I can accept that, but imo having the setting overwrite the sbs'
> %Vi ties it to a .cfg even more than the other way.
>

I cannot follow that argument. If you load a sbs that conflicts with the
already set UI vp, one can fix the UI vp. The sbs is still theme
independent, just the theme is not sbs independent.

> If someone were to take a sbs from a theme without taking the setting
> line one of two things will happen, either the sbs will take the
> entire screen because the artist never put a %Vi in because its
> redundant, or there will be redraw issues because the theme its copied
> into has a "ui viewport" setting already which completly overlaps the
> sbs. (Or the 3rd option is that it does work by fluke or miracle!)
>
> If the sbs takes priority and someone copies the sbs it *will* work
> (*at least with the lists)... if however the user wanted a smaller ui
> area they could easily modify one number in the sbs.
>

Again, that breaks the intention of %Vi. It is supposed to *never*
change unless the sbs itself is changed (redesigned for example). %Vi is
a property of the sbs, and not of a theme.
On can fix the UI vp setting just as easily as %Vi, with the bonus that
it doesn't what it's meant for.


Best regards.
Received on 2009-10-28