[Ned Scott]

Original discussion: https://github.com/xbmc/xbmc/pull/5428

This discussion started out on github regarding a pull request that seemed to be dismissed simply because it added GUI settings (although another reason to not accept it is that another PR might allow the same feature in a more flexible way). Since this is a topic of much debate and we don't want to flood github comments with it, and because I've wanted to start this discussion for a while now, I'm opening this forum thread for discussion about when we should have settings in the GUI vs advancedsettings.xml.

I'd like to hear both what Team Kodi thinks about this as well as devs and users outside the Team, but please no "me too" type posts (translation, we're looking for actual discussion rather than a poll).

EDIT: rejected/dismissed

[Ned Scott]

Here's a little recap of the github discussion for those too lazy to open a new browser tab ;)


okalinsk opens a PR titled "Move time seek settings from advanced settings to standard user settings" with no description. What follows are comments for this PR.

I don't think we want to open pandoras box and add each of the seek sizes to the GUI. #5407 is the way to go IMO while keeping the "old" seek sizes in as.xml

nope to adding it to gui

Hi @da-anda and @MartijnKaijser,
Thanks for your input.

da-anda, I reviewed #5407 and it looks sound, but might be too complex for GUI. Hope you guys could pull it off and still keep it user friendly.

Martin, seek time can be controlled in GUI in most of the players out there. Could you share why do you think it shouldn't be added to the GUI in XBMC?

Thanks in advance,
Oren.

I don't mean to start a debate, and I'll probably post this on the forum for further discussion, but I want @okalinsk to see this comment as well.

Regarding settings in general: We have different settings levels now. There's no reason to not add these kinds of things, no matter how advanced or cluttered they might be, to the GUI. Even if it means we make a specific page for all advanced settings and set it to "expert" (level 3, I think), with big fat warnings about how each setting will burn people's house down. (Not saying we should do that, but I don't see a strong argument for preventing it, either).

Normal users won't see clutter or confusing settings. It's one of the greatest benefits we have now with multiple settings levels, so we should consider using it for safe-but-specific settings.

Going forward, the only thing that advancedsettings.xml should be used for is for anything "experimental" or "dangerous", like MySQL or something that could really break a setup.

BUT

That being said, even if I agreed that most advancedsettings should stay in advancedsettings.xml, these specific settings are used a lot and are very common in just about any other video player. I have made only a handful of how-to guides on our wiki about advancedsettings.xml, and one of the most popular ones is specifically about these settings. I'd be willing to bet that the only thing stopping more users from wanting to change these settings is probably because they don't know the option exists at all, so they assume it can't be done.

if #5407 can be done then even better, but in the event that that can't be added, this deserves consideration, regardless of how we view most advancedsettings.

Without saying anything about this particular setting I must say that comparing us to any other player is a bad idea. Not every other player are designed with a 10 foot interface in mind.

Also the settings levels are more about there complexity, how advanced they are rather than to tweak every little small thing.

Also, every tweak means a dynamic input and each input makes the applications complexity go up. Which means more bugs for every user, not only the 0.1% that wanted that specific feature.

[Ned Scott]

and to resume the discussion:


Don't get me wrong, I'm someone who's happy with the defaults, and in most cases I wouldn't even bring this up. However, this specific setting is literally something I have listed in a text document called "things I think should be GUI settings", based on the feedback I've seen from other users and various other considerations. It's a topic I've thought a lot about (probably too much, lol).

I wouldn't normally compare us to other players in most situations, but here the changing of time seeks doesn't impact the control (a remote) or the interface/GUI at 10 feet. The fact that it's also something that our own users ask for (because they don't know it's possible, or are unsure where the setting might be) tells me it's something that is a bit universal to both the 10 foot UI and the 2 foot UI.

As for what the settings levels are for, I think it's a fine line between "simple-yet-small" tweaks, and complex features. Much in the same way we use advancedsettings.xml for both types, I think it wouldn't be that odd to use level 3 (expert) settings for both, even if it wasn't a fine line. Even for my parents who've used XBMC before, and who would understand many of our "standard" level settings, I think they would describe a setting like this as "advanced" and wouldn't understand it without some explaining ;)

This isn't a case of adding any features. These are existing features that are currently handled by editing an XML file. If making them GUI settings instead of settings in an XML file means additional bugs, then I can understand that, but I'm not sure if that's the case here?


Phew. I honestly didn't mean to write that much, but like I said, I've been thinking about this topic for a while :D

Debate, discuss, have fun, etc :)

