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.

Sign up for GitHub

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

Jump to bottom

Toolbar drop-downs affect the positioning of new windows #3812

Closed
DorpsGek opened this issue May 4, 2010 · 4 comments
Closed

Toolbar drop-downs affect the positioning of new windows #3812

DorpsGek opened this issue May 4, 2010 · 4 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 May 4, 2010

ste opened the ticket and wrote:

This is a pathetic issue, but I'll report it anyway.

According to the source, auto-positioned windows should be first put in the top-left, unless it would obscure existing windows.
The toolbar drop-down is counted in this (even though it disappears when the new window is shown)

Repro:
- During game, no windows open.
- Make the toolbar positioned on the left
- Click the subsidies button (7th)
The subsidies window positions next to where the toolbar drop-down was
- Hit del
- Click the stations button (8th), the same thing happens
- Hit del
- Click fund new industry - the new window is on the left as it is not as wide

To see the correct positioning:
- Move the toolbar to the right, game window 1024+ wide
- Click the subsidies button, and the new window is on the left.

Suggested fix:
Ignore dropdowns when positioning windows

In IsGoodAutoPlace1 and IsGoodAutoPlace2 (window.cpp) replace:

FOR_ALL_WINDOWS_FROM_BACK(w) {
if (w->window_class == WC_MAIN_WINDOW) continue;

with something like:

FOR_ALL_WINDOWS_FROM_BACK(w) {
if ((w->window_class == WC_MAIN_WINDOW) && (w->window_class == WC_DROPDOWN_MENU)) continue;

in both functions.

However, people may be used to the "incorrect" initial position

Reported version: trunk
Operating system: All

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

DorpsGek commented May 4, 2010

Alberth wrote:

Rather than adding yet another special case check based on specific window classes, I think the answer lies in a more general approach where each window type gets a priority. A priority should at least allow deciding which window lies ALWAYS on top of which other window (think chat window, main display, news window, ...?)
It should also be able to handle this problem imho, although I currently don't see how exactly.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3812#comment7981

@DorpsGek
Copy link
Member Author

DorpsGek commented May 5, 2010

ste wrote:

There's a typo in the example fix: it should be '||' (logical OR), not '&&'

This comment was imported from FlySpray: https://bugs.openttd.org/task/3812#comment7982

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Alberth, "problem" with priorities is that you want (other) windows to take the chat input/main toolbar into account when finding a location but ignore the main window. The chat output isn't so much a window as drawing directly onto the viewport, i.e. always on top. I think the news window should not be obscured by windows if there's place somewhere else.

Nevertheless, the dropdown menu issue is kind of a different league of problem; conceptually the dropdown window will be gone when the new window is opened, but in reality it isn't yet, which is why the new window placement takes the dropdown into account.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3812#comment8080

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r19883

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

@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
Assignees
No one assigned
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek