Suggestions for revamping Options Screen

[MestreLion]

I was adding some #TODO for code/screens/options.py, the list got too long, so maybe it's better to share here and ask for feedback:

Here I'm also adding some remarks for each suggestion...

#TODO: Create and use a global resolution list so buttons can be dynamic
current code for that is *ugly*

#TODO: Change available resolutions. Drop 640x480, add widescreen ones. It's 2012!
What would be your list? There are 4 buttons + default custom. My suggestion:
- 1024x600 (for old netbooks)
- 1024x768 (the universal one... classics never die)
- 1280x720 (HD, for TVs and low-end laptops and netbooks)
- 1366x768 (a must nowadays, THE most commonly used worldwide)
- 1920x1080 (E:S in full-hd! :)

Maybe CUSTOM should always be set to current game resolution. We would miss the 5th "option", but read below...

If we can somehow read read user's current screen resolution, we could provide different choices depending if user is 4:3 or 16:9.  That's 4x2=8 predefined resolutions, more than enough to anyone's tastes. Reading current screen, if possible, would also open many possibilities: Dialog could be smarter too, preventing setting a higher res than screen (or at least warning about risks). It could also fallback to a safe default if data in prefs file is higher than current screen (if, say, user copy his prefs dir from full-hd desktop to his tiny netbook). A "force res" option in prefs would disable such warnings.

#TODO: Consider default to Fullscreen, using user's current screen resolution
This is closely related to available resolutions. A 1024x768 window in a 1024x768 screen is cropped due to window title bar, user top/bottom panels, etc. This holds true for *any* resolution.



#TODO: Why text in resolutions buttons is so tiny?

#TODO: Show a 2-or-so-seconds "Please wait" dialog when changing sound options
#      (both Enable/Disable and Sound Buffering ones), because huge lag when
#      applying them might confuse users in clicking them several times

#TODO: Integrate "Save Options to Disk" functionality in OK button. There is
#      little point for a user not to save preferences automatically, and most
#      will be confused when settings are not applied on next run

#TODO: Add dialog suggesting restart when language changes, so changes may apply
#      at least until/if we find a way refresh all screens. Don't forget to
#      remind user to save current game (if loaded from map menu)

I already have a functional code for clean restart in testing/restart branch. Works perfectly

#TODO: Is it really needed to have Sound Buffering options? Or Grab Mouse? Why
#      would a regular user want to tinker with that? Could be command-line only

#TODO: There is Enable/Disable Sound. Maybe add Music too?

... and Happy Easter everyone!
ML

[Phil Bordelon]

On 04/08/2012 07:29 PM, MestreLion wrote:
> I was adding some #TODO for code/screens/options.py, the list got too long,
> so maybe it's better to share here and ask for feedback:
>
> Here I'm also adding some remarks for each suggestion...
>
> #TODO: Create and use a global resolution list so buttons can be dynamic
> current code for that is *ugly*
>
> #TODO: Change available resolutions. Drop 640x480, add widescreen ones. It's
> 2012!
> What would be your list? There are 4 buttons + default custom. My suggestion:
> - 1024x600 (for old netbooks)
> - 1024x768 (the universal one... classics never die)
> - 1280x720 (HD, for TVs and low-end laptops and netbooks)
> - 1366x768 (a must nowadays, THE most commonly used worldwide)
> - 1920x1080 (E:S in full-hd! :)

I had to Google for 1366 to see what the heck that was.

Anyway, yes, that seems like a reasonable set of defaults, although I'd
leave 800x600 as well. E:S runs quite well on older computers, and there's
no reason to /completely/ stiff them. For the time being, at least.

> Maybe CUSTOM should always be set to current game resolution. We would miss
> the 5th "option", but read below...
>
> If we can somehow read read user's current screen resolution, we could
> provide different choices depending if user is 4:3 or 16:9. That's 4x2=8
> predefined resolutions, more than enough to anyone's tastes. Reading current
> screen, if possible, would also open many possibilities: Dialog could be
> smarter too, preventing setting a higher res than screen (or at least
> warning about risks). It could also fallback to a safe default if data in
> prefs file is higher than current screen (if, say, user copy his prefs dir
> from full-hd desktop to his tiny netbook). A "force res" option in prefs
> would disable such warnings.