[Koying]

Tricky debate, indeed
This is about finding a good balance between ease-of-use and not flooding the users with options.

We now have the "settings level" feature, which would avoid the flood to lambda users. After the settings rework from Montellese, I tend to think it is not more complex to add a gui setting than an advanced one, as they are practically handled the same.

So my vote would go to GUI for settings which actually make sense to an average user, which is the case in this instance.

[Montellese]

IMO there are a few advanced settings that could/should be moved to settings visible in the GUI (in whatever level) like "videolibrary.cleanonupdate" or "videolibrary.hideallitems" and a few others.

GUI settings have several advantages over advanced settings:

• They can be found without leaving Kodi. That might lessen the amount of users requesting something that is already possible but hidden away in advancedsettings.xml
  
• We can provide a (more or less) good label and description about the setting and what it does.
  

IMO advanced settings should mainly be used for experimental stuff and setting values that are very hard to handle in a 10 foot interface e.g. whole structures or a list of file extensions.

Personally I think that the argument of "this might introduce a bug" is invalid for settings that are already there as advancedsettings.

[wsnipex]

I've always been fond of makeing useful settings available without hassle, so +1 to make this a GUI setting in advanced or expert level.

[FernetMenta]

Many devs are tempted to add their desired functionality as quick and simple as possible. Quite often settings are abused. I think nobody needs
https://github.com/xbmc/xbmc/pull/5428 if we have additive seeking:
https://github.com/xbmc/xbmc/pull/5407

[Martijn]

Many devs are tempted to add their desired functionality as quick and simple as possible. Quite often settings are abused. I think nobody needs
https://github.com/xbmc/xbmc/pull/5428 if we have additive seeking:
https://github.com/xbmc/xbmc/pull/5407

This is indeed something agree with.
Another example is: PR4342
First intention was to add extra settings for PVR, later in the PR it changed to a change in the API which made the settings obsolete.

First see if there's a way to make it more intuitive to use and perhaps make bigger changes to make settings unneeded. If after consideration they are still wanted no one will complain about it. Useful settings indeed need to be in GUI (i know some for myself i always set on by default in as.xml which could easily belong in GUI)

[da-anda]

I'm also not against adding the seek step size to the GUI settings in general, but I think it doesn't make sense anymore at this point when having a replacement (additive seeking) in the pipeline which most likely will replace/remove this. We'd add the GUI setting only for Helix and already drop it probably a few weeks later in master, but then we also would have to write a migration script - and this just doesn't make sense to me.

In general I'm all for moving as.xml settings to GUI settings, but only if they make sense there (we can't just stuff all in there).

[xhaggi]

I've created a new PR which adds additive/smart seek support. With this you can configure seek steps in the GUI settings.

see https://github.com/xbmc/xbmc/pull/6347

[Dark_Slayer]

Looks like I missed the debate it seems, but I'd love to give a simple-minded-user opinion

1) With settings levels does there need to be restriction? Moving to "expert" seems like a good enough way of saying "know what you are doing" (to me at least)

2) Does there really need to be an intermediate settings level? Your either beginner or expert, nobody is going to learn the difference between three levels, two is a lot better

3) I could make a list of the things already available in GUI settings that I think are less important (WINS server, using proxy to access internet, changing font of subtitles -- don't get me wrong the ability to change what you need is paramount, but having a gui ability to change from a default that works for over 99% does seem pointless --- i.e. those are already there what makes them more justified?)

[Koying]

I pretty much agree on what @Dark_Slayer says

[da-anda]

as for 2 - it's not about experience level but better overview of settings if you tend to change stuff a lot but don't need the hardcore low level expert settings.