QComboBox bug in Qt5.15

JonB

@sjlee
IIRC there was specifically a bug quite "a while ago" where a literal & in a menu item got changed into ellipses. Discussed somewhere in this forum. But how you find that now I'm not sure....

Ah, see https://forum.qt.io/topic/133278/ampersand-works-strange-way-in-menu-action-title-in-qt-6-x ! That was Qt6, but maybe it started at Qt 5.15?
Oh, I have only just realised that is menu items, you are talking combo box items. So don't don't whether that is germane....
Just in case, have you tried doubling to && in a combo item?

sjlee

@JonB

Just in case, have you tried doubling to && in a combo item?

Of course, I tried it. Two ampersand characters change into "...".

I just want to report this bug. Already, I have to setMinimumWidth(mimimumSizeHint().width()+4) to workaround the problem.

FYI, this bug persists in 5.15.9.

Axel Spoerl

@sjlee A double ampersand "&&" is the right way to escape it and it should definitively work, provided there is enough space for the entire string. If it doesn't, there is something wrong on our side or on yours.
Could you please post a compilable minimal example?

sjlee

You guys would think the problem may be complex. But it's very simple. I don't think you need the code.

See the simple combobox:
alt text

alt text

You could be confused with combobox item between macOS and other OS. While macOS combobox items are just menu items, it's just combobox item in Linux or Windows in native framework.

SGaist

Hi,

Well, yes, the code is still needed, and even more the font used by your application.

One thing that you don't seem to realise is that replacing a + with &, depending on the font you use, will not take the same space hence it might show the whole string in one case and get elided in the second.

Ensuring everybody runs the same minimal application will allow to better understand what happens to you.

sjlee

@SGaist

The symptom is identical on all Linux distros regardless of their system font. The problem would be related with string count.

However, while setMinimumWidth(minimumSizeHint().width()+3) workaround for some fonts, setMinimumWidth(minimumSizeHint().width()+4) do for other fonts.

Thank you.

ChrisW67

This has nothing to do with the ampersand. That can plainly be seen from your screenshot where text other than the ampersand has been elided. Between version of Qt this space seems to have changed by a pixel or two.

This has only to do with the text items in the combo box that are longer than the space determined at the time the QComboBox was first shown (the default behaviour). The code below generates a combo box that correctly displays "Read Only" and "Read & Write" at start. However, a longer item added after the first show has its text elided exactly as I described earlier.

// Linux Qt 5.15.3, GCC 11.3, 64-bit
#include <QApplication>
#include <QComboBox>
#include <QTimer>

int main(int argc, char **argv) {
        QApplication app(argc, argv);

        QComboBox *cb1 = new QComboBox();
        // cb1->setSizeAdjustPolicy(QComboBox::AdjustToContents);
        cb1->addItem(QStringLiteral("Read Only"));
        cb1->addItem(QStringLiteral("Read & Write"));
        cb1->show();

        QTimer::singleShot(5000, [=]() { cb1->addItem(QStringLiteral("Text that is too long")); } );
        return app.exec();
}

You can have the combo box rethink any time an item is added by uncommenting the line above. An unrestrained QComboBox will resize if needed, but in your example the table imposed a constraint on the combo box size.

sjlee

@ChrisW67

Please try your code with "landscape & this" and "portrait & this" items instead of ro/rw. I mean longer string than its width.

Thank you.

JonB

@ChrisW67
I too have Qt 15.5.3. I am under Ubuntu 22.04, with GNOME desktop. I think you are different because of the "X" in the top left of your combo, I do not get this, I think you are using a different window manager?

You will have to bear with my explanations, because I cannot figure how to take screen shots with a combo dropped down :(

I do not get the behaviour you show with your code. When the "Text that ..." is added I get no ellipsis, instead the whole line is shown but with the dropped-down portion being allowed to be wider than the combo box width, so it sticks out right below. Just saying.

@sjlee
Your instructions are most unclear as to exactly what you want the whole thing changed to. I won't go through all the combinations I tried as to what precisely you might mean, they behave in various ways. However, I did come across one oddity which just might be a clue to what is going on and the oddity of &. Try exactly this:

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QComboBox *cb1 = new QComboBox();
    cb1->addItem(QStringLiteral("portrait & this"));
    cb1->show();

    QTimer::singleShot(5000, [=]() { cb1->addItem(QStringLiteral("landscap & this")); } );
    return app.exec();
}

Note that my landscap [sic.] is deliberately written like this. Now when I do this if you look very closely at the appended item I see

landsc..._this