No comment on this at the moment; doing this cross-platform may be decidedly
non-trivial.

> #TODO: Why text in resolutions buttons is so tiny?

I'm sure that's a bug.

> #TODO: Show a 2-or-so-seconds "Please wait" dialog when changing sound options
> # (both Enable/Disable and Sound Buffering ones), because huge lag when
> # applying them might confuse users in clicking them several times

Not a bad idea, although I wouldn't sling too much code at it.

> #TODO: Integrate "Save Options to Disk" functionality in OK button. There is
> # little point for a user not to save preferences automatically, and most
> # will be confused when settings are not applied on next run

Agreed.

> #TODO: Add dialog suggesting restart when language changes, so changes may apply
> # at least until/if we find a way refresh all screens. Don't forget to
> # remind user to save current game (if loaded from map menu)

Also agreed.

> I already have a functional code for clean restart in testing/restart
> branch. Works perfectly
>
> #TODO: Is it really needed to have Sound Buffering options? Or Grab Mouse? Why
> # would a regular user want to tinker with that? Could be command-line only

This is the sort of crap that should be hidden behind an 'Advanced' tab or
the like. Most users would never want to tinker with it, but E:S has run
on a wide variety of hardware over the years, and some of it required
tinkering. Grab Mouse is such a religious Linux thing that I am very
leery of getting rid of it.

> #TODO: There is Enable/Disable Sound. Maybe add Music too?

Good idea.

> ... and Happy Easter everyone!
> ML

P

[evilmrhenry]

>> Maybe CUSTOM should always be set to current game resolution. We would
>> miss
>> the 5th "option", but read below...
>>
>> If we can somehow read read user's current screen resolution, we could
>> provide different choices depending if user is 4:3 or 16:9. That's 4x2=8
>> predefined resolutions, more than enough to anyone's tastes. Reading
>> current
>> screen, if possible, would also open many possibilities: Dialog could be
>> smarter too, preventing setting a higher res than screen (or at least
>> warning about risks). It could also fallback to a safe default if data in
>> prefs file is higher than current screen (if, say, user copy his prefs
>> dir
>> from full-hd desktop to his tiny netbook). A "force res" option in prefs
>> would disable such warnings.
>
> No comment on this at the moment; doing this cross-platform may be
> decidedly
> non-trivial.

pygame.display.Info(), if called before setting a video mode, should
return the desktop resolution.

pygame.display.list_modes() is supposed to show all supported fullscreen
modes.

Doing this cross-platform will likely involve checking for weird values
and dropping back to defaults, but I don't know which platforms it will
fail on, and what to check for.

[Phil Bordelon]

On 04/09/2012 01:17 AM, evilmrhenry wrote:

> pygame.display.Info(), if called before setting a video mode, should return
> the desktop resolution.
>
> pygame.display.list_modes() is supposed to show all supported fullscreen modes.
>
> Doing this cross-platform will likely involve checking for weird values and
> dropping back to defaults, but I don't know which platforms it will fail on,
> and what to check for.

Nice. I like it when things are easier. (I didn't look up how to do it in
Pygame last night.) I think we can go ahead with implementing this and then
seeing where it breaks :)

P

[MestreLion]

> #TODO: Change available resolutions. Drop 640x480, add widescreen ones. It's
> 2012!
> What would be your list? There are 4 buttons + default custom. My suggestion:
> - 1024x600 (for old netbooks)
> - 1024x768 (the universal one... classics never die)
> - 1280x720 (HD, for TVs and low-end laptops and netbooks)
> - 1366x768 (a must nowadays, THE most commonly used worldwide)
> - 1920x1080 (E:S in full-hd! :)

I had to Google for 1366 to see what the heck that was.

