Interface theme
9 views
Skip to first unread message
Philippe Tetar
May 7, 2012, 4:25:59 PM5/7/12
to endgame-singularity-dev
Hi,
As suggested, I answer here about my idea to add earth theme to E:S.
I agree earth theme may be a part of a more powerful feature. Like E:S
is a windowed game, it can be easily and heavily customizable. A lot
of thing, as the color of menu or the font. However, E:S haven't (now)
a lot of feature to customize, it's a small game.
That is a test of a roadmap :
- Add one or more theme options.
- Factorize in a class (Theme).
- Add custom theme section in prefs.dat.
- Add a list of different theme in option screen. (first there are
two, default and custom)
- Add the loading of default theme and different options from data/
theme.dat.
- Add many themes
- Add the possibility to add more than one custom theme in prefs.dat.
Of course, we must discuss a lot of thing. All this features isn't
really useful. Have we need to allow more than one custom theme?
Add a complete theme feature need to add a lot of widget in option
screen. So, the new revamp option is needed.
About the earth theme, I need more works, because there are still few
bugs. I agree to set the vector images to default.
As suggested, I answer here about my idea to add earth theme to E:S.
I agree earth theme may be a part of a more powerful feature. Like E:S
is a windowed game, it can be easily and heavily customizable. A lot
of thing, as the color of menu or the font. However, E:S haven't (now)
a lot of feature to customize, it's a small game.
That is a test of a roadmap :
- Add one or more theme options.
- Factorize in a class (Theme).
- Add custom theme section in prefs.dat.
- Add a list of different theme in option screen. (first there are
two, default and custom)
- Add the loading of default theme and different options from data/
theme.dat.
- Add many themes
- Add the possibility to add more than one custom theme in prefs.dat.
Of course, we must discuss a lot of thing. All this features isn't
really useful. Have we need to allow more than one custom theme?
Add a complete theme feature need to add a lot of widget in option
screen. So, the new revamp option is needed.
About the earth theme, I need more works, because there are still few
bugs. I agree to set the vector images to default.
Phil Bordelon
May 7, 2012, 11:42:22 PM5/7/12
to endgame-sin...@googlegroups.com
On 05/07/2012 03:25 PM, Philippe Tetar wrote:
> Hi,
>
> As suggested, I answer here about my idea to add earth theme to E:S.
Welcome, Philippe!
> Hi,
>
> As suggested, I answer here about my idea to add earth theme to E:S.
decide just what direction we want to take with my proposed UI refresh.
A lot of what goes on there is not possible with "simple theming," as it
requires new ways to handle a lot of the data that E:S currently presents.
That said, the ability to use either the current "realistic-Earth" images
or my vector Earth images (and if someone would like to make a better one
of those, I wouldn't mind) is pretty easy, low-hanging fruit. If nothing
else, it could be a command-line option.
Thoughts? Which should be default, the classic theme or the vector one?
P
Mestre Lion
May 10, 2012, 12:57:51 AM5/10/12
to endgame-sin...@googlegroups.com
Welcome Philippe!
On Monday, May 7, 2012 5:25:59 PM UTC-3, Philippe Tetar wrote:
I think for starters we have 2: Default and Vector.
The classic Class + global list/dict of instances approach.
Instances may be created (and appended to a global themes = [] list) in a code/g.py, as in:
def load_themes():
for theme in whatever_data_model_we_use:
themes.append(Theme(foo,bar,etc))
theme = themes[0]
Then g.load_themes() would be called by code/singularity.py at startup
I think prefs.dat should would have an entry of what is the /current/ theme. For example:
theme = vector
I vote for default and vector. There's no "custom" theme, every theme has a name. And user could create more custom themes. More on that below
How about data/themes (for the themes bundled with E:S) and prefs_dir/themes ?
Inside, we would have:
./themes
default/
theme.dat
someimage.png
somefont.ttf
...
vector/
theme.dat
someotherimage.png
anotherfont.ttf
...
...
And the user could replicate this "themes" dir in his own prefs dir, and create as many themes he want. We could pre-create that dir the same way we currently do with music/ (maybe even adding a README.theme like Phil did with music)
So g.load_themes would simply scan both themes/ dir (user and system, but respecting --singledir), read theme,dat from each subdir, and create the themes list. Options screen list would be as easy as:
for theme in themes:
list-or-whatever-ui-it-uses.append(theme.name)
where name of a theme is simply the subdir name. g.load_themes() would also use config parser for each theme.dat
Go for it! :D
But for now, fonts (as in data/strings_xx_XX.dat [fonts]) and earth background image are the only "hanging fruits" that are easily customizable.
My suggestion covers that. No need to edit prefs.dat, except to set the user's current theme
Not really, at least as long as earth image and fonts are the only thing we make "themable". But once the engine is set up, adding new themable options is relatively painless, only require to change all hardcoded entities in code to point to g.theme.myattr
This is how I envision how a powerful yet relatively simple themes engine should work. But, as Phil said, it is still a lot of work for perhaps little gain. If you're motivated for the challenge, great! :D
ML
On Monday, May 7, 2012 5:25:59 PM UTC-3, Philippe Tetar wrote:
Hi,
As suggested, I answer here about my idea to add earth theme to E:S.
I agree earth theme may be a part of a more powerful feature. Like E:S
is a windowed game, it can be easily and heavily customizable. A lot
of thing, as the color of menu or the font. However, E:S haven't (now)
a lot of feature to customize, it's a small game.
That is a test of a roadmap :
- Add one or more theme options.
I think for starters we have 2: Default and Vector.
- Factorize in a class (Theme).
The classic Class + global list/dict of instances approach.
Instances may be created (and appended to a global themes = [] list) in a code/g.py, as in:
def load_themes():
for theme in whatever_data_model_we_use:
themes.append(Theme(foo,bar,etc))
theme = themes[0]
Then g.load_themes() would be called by code/singularity.py at startup
- Add custom theme section in prefs.dat.
I think prefs.dat should would have an entry of what is the /current/ theme. For example:
theme = vector
- Add a list of different theme in option screen. (first there are
two, default and custom)
I vote for default and vector. There's no "custom" theme, every theme has a name. And user could create more custom themes. More on that below
- Add the loading of default theme and different options from data/
theme.dat.
How about data/themes (for the themes bundled with E:S) and prefs_dir/themes ?
Inside, we would have:
./themes
default/
theme.dat
someimage.png
somefont.ttf
...
vector/
theme.dat
someotherimage.png
anotherfont.ttf
...
...
And the user could replicate this "themes" dir in his own prefs dir, and create as many themes he want. We could pre-create that dir the same way we currently do with music/ (maybe even adding a README.theme like Phil did with music)
So g.load_themes would simply scan both themes/ dir (user and system, but respecting --singledir), read theme,dat from each subdir, and create the themes list. Options screen list would be as easy as:
for theme in themes:
list-or-whatever-ui-it-uses.append(theme.name)
where name of a theme is simply the subdir name. g.load_themes() would also use config parser for each theme.dat
- Add many themes
Go for it! :D
But for now, fonts (as in data/strings_xx_XX.dat [fonts]) and earth background image are the only "hanging fruits" that are easily customizable.
- Add the possibility to add more than one custom theme in prefs.dat.
Of course, we must discuss a lot of thing. All this features isn't
really useful. Have we need to allow more than one custom theme?
My suggestion covers that. No need to edit prefs.dat, except to set the user's current theme
Add a complete theme feature need to add a lot of widget in option
screen. So, the new revamp option is needed.
Not really, at least as long as earth image and fonts are the only thing we make "themable". But once the engine is set up, adding new themable options is relatively painless, only require to change all hardcoded entities in code to point to g.theme.myattr
About the earth theme, I need more works, because there are still few
bugs. I agree to set the vector images to default.
This is how I envision how a powerful yet relatively simple themes engine should work. But, as Phil said, it is still a lot of work for perhaps little gain. If you're motivated for the challenge, great! :D
ML
Mestre Lion
May 10, 2012, 1:13:13 AM5/10/12
to endgame-sin...@googlegroups.com
I'm a little leery of anyone banging too much on theme coding until we
decide just what direction we want to take with my proposed UI refresh.
A lot of what goes on there is not possible with "simple theming," as it
requires new ways to handle a lot of the data that E:S currently presents.
Well, I have *zero* design skills, so I'm the last person to talk about directions on a new UI. But, the way I see it, your UI proposal and themes support are complementary. The former sets a complete revamp on the UI engine (and in many other things too I presume), the latter simply adds a an engine to avoid hardcoding a few elements, like "this font" or "that image", as in g.theme.background_image instead of g.earth_image, where g,theme is an instance of Themes and an element in g.themes.
So both ideas could live toghether just fine, regardless if we do both or not, and regardless or order of implementation.
That said, the ability to use either the current "realistic-Earth" images
or my vector Earth images (and if someone would like to make a better one
of those, I wouldn't mind) is pretty easy, low-hanging fruit. If nothing
else, it could be a command-line option.
We can do much better than a command-line option Phil ;)
For an easy, quick-and-dirty route, a list of available eatch images in Options screen, looping from data/images/earth.xxx.jpg, where xxx is the "friendly name" of the backgound in the Options list. This is what? A 10-15 lines patch, tops.
Thoughts? Which should be default, the classic theme or the vector one?
My vote? Classic. I /love/ that sattelite image :D
But a /strong/ supporter of adding your vector backgrounds somehow, either theme of my "quick-and-dirty" approach above.
ML
Mestre Lion
May 15, 2012, 5:24:49 AM5/15/12
to endgame-sin...@googlegroups.com
I've published a fully working prototype at testing/background branch.
Fetch it, test it, enjoy it. But *please* don't look at the source code :P
This theming thing ended up being a /lot/ more complex than I expected. Even the "quick-and-dirty" approach took a whole day to get it right. So it was not "quick" at all, but it is surely /very/ dirty.
B
Next steps (wanna join Philippe?), in no particular order:
- Scan both data_dir /and/ prefs_dir, so user can create his own themes
- Use the above logic in a elegant way in gg.available_themes, so singularity.py can use that list to check prefs file and arg parsing (like languages)
- Always Load default theme first and then the requested theme, so requested may afford to be an incomplete theme. Kinda like the way languages is handled currently. And then we can delete those awful symlinks in vector
- Parse themes.dat from each theme, so user can map images to arbitrary files (instead fixed names like "earth_night.{png,jpg}"
- Once this is done, use more "generic" names for the image keys in code: background_day, background_night, icon, arrow
- Make themes a Class, with attributes instead of keys in gg.images
- Reload Earth images in a more elegant, non-hack-ish way
And, once this is done, the easy ones:
- Make icon, arrow, and, why not? fonts themable too :)
Good luck me and whoever ventures into that ;)
ML
On Monday, May 7, 2012 5:25:59 PM UTC-3, Philippe Tetar wrote:
Fetch it, test it, enjoy it. But *please* don't look at the source code :P
This theming thing ended up being a /lot/ more complex than I expected. Even the "quick-and-dirty" approach took a whole day to get it right. So it was not "quick" at all, but it is surely /very/ dirty.
B
Next steps (wanna join Philippe?), in no particular order:
- Scan both data_dir /and/ prefs_dir, so user can create his own themes
- Use the above logic in a elegant way in gg.available_themes, so singularity.py can use that list to check prefs file and arg parsing (like languages)
- Always Load default theme first and then the requested theme, so requested may afford to be an incomplete theme. Kinda like the way languages is handled currently. And then we can delete those awful symlinks in vector
- Parse themes.dat from each theme, so user can map images to arbitrary files (instead fixed names like "earth_night.{png,jpg}"
- Once this is done, use more "generic" names for the image keys in code: background_day, background_night, icon, arrow
- Make themes a Class, with attributes instead of keys in gg.images
- Reload Earth images in a more elegant, non-hack-ish way
And, once this is done, the easy ones:
- Make icon, arrow, and, why not? fonts themable too :)
Good luck me and whoever ventures into that ;)
ML
On Monday, May 7, 2012 5:25:59 PM UTC-3, Philippe Tetar wrote:
Reply all
Reply to author
Forward
0 new messages