[Fergus]

I was planning to produce a simple patch to control the speed of Automatic Scrolling of Plot/Review text. My preferred skin (PM3.HD) has an option to enable/disable auto-scrolling, but I found myself having to edit the autoscroll values in ViewsVideoLibrary.xmlwhen I wanted to slow down the scrolling speed.

I though that a SpinControlEx to replace the existing RadioButton on custom_SkinSetting_1111.xml would be a good way of extending the current "On, Off" capability to something like "Off, Slow, Medium, Fast".

If nobody wanted to accept this functionality into XBMC, then what the hell; at least I'd learn something and gain some personal satisfaction from the exercise.

At first, I thought I'd nothing more to do than tinker with custom_SkinSetting_1111.xml and ViewsVideoLibrary.xml to make my change, but further reading suggested that SpinControlEx cannot be populated or interrogated without making changes to both the skin and the source. Although this is slightly more complex than this rusty developer had anticipated, I thought I could give it a go in any case, and looked to the code that controls the "Auto Resume" function in GUIWindowSettingsCategory.cpp for inspiration.

Having got this far through the thought process, I now have a fundamental question;

If I successfully replaced the RadioButton with a SpinControlEx in custom_SkinSetting_1111.xml and GUIWindowSettingsCategory.cpp (and managed to actually make use of it's set value in ViewsVideoLibrary.xml) would I have produced a patch that effectively breaks every other skin?

Although PM3.HD and Project Mayhem III and the only two current official skins in SVN, I'm assuming that any new feature which breaks existing Skins would be considered a bad thing. Can anyone confirm if my fears around this proposed patch are indeed valid?

Many thanks in advance,

Fergus.

PS - If it's not already apparent, I haven't undertaken any real programming for years (Project Manager to trade these days) and intended to tackle this by copying and modifying existing fragments of code without necessarilly understanding the ins and outs of each line. It's for this reason that I fear that the need for widespread/complex code changes may be beyond me.

[jmarshall]

1. Skin settings don't use GUIWindowSettingsCategory.cpp, so altering that will do nothing.

2. You'd have to add support to the controls directly. Thus, you'd have to have some option for specifying the labels for the spincontrolex and for ensuring that the results go into the skin variable (a skin string is your only option here).

3. You'd have to then add support where it's doing the scrolling using a stringcompare to test against said string.

To be honest, I'd prefer to move skin settings to something more akin to the way plugin and scraper settings work, though that is currently fixed to using a dialog, which may not be what skinners want exactly. If both XBMC's guisettings and the plugin settings were standardized, however, this likely wouldn't be as much of an issue.

Currently all skins have to generate their own skin settings pages, which is insane.

Cheers,
Jonathan

[Fergus]

Thanks for the response Jonathon - appreciate you taking the timeout to respond.

Sounds like I'd need to bite off way more than I'm capable of to do this properly, so I'll simply tinker with hardcoded autoscroll values in PM3.HD untill I find a speed that I consider 'just right' for me. I'll then create a fresh post (in Skins or Feature Requests) to see if the wider audience wants the skin patched with the revised autoscroll values or if they're all happy with the current speed.

Seeing as I can't tackle your forward-looking statements, do you want me to capture any of your points in Trac as feature request? Happy to do so if it's considered helpful. Happy to butt-out if it's considered a hinderance.

[jmarshall]

Let's move the post into the skinning development forum for now, and see what skinners think about possibilities for simplifying their settings screens.

Cheers,
Jonathan