It's, according to *all* statistics websites I've googled (and "wikipedia'ed"), *THE* most used desktop resolution in the world.

It got a *massive* usage increase in the last 2 years, recently surpassing the king of the decade 1024. And it's still rising...

This blog compiles a nice list of statistics websites, roughly the same I researched:
http://www.impressivewebs.com/browser-usage-stats/

And the statistics are...

http://gs.statcounter.com/#resolution-ww-monthly-200903-201203
http://gs.statcounter.com/#resolution-ww-monthly-201202-201204-bar
(amazing timeline, so we can see not only current values but more importantly, *trends*)

http://www.w3counter.com/globalstats.php
(current data)

http://www.statowl.com/screen_resolution.php?timeframe=last_3&interval=month&chart_id=6&fltr_os=Linux
(one of the few that allows filters. I've filtered results to Linux system)

http://www.w3schools.com/browsers/browsers_display.asp
(bad source for learning, but a good 10-yr stats page)

http://www.superiorwebsys.com/blog/93/Most_Common_Screen_Resolutions_in_2011/
(also show trends from last 3 years)

Differences apart, we can see they all share some basic consensus:
- 8 (or 9) of the top 10 are widescreen
- 1024x768 is still in top 3 (or even top 1), but rapidly dropping
- 1366x768 is always in top 3, rising fast, some say now it's #1
- 1280x800 is surprinsingly (for me) always in top 3
-  800x600 is not even in the top 10. For the few sites that report it, its < 1%
- I was wrong about 1280x720. Looks like HD is not popular in PCs
 

Anyway, yes, that seems like a reasonable set of defaults, although I'd
leave 800x600 as well.  E:S runs quite well on older computers, and there's
no reason to /completely/ stiff them.  For the time being, at least.

With current defaults (not fullscreen, not based on user's desktop), sure, I agree. But if we either go fullscreen by default or find a way to use user's desktop resolution, I say stiff it.

Also, I still miss you opinion about if we should default to fullscreen or not. Windowed mode really decreases real-estate, since we need to subtract for panels, title bar, etc. As I said, a X,Y windows won't fit a X,Y desktop. But it works fine in fullscreen
 

> If we can somehow read read user's current screen resolution, we could
> provide different choices depending if user is 4:3 or 16:9. That's 4x2=8
> predefined resolutions, more than enough to anyone's tastes. Reading current
> screen, if possible, would also open many possibilities: Dialog could be
> smarter too, preventing setting a higher res than screen (or at least
> warning about risks). It could also fallback to a safe default if data in
> prefs file is higher than current screen (if, say, user copy his prefs dir
> from full-hd desktop to his tiny netbook). A "force res" option in prefs
> would disable such warnings.

No comment on this at the moment; doing this cross-platform may be decidedly
non-trivial.

Isn't pygame cross-plataform? It either can read user's desktop or it can't. But I'll research a bit on how cross-plataform and reliable this particular info, if available, is.
 

> #TODO: Is it really needed to have Sound Buffering options? Or Grab Mouse? Why

> # would a regular user want to tinker with that? Could be command-line only

This is the sort of crap that should be hidden behind an 'Advanced' tab or
the like.  Most users would never want to tinker with it, but E:S has run
on a wide variety of hardware over the years, and some of it required
tinkering.  Grab Mouse is such a religious Linux thing that I am very
leery of getting rid of it.

But do you agree on letting those as command-line only? I promise I'll try to bring them back ASAP with an "Advanced Options" sub-screen. But for now, we need more real-state for resolutions, music, and some other surprises I have in my sleeve ;)
 

[MestreLion]

First, I'm so glad to see you back, Mr Evil Henry :D

Ok, maybe not *back*, but it's good to see your feedback :)

That said... *amazing* info on pygame/resolutions. That surely opens a world of possibilities (default to fullscreen anyone? ;)

As for the other stuff, wha'ts your opinion?

[Phil Bordelon]

On 04/11/2012 09:24 PM, MestreLion wrote:

> Also, I still miss you opinion about if we should default to fullscreen or
> not. Windowed mode really decreases real-estate, since we need to subtract
> for panels, title bar, etc. As I said, a X,Y windows won't fit a X,Y
> desktop. But it works fine in fullscreen

This is a tough call. For the vast majority of games, I think fullscreen
is the best default. But E:S is one of the rare games that really works
well as a windowed application; you can set it to the slowest time and go
do work or whatever, then jump back to the game and speed it back up. Not
many games fit this model, and I think it's not a bad idea to keep featuring
it.

Which may mean that we want to set default resolutions to /smaller/ than
standard, so that things like titlebars and the like have room. I'm not
sure, though, and would like more opinions on the matter.

> But do you agree on letting those as command-line only? I promise I'll try
> to bring them back ASAP with an "Advanced Options" sub-screen. But for now,
> we need more real-state for resolutions, music, and some other surprises I
> have in my sleeve ;)

Leave Grab Mouse; move the more complicated crap to the command-line.

P

[MestreLion]

On Wednesday, April 11, 2012 11:37:31 PM UTC-3, Phil Bordelon wrote:

On 04/11/2012 09:24 PM, MestreLion wrote:

> Also, I still miss you opinion about if we should default to fullscreen or
> not. Windowed mode really decreases real-estate, since we need to subtract
> for panels, title bar, etc. As I said, a X,Y windows won't fit a X,Y
> desktop. But it works fine in fullscreen

This is a tough call.  For the vast majority of games, I think fullscreen
is the best default.  But E:S is one of the rare games that really works
well as a windowed application; you can set it to the slowest time and go
do work or whatever, then jump back to the game and speed it back up.  Not
many games fit this model, and I think it's not a bad idea to keep featuring
it.

Yeah, tough call indeed. And true, E:S works well as a window. But, I didn't suggest to /remove/ that feature. Just change the /default/ from windowed to fullscreen.

Which may mean that we want to set default resolutions to /smaller/ than
standard, so that things like titlebars and the like have room.

... and that's precisely why the move from a default window to fullscreen is so important.

Two major benefits from this would be:
1 - Allow us to bump the default resolution a bit (to either 1024x768, 1024x600, or 1280x720, all still very conservative and safe)
2 - Allow the user to actually choose a resolution that matches his screen, instead of either picking a lower one (or typing a custom one) to account for panels and title bars

 I'm not sure, though, and would like more opinions on the matter.

So do I... sometimes this dev mailing list looks like a private chat between you and me :P

Fullscreen, default resolutions, all are tough calls where more input would be highly appreciated..

Last but not least.... I know I may sound obsessive (and maybe annoying) about bumping resolution. But the reason is: many labels in E:S are /very/ tiny. And when we add true i18n, it gets /much/ worse. English is a very concise language, labels and titles require very few words and letters. Now try basically /any/ of the available translations: most labels are either larger than the button (dumping nasty error messages in console), or the font auto-resize feature makes them so tiny it's impossible to read. Try the pt_BR pack and open Knowledge screen. Good luck reading some tech and item names :P

Hence, screen state is crucial, specially width. Most  buttons were sized to accommodate en_US, with very little (if any) room for more letters required by other languages. We need wider buttons, and a wider screen so text is actually readable.
 

Leave Grab Mouse; move the more complicated crap to the command-line.

P

Take a look at testing/option branch. Still in early stages, but already worth checking if I'm in the right direction...

ML

[MestreLion]

The new revamped options screen is ready to merge.

tt was included as a single commit inside the public/i18n branch
(which is also ready to merge too, more on that in my other email.)

I am *very* excited about this new screen.. hope you like it!

A little teaser from the commit message:

Major changes:
- add more resolutions, including widescreen ones
- drop sound buffer options
- display language names instead of locale codes

Sound buffer size can still be set via command-line options, and it will
still be saved to preferences file if user enter option screen and
save prefereces to disk

Resolution buttons' font is also a bit larger. Apply button was dropped

There is now a list of available resolutions in code.graphics.g, as well
as a default_screen_size, so both no longer need to be hardcoded. Options
screen and command-line options were adjusted to make use of them

Language names in the available languages selection list are presented
in native language, if possible, or in English. Names are read from
the data/languages.dat pickle file created by tools/languages.py

ML

[Phil Bordelon]

On 05/05/2012 05:06 AM, MestreLion wrote:

> Language names in the available languages selection list are presented
> in native language, if possible, or in English. Names are read from
> the data/languages.dat pickle file created by tools/languages.py

Everything else you mentioned is fine, but this seems a bit "magic."
Whose responsibility is it to rebuild this data file, for example?
Why can't it just be a flat text file like basically everything else?
I mean, we're showing a native language's name in its own name; that's
not a whole lot of entries.

Also, how would one pick between (say) pt_BR and pt_PT now? I only see
one entry.

This isn't enough of a problem to keep me from merging the (otherwise
fantastic) set of changes you've done, so you'll be seeing a large
merge commit very soon. But I'm curious as to these two things and
how you think we could best address them.

