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...
Please help me
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
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?
thanks kikko77
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
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 :-(
Bye
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. :-)
Andreas Brugger wrote:
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
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? :-)
Well, I guess this is one of the times where I need to say: KISS!
Let's keep things simple! A skin can display the menus and stuff in whatever way it likes. A plugin can't even begin to imagine what exactly a skin looks like. 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 ;-)
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. :-)
Thanks.
Though I'm not sure whether we should really be looking forward to HDTV. After all, the providers will come up will all kinds of new restrictions and probably may make digital recording completely obsolete... :-(
Klaus
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
I don't think that FTA will dissapear in the future and also they will move towards HDTV if they want to stay into business. The real question is rather, will there be a full featured DVB card that supports HDTV so that the slow systems can still benefit from the HDTV transmissions. On the other hand, most TV's / Beamers are still not capable to work with a HDTV signal due to resolution limits. Indeed, it's not needed to look forwards but just keep the changes in mind.
Our Internet Service provider who also owns the cable infrastructure has just started PCTV. So, their cable customers can look to TV or a DVD movie in realtime. DVD means paying of coarse and no recording is possible. Viewing a DVD costts around 4 euro and is 24 hours available.
Stefaan
Klaus Schmidinger wrote:
Though I'm not sure whether we should really be looking forward to HDTV. After all, the providers will come up will all kinds of new restrictions and probably may make digital recording completely obsolete... :-(
__________ NOD32 1.1002 (20050218) Information __________
This message was checked by NOD32 antivirus system. http://www.nod32.com
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
Klaus Schmidinger wrote:
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.
[....]
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.
Yes, that would probably be enough and it's just what I was asking.
Bye
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
-
Andreas Brugger -
Klaus Schmidinger -
Luca Olivetti -
Stefaan Coddé -
tinconn＠virgilio.it