Add theme parameters to make dark themes look better

[Ranran(Hibernating)]

Ranran, who got lost in Cyber-space, obtained two types of cyber themes.
However, there are still some challenges to applying it in simutrans.






(1) The title bar is not beautiful
Currently the brightness of characters and background is automatically adjusted by gui_player_color_dark and gui_player_color_bright, but this is not enough. Especially on dark colored themes.
Because this is intended to invert the brightness. But with a dark theme it is not always correct.



I think the parameters related to the title bar and normal text brightness should be separated.
Ideally, we should have a color mask like for color buttons.


(2) Borders where theme can't specify a color will spoil the look
For example, components such as progress bars, color boxes, and views have a two-color gray border.
I want you to be able to specify the color of these borders as well.


(3) Menu bar...
The Menubar design depends on pakset and is separated from the theme. So it creates a contradiction with the theme design and creates a weird look. This fact shatters the minds of theme designers. (´・ω・｀)
My suggestion is to separate the button background from the button icon.


The theme designs the foundation and pakset designs the objects.
I don't think the transition to this specification will cause any problems. Because all existing icons have the whole image.
Not only does this remove the contradiction, but it also improves the look somewhat by not stretching the background with large buttons.


(4) halttype symbols
This also improves the appearance if you can design with the theme.
I know that the 192 comic has a sleekly designed halttype symbol, but pakset is just doing what the theme should support. For example, if you change to a high contrast theme, those symbols will create a design contradiction.



The following is a greedy request.
(5) Can you set the color of the white frame that appears when you press the button, or make it a different style?


Does not match the shape of the button (´・ω・｀)

[prissi]

I am not sure that I would use a dark theme, but more flexibility is certainly a good idea. However, I fear it would be up to you to make a patch. Some things are probably easy, while other may be very hard. So I would suggest a number of patcher obe by one.

I have serious doubts if the new transparent icon would be adapted fast. Alternatively one may thin of the cursor for many objects like ways.

[Yona-TYT]

Their themes are great!


"Currently the brightness of characters and background is automatically adjusted by gui_player_color_dark and gui_player_color_bright, but this is not enough. Especially on dark colored themes.
Because this is intended to invert the brightness. But with a dark theme it is not always correct. "
A mask like the one with the colored buttons should be the way to go, it doesn't seem like something that difficult to code.

"The Menubar design depends on pakset and is separated from the theme. So it creates a contradiction with the theme design and creates a weird look. This fact shatters the minds of theme designers. (´ ・ ω ・ ｀)
My suggestion is to separate the button background from the button icon. "

This seems like a good idea to me, the background in question is the same as the old theme, I suppose that the one offered by the theme file should be used.

"(5) Can you set the color of the white frame that appears when you press the button, or make it a different style?"

I was looking for something like this for the high contrast theme, but I didn't get anything in the code, a hint would be nice, so I can add a new parameter.


I really love this, how I wish I had time to work on this.

[Ranran(Hibernating)]

more flexibility is certainly a good idea. However, I fear it would be up to you to make a patch. Some things are probably easy, while other may be very hard. So I would suggest a number of patcher obe by one.

Okay. Submit the first patch for (1). Separates the brightness of the player color title bar from existing parameter (gui_player_color_dark).
I'm not good at naming variable names in English. It's so long that you can change it if necessary.
And I don't know if it is correct to be included in the saved version, (122,1).

I edited the high contrast theme. You can confirm that the player color title bar is darker than the existing version. In addition, there is no change in other themes.
That is the effect of this patch.


EDIT:
I submit an additional patch for (2).
It allows to change some border colors with the theme.
The default is MN_GREY0 for top left and MN_GREY4 for bottom right. In that case, the display will be the same as before.


About (5), it is easy to make the color changeable. But I wonder if that is the best solution.

EDIT2:
There was an error in titlebar_bg_brightness.patch so I uploaded a modified version

[Leartin]

(3) Menu bar...
The Menubar design depends on pakset and is separated from the theme. So it creates a contradiction with the theme design and creates a weird look. This fact shatters the minds of theme designers. (´・ω・｀)
My suggestion is to separate the button background from the button icon.


The theme designs the foundation and pakset designs the objects.
I don't think the transition to this specification will cause any problems. Because all existing icons have the whole image.
Not only does this remove the contradiction, but it also improves the look somewhat by not stretching the background with large buttons.

Be aware that there already is something like that. Menu icons can be transparent with a "background image" defined for each seperate menu in the menuconfig - that's how pak192.comic does it's color indicators at the bottom (such that the same object can be in several menus, and pressing the icon does not darken the color strip). Hence there are already many icons with transparency, and I don't see why a theme should be able to overwrite the color indicators. (Unless the paksets could choose the color of the title bar instead, which makes the bottom strips obsolete - though I'm not sure that would make you any happier)

Otherwise, I feel that p192c gets off the hook due to black outlines, which mean that really, only a black background would hurt them. Most paksets are not that lucky. Pretty sure no theme designer would check on all icon colors, and no pakset designer would check all themes when creating icons, so something like the attached graphic will happen - and that's no good.

Your example themes have another issue - even if the icons would adapt to their background color, it still wouldn't "feel" right - they should mostly be monochrome lineart to fit the style. You typically see that when you download such themes for an OS - all the popular apps get updated automatically and look flashy, but anything else is off even with transparent background. What might help instead are additional borders around the icons. Just one or two pixels could be enough to inject the essence of the theme into the menu without changing the actual icons. In a similar vein, when a dark theme is used, perhaps all pakset graphics (eg the vehicles in the depot) should get an outer glow.

Similarly, for the title bar colors, I'd rather suggest a solution similar to color buttons. If the menu bar is composed of 9 elements just like buttons are, you could make it such that not the complete title bar is player colored, but rather has a color indicator bulb on the left edge, or a colored line seperating the title from the main window, or...

[Ranran(Hibernating)]

The menubar is separate from the theme and is protected by pakset. No matter how the theme provides a modern design, menubar retains the old design and thus causes an overall look mismatch.




Both the buttons on the GUI and the menubar are buttons. But very different designs coexist.

The menubar is an inviolable area for theme designers. It's the realm of pakset designers.
Currently, you have to provide a menubar for all paksets to resolve this discrepancy.
The idea of a base button is to try to get rid of this somewhat.
This is what I wanted to say.

so something like the attached graphic will happen - and that's no good.

I'm afraid but you deliberately presented a bad design example. Or I don't think I understand my claim. It's a designer issue.
The color scheme should be as familiar to the icon as the background color of the chart.
I'm not proposing to colorize the traditional button design with just one color. In addition, you are deliberately choosing bad colors (saturation and brightness).




Certainly must be somewhat sophisticated.

no pakset designer would check all themes when creating icons

Of course, there may be a mismatch between the icon provided by pakset and the theme. If they don't like the theme, players can choose not to use it.

Otherwise, I feel that p192c gets off the hook due to black outlines, which mean that really, only a black background would hurt them. Most paksets are not that lucky. Pretty sure no theme designer would check on all icon colors, and no pakset designer would check all themes when creating icons, so something like the attached graphic will happen - and that's no good.

Also, if pakset doesn't want to change the background, it won't change unless you still use a transparent background.



If pakset provides a transparent icon, but the theme doesn't have a default base icon image, the system should show a default button. It may be possible by stretching the regular button to icon size.
Placing another image above the menu button is currently done by the compass on the map rotation icon. So I don't think it's impossible. However, there remains some doubt as to whether the perfect design will be offered.
For example, key binding characters, icon image colors, etc.

[Leartin]

I'm afraid but you deliberately presented a bad design example

Indeed, I deliberatly depicted a bad design example, just as you attempt to deliberately depict a good design example. You take the slope symbol and make a background that works for it - the issue being that just because it works for the slope symbol does not mean it works for all symbols. I attached how two of your design examples look like with a different symbol from the same menubar. Your "better" design falls completely flat with the line management symbol. Could that symbol be changed? Yes - but not by the theme designer, only by the pakset designer. And changed to what, anyway - the pakset designer couldn't be sure what crazy ideas theme designers come up with next, so there is no 'save color' to pick. Even if there were save colors by having strict design guidelines on how dark/saturated the background could be, it would still restrict the design choices for the pak designer.