P

[MestreLion]

You gonna love the answers...

On Sunday, May 6, 2012 1:36:34 AM UTC-3, Phil Bordelon wrote:

On 05/05/2012 05:06 AM, MestreLion wrote:

> Language names in the available languages selection list are presented
> in native language, if possible, or in English. Names are read from
> the data/languages.dat pickle file created by tools/languages.py

Everything else you mentioned is fine, but this seems a bit "magic."
Whose responsibility is it to rebuild this data file, for example?

No need to rebuild, there are 292 entries there already. But, if you want to rebuid, just run utils/languages.py. It will search for language names using PyICU, babel, /and the *.po  files/
 

Why can't it just be a flat text file like basically everything else?

No important reason, just size. It can perfectly be a code/languages.py file with a single languages = { ... } dict. Actuallty, that's /exactly/ what Locale.dumpPythonCode() method is for.

But anyone can customize the language name without messing with the binary data. The values from the PO files headers take precedence, and the PO files are plain text files.
 

I mean, we're showing a native language's name in its own name; that's
not a whole lot of entries.

There's 292 entries actually. Taken from ICU.
 

Also, how would one pick between (say) pt_BR and pt_PT now?  I only see
one entry.

Because there is no pt_PT translation, only pt_BR.

If it had both, Options Screen is smart enough to show both, like "Português (Portugal)" and "Português (Brasil)"

