From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 29 Jun 2009 17:15:31 -0700

2009/6/29 Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>:
>>
>> At the bottom we have the button bar for those targets (this is currently
>> "broken" IIRC so needs to be fixed up.)
>
> I've never seen it in action anyway. Do we really need it, I remember you
> said there's only 1 target that has it anyway? (to answer your next email
> too a bit). In my impression, it makes coding just a pita.

I'd really love to say no we don't need it... and I'm wondering why
noone has come out saying they'll get the pitchforks out if that
happened...

>>
>> The middle area is going to be split by the users config. That "UI AREA"
>> is where all screens MUST draw in (with the exception of the splash
>> (MAYBE)), This part could take up the entire screen if the bars are
>> disabled... The important thing here is that UI screens work in that
>> viewport and don't assume they own the whole screen.
>> The area outside of that "UI AREA" is going to be special... What I'd
>> really like is to allow that to either be dead space (so just showing the
>> backdrop from the menu), or have it displaying part of the WPS (requires the
>> themer to do extra work here, but proof of concept works well).
>
> That's how my customlist patch is designed so far. Splashes are really
> problematic. And there're a few places (mostly: debug menu) where UI doesn't
> count but a maximum of displayed information
>
> If it's all done properly, we don't need to care about the outside area. My
> patch has a mechanism to clear it anyway in case of the WPS for example (we
> don't really want to restrict it to the UI area, do we?).
>>
>> How this all needs to work is with the viewport_manager_*() functions
>> (badly named, someone come up with something better?.) When a screen wants
>> to do some drawing they need to call viewport_manager_get_uiarea() which
>> will return a viewport which you can draw in... 0,0 in this viewport could
>> literally be anywhere on the display so screens need to be able to handle
>> not owning the full thing.
>>
>
> That get_viewport function is also already implemeted in my patch. It was
> needed to avoid giving simple things like set_int() or the simplelist
> (though, the simplelist doesn't call it yet), a way to draw in the active,
> not necessarily UI area viewport without poluting the parameter list
> further.
> It's a handy function after all.
>>
>> The buttonbar is a bit wierd because its linked to individual screens, but
>> it outside the usual ui area... so quick aside here is to remove it
>> completly..... (or not....)
>>
>> There is going to be some cases where the full screen needs to be stolen
>> (the quickscreen is an obvious example), so there will need to be a viewport
>> function which will disable the background wps drawing (if enabled), the
>> buttonbar and the statusbar (if enabled, but also this one will probblay be
>> optional.) If a screen calls this, it MUST reenable everything when it
>> exits.
>
> I don't think the quickscreen needs to be fullscreen. It can be perfectly
> fine within the UI area.

I'm almost thinking that this would be confiugurable itself.... some
themes might look horrible with the QS using the ui area instead of
the full area.

>>
>> Plugins are special cases and I tihnk the plugin loader should be
>> responsible of disableing everything when a plugin loads and reenableing
>> everything on exit. The menu widget will probably be made to always enable
>> the statusbar (if its enabled by the user) and the buttonbar (ditto). This
>> will give a nice consistant look to everything using the standard menu
>> (which all plugins do now).
>
> I'm still unsure about the disable thing, especially for the statusbar. I
> think plugins should handle setting up there own drawing boxes, but it will
> be much work, indeed.
> On the other hand, it would be nice if a do_menu call would look like in the
> core without the plugin doing anything. Is there a simple solution? Plugins
> will need to switch between UI area and fullscreen much more often.
>
> Currently, you can deactivate the UI viewport using
> viewportmanager_set_ui_vp(false), but everything that uses the NULL viewport
> still gets the UI viewport.

The way I'd like it to work is along these lines... screens have the
option of using the FULL lcd (maybe with the choice for the
statusbar), or the UI area... no other options pretty much everything
that wants to draw needs to get a viewport so I'm not even sure this
all couldnt happen in one call..



>>
>> The last thing is the background WPS idea. The way my proof-of-concept
>> worked was with a flag in global_status which was set to true if the WPS is
>> being drawn in the actual WPS screen, or 0 if it was in the menu. Themers
>> need to be careful here and use that conditional to make sure to not draw in
>> the rectangle where the "UI area" is (or the statusbar of course). It would
>> get updated like how the statusbar is now... so in every action_get() call
>> (pretty much once per redraw of every screen, so screens which loop on HZ/x
>> will look better than those which block). If this is enabled there will most
>> probably be a battery hit, but thats up to the user if they want it or not
>> (and it does look nice... :) )
>>
>> so... comments, questions, suggestions?
>> Jonathan
>>
> That would definitely be neat. But the wps needs more updating, let it be
> alone progress bar. There could also be the case where you want the
> peakmeters in the mainmenu, which need constant updating.
>
> I think we could have the WPS define areas to be shown, e.g. special
> viewports, or rather updated, while being in other screens. The wps update
> routines would only update these areas then.
>
> Nevertheless, I'd absolutely love that feature.
>

Either way would work, I tinhk I did it the way I did because its
easier to implement (from the code and the themer POV).
Received on 2009-06-30