The space before this is an underlined space. That implies [to me] that at some level Qt is treating the & [ampersand followed by space] as shortcut indicator, not a literal ampersand. And my guess is that somewhere in the ellipsisation code this "incorrect interpretation" is made. But not always, because it does not happen in other cases, e.g. landscape & this shows as landsca...& this, no shortcut. Maybe something like "if & is the last character "chopped off" by inserting ellipses then it incorrectly treats the following, preserved character as having been marked as a shortcut by the removed & preceding it".

I don't know whether this helps! But maybe there is indeed some special treatment of & going on here, only showing up under special circumstances?

Christian Ehrlicher

Please make sure you have the same QStyle::SH_ComboBox_Popup setting. It depends on the style used.

sjlee

@JonB
FYI, You can capture image for combobox popup using gimp (File > Create > Screenshot). You are unable to capture using the PrtScrn key since the combobox grabbed the keyboard focus.

JonB

@sjlee
I installed gimp. Maybe you can make it work, I can't, at best I get a black rectangle captured for the combo box! I think/hope you can manage without a screenshot from my explanation, maybe you can reproduce same (if you use same default fonts/sizes etc. as I get).

ChrisW67

@sjlee said in QComboBox bug in Qt5.15:

@ChrisW67

Please try your code with "landscape & this" and "portrait & this" items instead of ro/rw. I mean longer string than its width.

Thank you.

@sjlee You mean text that is longer than the combo box width, like "Text that is too long" that you already have an example of? How about you provide your code that demonstrates the alleged bug.

ChrisW67

@JonB said in QComboBox bug in Qt5.15:

I too have Qt 15.5.3. I am under Ubuntu 22.04, with GNOME desktop. I think you are different because of the "X" in the top left of your combo, I do not get this, I think you are using a different window manager?

@JonB
It is KDE (so kwin). It's a pain in the backside to capture the open combo box there also. With a standalone combo box the window manager will have input into size constraints and the constraint it imposes here causes text to elided. In the OP's screen shot the size of the combo box is constrained to some degree by the table cell the delegate is opening it over, and by the options set, and text is elided. This is exactly what was shown in the OP's opening screen shot. The ampersand was completed elided and there was no errant underline.

The oddity you noticed with the ampersand I will try to reproduce when I am back at my Linux box.

ChrisW67

@JonB Whatever that behaviour is, it is sensitive to the environment. This is what your code does by default in my KDE environment:

If I subsequently narrow the window as much as the window decorations allow:

Note, no spurious underscore. I fiddled a bit but could not reproduce it (Fusion or Windows style). Qt 6.4.2 did something different again

JonB

@ChrisW67
For one, thing you are using both a different font and a different window-look. Understandably. I can only suggest if you want to try to replicate mine, you find a string such that Qt puts ellipsis into it to shorten and the last character of what was removed is the & character. So the eliding produces abc... def from what used to be something like abc123 & def.

Meanwhile I might be more confident about producing a screen shot from a dropped-down combo so will have another go at producing that for pasting soon :)

kkyzivat

For what it's worth, I am also seeing this strange behavior, and it seems to not relate to text eliding in the contained QAbstractItemView, either that, or the QAbstractItemView is ignoring my setTextElideMode(Qt::ElideNone) call.

The project in question I am working with is apitrace, and I can reproduce this behavior in the app build, but not in just a standalone example showing just the dialog that contains this combo box.

The & is replaced with ... even when I call combo->view()->setTextElideMode(Qt::ElideNone).

This occurs for me in Qt 5.15.14, and Qt 6.5.1.

To see my attempts to reproduce the issue outside of qapitrace, and to explain how to reproduce this in qapitrace, clone this small repo and follow the README.md:
https://github.com/keithel/qapitrace-combobox-elide-bug

Christian Ehrlicher · This occurs for me in Qt 5.15.14, and Qt 6.5.1.

@kkyzivat if you have a simple reproducer then please create a bug report and post the link here.

kkyzivat

@Christian-Ehrlicher
Oh, of course. I just haven't gotten there yet. Simple reproducer doesn't seem to be reproducing the issue (though I am using a different Qt build, one part of Pypi Qt for Python build). I should just rewrite my reproducer in C++ to test apples to apples.

I find writing these simple reproducers in Python is often quicker.

Christian Ehrlicher

@kkyzivat said in QComboBox bug in Qt5.15:

I find writing these simple reproducers in Python is often quicker

Maybe, but it makes debugging for the dev harder as he has to create a c++ test case in most cases first. So providing a small c++ reproducer will likely result in an earlier bugfix.