It is also smart enough to notice that, since currently there's a single pt_XX translation available, to call it simply "Português"

This isn't enough of a problem to keep me from merging the (otherwise
fantastic) set of changes you've done, so you'll be seeing a large
merge commit very soon.  But I'm curious as to these two things and
how you think we could best address them.

P

You raised valid points, and they are all already addressed in current code... I hope in a good way for you.

Here is the workflow:

For new translaions:
- You use utils/gettext-singularity to create a new translation file, let's say --new en_GB
- It asks you the native name of the language at creation time. so you can say "British English" instead of the current "English (United Kingdom)" default (from ICU)

For existing translations:
- You open data/messages_en_GB.po (which is a plain text file), and you edit its headers "Language-Name" or "Language-Native-Name" to whatever you want

For both, you run utils/languages.py , which will scan the PO files headers and update the data/languages.dat entries.

If you don't do any of this, it's fine... E:S now comes bundled with 292 default entries. That's why you see "Swenka" for sv_SV" even when I didn't touch any of the swedish translation files.

[Phil Bordelon]

On 05/06/2012 12:31 AM, MestreLion wrote:
> You gonna love the answers...

Okay. The answers /are/ good, actually, but I'm still a little leery of
carting around a pickle file rather than just a flat text one. 292 entries
is just not that big of a text file, and I think it's worth the "extra"
overhead to not have a binary file. Particularly since every other .dat
in that directory is flat text.

