tinconn@virgilio.it wrote:

hallo all I'm like to make dynamic the color of my plugin using the current set theme. I have read the PLUGIN.html but i understand that with this three line of c++ code i can set a clrTitle color and then i can use it:

static cTheme Theme; THEME_CLR(Theme, clrTitle, 0xFFBC8024); int clrBackwindow = Theme.Color(clrTitle);

I don't wont to redefine the color, but i want to use the actual theme color...

I don't think that it's possible with the current theme model: only the skin defining the color has access to it (i.e it's the only one knowing the correct index), externally it's not possible to know the colors for the various skin elements. I'd like that feature too: since I draw my own osd I'd like to at least use the same color as the general skin. Now I hardcoded the colors used by the ttng skin but it will look bad with any other skin.

Bye

tinconn@virgilio.it wrote:

Luca Olivetti wrote:

...

tinconn@virgilio.it wrote:

...

hallo all I'm like to make dynamic the color of my plugin using the current set theme. I have read the PLUGIN.html but i understand that with this three line of c++ code i can set a clrTitle color and then i can use it:

static cTheme Theme; THEME_CLR(Theme, clrTitle, 0xFFBC8024); int clrBackwindow = Theme.Color(clrTitle);

I don't wont to redefine the color, but i want to use the actual theme color...

I don't think that it's possible with the current theme model: only the skin defining the color has access to it (i.e it's the only one knowing the correct index), externally it's not possible to know the colors for the various skin elements. I'd like that feature too: since I draw my own osd I'd like to at least use the same color as the general skin. Now I hardcoded the colors used by the ttng skin but it will look bad with any other skin.

Bye

---

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

What Luca Olivetti says is corrected? For now it's inpossible to use a global theme colors for plugin?

There is no way an arbitrary plugin could reasonably use any of the colors a skin has defined - it doesn't have any idea about what each color is actually used for!

The only way a plugin might "blend in" usefully would be to open a cSkinDisplayMenu and draw some stuff into the "central area" of that menu. That way the "decorations" (like title, buttons etc) would be drawn in the skin specific way, while the actual content is up to the plugin to draw.

I do plan to implement this possibility, but right now I'm still at the (audio) track stuff...

Klaus

The only way a plugin might "blend in" usefully would be to open a cSkinDisplayMenu and draw some stuff into the "central area" of that menu. That way the "decorations" (like title, buttons etc) would be drawn in the skin specific way, while the actual content is up to the plugin to draw.

I do plan to implement this possibility, but right now I'm still at the (audio) track stuff...

Klaus

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

This would improve the overall design of VDR and its plugins, but the "central area" would still have a different design. I know that this would be a huge piece of work, but wouldn't it be better to alter the skins, that they would define a general design of the menus, but also the design of standard objects (like title, button, text, highlighted text, progress bar ...). So a plugin could take this standard-objects and assemble the screen. I don't know how KDE or GNOME handels skins, but it should be anything similar to this.

What do you think? Something for vdr-1.6 or vdr-8.0? :-)

Bye, Andreas Brugger

P.S.: My best wishes for the 5th vdr-anniversary. Although I'm only "witness" of the last two years there were huge improvements and the software was always ahead of the other products. I hope there is much to come (HDTV maybe) so the VDR-hobby shall never die. :-)

Klaus Schmidinger wrote:

Well, I guess this is one of the times where I need to say: KISS!

I agree, that's why I don't understand the current, complex, way of each skin defining all colours again and again (clrMenuItemCurrentFg, clrMenuItemCurrentBg, etc.), each in a non discoverable way. Why not defining a set of fixed base colours (the name/id, not the colour itself)? Then a skin could use more if it needs to.

Let's keep things simple! A skin can display the menus and stuff in whatever way it likes.

But all of them have to define a colour for selected/selectable/unselected/unselectable items

A plugin can't even begin to imagine what exactly a skin looks like.

but at least it could use the same colours

That's why there is only a very basic interface to a thing like cSkinDisplayMenu, which can have several features like a title, buttons, items etc. After all this is not a desktop - it's an appliance!

There's nothing wrong with a plugin taking the whole OSD and displaying on it whatever it wants - if it thinks the standard cSkin* objects aren't suitable for what it has to display, then it doesn't fit into the overal VDR scheme, anyway ;-)

but by using the same colours it could at least not seem too much alien.

Bye

Luca Olivetti wrote:

Klaus Schmidinger wrote:

...

There is no way an arbitrary plugin could reasonably use any of the colors a skin has defined - it doesn't have any idea about what each color is actually used for!

Unless you define some standard names/ids that have always the same meaning (like "background colour", "selected text colour", "selected text background", "non selected text colour", etc.). Obviously these would be skin/theme dependent but the plugin wouldn't need to know that, only ask vdr for the current "selected text colour", etc.

...

The only way a plugin might "blend in" usefully would be to open a cSkinDisplayMenu and draw some stuff into the "central area" of that menu. That way the "decorations" (like title, buttons etc) would be drawn in the skin specific way, while the actual content is up to the plugin to draw.

So if the plugin has to show some text/selection/etc. inside that area we're back to square one :-(

Not necessarily. Since the skin will give the plugin a cBitmap, there will also be information about the color depth and a palette. The skin can fill the palette with the colors it can provide, and by convention it could be

0 = background 1 = text foreground unmarked 2 = text foreground marked 3 = text background marked

or something like that. Defining more than 4 colors might be a problem for unmodified full featured DVB cards, because there the "central area" only has 2bpp.

Klaus

Luca Olivetti wrote:

Klaus Schmidinger wrote:

[...]

...

0 = background 1 = text foreground unmarked 2 = text foreground marked 3 = text background marked

or something like that. Defining more than 4 colors might be a problem for unmodified full featured DVB cards, because there the "central area" only has 2bpp.

Yes, that would probably be enough and it's just what I was asking.

Well, thinking of it, it probably wouldn't: considering my plugin, on the top I need 4 fixed colours (for the signal information: background, red, yellow, green) and the central area 4 colours too for the menu, but those may be different than the previous ones. At the moment I'm using three areas (one for the signal display, one for the menu and one for the eventual status message). I could just do with drawing the osd myself but knowing those 4 colours for the current skin/theme. Of course I won't mind if you're going to come out with a better solution ;-)

Bye