Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

save dialog hides behind news message #4709

Closed
DorpsGek opened this issue Aug 3, 2011 · 10 comments
Closed

save dialog hides behind news message #4709

DorpsGek opened this issue Aug 3, 2011 · 10 comments
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Aug 3, 2011

foobar opened the ticket and wrote:

If you open the save dialog when a news message is still open, the save dialog will hide behind the news message. As the game is paused, the news message doesn't go away by itself either.

This means that you have to close this message manually before being able to save, as it hides the save button.

Picture attached, exists for longer, currently tested in r22711, Win7.

Attachments

Reported version: trunk
Operating system: Windows


This issue was imported from FlySpray: https://bugs.openttd.org/task/4709
@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 6, 2011

monoid wrote:

Here's an attempt at cleaning up the window z-ordering code, along with making the save/load window to be handled using this new z-ordering prioritization code.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10158

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 6, 2011

monoid wrote:

Fixed up whitespace.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10159

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 6, 2011

Alberth wrote:

Nice for a first try.

This cannot be complete however, there is also the big main view window that must stay at the bottom.
The console window also seems to be missing.

Code-wise:
- the new function needs a doxygen comment. In particular, it should explain what 'high priority' means in the window stack.
- There should be an empty line between alternatives in a switch.
- "/* Bring the window just below the prioritized windows */" does not seem to be exactly right, if a high priority window like the endscreen is opened
- the 'w = w->z_back;' statement in the last change must either be put at the same line as the while, or you must use curly braces (coding style does not allow such multi-line statements).


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10160

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2011

monoid wrote:

Version 2.

This doesn't change the z-priority of the console window compared to what the current trunk does; should it?

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10163

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2011

monoid wrote:

Version 3. Adds more windows to their own z-priorities, and fixes some comments.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10165

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2011

monoid wrote:

Version 4.

* Adds console window to its own z-priority layer
* Fixes WC_INVALID'd windows causing new/brought-to-top windows to be incorrectly placed in the z-ordering, and added assertions to check for this happening in future
* Comment tidyup

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10170

@DorpsGek
Copy link
Member Author

Alberth wrote:

Not one new version but three :)
Nice progress.

The window class I found missing in the priority list was the error message window. I don't know whether you considered that window already.
The other candidates would be the edit box and the osk window. However, I dismissed those as 'not interesting enough'.
(I can imagine a popup of an edit-box, and then a user needing to open some other window to find out what to type. Such actions should be possible imho.)

The second biggest issue is a bit of re-ordering of the window-insert code to improve readability and remove the dead code.

The other remarks are just minor issues that can be fixed very quickly. See the attached file.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10173

@DorpsGek
Copy link
Member Author

monoid wrote:

Thanks for your comments Alberth; I'm still getting used to the OpenTTD coding style :P

I've taken all your advice, and done some more cleanup.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10256

@DorpsGek
Copy link
Member Author

monoid wrote:

Fixed comment typo, added more z-priorities, removed literal priority values.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709#comment10275

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r23336. Thanks for the patch monoid.


This comment was imported from FlySpray: https://bugs.openttd.org/task/4709

@DorpsGek DorpsGek added component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) bug labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant