Qt-interest Archive, September 2005
SuSE 9.3 problem?
Message 1 in thread
We have an odd case with a customer using our application on SuSE 9.3
where a message box asking for yes or no always returns back no to the
application so they can't carry on. There was a thread on this list
about something like this before and I was wondering if anyone ever
found the problem or if anyone knows of a work-around besides reloading
the whole computer with SuSE 9.2.
--
[ signature omitted ]
Message 2 in thread
Hello,
Brad Pepers wrote:
> We have an odd case with a customer using our application on SuSE 9.3
> where a message box asking for yes or no always returns back no to the
> application so they can't carry on. There was a thread on this list
> about something like this before and I was wondering if anyone ever
> found the problem or if anyone knows of a work-around besides reloading
> the whole computer with SuSE 9.2.
We have the same problem with LinCVS. And the Scribus team also.
Therefore we provide a statically linked binary.
Best regards, Tilo
--
[ signature omitted ]
Message 3 in thread
Tilo Riemer wrote:
> Hello,
>
> Brad Pepers wrote:
>
>> We have an odd case with a customer using our application on SuSE 9.3
>> where a message box asking for yes or no always returns back no to the
>> application so they can't carry on. There was a thread on this list
>> about something like this before and I was wondering if anyone ever
>> found the problem or if anyone knows of a work-around besides reloading
>> the whole computer with SuSE 9.2.
>
>
> We have the same problem with LinCVS. And the Scribus team also.
> Therefore we provide a statically linked binary.
Thanks for the quick response! Its quite sad really though. Anyone
take it up with SuSE and try to get it fixed? You would think with
LinCVS and Scribus and our application that they would have to admit
there was a problem!
If you use a statically compiled version you won't be able to load the
styles so your application won't look as good and of course if bugs are
fixed in libraries, you won't be able to take advantage of it because of
the static compile so I've tried to stay away from a static version but
I guess I may have to do one.
What distribution do you do the static compile on?
--
[ signature omitted ]
Message 4 in thread
Hello,
Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> Thanks for the quick response! Its quite sad really though. Anyone
> take it up with SuSE and try to get it fixed? You would think with
> LinCVS and Scribus and our application that they would have to admit
> there was a problem!
Yes, I think. I'm sure that's a SuSE problem. It works on Windows, on
NetBSD, on Ubuntu. It works with a self compiled Qt from Trolltech.
> If you use a statically compiled version you won't be able to load
> the styles so your application won't look as good and of course if
> bugs are fixed in libraries, you won't be able to take advantage of it
> because of the static compile so I've tried to stay away from a static
> version but I guess I may have to do one.
There are some disadvantages of course. But it's the simplest solution.
Only SuSE is affected, no other distribution. And everyone has the
possibility to compile LinCVS by oneself using a working Qt version.
> What distribution do you do the static compile on?
SuSE 9.3 ;-)
With a original self compiled Qt.
Best regards, Tilo
--
[ signature omitted ]
Message 5 in thread
Tilo Riemer wrote:
> Hello,
>
> Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
>
>>Thanks for the quick response! Its quite sad really though. Anyone
>>take it up with SuSE and try to get it fixed? You would think with
>>LinCVS and Scribus and our application that they would have to admit
>>there was a problem!
>
> Yes, I think. I'm sure that's a SuSE problem. It works on Windows, on
> NetBSD, on Ubuntu. It works with a self compiled Qt from Trolltech.
I've found that at least in SuSE 9.3 there are patches installed to Qt
when its built that enable integration with KDE for all Qt applications.
What it does is capture calls to the file dialog, color dialog, font
dialog, and more interestingly the messagebox dialogs. If enabled it
then calls a replacement function instead of the Qt one that does the
same work but uses KDE methods. So I suspect the problem is in there.
Also it looks like there is no such code in SuSE 9.2 so it might have
just been added in 9.3.
One nice thing is that they built in a couple ways to disable it if
needed. If the environment variable QT_NO_KDE_INTEGRATION is set to 1
before any dialogs are opened then the original Qt dialogs will be used.
Also there is an extern bool qt_use_native_dialogs that can be set to
true to also disable it. The environment variable stops it only for the
first time when its trying to initialize itself but the bool would work
at any time so you could turn the integration on and off at will.
So I think a workaround to this on SuSE 9.3 might be to add a line of
code that does a setenv("QT_NO_KDE_INTEGRATION", "1") early on in your
program and then the native Qt dialogs will be used which I suspect
would fix the problem!
If you can reproduce the problem easily and give this fix a try, let me
know if it works or not. I don't have an easy way to make the problem
happen at will here but I'm going to make the change and install it on a
customers computer and just wait and see if the problem goes away or not.
BTW: I had a quick look at the code for the KDE replacement to the Qt
dialogs and what I suspect is that if the order of the buttons on your
dialog are not in the Yes/No/Cancel order then thats what triggers the
problem so if you have some dialogs that you know are causing problems,
can you check the order of the buttons and let me know?
--
[ signature omitted ]
Message 6 in thread
Just a follow up to the problem. Its nothing to do with the order of
the buttons. Its just a coding mistake on the part of the SuSE people
who wrote the replacement KDE function. If the KDE replacement is used
the message box returns back the button *number* picked and not the
identity of the button that was picked. So if your dialog uses
QMessageBox::Yes and QMessageBox::No then the KDE function will return
back 0 or 1 depending on which button was picked instead of the proper
values of QMessageBox::Yes or QMessageBox::No and then if your code is
comparing the return against QMessageBox::Yes/No it won't match. It
looks like they only tested the case where you pass the button text to
the dialog in which case it should be returning back the button number.
I'll try to get SuSE to fix the problem but if there happens to be a
SuSE person on this list, let me know that you are working to fix it.
The problem will cause many non-KDE Qt applications to fail on SuSE 9.3
and it should be fixed!
--
[ signature omitted ]
Message 7 in thread
Hello,
Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> If the KDE replacement is
> used the message box returns back the button *number* picked and not
> the identity of the button that was picked. So if your dialog uses
> QMessageBox::Yes and QMessageBox::No then the KDE function will
> return back 0 or 1 depending on which button was picked instead of the
> proper values of QMessageBox::Yes or QMessageBox::No and then if your
> code is comparing the return against QMessageBox::Yes/No it won't
> match.
That correlates with our observations.
> I'll try to get SuSE to fix the problem but if there happens to be a
> SuSE person on this list, let me know that you are working to fix it.
The problem is known since some weeks. I have few hope that someone from
SuSE has noted it.
> The problem will cause many non-KDE Qt applications to fail on SuSE
> 9.3 and it should be fixed!
Yes, that's right.
Best regards, Tilo
--
[ signature omitted ]
Message 8 in thread
I wrote this little test program and ran it on SuSE 9.3 and it shows
that the QMessageBox::warning is returning 0 or 1 but if I set
QT_NO_KDE_INTEGRATION to 1 in the environment and run it again, the
results are 3 and 4 as they should be so thats the problem all right and
just setting QT_NO_KDE_INTEGRATION is a work around for now. I hope
SuSE puts out a proper fix for it soon!
Here is the test program:
#include <qapplication.h>
#include <qmessagebox.h>
int
main(int argc, char** argv)
{
QApplication app(argc, argv);
int ch = QMessageBox::warning(NULL, "Test", "This is a test dialog",
QMessageBox::Yes, QMessageBox::No);
qDebug("choice = %d", ch);
return 0;
}
--
[ signature omitted ]
Message 9 in thread
Hello,
Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> I wrote this little test program and ran it on SuSE 9.3 and it shows
> that the QMessageBox::warning is returning 0 or 1 but if I set
> QT_NO_KDE_INTEGRATION to 1 in the environment and run it again, the
> results are 3 and 4 as they should be so thats the problem all right
> and
> just setting QT_NO_KDE_INTEGRATION is a work around for now. I hope
> SuSE puts out a proper fix for it soon!
Thanks. I will test it and add a workaround.
Best regards, Tilo
--
[ signature omitted ]
Message 10 in thread
Hello,
I tested setting of QT_NO_KDE_INTEGRATION and it worked as expected. It
used Qt dialogs instead of KDE dialogs and QMessagebox did work.
Then I tested it with KDE dialogs *ooops*
It works also. The KDE Messagebox returns the right values.
I don*t know when SuSE has updated KDE... can someone confirm it? I use
SuSE 9.3
Best regards, Tilo
--
[ signature omitted ]
Message 11 in thread
Tilo Riemer wrote:
> Hello,
>
> I tested setting of QT_NO_KDE_INTEGRATION and it worked as expected. It
> used Qt dialogs instead of KDE dialogs and QMessagebox did work.
>
> Then I tested it with KDE dialogs *ooops*
> It works also. The KDE Messagebox returns the right values.
>
> I don*t know when SuSE has updated KDE... can someone confirm it? I use
> SuSE 9.3
It returns the right values when using the button id method or the text
method of using QMessageBox? The text method is right but the button id
method is the one thats broken. I just checked and I have all the
latest updates from SuSE on 9.3 and my test program still shows the
problem. Can you confirm how you are testing and the QMessageBox call
you are using. Ideally try the test program I wrote both with and
without setting the QT_NO_KDE_INTEGRATION environment var and see if you
get the same results from the program both ways. I don't here and users
have reported setting the env var fixed their problems so I'm pretty
sure the problem is still there for you too.
--
[ signature omitted ]
Message 12 in thread
Hello,
Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> It returns the right values when using the button id method or the
> text method of using QMessageBox?
The button id method!
We have played with the idea to switch to text method but this causes
unusing of icons for yes/no and so on.
> Can you confirm how you are testing and the QMessageBox
> call you are using.
I think in the same way which you go in your example...
but testing it with your example the Messagebox returns 0 and 1 :-(
and 3 and 4 after setting QT_NO_*
Strange.
I will check it later.
Best regards, Tilo
--
[ signature omitted ]
Message 13 in thread
On Thursday 15 September 2005 23:33, Tilo Riemer wrote:
> Hello,
>
> Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> > It returns the right values when using the button id method or the
> > text method of using QMessageBox?
>
> The button id method!
>
> We have played with the idea to switch to text method but this causes
> unusing of icons for yes/no and so on.
>
> > Can you confirm how you are testing and the QMessageBox
> > call you are using.
>
> I think in the same way which you go in your example...
>
> but testing it with your example the Messagebox returns 0 and 1 :-(
> and 3 and 4 after setting QT_NO_*
>
> Strange.
> I will check it later.
>
>
> Best regards, Tilo
I can confirm exporting this variable fixes the couple of issues Suse 9.3
users have come across with Scribus.
Craig
--
[ signature omitted ]
Message 14 in thread
Hello,
Zitat von Brad Pepers <brad@xxxxxxxxxxxxxxx>:
> Also there is an extern bool qt_use_native_dialogs that can be set
> to true to also disable it. The environment variable stops it only
> for the first time when its trying to initialize itself but the bool
> would work at any time so you could turn the integration on and off at
> will.
Great :-)))
So we can fix this ugly problem. Thank you very much.
> So I think a workaround to this on SuSE 9.3 might be to add a line of
> code that does a setenv("QT_NO_KDE_INTEGRATION", "1") early on in
> your program and then the native Qt dialogs will be used which I
> suspect would fix the problem!
We will test it.
> If you can reproduce the problem easily and give this fix a try, let
> me know if it works or not.
Yes of course. I think this evening...
> BTW: I had a quick look at the code for the KDE replacement to the Qt
> dialogs and what I suspect is that if the order of the buttons on
> your
> dialog are not in the Yes/No/Cancel order then thats what triggers
> the
> problem so if you have some dialogs that you know are causing
> problems,
> can you check the order of the buttons and let me know?
Our order is from left to right: Yes, No.
Best regards, Tilo
--
[ signature omitted ]
Message 15 in thread
# From: Brad Pepers [mailto:brad@xxxxxxxxxxxxxxx]
# Sent: Thursday, September 15, 2005 6:34 AM
# To: Tilo Riemer
# Cc: QT Interest Maillist
# Subject: Re: SuSE 9.3 problem?
#
# I wrote this little test program and ran it on SuSE 9.3 and it shows
# that the QMessageBox::warning is returning 0 or 1 but if I set
# QT_NO_KDE_INTEGRATION to 1 in the environment and run it again, the
# results are 3 and 4 as they should be so thats the problem
# all right and just setting QT_NO_KDE_INTEGRATION is a work around for
# now. I hope SuSE puts out a proper fix for it soon!
Good news is that my experience is that the folks at SuSE are very quick
to turn these things around once someone tells them about it (especially
if it's explained in the level of detail that is has been here).
Good sleuthing...
--
[ signature omitted ]
