Bugzilla – Bug 5992
support new settings UI from EN
Last modified: 2011-11-06 23:24:20 UTC
This will allow the UI to be used by any of the other skins (thus also collecting the work into common code for the settings ui) Offhand, this means the following files need relocation: settings/index.html settings/footer.html settings/header.html settings.css slim-ext.css html/utils.js html/settings.js settings/server/plugin.html html/images/slim-ext/* (that or dummy replacements?) the catch is that there is a conflict with html/settings.js, so this would mean having to rename one (settings-ext.js perhaps), or it forces all skins to use the new UI. the latter isn't perhaps so nice for handheld, touch or nokia770. renaming is probably the nicest way since it only affects on skin right now. html/images/background* images might also be nice to move so that there is a default look that works. it also gives a base set for skin authors to use as a guide for required images when making a new skin.
Could you explain a little more what the idea behind this is? Do you just want to have a popup for the settings as in Default? There's not much new in the Default's settings. It's rather that we don't use static links any more, but added some eye candy in the form of tabs...
There is actually a lot new, in that player and server settings are combined within the same tabbed interface, certain tabs give more exposure to certain settings, advanced tab hides higher level functions. Describing the process to new users will require knowing which skin then describing specific steps. of course, there is always the option of simply hardcoding the default settings link (which I may do for fishbone just to simplify dealing with the ui states)
> player and server settings are combined within the same tabbed interface Not necessarily better, just different. All it really accomplishes is fewer links at the top level. I like the current approach used in EN/Classic better, as I can get to a specific player's settings much easier than in the new skin. > advanced tab hides higher level functions. If it's been decided that this is better for users, then it would be good to propogate the same approach to EN/Classic. Also, for the same reason as the next point. > Describing the process to new users will require knowing which skin > then describing specific steps. Very good point. The specific tabs/pages need to have the same names and the same sets of setttings if you want to keep things sane from a support perspective. If Settings are to be completely "reorganized" then they need to be reorganized in all skins. I would hope that several things can be kept the same in the old skins: 1. Navigation via drop-down menu. 2. Settings pages continue to open in the browse pane, instead of a new window. 3. Visually, the layout remains the same. With headers, description, form fields below. Obviously, you can't use the same layout being used in the new skin and fit it in the browse window. One other point that I mentioned long ago in the forums, which may work itself out if the above is implemented: It would be better to have the individual plugin pages accessible from a single 'Extras' page, as in the new skin. The drop-down box for navigating Server Settings under the Classic skin has become way too big.
settings/index.html is the main page to keep all this together. The main issue I'm seeing is all that fancy JS stuff which is mainly eye candy. But we could come up with a simpler version, with the tabs as simple links, no hiding of lengthy descriptions etc. This would work with most skins without too much hassle.
Created attachment 2429 [details] rough conversion of Default's settings framework for "old" skins
I tested the patch, and made some local mods. However, I didn't get time to post it while I was still at work. working on a newer and better version.
Created attachment 2430 [details] updated patch a few fixes, styles for all frames, player chooser in the player settings, working player setting links.
Created attachment 2431 [details] updated patch pt 2 missed a slight change to setting_chooser in that last one. this allows the target to be set to the settings frame so that we maintain the top frame menu. still needs some settings_* based css work to make it all look like it is supposed to be like this.
Michael: do we want to do this for 7.0?
Yes, I'll try to get it in. But low priority.
There are no longer nested framesets created by index.html. Though implementing this change should now be easier it won't make it into 7.0.
I'll give it another try... targeting so it doesn't fall off the radar
Don't know whether this is ever going to happen, I'm sorry.
Unassigned bugs cannot have a priority.