Having it as a python dict rather than in the current config file format is
perfectly fine, by the way; that's still editable text.

Would you be willing (after you give me your information so I can add you to
the committers--I don't see one in my mailbox, at least) to change it so
that it's either a Python dict or a "standard" config file?

P

[Mestre Lion]

As promised, I've posted a patch that handles a text data/languages.dat (using json instead of cPickle)

As expected, file had a 20% increase in size, and it's now the largest data file (not counting Attribution-ShareAlike 3.0.html, of course)

Other than that, it works perfectly, and it was quite a small code change from cPickle to JSON. It can be tweaked further to use a ConfigParser format instead of JSON, although size increase will be substantial (I estimate a 52% increase). The size breakdown is as follows:

18.4K (cPickle, current)
22.4K (JSON, in patch)
33.5K (Config, estimative)

The commit is in my testing/lanaguagedata branch at github. Take a look (but don't merge yet) and tell me what you think...

But, size considerations apart, I wonder: /why/ would anyone want to edit /that/ file? The only sane reason would be to edit the language name of a /currently existing/ translation, like pt_BR or fr_FR. And for that, he/she could simply edit the corresponding .PO file instead and run tools/languages.py  to scan the PO headers and update the languages.dat file. It is /much/ simpler than directly editing a file with 292 entries.

Try this:
- open data/messages_pt_BR.po
- find "Language-Native-Name:" and replace "Português Brasileiro" for "MestreLion's Lang"
- run utils/languages.py
- run the game, open Options screen, enjoy the result! ;)

So, IMHO, there is little point in directly editing data/languages.dat. So we can save space and go cPickle (or JSON). But It's your call.

ML

[Phil Bordelon]

On 05/11/2012 07:58 AM, Mestre Lion wrote:

> The commit is in my testing/lanaguagedata branch at github. Take a look (but
> don't merge yet) and tell me what you think...

Looks fine. This is much better, because the size gain isn't that much
(20%? Who cares?), and now the file is text that someone could potentially
edit by hand. I'm not saying they will, I'm not saying they /should, I'm
saying they /can/. And it returns everything in that directory to being a
text file that can be edited.

json was added in Python 2.6, but we already require a Python that new, so
that's not a problem.

Excellent. Push it up :)

P

[Mestre Lion]

On Friday, May 11, 2012 10:30:52 AM UTC-3, Phil Bordelon wrote:

On 05/11/2012 07:58 AM, Mestre Lion wrote:

> The commit is in my testing/lanaguagedata branch at github. Take a look (but
> don't merge yet) and tell me what you think...

Looks fine.  This is much better, because the size gain isn't that much
(20%?  Who cares?), and now the file is text that someone could potentially
edit by hand.

Ok, we are talking mere kilobytes here, but still, it is currently the largest .dat file. I was trying to lay low by not bringing too much "attention" to a file that has such a limited usage.
 

 I'm not saying they will, I'm not saying they /should, I'm
saying they /can/. And it returns everything in that directory to being a
text file that can be edited.

Ok, I agree with with you. Now they can, but they shoudn't, and I hope they wont ;)

PO files' headers and utils/languages.py is the right tool for that
 

 json was added in Python 2.6, but we already require a Python that new, so
that's not a problem.

Hum, good point... I didn't realize I was adding one more item to the "why we /need/ 2.6 now" list. I try to avoid those whenever I can. My relief is that all currently-supported distro releases are already at 2.7. My now-ancient Mint 10 Julia (Ubuntu Maverick 10.10) is probably the last shipping 2.6, and it was EOL'ed this month.
 

Excellent.  Push it up :)

Pushed :)

ML

PS: Should I pursue a ConfigParser solution, or let it this way?

[Phil Bordelon]

On 05/12/2012 12:08 AM, Mestre Lion wrote:

> PS: Should I pursue a ConfigParser solution, or let it this way?

Leave it be. json is fine for this. It's obscure and no one /should/
be hand-editing it, as you said. I just wanted the ability to be there.

P