Qt-interest Archive, May 2008
Re: When exiting, Qt 4 apps wreak havoc on my X11 display
Message 1 in thread
Hi,
> > That's probably an icewm issue.
> The same icewm does not do it on Qt 4.0.1 nor with any other app I ran.
The window manager shouldn't freeze or shift down windows unrelated to the Qt
application. It really looks like an icewm bug.
Imagine a Qt application crashing the Linux kernel. You can't blame Qt, it's a
kernel issue: the kernel simply shouldn't crash. This issue at hand is
somewhat similar.
>> Have you tried a newer version of Qt?
> I'm afraid I don't have the option to spend half of my time upgrading
> this upgrading that and the other half solving the new problems arising...
Said otherwise, if you can't spend time fixing the problem on your side, don't
expect users on this list to spend time helping you fix the problem.
>> Which version of icewm is this?
> icewm-1.2.26
>
>> Is a newer version of icewm available?
> Yes. I tried to compile the last stable version icewm-1.2.35 with the
> light option on but compilation failed.
Since this looks like an icewm issue, you really need to try and upgrade
icewm. Please tell us how it goes once you've installed a newer icewm.
>> Which exact Linux distribution?
> I'm still running an old Fedora Core 2. I rather upgrade programs
> individually, when necessary. I have an Ubuntu 7.10 at hand but I just
> don't want to run into days or weeks of uninteresting problem solving (I
> speak for myself, and I could as well say loss of time) to go back to my
> current functionality level.
If I recall correctly, you've already written to this list about problems on
this heavily customized Fedora Core 2 machine. These problems couldn't be
reproduced by anyone else, just like the current problem. Chances are the
problem is caused by incompatibilities in the software stack on this machine,
and not by Qt. I think you'll probably spend less time solving uninteresting
problems by using a standard distribution instead of using an old and heavily
customized distribution.
--
[ signature omitted ]
Message 2 in thread
Hi all,
Dimitri écrivait:
> The window manager shouldn't freeze or shift down windows unrelated to
> the Qt application. It really looks like an icewm bug.
>
> Imagine a Qt application crashing the Linux kernel. You can't blame Qt,
> it's a kernel issue: the kernel simply shouldn't crash. This issue at
> hand is somewhat similar.
Maybe we could turn it that way: Qt 4.2.2 apps revealed a hidden problem
in icewm-1.2.26. I now installed the full version of icewm-1.2.35 and
this very unpleasant symptom (I have a clock - with no frame to move it
- handle that was wandering on the screen) disappeared.
> Said otherwise, if you can't spend time fixing the problem on your side,
> don't expect users on this list to spend time helping you fix the problem.
The only thing I was not willing to do in your list of suggestions was
upgrading Qt. Each time you have a problem do you upgrade everything on
your computer and only then ask for help ?
> Since this looks like an icewm issue, you really need to try and upgrade
> icewm. Please tell us how it goes once you've installed a newer icewm.
You were pretty well right ! I'm glad I did not upgrade Qt for that matter.
4.2.2. is almost too new for the purpose and hardware of the concerned
computer!
>>> Which exact Linux distribution?
>> I'm still running an old Fedora Core 2. I rather upgrade programs
>> individually, when necessary. I have an Ubuntu 7.10 at hand but I just
>> don't want to run into days or weeks of uninteresting problem solving
>> (I speak for myself, and I could as well say loss of time) to go back
>> to my current functionality level.
>
> If I recall correctly, you've already written to this list about
> problems on this heavily customized Fedora Core 2 machine. These
> problems couldn't be reproduced by anyone else, just like the current
> problem.
I run different computers in different contexts and different configs.
As to the few issues I reported to this list before this one, all were
*strictly Qt problems*. Some were solved by upgrading Qt, some were
solved right away due to the very competent advice I got, some I could
solve myself or workaround thanks to the clever hints given, and some
were Qt bugs.
None of those issues were due to the particular config where they were
observed.
You know, I use Linux for several reasons, one of which being that I
like to be able to do what I want with my config(s). If you think one
should upgrade everything before trying other solutions, this is just as
much your right than it is mine to run the config I please.
I stick to have an old config at hand for different reasons, one being
to have more chances that my programs will run on the average user's
machine. Isn't backward compatibility more generally observed than
forward compatibility ?
Well now of course I wrote this message a bit out of frustration.
Probabbly I should have refrained. But it was nice to talk with you anyway.
Thanks again for your help,
--
[ signature omitted ]
Message 3 in thread
Hi,
> The only thing I was not willing to do in your list of suggestions was
> upgrading Qt. Each time you have a problem do you upgrade everything on
> your computer and only then ask for help ?
I didn't ask to upgrade "everything" - just Qt.
> You know, I use Linux for several reasons, one of which being that I
> like to be able to do what I want with my config(s). If you think one
> should upgrade everything before trying other solutions, this is just as
> much your right than it is mine to run the config I please.
> I stick to have an old config at hand for different reasons, one being
> to have more chances that my programs will run on the average user's
> machine.
I certainly didn't mean to say it's a bad idea to have such an atypical
machine for testing purposes. However the consequence is that you'll have to
spend extra time to make sure your program runs on this machine, whether the
problem originates in Qt or not. Also, it's best to test on a common system
(such as Ubuntu 7.10) before reporting a problem to the mailing list. The
benefits are:
* we know the problem is related to broken versions or incompatibilities in
the specific software stack,
* other users might be able to reproduce the problem if it can be reproduced
on a common system, but they won't be able to test on a system like yours,
* other users might be more eager to help if they see you've already made the
extra effort to test on a common system.
--
[ signature omitted ]
Message 4 in thread
On Friday 02 May 2008 19:02:16 Dimitri wrote:
> Also, it's best to test on a common
> system (such as Ubuntu 7.10) before reporting a problem to the mailing
> list.
please do not report bugs of a fork upstream.
--
[ signature omitted ]
Message 5 in thread
Hi,
>> Also, it's best to test on a common
>> system (such as Ubuntu 7.10) before reporting a problem to the mailing
>> list.
> please do not report bugs of a fork upstream.
What do you mean by that? A Qt fork? Alexandre has not forked Qt as far as I
could understand. I was just suggesting he builds Qt and runs programs on a
more common system before reporting issues.
--
[ signature omitted ]
Message 6 in thread
Alexandre Oberlin wrote:
> Dimitri écrivit:
>> Hi,
>>
>>> I'm afraid I don't have the option to spend half of my time upgrading
>>> this upgrading that and the other half solving the new problems
>>> arising...
>>
>> Then I'm afraid I won't have time to help either :-)
>>
>
> This philosophy looks more and more like the old "You should reinstall
> Windows" ;-)
No it's more like the old "Oh you are running (unsupported) Windows 95, and
you've hacked the daylights out of it and expect stuff written years later
to work on it and if something goes wrong it's not worth your time to do
any troubleshooting but rather expect others to solve your problems on the
bastardized and old system for free? Well then good luck to you, it won't
be me." philosophy. ;^)
--
[ signature omitted ]
