Bug 427632

Created attachment 240487 [details]
Screenshot

Looks like that code that loads icons for the new and shiny installation via Qt style sheets never does any checking (!!!) if anything really could be loaded. It simply ignores any error and happily continues.

Even worse, it dumps misleading information (!) to the logs that normal people would interpret as "everything OK":

QYStyler.cc:

bool QY2Styler::updateRendering( QWidget *wid )
{
    if (!wid)
       return false;

    QString name = wid->objectName();

    if ( !_backgrounds.contains( name ) )
        return false;

    if (! wid->isVisible() || !wid->updatesEnabled() )
        return false;

    if ( _backgrounds[name].pix.isNull() )
    {
        QString back = _backgrounds[ name ].filename;
        _backgrounds[ name ].pix = QImage( back ); // Load image from file

        // Log message that looks like success (even if it failed)
        qDebug() << "loading " << qPrintable( back ) << " for " << qPrintable( name );

        // No check with QImage::isNull(), no error handling
    }
    ...
}

I just saw the same on openSUSE-11.1 Beta1, so it's not just a SLE-11 problem.

The theme is there allright, the installation.qss style sheet is there and looks good, the icons are referenced by their correct names in that style sheet, and the icons are there. Everything looks reasonable so far.

My (wild) guess is that the (very fragile IMHO) mechanism to make this work might not work any more in libqt4: 

When the status is to change, YQWizard::Step::setStatus() doesn't change the pixmap directly (QLabel::setPixmap()). Rather, it changes the widget's Qt class name via the QProperty mechanism, hoping that Qt will apply all styles defined in the current style sheet (installation.qss).


http://svn.opensuse.org/svn/yast/trunk/qt/src/YQWizard.cc

void YQWizard::Step::setStatus( Status s )
{
    if ( !_statusLabel || !_nameLabel || _status == s )
        return;

    _status = s;

    if ( s == Todo )
    {
        _statusLabel->setProperty( "class", "todo-step-status QLabel" );
        _nameLabel->setProperty( "class", "todo-step-name QLabel" );
    }

    if ( s == Done )
    {
        _statusLabel->setProperty( "class", "done-step-status QLabel" );
        _nameLabel->setProperty( "class", "done-step-name QLabel" );
    }

    if ( s == Current )
    {
        _statusLabel->setProperty( "class", "current-step-status QLabel" );
        _nameLabel->setProperty( "class", "current-step-name QLabel" );
    }

    _statusLabel->style()->polish( _statusLabel );
    _nameLabel->style()->polish( _nameLabel );
}



http://svn.opensuse.org/svn/yast/trunk/theme/openSUSE/wizard/installation.qss

.todo-step-status {
   qproperty-pixmap: url(white-step-todo.png);
   max-width: 14px;
   min-width: 14px;
}

.done-step-status {
   qproperty-pixmap: url(white-step-done.png);
   max-width: 14px;
   min-width: 14px;
}

.current-step-status {
   qproperty-pixmap: url(white-step-current.png);
   max-width: 14px;
   min-width: 14px;
}

Using the most recent version of the Qt-Libs from http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/ , I can now reproduce the problem locally with the Wizard3.ycp example.

So this seems to be indeed a change in libqt4 that now does things slightly differently. I wonder if it is documented anywhere in the Qt reference documentation that changing a widget class property on the fly (ugh?!) should have any effect. I couldn't find anything in the docs about it.

I didn't even find any documentation of a Qt property "class" in the Qt4 ref docs.

That code in QY2Styler / YQWizard might rely on side effects that now behave differently. Will continue investigating.

Another examples for QObject::setProperty( "class" ):

http://doc.trolltech.com/4.4/widgets-stylesheet-mainwindow-cpp.html

    ui.nameLabel->setProperty("class", "mandatory QLabel");

Similar usage there.

The behaviour changed from libqt4-4.4.0 (openSUSE-11.0) to libqt4-4.4.2-1.1 (openSUSE-11.1 / SLE-11): QObject::setProperty("class", ...) and a subsequent mywidget->style()->polish( mywidget ) used to apply the style again in the old version, and it doesn't do it any longer in the new version.

Created attachment 241200 [details]
Test case

Test case, made from the Qt4 standard example under /usr/lib/qt4/examples/widgets/stylesheet :

Toggle the "accept license terms" check box. With the older libqt, it will change the color of the "age" spinbox's label immediately. With the newer libqt, it will only apply the change if you open the style sheet editor, apply another style and then apply the "coffee" style again.

Tested on snell.suse.de with libqt4-4.4.2 vs. belana.suse.de with libqt4-4.4.0 .

Relevant part of the test case:


void MainWindow::on_agreeCheckBox_stateChanged()
{
    bool mandatory = ! ui.agreeCheckBox->isChecked();
    
    qDebug() << "Mandatory age: " << mandatory;

    ui.ageLabel->setProperty( "class", 
        mandatory ? "mandatory QLabel" : "QLabel" );
    ui.ageLabel->style()->polish( ui.ageLabel );
}

IMHO this is a regression and needs to be addressed on the libqt4 level.

-> libqt4 maintainer (dmueller according to PDB)

*** Bug 427947 has been marked as a duplicate of this bug. ***

*** Bug 432297 has been marked as a duplicate of this bug. ***

*** Bug 432631 has been marked as a duplicate of this bug. ***

I can no longer replicate the issue with the Factory version of Qt (4.4.3)

r

So, it must have been FIXED, definitely not "WORKSFORME".

It's back. I can reproduce it on snell.suse.de with libqt4-4.4.3-11.1 .

*** Bug 436229 has been marked as a duplicate of this bug. ***

This can also be reproduced with the Wizard3.ycp UI example

http://svn.opensuse.org/svn/yast/trunk/ycp-ui-bindings/examples/Wizard3.ycp


    /usr/lib/YaST2/bin/y2base ./Wizard3.ycp qt

with default stylesheet (grey) or with

    export Y2STYLE="installation.qss"

(colored installation style).

Same problem with libqt4-4.4.3-15.1 from http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_11.0/

*** Bug 431573 has been marked as a duplicate of this bug. ***

fixed in yast2-qt

Fixed in yast2-qt >= 2.17.17

*** Bug 439563 has been marked as a duplicate of this bug. ***

Still in beta4 !! I have to reopen it or the fix was not integrated to beta4?

the fix was only checked in this sunday

*** Bug 439034 has been marked as a duplicate of this bug. ***

*** Bug 445500 has been marked as a duplicate of this bug. ***