Plugin developers read

[Fatman_do]

Oh. I guess I didn't interpret his comment that way. I've seen him make that same suggestion before and I am all for it. I'm still trying to figure out you derived that meaning though.

I took Old Dog's comments the same way Jeff did. It is a plugin display related request.

"could we get them to refresh their skin related settings each time they are activated"

Bold emphasis is mine.

[Old Dog]

So far, everybody's right!

Basically, whenever the skin for a plug-in is changed, by the end-user or by the skinner, it would be good if the changes were reflected by the display the very next time the plug-in is selected.

There are two possible triggers for this:

• The plug-in's activate method is called
  
• Sub tells them (he actually is planning a software mechanism for this)
  

I would suggest that the plug-in incorporate an Initialize method that rereads the skin.xml among other things. This method could be called from Activate() or as a result of Sub new mechanism.

Regards All,
Old Dog

[psycik]

So far, everybody's right!

Basically, whenever the skin for a plug-in is changed, by the end-user or by the skinner, it would be good if the changes were reflected by the display the very next time the plug-in is selected.

There are two possible triggers for this:

• The plug-in's activate method is called
  
• Sub tells them (he actually is planning a software mechanism for this)
  

I would suggest that the plug-in incorporate an Initialize method that rereads the skin.xml among other things. This method could be called from Activate() or as a result of Sub new mechanism.

Regards All,
Old Dog

It's just as easy to store the date modified of the skin.xml file and test it easy time a render is done - you only test it once for the plugin BTW, not for each screen that would be too much IO.. Only one plugin at a time has focus at a time so it shouldn't really cause any problems.

But if later on i could be integrated into that settings area that sub started a couple of versions back, then he could worry about the skin file/config.xml etc being updated and it would be more consistent across plugins.

I'm going to have to look at my plugins at what i can get from baseSkin.xml rather then defining it all myself in my skin file.

[sub]

It's just as easy to store the date modified of the skin.xml file...

You do realize that if you had this, users would soon start asking about why changes to baseskin.xml or any image files used are not automatically detected. It all gets pretty messy pretty quickly.

[Fatman_do]

I'm going to have to look at my plugins at what i can get from baseSkin.xml rather then defining it all myself in my skin file.

Not much right now. (SelectedButtonImage, NormalButtonImage, PopupNormalButtonImage and PopupSelectedButtonImage composite images and Default, ButtonText and ScreenName textstyles.)

I listed everything that currently is in baseskin.xml

I would wait to see how baseskin.xml changes comming up will effect it.

That pretty much goes for any plugin right now. (I have looked at them lately for some reason... )

[sub]

Yeah there isnt really much in the current baseskin.xml. Pretty much anything could be put in there, but I think everyone was following my lead in the blue skin, so it wasnt used for much even in other skins. Thats said, even having the buttons and couple of text styles was a big jump forward from when baseskin.xml didnt exist.

I'm going to define a few more things in there for the next release (some standard colours, fonts etc), and adjust the blue skin to use these extra things, which will hopefully encourage its use a bit more.

[Old Dog]

Not much right now. (SelectedButtonImage, NormalButtonImage, PopupNormalButtonImage and PopupSelectedButtonImage composite images and Default, ButtonText and ScreenName textstyles.)

I listed everything that currently is in baseskin.xml

I would wait to see how baseskin.xml changes comming up will effect it.

That pretty much goes for any plugin right now. (I have looked at them lately for some reason... )

From a plug-in developer's perspective, what is the correct mechanism for using BaseSkin.xml. Should the plug-in read and process BaseSkin.xml? Is BaseSkin.xml transparent to the plug-in, somehow hidden by other system calls that first check skin.xml then fallback to baseskin.sml? Something else?

Thanks,
Old Dog

[sub]

Is BaseSkin.xml transparent to the plug-in, somehow hidden by other system calls that first check skin.xml then fallback to baseskin.xml?

yes.

[psycik]

using the baseskin more would certainly help in making wholesale changes to fonts sizes etc - something I have done on my MVP skin since it's on a 14" tv, I can't remember the number of places i had to change it with our "current system'

You do realize that if you had this, users would soon start asking about why changes to baseskin.xml or any image files used are not automatically detected. It all gets pretty messy pretty quickly.

Hmm, didn't think of that - was trying to spare you having to write something guess it'll have to be something that you add to iMenuTask - a skinupdated callback/event.

[reven]

sub if i try select a node,

sk.getNode(".....");

that isnt in the actual skin, but in the "base" skin will it get that node from the base skin automatically? (im in the process of updating all my code to the new skin helper constructor)