View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0020379 | MMW 5 | Main Panel | public | 2023-11-16 22:54 | 2026-11-12 14:00 |
| Reporter | zvezdan | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 2027.0 | Fixed in Version | 2027.0 | ||
| Summary | 0020379: Heigh of scrollbars are not consistent between main filelist and Playing | ||||
| Description | The vertical scrollbar of the main filelist in MM5 appears above header and list, the scrollbar of the Playing list is only above list, but not header. MM4 has both these scrollbars only above list, but not headers. Total Commander has the same style. Windows Explorer has vertical scrollbar above header as well. Whichever approach you decide to use (above header or not), you should be consistent and use it on both the main filelist and Playing list. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 3531 | ||||
| has duplicate | 0021812 | closed | Ludek | Scroll bar extends into column headers in the Filelisting |
| has duplicate | 0016490 | closed | Ludek | Scrollbar: Vertical scroll bar overlap List views headers |
| related to | 0020464 | closed | Ludek | Two vertical scrollbars in main tracklist with Playing node |
| related to | 0020482 | assigned | petr | Invalid resizing handle in listviews with restricted content width |
|
|
It makes sense that the scrollbars for the tracklist and Playing list should both go up to the bottom of the header (currently, it goes above the header in the tracklist). |
|
|
Fixed in 3522 Goes consistently above the header like in Windows Explorer. |
|
|
Verified 3523 |
|
|
The header in 'Playing' panel when it is in the "Simplified list" layout is very similar to the title bars of Preview and Lyrics panels (centered title, menu button on the left). However, the scroll bar above its header is not consistent with the scroll bars of these another panels that goes below their title bars. Maybe it would be better if the scroll bars go up to the bottom of the header in the main panel filelist and the 'Playing' panel in both layouts. |
|
|
|
|
|
Fixed in 3529 Was a little bit tricky (as LV resides in Scroller), but made scroll bars to go up to the bottom of the header in the main panel filelist and the 'Playing' panel in both layouts. |
|
|
Headers in the main filelist and 'Playing' have an invisible part of scrollbars in b3529. It is only visible with skins that have the bottom border in header and/or when having different background color of header on hover, like Metro and my skin. Also, you could see truncated text of fields in header above the scrollbar, even on the other skins. If you take a look on MM4 and Total Commander, you will see the header with its text is displayed above scroll bar. Also, Metro skin doesn't have displayed up arrow button on the scroll bar. The scrollbar in my skin goes fully above the header, and I don't think I could do anything about it in skin. |
|
|
Fixed in 3530 |
|
|
My skin doesn't have top arrow button on the scrollbar in b3530, both in the main filelist and 'Playing'. When I click on the area where it should appear, I get scrolling as if I clicked on the area below the thumb. Metro behaves fine now, but after I took a look at it, I saw that you added a new .scrollbarBelowHeader class, just because of this problem. Isn't that solution too dirty? What if someone else wants to create a skin which will display scrollbar buttons, just like Metro? They all need to do such tricks with their skins. Couldn't you do something about it which would not require things like that? Maybe you could add it to the basic skin at least? |
|
|
Agreed—the Metro-only workaround was too skin-specific. Fixed the shared scroller and base styles to position the entire scrollbar below the header, including its buttons. Removed Metro’s special rules. .scrollbarBelowHeader remains internal; skin authors need no extra rules. => Fixed in 3531 |