#3113 closed defect (fixed)
GUI: Switching options dialog between 1x and 2x
| Reported by: | eriktorbjorn | Owned by: | sev- |
|---|---|---|---|
| Priority: | blocker | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Latest SVN snapshot
The options and edit game dialogs have a different number of tabs depending on the size of the dialog. This causes a number of problems when switching between 1x and 2x mode. The most serious one - that I have seen - even causes ScummVM to terminate:
* Open ScummVM in 1x mode. * Open the Edit game dialog. * Click on the Audio tab. * Change to 2x mode.
ScummVM terminates with a "Undefined variable gameoptions_volumeCheckbox.x!" message.
Going in the other direction - from 2x to 1x - just causes overlapping widgets. Less serious, but probably an aspect of the same underlying problem.
Ticket imported from: #1677997. Ticket imported from: bugs/3113.
Change History (16)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
| Owner: | set to |
|---|
comment:3 by , 17 years ago
Hm, a crash is bad :/.
To deal with this fully, we would have to map the different tab settings, and do lots of other stuff.
But a simple solution might be to simply detect a screen res change, and then close (and possible, later re-open) then dialog. That should work, shouldn't it?
comment:4 by , 17 years ago
| Priority: | normal → high |
|---|
comment:6 by , 17 years ago
| Priority: | high → blocker |
|---|
comment:7 by , 17 years ago
| Owner: | changed from to |
|---|
comment:8 by , 17 years ago
(Temporarily assigning to LordHoto, to make sure he's aware of this :-).
As I see it, for a proper fix we'd have to modify OptionsDialog::reflowLayout() to move the widgets between the tabs, then change the number of tabs. Correct? I'll try to add a TabWidget::removeTab() method now.
comment:9 by , 17 years ago
I added a temporary workaround for the issue in the "Edit Game" dialog. What I do is that I simply recreate the whole dialog on the fly when a resolution change occurs. The ugly part is that all changes the user made so far get lost. But I figur that's a minor problem compared to a crash / messed up dialog.
A similar change could be applied for the global options dialog. Once that happened, we can probably lower the priority of this. For a proper fix, I think we would have to at least retain the user changes (this isn't that difficult to implement, BTW, just read out all widget settings before killing them, then restore the content afterwards -- I am just too lazy to implement this right now :-)
comment:10 by , 17 years ago
I was aware of this bug, but I thought sev is taking a look at it. I don't see any reason why it's assigned to me, so I'll just reassign it to sev. And I don't have any clue what's going on here (I didn't take a closer look at it though).
comment:11 by , 17 years ago
| Owner: | changed from to |
|---|
comment:12 by , 17 years ago
I guess I'll extend my workaround to the global options dialog and then somebody (eugene?) could sync it with the 0.10.0 branch, if you deem the fix good enough.
comment:14 by , 17 years ago
I reverted your patches and added Volume tab to all resolutions both global and game options dialogs. This effectively fixed it. :)
comment:15 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:16 by , 5 years ago
| Component: | → GUI |
|---|
The reason for this is that now some widgets are assigned to different tabs at different resolution. I.e. in smaller resolutions volume controls are placed on their own tab when in bigger resolution they are on audio tab.