Of course, there may be a mismatch between the icon provided by pakset and the theme. If they don't like the theme, players can choose not to use it.

Wait a minute there. So, if there is a mismatch between the symbol provided by the pakset and the background provided by the theme, and the player doesn't like it because they can't even read it, your "solution" is for the player to just not use that pakset-theme-combination? oô Why, in that case, what's the issue with what we have? If the style clash between a pakset and a theme offends you, just don't use that combination. If the theme clashes with all paksets, just don't use it at all...


And by the way - It's not that I disagree with the problem at hand. I don't like the clash between theme and paksets either - my preferred method to solving that is to use the theme provided with/for the pakset, which allows for a coherent style. It's just that I don't think changing the background would work well, as you simply move where the clash happens (within the button, rather than menu vs. gui).
A proper way to do it (although much more work) could look like this:
1) Have an Icon-Object that holds Icons and links to other objects. When the game loads, Icon-objects are read and the icon graphic of the linked object replaced by (one of) the icon in the icon-object. (That Icon-Object could also replace the tool buttons by linking to those tools)
2) Establish that the Icon-Object can hold more than one icon for another object. Which icon is used depends on theme settings. For now, one could think of three different sizes - 32p, 48p, 64p - in the same Icon-Object, using the appropriate size when set by the theme. Other options could be, for example "Bright" - which would be used by dark themes which require bright/inverted symbols, or "round" for themes that cut corners.
3) Load Icon-Objects from Themes.

