#4057 closed defect (fixed)
LAUNCHER: "(Mass) Add" buttons + built-in GUI = buggy
| Reported by: | SF/sanguinehearts | Owned by: | SF/tanoku |
|---|---|---|---|
| Priority: | blocker | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Ive noticed an issue that was confirmed happening for both myself and wjp, Im using a win32 SVN build compiled myself from the latest code.
When hovering the mouse cursor over the Add Game button it selects it and highlights it green, If you then proceed to press shift to change to Mass Add the text for Add Game is still left unchanged below.
The same also happens if you choose mass add, move the cursor onto it to highlight it, then release shift to deselect Mass Add.
This leads to an unreadable button.
Rob
Ticket imported from: #2472185. Ticket imported from: bugs/4057.
Change History (16)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Just wanted to say that this occurs with the Classic theme for me, not the Modern one. There's another place where the same (?) bug occurs. Go to Options -> audio options tab, and click on the button that toggles speech and subtitles
comment:3 by , 15 years ago
Sounds like the same problem, though I haven't checked any closer. I should have mentioned that in the modern theme buttons are filled, so the old text is probably painted over.
comment:4 by , 15 years ago
| Summary: | problem with add/mass add buttons in inbuilt GUI → LAUNCHER: "(Mass) Add" buttons + built-in GUI = buggy |
|---|
comment:5 by , 15 years ago
| Owner: | set to |
|---|
comment:6 by , 15 years ago
eriktorbjorn is right. The problem only happens in the classic theme because buttons aren't filled when drawn. I'm looking into it (assigned to myself). Cheers.
comment:7 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:8 by , 15 years ago
That was easier than expected -- check it at revision 35617 and tell me if there's anything wrong still. Thanks for reporting!
comment:9 by , 15 years ago
I'm reopening it since it doesn't look like the right solution. In fact it causes a regression on the modern theme: the background of the buttons isn't painted when hovering (well, it's painted and restored). I guess the solution would be to restore the background at the beginning of each widget.
comment:10 by , 15 years ago
| Status: | closed → new |
|---|
comment:12 by , 15 years ago
| Priority: | normal → blocker |
|---|
comment:13 by , 15 years ago
I'm not able to reproduce this issue over here with latest SVN. It works fine when I hover "Add Game" and then press shift, the button text then changes for me to "Mass add". The I'm also unable to reproduce the other issue you have. Pressing shift, hovering "Mass add" and then releasing shift, will revert the button text without any issues to "Add Game".
comment:14 by , 15 years ago
Hi Johannes, you are not able to reproduce the reported issue because I fixed it one week ago; this is still open as a release critical bug, though, because such fix added a regression where buttons were not being "highlighted" with the Modern theme. I've just commited revision 35789 which hopefully fixes the regression and the original "add game" bug.
Tell me if anything is still broken, I'm closing this meanwhile.
Cheers as always!
comment:15 by , 15 years ago
| Status: | new → closed |
|---|
comment:16 by , 5 years ago
| Component: | → GUI |
|---|
I'm not really familiar with how the GUI / Theme stuff works these days, but I think the problem here is that in the classic and builtin themes, buttons are drawn as unfilled squares. That is why, when the button is repainted with new text, the old text is not erased.
So at least theoretically, something like the following change should work.
Look for the following lines in gui/themes/default.inc and gui/themes/scummclassic/classic_gfx.stx:
<drawdata id='button_idle' cache='false'> <drawdata id='button_hover' cache='false'> <drawdata id='button_disabled' cache='false'>
A few lines below each of these, there is a <drawstep> tag with a fill='none' attribute. Change this to fill='background'.
But I'm a bit confused about the difference between fill='foreground' and fill='background', because both seem to fill with the same colour. Actually, the drawBeveledSquare() function (which is what I think the buttons are using) only seems to care about if the square is filled or not, not its colour, so it probably doesn't matter.
If I'm misreading, and it uses drawSquare() instead, it would matter. But I'm not sure exactly how. This is what drawSquare() in VectorRendererSpec.cpp does:
case kFillForeground: drawSquareAlg(x, y, w, h, _fgColor, kFillForeground); break;
case kFillBackground: drawSquareAlg(x, y, w, h, _bgColor, kFillBackground); drawSquareAlg(x, y, w, h, _fgColor, kFillDisabled); break;
I'm not sure why it calls drawSquareAlg() twice if it's filling with the background colour.