- 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.
Default is <plugin>_hint.png; an entry 'hinticon=another_name' in
<plugin>.cfg overrides this; use icon in plugindir first; if not found
use icon in one of the other wellknown neutrino icon directories.
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.
Stop() is not exactly attributable if fader class used as inherited and
Fade() don't tell really what done and related to return value 'bool'...
especially as the fader class members have been not documented.
Use strictly CComponentsForm as parent parameter in constructors.
Some parts have been cleaned up (Constructors, init methodes removed)
New parameter makes it possible already add current item in constructor.
So in mostly situations is it not necessary to use explicit addCCItem(),
but addCCItem()is still valid and necessary in certain situations.
Affected are all cc-classes and their derivates.
Some classes must or can be adapted later. The function is
not currently restricted, because usage of parent parameter is not explicit
defined in constructors, see CImageInfo, here yet are used addCCItem()
methodes.
Generally this parameter is located in the constructors before bool has_shadow,
but it is not sure whether it would be better to use this parameter as the first.
That remains to be clarified.