So what's the differences with these things in place?
First of all, you don't need access to the sources. Some might be lost or nobody has the required rights to alter them for old paksets, such that not even the current maintainer could easily change the symbol to have a transparent background anyway. But also, it's not up to the pakset creator to change icons, as anybody could provide fitting icon-objects - it's not more work for pakset creators.
Secondly, if some symbols don't work with a theme, those specific symbols can easily be adressed. That is, you can use the design you proposed which might well work for most symbols anyway, but instead of the hardline "if you don't like it, don't use it", you can also provide a fix for the line management symbol, using light gray instead of white for stations. - which then works with that theme, but wouldn't with others. Nobody would have to ask the pak-designer to change their design to accommodate a theme.
Thirdly, I feel like if I could use such icon-objects, I would, even without any benefits in regards to themes, just for organisational reasons. (Not that I'm currently active anyway)

[Yona-TYT]

In my humble opinion I think that the player must decide with a selector in the configuration window on the style of the menu and its icons, this to decide if he wants the theme to decorate the icons / menus or for the pakset to do it as seen now .

[Vladki]

From pakset creators point of view
- I'd like to create menu icons with transparent background, and let the theme to put the button there. It would make things easier especially when one wants to fix something and does not have the layered version of the image anymore.
- what it would need is an agreement, how much space should be left for button-like border decorations. Now it is 2 pixels, this should be retained as a rule for theme designers, not to make the frames thicker.
- multiple sizes would be nice, but a fallback is necessary. IMHO for some buttons it would not be a problem, as I already have 3 versions of the same object: 128px game object, 64px cursor, 32px menu button.
- one new special color should be introduced for the parts of the icon, that absolutely needs to be in contrast against the button background. This color would then be determined by the theme. This will allow for light/dark themes.
- when we are at it - automatic adding of hot-key bindings to the buttons would be very nice. Now it is very unpractical to add them, and even worse if it has to be changed.
- even more automation as wishlist
-- icons for passenger/mail/cargo stations,
-- special backgrounds to distinguish general_tool, simple_tool, dialog_tool, toolbar,
-- different button background for some toolbars (lists)

[Leartin]

- what it would need is an agreement, how much space should be left for button-like border decorations. Now it is 2 pixels, this should be retained as a rule for theme designers, not to make the frames thicker.

I know where the idea of the 2px border comes from, but in practice, many symbols in various paksets exeed that limitation already. Not that they couldn't be cropped though. But I'm wondering: Why make something like that a "rule for theme designers" rather than a practical limitation?
Think of this: The full 32² menu icon may not be impeded on, but the theme may add additional borders around/between buttons. As such, the theme could look a bit better even without specific transparent buttons, and non-matching buttons (eg. from addons) would be a bit less of an eyesore since there still is a connecting element.

Still not sure how any of this would work with currently transparent icons due to colorcoded menus.

[Vladki]

OK then just scratch the border requirement from my list.

[Ranran(Hibernating)]

I've attached a theme here to test the dark theme. I think there is still a problem with using the dark theme in Simutrans without some adjustments, such as extending the changeable text color.
Note that there are a number of parameters for extended and testing purposes. However, you will be able to load and use it normally.

[Ranran(Hibernating)]

I don't know where the text colors ① and ② come from. Is it the same color as the disabled button?
However, ① and ③ are the same text in the same situation, but the colors are somehow different.

(1) The title bar is not beautiful
Currently the brightness of characters and background is automatically adjusted by gui_player_color_dark and gui_player_color_bright, but this is not enough. Especially on dark colored themes.
Because this is intended to invert the brightness. But with a dark theme it is not always correct.



I think the parameters related to the title bar and normal text brightness should be separated.
Ideally, we should have a color mask like for color buttons.

So what I meant to say was this. I believe this measure is included in the patch.

(2) Borders where theme can't specify a color will spoil the look
For example, components such as progress bars, color boxes, and views have a two-color gray border.
I want you to be able to specify the color of these borders as well.

The color bar may be difficult to see depending on the background color.
The border is gone, but it may be easier to see if there is a border.
The ability to set the color of the border (included in the previously submitted patch), or to set whether or not the border is present, would expand the scope of the design.


EDIT:

Dark-filled icons are visible in the gray theme.


However, it is not visible on a black background theme... (´・ω・｀)

Code Select Expand


boost_electric.set_transparent(fab->get_prodfactor_electric()>0 ? 0 : TRANSPARENT50_FLAG | OUTLINE_FLAG | color_idx_to_rgb(COL_BLACK));
boost_passenger.set_transparent(fab->get_prodfactor_pax()>0 ? 0 : TRANSPARENT50_FLAG | OUTLINE_FLAG | color_idx_to_rgb(COL_BLACK));
boost_mail.set_transparent(fab->get_prodfactor_mail()>0 ? 0 : TRANSPARENT50_FLAG | OUTLINE_FLAG | color_idx_to_rgb(COL_BLACK));

The color to be masked is fixed at black.

[prissi]

In the convoi info line of combobox these are SYSCOL_TEXT. (gui_color_text)

The entry to edit are SYSCOL_EDIT_TEXT or ..._DISABLED (gui_color_edit_text or ..._disabled)

So they should be different

The background for comboboxes and textinout are both from editfield graphics

[Ranran(Hibernating)]

In the convoi info line of combobox these are SYSCOL_TEXT. (gui_color_text)

The entry to edit are SYSCOL_EDIT_TEXT or ..._DISABLED (gui_color_edit_text or ..._disabled)

So they should be different

Thanks for the information. It worked. I overlooked this setting because I have not seen such a combo box before.
That is, as reported above, the depot dialog combo box may be disabled, but it does not change its appearance to look like it is disabled.
e.g. a depot dialog that cannot be manipulated by another player. This is also the case with extended.

The color to be masked is fixed at black.

This case do not exist in extended, but I think SYSCOL_TEXT should be used instead of COL_BLACK.
Because SYSCOL_TEXT should always use a color with a certain visibility against the GUI background. So it will be suitable for any theme.

[Ranran(Hibernating)]

However, it is not visible on a black background theme... (´・ω・｀)

This case do not exist in extended, but I think SYSCOL_TEXT should be used instead of COL_BLACK.
Because SYSCOL_TEXT should always use a color with a certain visibility against the GUI background. So it will be suitable for any theme.

I submit a patch on this.