Improve in-game checkboxes

I have never been confused by that because for me, green means activated and red not.

But I could imagine that it can be misleading for red/green color blinds. Removing the red X seems a good idea, but as you have already observed, the checkbox might then be badly visible. What about making them much brighter?

1+
The red is unnecessary and brighter box that is empty would make better sense.

> What about making them much brighter?

Might work. At least they should contrast the background, and perhaps have slightly thicker borders than currently.

A distinctive border in a contrasting color would definitely improve the visibility. If the color contrast to the background is high enough, a border width of 1 pixel should be sufficient IMHO.

I have attached a graphic that compares the original/current check boxes with one possible approach for new versions that have a higher contrasting color in their borders. These are presented merely as examples to provide a base for discussion..

I haven't tried these in the game but I present them on a typical background. The images are all PNG files and the titles in the example are the actual file names as found in the ~/widelands/pics folder.

This example includes the check boxes overlaid with a white transparent layer at 25% opacity.

This is an example of possible variations on the check box frame including possibilities for when a feature is not available (NA).

#8
I think 2) and 6) looked best.

#7
The light background is great! Combined with the framing it will perfect!

Please note that the checkboxes are also used in the in-game sound options, so it needs to work with the brown wooden background as well.

I think you might be on to something with the light backgrounds, but I don't know how well they fit in with the overall style (colors used by other buttons and controls). Also, I would prefer to see a noticable difference when hovering the cursor over them (like the buttons do currently), though I am not sure whether the checkboxes are set up to support this, so that might be a separate issue. Still, something to keep in mind.

Here is an example of the lighter check boxes with the same shade of yellow as found in the game. The text is also in that shade to aid comparison.

@#10 - These buttons all have transparent backgrounds and should work with any of the backgrounds found in the game, but I'll render a graphic with the background of the sound options window.
The check boxes currently in the game do not change upon mouse-hover. To implement that feature would require code changes.

Here are the frames with the wood background.

In consideration of the comments so far received, I propose the check boxes as illustrated in the attachment for use in the game.

Anticipating a possible mouse-over functionality I have included graphics for its support. I also include a proposal for depicting an unavailable option (NA).

And here are the boxes with the wood background found in the sound options window.

Comments please.

I dislike the yellow border a tiny bit - it's so bright. Otherwise they are much clearer to me than the old ones.

@#15 - Not a problem. I'll work some up with a neutral color border.

Proposed check boxes with neutral borders.

Proposed check boxes on the wood background.

Again, comments please.

melikes! :)

I like the checkboxes on the normal background, but on the wood background, they are too grey. The current border looks better than the yellow one.

I do definitely not like the mouse-over checkboxes, they look just strange. I do not think that we need them because the checkboxes are quite small. So the user sees whether the mouse pointer is over it or not.

Which one of the checkboxes will be used in the game (or will they all be used). I think we need only a checked and an empty one, so the very last row. Or did I get something wrong?

@wl-zocker #20 -
Inasmuch as the check boxes appear on the wood background in only one window in the game (i.e. the sound options) and I believe the this style is sufficiently distinguishable, I am not inclined to make any more adjustments.

The mouse-over feature is not currently used for the check boxes in the game. I merely provided those samples for potential use IF mouse-over was ever implemented. With no coding changes, they will not be seen in the game (and not added at this time.) The same is true for the "NA" graphic.

I have not yet checked to determine if the current code requires all of the check boxes in column 1 (original). I merely restyled all of the check box files I found in the pics folder. If I were to guess, the "checkbox_light_new" graphic is now used in stead of the "checkbox-light". I will search the code for each filename and only implement those I find in the current code.

It is my intent to not alter any code, but only the graphic files that are currently referenced.

I will post my findings here before pushing any changes.

I have searched the ~widelands/src folder and have found two files that reference checkbox png files:

checkbox.cc - references checkbox.png and checkbox_light_new.png

table.cc - references checkbox_checked.png and checkbox_empty.png

I now plan to delete from the pics folder: checkbox_light.png as it is no longer referenced in the code.
Additionally, I will update the four png files noted above.

New checkboxes have been added in bzr rev #6357

Regarding #22, my personal preference would be to keep/update checkbox_light.png, remove checkbox_light_new.png and update the code to point to the former file.

First of all, I find marking files with _new to indicate they are newer a bit silly (especially considering we have version control). Both because it won't be new a couple of years down the road, and it also encourage people to add file_new2 or file_new_new which makes it harder to keep track of what they do.

PS. I filed bug 990623 for the code part of change-image-on-hover.

@hjd #24 - Retaining the old NAME and upgrading the image to which it refers makes perfect sense and is certainly fine with me. I share your reasoning. As I have stated, though, I personally try to avoid making code modifications by myself. While this is likely a rudimentary file name change, I do not care to make assumptions about what appears to me to be an item with limited scope. In other words, as a graphician, I don't like to mess with code. Conf files are bad enough. :)

I agree with hjd. I guess this file is around from the old svn days where we all had no clu about notting yet :)

>While this is likely a rudimentary file name change, I do not care to make assumptions about what appears to me to be an item with limited scope.

Well, minor changes like this shouldn't really be able to brek anything. (Though these are famous last words when it comes to software development ;) )

Since there were agreement this was the way to go, I have pushed a branch where the file is renamed and references to it upgraded. WL still ran and checkboxes worked after these changes.

Released in build-18 rc1.