ui viewport, custom statusbars and backdrops

[JdGordon]

almost cut/paste from the dev ml... I'm fixing the way backdrops are handled by skins (including the sbs) and I've hit a snag. In svn the sbs cant load a backdrop which is fine, the setting then is *always* shown unless the WPS displays its own backdrop. This breaks with plugins which have the backdrop disabled (because most wont work with the users backdrop).
The problem is the menus in those plugins then enable the theme again but they look crap because the backdrop is disabled.

Now, I have 4 options how to deal with this. In all of them the "theme" includes the custom statusbar and the ui viewport and colours, etc. The main time you will see a theme disabled is in plugins.

option 1) "backdrop setting always takes priority, backdrop shown when theme is disable" -- if the .sbs loads a backdrop, and the user specified a backdrop in the settings, the sbs one will be ignored. whichever backdrop is loaded will *always* be displayed unless another skineed screen (WPS) loads its own backdrop.

option 2) "setting takes prioty, no backdrop shown when theme is disabled" -- same as 1) except no backdrop will be displayed when the theme is disabled (plugins, a wps with %wd, etc). This is my prefered option

option 3) "sbs backdrop takes priority, setting backdrop shown if theme is disabled" -- same as 2) except the sbs backdrop will be used even if a setting backdrop has been specified.

option 4) "sbs backdrop takes priority, nothing shown when theme is disabled" -- if the .sbs and setting both want a backdrop BOTH are loaded into RAM, when the theme is enabled the sbs backdrop is shown, when its disabled the setting one is shown, in the WPS the wps one is shown. This will almost certainly not happen because of the extra RAM use needed.

If you choose option 5 and dont leave a comment I'll hunt you down and... well... it wont be pretty....


without wanting to sway the vote too much, option 2 is my prefered, 1 is the next best (but this will mean lots of extra work for plugins).... so vote 2!

[GodEater]

I don't know and don't care

[fml2]

I think that it's wrong to have two sources for the backdrop image. Why not have just one (i.e. allow the backdrop to be set either only via sbs or only in the setting)? Then there will be no confusing for the user, and the implementation will be simpler as well.

[AlexP]

I'm confused just reading the options given.

[fml2]

And my general feeling is that the recently introduced features (custom UI, sbs) have unnecessarily complicated things. Before, nearly 100% of users understood how it works, now, I think, it's 20% at best. May be this is because it's not clearly documented.

[GodEater]

And my general feeling is that the recently introduced features (custom UI, sbs) have unnecessarily complicated things. Before, nearly 100% of users understood how it works, now, I think, it's 20% at best. May be this is because it's not clearly documented.

Heartily agreed.

[JdGordon]

I agree as well, but when I tried to get support for removing the settings I was pretty angrily shot down on the ml, this is the compromise solution. And yes, better documenting how the theme works together is something I've been wanting to do.

edit: well, adding those features didnt complicate thing unnessecarily. they complicated things because people are afraid of removing the simpler options.

[AlexP]

All IMO: 

Themeing has got to the point where it is no longer a mish-mash of different settings (i.e. choose a backdrop, choose a wps etc) - it needs to be a coherent whole.  You download a theme that sets everything up, or you create one.  Everything is controlled from the theme.  The current state is just hugely confusing and unmaintainable.

[JdGordon]

AH bugger... I cant find the mailing list thread, but I agree 100% with Alex but have since given up trying to get rid of the various themeing settings and just made them work.

yes, we have the theme site which means its dead simple for a theme to be just a single .cfg (what it should be), which simplifies things for everyone, except those which don't want anything more fancy (and I accept that view also).

Actually, from a users POV I think the single most confusing thing is how the sbs %Vi user area viewport interacts with the "ui viewport" config setting (which by the way is a .cfg only setting, i.e no UI to change it). it confuses me every time and I know how it works, so how is a user supposed to understand it?

[karashata]

I have to agree that the options as they are discribed are quite confusing... I just need a little more clarification on option 2... Would that mean that a WPS would no longer display its own backdrop if it disables the status bar (say in favour of always displaying the information that may also be displayed in the custom status bar in the rest of the UI)..? Or would it even display its own backdrop at all anymore, instead using whatever backdrop the rest of the UI uses (which I'm assuming would be defined in the theme's config file)..?

[JdGordon]

rereading the options and yeah, I could have made them more confusing if I tried, but not much more :p

The situation is thus:
a theme has a .sbs which specifies a backdrop (s.bmp), a setting which species the backdrop (t.bmp) and a wps which specifies w.bmp.

Option 1) outside of the wps t.bmp will be shown. In the wps w.bmp will always be shown.
Option 2) same as 1 except plugins will have no backdrop (almost the same as svn).
Option 3) same as 1 except s.bmp instead of t.bmp
Option 4) in plugins, t.bmp is shown, in the wps w.bmp is shown, s.bmp is shown anytime the sbs is enabled.

[karashata]

Ah, that helps... I would say option 2 would work fairly well for most people, option 3 though may be a little bit better a fit for those people that make .sbs screens that require elements drawn on the backdrop to look right, and the backdrop would therefore look bad with the .sbs disabled... Kinda like my themes, come to think of it...

[JdGordon]

option 3 takes control away from the user somewhat though. They might not like your backdrop at all and come up with one that does work and looks better. it sounds like option 4 is more what you are after, but thats one I'm pretty confident will not be done ever.

[Llorean]

If they come up with one that they like better (which more or less generally requires the use of the PC unless they're very determined) wouldn't they then just alter the theme to use it, rather than using the setting?

[JdGordon]

they'd go into the file browser and change the backdrop from there, and then wonder why the heck its not taking preference with #3.