* add new header that only contains neutrino_msg_t and friends, often this
is all that's needed instead of full rcinput.h
* directly include rcinput.h in some cpp files instead of relying on
accidental inclusion in some header
* add class forward declarations to avoid dragging in rcinput indirectly
This could use more work to further reduce the impact; maybe separating
the CRCinput::key_* constants from the rcinput class would be good.
* remove intergration conversion because we can use the integer as it is
* update headers
Do we need /src/plugin.h anymore? Maybe this code could be merged into src/gui/plugins.h.
Signed-off-by: Thilo Graf <dbt@novatux.de>
instead of including framebuffer.h almost everywhere, replace it with
class CFrameBuffer forward declarations and/or generic system includes.
Add a hack to define fb_pixel_t to config.h (one reason for
framebuffer.h includes was the fb_pixel_t define)
- don't create header instance on every widget paint.
- remove parameters from hide(), not needed anymore
- add signal/slot OnBeforePaint(), OnAfterHide()
- try to fix infoclock handling
- add member ResetModules()
- allow separator to paint with gradient
The issue is that it's not really possible to disable/enable menu items on
runtime with an existant menu widget instance eg with personalized menu items.
Here we need a dynamic solution to disable items depends on stb-mode (mode_ts, mode_tv etc)
This should be solved here with an additional parameter for personalized items.
New paramter is named: disable_condition
Possible alvailable values at the moment are:
DCOND_MODE_NONE as default
DCOND_MODE_TV
DCOND_MODE_RADIO
DCOND_MODE_TS
includes some improvements by Sven
- menue: remove old_iconName handling
... icons should be painted on deactivated items too
- menue: try to fix position <-> selection missmatch
Color gradient feature was originally intended for use
inside theme settings and it's not really suitable for
generally use as default in all themes at the moment, so it makes more
sense to have options in theme settings and let the user decide
to customize this, unless enough other gui parts can use this feature.
In some situations is it more senseful to suppress painting of details line.
Required if menu window is painted over another window.
The hide() functionality of detailsline paints only an empty background on screen so we have
blank parts on screen. That looks bad. For example, this is to observe
on context menu in channellist.
We should see this as a workaround. It is not certain whether the
details line is really needed in the future.
