Qt-interest Archive, April 2007
Qt4.3/X11: Bug in QMenuBar selection
Message 1 in thread
The attached program creates a window with a menu bar.
Click on the "File" menu item and see a popup menu open.
Click on "File" again and the popup menu closes.
Now click on "File" again and see that the popup menu doesn't open.
Only after yet another click does it open again.
This used to work fine until around 2007-02-07, but at some point
between that and 2007-03-20 it has been broken. I have reported this
newly introduced bug during the beta phase for Qt 4.3.0 (see task tracker
entry #156727), and much to my surprise I had to see that Trolltech has
scheduled the fix for this for version 4.3.1. So apparently they break
stuff, but are unwilling to fix it for the next official release, even
if it is reported in time.
Sure, there are so many other bugs in the Qt4.3 snapshot version that
maybe they consider this a minor flaw. But hey: it was *introduced*
in the beta version, so why not fix it before officially releasing
Qt 4.3.0? After all, KDE 4 is likely to be based on Qt 4.3 - should
all KDE 4 apps have this bug?
Is it just me, or do others also think that is bad quality management?
Klaus Schmidinger
#include <qapplication.h>
#include <qapplication.h>
#include <qmainwindow.h>
#include <qmenubar.h>
#include <qmenu.h>
int main(int argc, char *argv[])
{
QApplication myapp(argc, argv);
QMainWindow *mw = new QMainWindow;
QMenuBar *mb = mw->menuBar();
QMenu *mf = mb->addMenu("File");
mf->addAction("Abc");
mw->show();
return myapp.exec();
}
Message 2 in thread
On 18.04.07 16:17:31, Klaus Schmidinger wrote:
> The attached program creates a window with a menu bar.
> Click on the "File" menu item and see a popup menu open.
> Click on "File" again and the popup menu closes.
>
> Now click on "File" again and see that the popup menu doesn't open.
> Only after yet another click does it open again.
Unreproducable here on Linux using qt4.3beta as obtained from KDE's
qt-copy (with no mainwindow-related bugfixes) and according to the
Tasktracker entry its not reproducable on windows either.
> This used to work fine until around 2007-02-07, but at some point
> between that and 2007-03-20 it has been broken. I have reported this
> newly introduced bug during the beta phase for Qt 4.3.0 (see task tracker
> entry #156727), and much to my surprise I had to see that Trolltech has
> scheduled the fix for this for version 4.3.1. So apparently they break
> stuff, but are unwilling to fix it for the next official release, even
> if it is reported in time.
>
> Sure, there are so many other bugs in the Qt4.3 snapshot version that
> maybe they consider this a minor flaw. But hey: it was *introduced*
> in the beta version, so why not fix it before officially releasing
> Qt 4.3.0? After all, KDE 4 is likely to be based on Qt 4.3 - should
> all KDE 4 apps have this bug?
Well, KDE4.0 will be released for Linux and possibly MacOS (if there are
no issues) and it won't include that much applications anyway. So unless
my setup here is very special I'm not sure all kde4 apps will suffer
from this. Normally there's a good reason if TT doesn't schedule a bug
for immediate fixing. And as far as I can see from the history it was
initially and later again scheduled for 4.3.0, so I would assume there's
a reason for delaying it.
> Is it just me, or do others also think that is bad quality management?
Well, if it was a bug that affects plenty of people I'd agree, but given
that I can't reproduce it here and a comment is in the bugreport that
its not reproducable on windows either I can understand that they delay
it. After all reproduction seems to involve some system specifics on
your system and maybe other systems, but its not a general problem for
all Qt4.3 users.
Instead of complaining about TT quality management, you should contact
TT and try to find out why they delayed it and if you can fix your
system(s) yourself.
Andreas
--
[ signature omitted ]
Message 3 in thread
Andreas Pakulat wrote:
> On 18.04.07 16:17:31, Klaus Schmidinger wrote:
>> The attached program creates a window with a menu bar.
>> Click on the "File" menu item and see a popup menu open.
>> Click on "File" again and the popup menu closes.
>>
>> Now click on "File" again and see that the popup menu doesn't open.
>> Only after yet another click does it open again.
>
> Unreproducable here on Linux using qt4.3beta as obtained from KDE's
> qt-copy (with no mainwindow-related bugfixes) and according to the
> Tasktracker entry its not reproducable on windows either.
I just downloaded today's Qt4.3/X11 snapshot, and the problem is still
reproducable here.
>> ...
> Instead of complaining about TT quality management, you should contact
> TT and try to find out why they delayed it and if you can fix your
> system(s) yourself.
I'm pretty sure it's not a problem of my system, because it works just
fine with older versions of Qt4.3 snapshots.
I already had a lengthy conversation with qt-bugs, and they finally
confirmed that it is actually reproducable under Linux. Why they won't
fix it for version 4.3.0 beats me.
The reason why I'm so persistent here is that in my experience, if
a bug is in Qt long enough, they tend to call it a "feature" and won't
fix it any more - ever...
Klaus Schmdinger
--
[ signature omitted ]
Message 4 in thread
Klaus Schmidinger wrote:
> I already had a lengthy conversation with qt-bugs, and they finally
> confirmed that it is actually reproducable under Linux. Why they won't
> fix it for version 4.3.0 beats me.
Hi, Klaus.
If you could have 4.3.0 on schedule, or a bugfix in QMenuBar for people who
frequently click the menu three times doing anything else, who now need to
click four times, on Unix only. If you got to choose, would you postpone
the release?
--
[ signature omitted ]
Message 5 in thread
> Klaus Schmidinger wrote:
> > I already had a lengthy conversation with qt-bugs, and they finally
> > confirmed that it is actually reproducable under Linux. Why they
won't
> > fix it for version 4.3.0 beats me.
>
> Hi, Klaus.
>
> If you could have 4.3.0 on schedule, or a bugfix in QMenuBar for
people
> who
> frequently click the menu three times doing anything else, who now
need to
> click four times, on Unix only. If you got to choose, would you
postpone
> the release?
>
For a bug introduced in 4.3.0, reported by a snapshot beta tester, it
should be fixed in 4.3.0.
Otherwise, in the long run, you will will lose support for your betas,
if people feel they use them to no avail.
Scott
--
[ signature omitted ]
Message 6 in thread
Scott Aron Bloom wrote:
>> Klaus Schmidinger wrote:
>>> I already had a lengthy conversation with qt-bugs, and they finally
>>> confirmed that it is actually reproducable under Linux. Why they
> won't
>>> fix it for version 4.3.0 beats me.
>> Hi, Klaus.
>>
>> If you could have 4.3.0 on schedule, or a bugfix in QMenuBar for
> people
>> who
>> frequently click the menu three times doing anything else, who now
> need to
>> click four times, on Unix only. If you got to choose, would you
> postpone
>> the release?
>>
> For a bug introduced in 4.3.0, reported by a snapshot beta tester, it
> should be fixed in 4.3.0.
>
> Otherwise, in the long run, you will will lose support for your betas,
> if people feel they use them to no avail.
I totally agree!
You (TT) can't just break things left and right and say "well, we'll
fix it in the next version (maybe)". By then there will probably
be so many new bugs in there that you'll lose track of all the old
bugs. And if a bug is in there long enough, you tend to call it a
"feature" (just think if the infamous QTreeWidget::setCurrentItem(),
which also messes up the selection state if the item!).
Maybe you guys should stop implementing new things and concentrate
on making the current version more stable and bug free. I'd happily
wait a little longer and get a really stable version than get a
buggy version "on schedule" and have to patch all sorts of stuff
later. Keep in mind that we are making a commercial product with
Qt, and every Qt bug in there reported by our users will primarily
be considered *our* fault! Our customers don't care if we tell
them "well, that's a Qt bug, and hopefully Trolltech will fix it
some day".
Klaus Schmidinger
--
[ signature omitted ]
Message 7 in thread
> Maybe you guys should stop implementing new things and concentrate
> on making the current version more stable and bug free. I'd happily
> wait a little longer and get a really stable version than get a
> buggy version "on schedule" and have to patch all sorts of stuff
> later. Keep in mind that we are making a commercial product with
> Qt, and every Qt bug in there reported by our users will primarily
> be considered *our* fault! Our customers don't care if we tell
> them "well, that's a Qt bug, and hopefully Trolltech will fix it
> some day".
I'd support this policy. Similar experiences are the cause we're (to be
exact, I am) still stuck with Qt 4.1 here - we tried 4.2.2 (that's three
releases into the 4.2 line!) once and weren't convinced of the results
with our existing code... Made not a really good expression, even on my
boss who's a developer himself and not pointy-haired.
What makes things worse, using the dynamic lib of Qt we're bound to port
and test *all* of our existing apps if we're going to switch to a more
current Qt. As nice as many new features would be, the rational decision
is to skip them and further use the existing workarounds instead of
introducing new, unknown bugs. So now I'm still waiting for an
opportunity to test and switch to a current, decent Qt 4.2...
Martin
--
[ signature omitted ]
Message 8 in thread
Martin Gebert wrote:
> What makes things worse, using the dynamic lib of Qt we're bound to port
> and test *all* of our existing apps if we're going to switch to a more
> current Qt. As nice as many new features would be, the rational decision
> is to skip them and further use the existing workarounds instead of
> introducing new, unknown bugs. So now I'm still waiting for an
> opportunity to test and switch to a current, decent Qt 4.2...
I'm in the process of porting our application suite (more than 100000 lines
Qt related code) from Qt3.3 to Qt4. I will be glad enough, if it will work
some day as stable at is does with Qt3, but there is absolutely no time for
introducing new features: all we need today is stability. (By the way: the
costs for the port exceed by far what we have paid for the licenses in the
last years.)
Nothing is more boring than wasting time on known bugs. So if my vote
counts: I would like to see Qt 4.2.x bugfix releases + no 4.3 releases only
because of a schedule.
Uwe
--
[ signature omitted ]
Message 9 in thread
> Nothing is more boring than wasting time on known bugs. So if my vote
> counts: I would like to see Qt 4.2.x bugfix releases + no 4.3 releases only
> because of a schedule.
I totally agree here!
I don't understand the policy of "timed releases" at all: If something
is not ready, you cannot release it yet but have to fix the known issues
before.
Just delegating fixes to later versions doesn't really help.
You can delay new features, but known bugs have to be fixed or at least
worked around.
\Ralf
--
[ signature omitted ]
Message 10 in thread
> What makes things worse, using the dynamic lib of Qt we're bound to port
> and test *all* of our existing apps if we're going to switch to a more
> current Qt.
Just an afterthought, perhaps worth to be discussed and considered:
Wouldn't it, by hindsight, have made sense for Qt 4.2 to finally give up
the binary and code compatibility pursue and made the libs a
Qt<module>42.* ? IMHO that would have made room for long suggested
improvements that require to break compatibility, and it would have been
a chance to port existing Qt4 apps piece by piece. All in all, I think
it would have taken pressure from both Trolltech and (commercial) Qt
developers. Meanwhile I even tend to consider the Qt<module>4.* branch
to be on the declining part of its lifespan... :-(
Martin
--
[ signature omitted ]
Message 11 in thread
Hi Andreas,
> If you could have 4.3.0 on schedule, or a bugfix in QMenuBar for people who
> frequently click the menu three times doing anything else, who now need to
> click four times, on Unix only. If you got to choose, would you postpone
> the release?
If this was the only bug, one could surely live with that for the time being, but regarding the list of open issues that have been postponed
from 4.3 to 4.3.1 just because of a "schedule", it is not ok.
As it looks like at the moment, our customers (engineers in the field of gearboxes/transmissions) have to live with a painting
issue (156964) until 4.3.1 comes out.
But maybe it gets postponed again, we've had that before, too:
A "priority 1" bug gets re-scheduled again and again, from 4.2.0 to now 4.4.0! (119433)
This is not pleasing.
\Ralf
--
[ signature omitted ]
Message 12 in thread
Andreas Aardal Hanssen wrote:
> Klaus Schmidinger wrote:
>> I already had a lengthy conversation with qt-bugs, and they finally
>> confirmed that it is actually reproducable under Linux. Why they won't
>> fix it for version 4.3.0 beats me.
>
> Hi, Klaus.
>
> If you could have 4.3.0 on schedule, or a bugfix in QMenuBar for people who
> frequently click the menu three times doing anything else, who now need to
> click four times, on Unix only. If you got to choose, would you postpone
> the release?
Just to make sure you get the reply (I've alread responded to Scott Aron
Bloom's posting):
If I have the choice between a buggy version "on schedule" and a
stable version with some delay, I'd chose the stable version in a
heartbeat!
Keep in mind that any bug our users find in our application will
be considered *our* fault - our customers don't care if we tell them
"it's not our fault - it was Trolltech who messed up!". They didn't
buy the program from Trolltech, but from *us*.
Ok, meanwhile you have apparently managed to fix this in the current
Qt4.3 snapshot. Just one more thing: the task tracker says that the fix
is scheduled for Qt 4.3.1 - can we be sure that this fix will be in
the final version 4.3.0?
Klaus Schmidinger
--
[ signature omitted ]
Message 13 in thread
Klaus Schmidinger schrieb:
> Ok, meanwhile you have apparently managed to fix this in the current
> Qt4.3 snapshot. Just one more thing: the task tracker says that the
fix
> is scheduled for Qt 4.3.1 - can we be sure that this fix will be in
> the final version 4.3.0?
the last lines in the history are:
2007-04-20 14:05 - Resolution set to 'Fixed'
2007-04-23 17:03 - Version for fix set to '4.3.0 (Next Minor Release)'
so yes, it's safe to say this will be in the final version 4.3.0
Cheers,
Peter
--
[ signature omitted ]
