[WIP] Round corners and modify tabed windows.

[Nevrdid]

This is my in progress modifications to gui.
Remaining work :

• Recenter home window and Esc menu.

• Fix unaligned things in widgets (scrollbar, background ...) or just use regular corner for them.

• Implement love.graphics.rectangle as in love 0.10 (https://love2d.org/wiki/love.graphics.rectangle)

• Implement love.graphics.setLineWidth(width)

• Fix info window top go out of the screen when game window height is reduced.

• Use renderShaderH for all rounded rectangles.

• Allow player to choose between rounded UI and sharp one.

• Verify Doxygenation.

• Replace magic numbers. ?

• Add missing documentation ?

Updated preview:
https://www.youtube.com/watch?v=DHr2B4N0UT8

[bobbens]

It looks great! Some comments:

1. I find the border contrast a bit too strong. Maybe weaken it a bit?
2. Would be cool to have it be optional. Maybe down the line it would be possible to have themes for the toolkit. This would probably make more sense most of the interfaces where moved to Lua so we didn't have to keep Lua and C synchronized.
3. The tabs at the top may be a bit hard to read when not focused. It seems like the text is almost covered up by the main window.
4. Does it work well with fullscreen windows?
5. Would probably be necessary to add to dat/scripts/luatk too, as things like the comms and some Lua-based interfaces use that.
6. Potentially could make sense to add to the VN too.

[Nevrdid]

1. I find the border contrast a bit too strong. Maybe weaken it a bit?

I changed it to the same color as the one for active buttons to "unify" active tab like the ones in Outfit window and active buttons.
Do you think we can also change the color for active buttons or it is better to check if the window is flaged as HASTABS and weaken only there ( so the tabs in Outfit for example will not change).

2. Would be cool to have it be optional. Maybe down the line it would be possible to have themes for the toolkit. This would probably make more sense most of the interfaces where moved to Lua so we didn't have to keep Lua and C synchronized.

I'll look at this. I also planned to remove all the hard coded values to defines ofc.

3. The tabs at the top may be a bit hard to read when not focused. It seems like the text is almost covered up by the main window.

True. I think the best is just to move all the tabbar up a little as this this will also fix the strang looking of tabbar inside windows.

4. Does it work well with fullscreen windows?

Fullscreen windows like map should not change as i not apply it to windows which not have tabs. About land one, it just appear like the screenshot but bottom stick to the top of the bottom blue bar and side stick to the game window.
No more a real fullscreen as borders are always rendered.

5. Would probably be necessary to add to `dat/scripts/luatk` too, as things like the comms and some Lua-based interfaces use that.

6. Potentially could make sense to add to the VN too.

I'm currently looking at this, i first try to change the graphics.rectangle method to behave like the love2d 0.10+ one.
I'm not sure however what i may change once the method is ready as I not yet dig into the lua codebase.

[bobbens]

OK, I took a quick look at it. Some notes.

1. circle.frag doesn't compile on linux/nvidia. I've pushed a fix to the round branch.
2. Buttons seem to have less border (or at least less clear than before)
3. White border seems to be stronger when not rounded vs rounded.
4. Main Menu isn't displayed on the main menu anymore (not a bad thing though, just a note. Haven't checked if it's more general)

I still have to play around a bit more. However, it seems to be quite nice.

[Nevrdid]

1. circle.frag doesn't compile on linux/nvidia. I've pushed a fix to the round branch.

Hum, strange but ok x')

2. Buttons seem to have less border (or at least less clear than before)

3. White border seems to be stronger when not rounded vs rounded.

I guess some doubles values may be floored through the functions arguments typecasting on some calls. I thought about it at a point but forgot to double check. Else i guess we must choose right values for line_width as for borders radius. For multiple elements, i choosen values "logicaly" without more testing than required i guess.

4. Main Menu isn't displayed on the main menu anymore (not a bad thing though, just a note. Haven't checked if it's more general)

It is intended, i globally removed windows title while i was working on windows size and i just seen it as useless x')
That's in the toolkit's window_renderBorder function. It's also where the borders were removed for fullscreen

[bobbens]

Overall, it looks good, however there's some hardcoded stuff that should probably be fixed, and some stuff that should be made explicit. Some of the major points are:

1. Don't do the conditional rounding in renderPane
2. Don't hardcode window / widget names, use parameters instead
3. Would be nice to have a fullscreen fallback for when running at minimum resolution. As in, don't show the background when landed at minimum resolution at all. Please see screenshot of 4. for an example.
4. The rectangular tabs have some weird offsets as shown in the screenshot below for the selected tab
   
5. The buttons are less visible, but the border is stronger compared to the main branch
   
6. There is also a difference in border brightness between the round and not round variant. Likely due to using the GL_LINE_LOOP. Probably would make more sense to just use a shader for all. You can use the discard; command to avoid rendering a pixel to be a bit faster.
   

[bobbens]

Another thing I just noticed, since it doesn't full resolution on landed at minimum resolution (1280x720), you actually can see the bottom bar as shown in the first screenshot of the previous post. In the current main, it covers up everything. This means that it is likely that the effective height es being further reduced, likely making worse some of the issues we have with lack of scrolling text and too large descriptions.

[Nevrdid]

Overall, it looks good, however there's some hardcoded stuff that should probably be fixed, and some stuff that should be made explicit. Some of the major points are:

1. Don't do the conditional rounding in renderPane

• I'm still thinking about it.

2. Don't hardcode window / widget names, use parameters instead

• Done using WINDOW_TABBED for wdwXXX, and saving parent of tabed windows for tabXXX.
  Not sure if the parent save is the better option but it work.

3. Would be nice to have a fullscreen fallback for when running at minimum resolution. As in, don't show the background when landed at minimum resolution at all. Please see screenshot of 4. for an example.

• Done. I basicly restored the fullscreen conditions and kept the tabs at top of window. But we lose the dividers style.

4. The rectangular tabs have some weird offsets as shown in the screenshot below for the selected tab

• Fixed. The frags were not that well setup so changed them a little bit and it looks pretty well like that.

5. The buttons are less visible, but the border is stronger compared to the main branch

• Done but yeah,
• I'll check again all widget and fine-tune the ones which not like the shader smoothing.
  I'll also have to correctly do the drawOutlinesThick effect and verify that i don't round corners to elements which should not have them.

6. There is also a difference in border brightness between the round and not round variant. Likely due to using the GL_LINE_LOOP. Probably would make more sense to just use a shader for all. You can use the discard; command to avoid rendering a pixel to be a bit faster.

• That was because of a different smoothing between them. Looks ok now. About discard, i'm not sure, I quickly googled it and seen that it's not such a good idea as it break gpu optimizations.

Another thing I just noticed, since it doesn't full resolution on landed at minimum resolution (1280x720), you actually can see the bottom bar as shown in the first screenshot of the previous post. In the current main, it covers up everything. This means that it is likely that the effective height es being further reduced, likely making worse some of the issues we have with lack of scrolling text and too large descriptions.

• Restored the original fullscreen window size and shifted it down instead of reduce it size. Looks good, i may even shift it more.

[bobbens]

Thanks for the fixes looks better than before. Please note I am using scalefactor = 1.5, which is probably the cause of many of these issues. Some (nitpicking) comments:

1. There's probably too little spacing at the top. It's really tight with other languages like Japanese. Probably could use 1-2 pixels on the top and bottom of the text.
   

2. In fullscreen, it seems to be partially clipping on screen.
   

3. Still a difference in brightness in the borders. Pretty sure this is related to the scalefactor, but not sure.
   

4. Here it is zoomed in with scalefactor = 1. Things to notice:
   4.1.Bbuttons are thinner and border is much thicker
   4.2. Window border colour is much much brighter.
   4.3. The window border seems to get "thinner" at the corner parts.
   

5. Since window names are removed. It would be nice to add the spob name to the landing main window. Maybe instead of "Landing Main", the first tab could be the spob name?

6. One thing that sort of bothers me a bit with the tabs is that they are now far away (in mouse distance) from the takeoff button. So on main I tend to click on the tabs from left to right, then click on takeoff. With the tabs on top, that's no longer possible. In that sense, maybe it would make sense to move the tabs to the bottom again?

7. Some of the dialogues would benefit from having the titles. I can think of things like tk.msg and friends (sort of being phased out). Maybe it would make sense for the windows to still have titles by default, and use a flag to disable it for things like landing window or main menu?

[Nevrdid]

Thanks for the fixes looks better than before. Please note I am using scalefactor = 1.5, which is probably the cause of many of these issues. Some (nitpicking) comments:

1. There's probably too little spacing at the top. It's really tight with other languages like Japanese. Probably could use 1-2 pixels on the top and bottom of the text.

2. In fullscreen, it seems to be partially clipping on screen.

• Yeah, i stoped yesterday once i restored fullscreen but i noticed that. Gonna do it. Also, i'll try all with different scalefactors.

3. Still a difference in brightness in the borders. Pretty sure this is related to the scalefactor, but not sure.

• I didn't try to change scalefactor as i missed those differences but i'll investigate it.

4. Here it is zoomed in with `scalefactor = 1`. Things to notice:
   4.1.Bbuttons are thinner and border is much thicker
   4.2. Window border colour is much much brighter.
   4.3. The window border seems to get "thinner" at the corner parts.

• Honnestly, i didn't yet tuned borders values comparing to main branch and that is a step i'll must do. I changed multiple colors and sizes values so i hope just revert to original values will fix this.

5. Since window names are removed. It would be nice to add the spob name to the landing main window. Maybe instead of "Landing Main", the first tab could be the spob name?

• Just spob name as first tab not a good solution imo. Maybe $spob_name Terminal ? But yeah i understand that we should quickly see which spob we're on no matter which tab is actually active.

6. One thing that sort of bothers me a bit with the tabs is that they are now far away (in mouse distance) from the takeoff button. So on main I tend to click on the tabs from left to right, then click on takeoff. With the tabs on top, that's no longer possible. In that sense, maybe it would make sense to move the tabs to the bottom again?

• I'm not sure about the render but It is totally possible.
  Another solution may be to totally move some buttons out of the window and place them like tabs.
  Possibly, i can move tabs to the right and take-off to the left. I may try to create a function to generate left side buttons to see how it render.

7. Some of the dialogues would benefit from having the titles. I can think of things like `tk.msg` and friends (sort of being phased out). Maybe it would make sense for the windows to still have titles by default, and use a flag to disable it for things like landing window or main menu?

• I'll add a WINDOW_NOTITLE