Menu
▾
▴
1 Attachments
#1481 Comboboxes missing scrolling bars and black on black
I'm submitting this as a bug. I don't know if it's really a bug, a new feature or a problem with my compilation.
I'm using svn 14401 build. Scrolling bars doesn't appear in the special parameters section on the left side of rosegarden anymore. Instead there are only up and arrows to row in the lists. It may look nice at first but if you have a long list of colors, instruments or others it may take a while to browse through it.
For example there's an attached image here that displays when I was trying to find a black color for a segment. Since black is one of the last colors in the list it took a while to find it without a scrolling bar.
Is it possible to have scrolling bars back?
Confirmed. All comboboxes now have small arrows, no scrollbar, and the text is black on a slightly less black background. I'm in Ubuntu/Unity.
Maybe it's a style thing? There has been some style tweaking recently related to Qt5 compatibility I think.
You are certainly right about the style thing: I'm using KDE and I can't see any problem.
For me, this problem only occurs with Qt5. I've been working on it.
I spent several hours digging around, and this is a very pernicious problem. I don't know what I am going to do in the end, but it will involve a lot more hours of study and experimentation before this one yields.
Rosegarden executable built on Nov 16 from SVN rev 14340:
Scrollbars present
Rosegarden executable built just now from SVN rev 14410:
Scrollbars absent (and a different font used throughout the UI -- the latter is actually a good thing, it's following my desktop font now where it wasn't previously)
Both are dynamically linked against the same set of Qt 4.8.7 libraries.
Desktop environment is GNOME 3 with gnome-shell. Judging from the other differences between the two, I'm guessing the newer build is using a GTK-alike theme where the older one wasn't.
Last edit: Chris Cannam 2015-12-17
Thanks for the report, Chris. Apparently the changes I have seen in Qt5 builds running on KDE are in place for non-KDE users with Qt4 builds.
I could solve that with a conditional build to use QPlastiqueStyle in Qt4 builds, but I still have to deal with its absence sooner or later.
This should be addressed in revision 14411. I hesitate to say "fixed" because I feel like this is still a regression. This is pretty much the best that can be done without going to extreme and elaborate lengths, I'm afraid.
The first problem was the dark background color. With all else failing, you can get around that by running without the stylesheet.
The second problem was the 1000 pixel high combo box drop downs. That was the default behavior years ago, when we ran the new GUI for the first time. I put a bunch of setMaxVisibleItems() calls in to get those tall bastards under control, and as far as I recall, everybody was more comfortable that way.
QComboBox intentionally ignores this setting "with certain styles." Everything else aside, when I run a Qt 5 build of Rosegarden on KDE 4 with no stylesheet, I get the stupid fricking tall combo boxes too. UNACCEPTABLE!!
After trying dozens of things that proved unsatisfactory, I finally tried setting the application style to "windows" and it fixed the combo boxes. There are various artifacts and clunky side effects I don't like, and can't realistically fix, but the alternatives I see are extremely expensive.
I'm not thrilled, but 14411 is where I'm going rest my case. Hopefully everyone will have similar results to mine, and I can move on. (Maybe I can find a way to deal with some of the artifacts.)
Are you talking about artifacts like those in the attached picture? Or are those a different kind of bug? (A brief explanation of the picture: All notes were typed in the right place in the score and they were displayed correctly. But then I scrolled the notation ahead to make some adjustments and when I scrolled it back to the beggining of the segment I got those artifacts. Notes and clef symbols were displayed out of place. But if I close that window and open it again everything is displayed correctly again.) I compiled 14413 and the scroll bars were back and the only artifacts I noticed in the main screen were some discreet white borders. They didn't bother me at all. But now I noticed these artifacts in notation too. Should I fill another bug ticket or is this the result of the code changes while there isn't a solution to the scrolling bars?
I was talking about the white borders, which are the remnants of a sunken shadow effect that isn't appropriate in this color scheme. The notation editor doesn't seem to have been impacted by any of this one way or the other, and it has had the same minor glitches for years and years.
It looked very strange to me. I was never hitted by any glitches in notation editor since I knew rosegarden in 2010. Except once when I overwrote the fonts of my system with the ones of a previous install and then rosegarden could not render notation correctly. But now I didn't mess with the fonts so I don't this could be the problem. Or could it?
I was concentrating on the blue highlighted parts of your screen capture before. The track titles collided with the staffs in a bad way. That is ugly, but I've seen that before, and usually everything comes out just fine on paper, so I didn't pay a lot of attention.
Looking at your screen capture again, I see several places where beam groups cross bar lines. What the hell? Can you send me that .rg file to look at for myself?
One possibility is that changing the style to "windows" had an impact on fonts in some way.
Also, I'm filing a separate bug for this, but when I open the Hallelujah example file, the "Trombe in B" part is rendered badly in both Qt4 and Qt5, and in Qt5 it has all these "down bow" marks that are floating in space, not attached to anything. What the hell?!
Obviously I need to have a closer look, because the notation editor definitely has new glitches, and some of them are quite serious. I do not have time for this today, however.
Closing this. The combo boxes are fixed. There are other issues, yes, but they need to be addressed individually, with new, separate bug reports.