How can I reopen a tracker bug report?
-
This bug report should not be closed, especially not for the reason of KDE root cause.
https://bugreports.qt.io/browse/QTBUG-7814
The issue still exists.
-
Hi @nulluse, and welcome to the Qt Dev Net!
I recommend you first test this on a system with the latest version of KDE, and open a new bug report if the issue persists in this latest version. Qt 4 and KDE SC 4 have both been discontinued long ago; all development efforts are now focussed on Qt 5 and KDE Frameworks/Plasma 5.
Also, have you tried the workaround suggested by Tom Bowles in that report? (call setViewportUpdateMode() on the QGraphicsView, and set the update mode to FullViewportUpdate)
@nulluse said:
This bug report should not be closed, especially not for the reason of KDE root cause.
Since the bug was not in Qt, and the engineer learned that the bug was fixed in KDE, then closing the report in the Qt bug tracker as "Out of Scope" was a perfectly reasonable thing to do. Note that Qt and KDE are different projects (KDE uses Qt).
-
This was tested on the latest PCBSD system with whatever version of KDE that the users will have to stick with for the next year or two. Jira says the issue can be reopened. As this is exact same issue, it should be reopened as apparently nothing has been done in 6 years to resolve it. Any lapses in logic?
-
I forgot to ask: What version of Qt are you using?
@nulluse said:
This was tested on the latest PCBSD system with whatever version of KDE that the users will have to stick with for the next year or two.
I meant the latest version of KDE, not the latest version of PC-BSD.
The latest PC-BSD uses an old version of KDE, which is no longer actively maintained. Even if you prove that there's a bug in KDE SC 4.14.3 and (re)open the bug report, I'm not sure if anyone on the KDE team will fix it. On the other hand, if you prove that the bug exists on the latest version of KDE, then it's much more likely to get fixed upstream.
Alternatively, you can report this to the PC-BSD team and see if they are willing to patch the old version KDE that they have chosen to support.
Alternatively, you can try the workaround that Tom Bowles suggested.
-
Not every OS packages the latest KDE. Especially that latest usually means full of bugs and volatile. Pushing everyone to use the latest version cannot be realistically welcomed by all.
@nulluse said:
Not every OS packages the latest KDE. Especially that latest usually means full of bugs and volatile. Pushing everyone to use the latest version cannot be realistically welcomed by all.
I agree and sympathize, however, do note that Qt 4.6 was released a bit over 6 years ago (1 December 2009), and Qt 4.8 was marked deprecated (not encouraged for active development) recently. So I do agree that while the bug hadn't been fixed in a timely fashion by the KDE folks, it is of no consequence to a distribution with a feasible release cycle (supposedly 2-3 years). From what I can tell KDE SC 4 is already 6 years old, and extending its usage further doesn't sound very viable.
Additionally, I concur with @JKSH that your best bet is to try and appeal to your distributions' package maintainer to port the fix from the newer to the older version that's distributed, provided the workaround from the JIRA's comments doesn't work.Kind regards.
-
My best bet is to abandon this altogether as it is clear no one is willing to do anything.
This problem exists under:Awesome
Fluxbox
KDE
Gnome
MATE
FVWM
IceWM
WindowmakerAnd the only window manager that did not have this problem was Cinnamon. So yes, blame KDE!
-
My best bet is to abandon this altogether as it is clear no one is willing to do anything.
This problem exists under:Awesome
Fluxbox
KDE
Gnome
MATE
FVWM
IceWM
WindowmakerAnd the only window manager that did not have this problem was Cinnamon. So yes, blame KDE!
@nulluse
I can't do anything but give advice or rather suggestions on how to fix your problem. I personally use Debian testing, but the stable flavor of said distribution had already migrated to Qt 5.3, so besides what I wrote in my previous post I have no idea how else I can be of help to you. Qt 4.6 is a pretty old release and I really doubt that someone from KDE will go poke into this to fix it, you could try, but don't expect miracles. Whether it's a Qt problem or KDE, I can't say, but the same thing applies to the Qt team, I don't believe anyone will go back and fix that version.Kind regards.
Read and abide by the Qt Code of Conduct
-
@nulluse
I can't do anything but give advice or rather suggestions on how to fix your problem. I personally use Debian testing, but the stable flavor of said distribution had already migrated to Qt 5.3, so besides what I wrote in my previous post I have no idea how else I can be of help to you. Qt 4.6 is a pretty old release and I really doubt that someone from KDE will go poke into this to fix it, you could try, but don't expect miracles. Whether it's a Qt problem or KDE, I can't say, but the same thing applies to the Qt team, I don't believe anyone will go back and fix that version.Kind regards.
-
@nulluse said:
what on Earth does this have to do with KDE?
I base the KDE reference on the following bug report comment:
IIRC this was a bug in Oxygen which has been fixed in recent KDE version.
However, whether it's a bug in Qt or KDE is not invalidating my other point.
-
My best bet is to abandon this altogether as it is clear no one is willing to do anything.
This problem exists under:Awesome
Fluxbox
KDE
Gnome
MATE
FVWM
IceWM
WindowmakerAnd the only window manager that did not have this problem was Cinnamon. So yes, blame KDE!
@nulluse said:
it is clear no one is willing to do anything.
That 6-year old workaround that I mentioned twice... Does it not work, or have you simply not tried it?
This problem exists under:
Awesome
Fluxbox
KDE
Gnome
MATE
FVWM
IceWM
WindowmakerAnd the only window manager that did not have this problem was Cinnamon. So yes, blame KDE!
If that's the case, then it's plausible that the issue is in Qt. I tested it on Windows 10 and Ubuntu 15.10 (Unity) though, and rubber bands in QGraphicsView works fine on both using Qt 5.5.1 -- no artifacts like the screenshots.
Given the age of the original report, I recommend opening a new one instead of re-opening the old one. You can provide a link to the original report. Make sure you include the version numbers of the window managers, OSes, and Qt where you encountered this.
-
Your own bug tracker Jira shows this baloon when hovering over a Closed ticket:
Closed
The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.So what is the process of re-opening a ticket?
I have to reopen an handful as you are rushing to close them before resolution. -
Your own bug tracker Jira shows this baloon when hovering over a Closed ticket:
Closed
The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.So what is the process of re-opening a ticket?
I have to reopen an handful as you are rushing to close them before resolution.@nulluse said:
So what is the process of re-opening a ticket?
You can contact the Qt engineers and request tickets to be reopened by subscribing to the Development mailing list and posting there.
Just so that there's no misunderstanding: The Qt engineers do not frequent this forum. We (the people who respond to you on this forum) are mainly users of Qt, just like yourself. We do not have the ability to close or reopen tickets.
I have to reopen an handful as you are rushing to close them before resolution.
Please refrain from passive-aggressive statements like this. They do not add any value to the discussion; they do not help anyone.
And from what I've seen over the past few years, requests that are passive-aggressive, rude, demanding, etc. tend to get ignored in the Development mailing list. You're more likely to get what you want if you write civilly.
