[kdelibs] [Bug 355275] kdelibs upgrade - Kopete crashes after closing a window
https://bugs.kde.org/show_bug.cgi?id=355275 Alexey Chernov <4er...@gmail.com> changed: What|Removed |Added CC||4er...@gmail.com --- Comment #51 from Alexey Chernov <4er...@gmail.com> --- Sorry for being too late, I faced this issue while porting Kopete to KF5 and fixed it with some minor commit: https://quickgit.kde.org/?p=kopete.git=commit=0f259ada3a4646b0230d6870ff185adfcb3b1085. To my investigation on this crash, it seems to be not due to the deletion order itself, but because of reparenting KHTML's view() subpart from previous parent specified in ctor call to QSplitter which leads to double deletion of the widget. I didn't dig into details, but in my toy application with KParts this is not preproducible without KHTML. Given that specifying parent for widget which gets reparented in a couple of lines doesn't change things too seriously, I just removed this specification. In general, it seems that there's some issue with parent changing and double deletion. @Alex Merry probably have more details on this, maybe he has some ideas about the actual cause according to this. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 292215] KDevelop crashes when no disk space on volume where project is placed
https://bugs.kde.org/show_bug.cgi?id=292215 --- Comment #3 from Alexey Chernov <4er...@gmail.com> --- Yes, I see. No problem. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 --- Comment #63 from Alexey Chernov <4er...@gmail.com> --- (In reply to John Stanley from comment #62) > (In reply to Alexey Chernov from comment #61) > > (In reply to John Stanley from comment #60) > > > (In reply to Alexey Chernov from comment #56) > > > > I've just applied and quite intensively tested two patches John > > > > attached. > > > > > > > > At first for patches: I've actually looked through them before > > > > applying, and > > > > there're a couple of questions: > > > > > > > > 1. I've modified kxmlgui patch a little — at first I've replaces close > > > > event > > > > stuff for calling queryClose() method. Following XSM protocol one is not > > > > allowed to close windows on the saving state as a) this is not necessary > > > > shutdown that save-yourself is triggered , it is explicitly stated in > > > > the > > > > documentation, and b) shutdown, if any, could normally be cancelled and > > > > session would continue, and closing some windows would just spoil this > > > > user's session. > > > Agreed. But, the close event here is actually "fake", no windows are > > > actually closed. In tracing queryClose(), it seemed appropriate to hook > > > KMainWindow::closeEvent() in KMainWindow::commitData() to pick up the > > > "auto > > > save" functionality in KMainWindow::closeEvent(). > > > KMainWindow::closeEvent() > > > potentially does some KMainWindow-specific auto saving, and then simply > > > calls queryClose(). > > > Anyway, I'm happy to go with your call on this, but have a look at > > > KMainWindow::closeEvent() if you haven't already. > > > > Yeah, I've looked at it just briefly applying the patch and now have looked > > closer. As far as I can see, it still can close window as soon as > > queryClose() returns true (as it accepts the event). But you're right that > > there's some code of auto-saving, yes. > > > Yea, but, in this case we are instigating the CloseEvent (not Qt via > close()/quit() for example), and so as I understand it, no actual close will > be triggered by event acceptance here. That is, I thought that an actual > close is done by Qt in, e.g., the close() method after Qt does a sendEvent() > and checks for acceptance Here, we only use sendEvent() to decide whether or > not to cancel the session Yes, you're probably right then, since we send close event by ourselves. I think, it's quite easy to test this as well — just left one client untouched and another one with modifications before logging out, cancel the shutdown in the latter and see what happens. I believe, you have tried the initial version of the patch, did you happen to follow this scenario? > > Another problem arises in that basically the client should ask session > > manager a permission to interact with the user to get the monopoly > > attention, but it's not so, as queryClose doesn't have any clue of session > > manager, it just shows the dialog. But still such things are minor, we need > > to bring back session restore first. > > > > > > Another thing I removed is restore() method which is obviously the same > > > > as > > > > before, but always returns false. Is there any reason for it? > > > > > > > The KMainWindow::restore() currently always returns false, which is not > > > useful for apps that choose to iterate over windows for multi-window > > > restorations (using a false return code terminate iteration). My change is > > > to return true on successful restoration, and false otherwise. > > > > Oh, yes, didn't notice, thanks for pointing out. > > > > > > 2. KSMServer patch is what I first have tried not to apply at all. > > > > Except > > > > the first edit, which seems to be right as it's just follows the > > > > comment, > > > > other stuff seems to be redundant. Could you please explain you ideas > > > > behind > > > > these changes? Anyway, everything works even without it (see below). > > > > > > > Yup, the first edit is the only important one. The others, well, I was > > > tinkering a bit, and thinking of doing more, but its a bit > > > time-consuming; I > > > should have removed them before posting. The final two edits are merely > > > code > > > restructuring, no functional changes, should've removed 'em. The remaining > > > edits, associated with "Phase 2 for non-WM clients", are an attempt to > > > allow > > > non-WM apps which want to do their shutdown processing in Phase 2 to do so > > > before the WM is shutdown (also in Phase 2). I don't specifically know of > > > any such apps, but, in principle there could be. > > > > OK. > > > > > > As for testing, I've tested the following use cases: > > > > > > > > 1. Plain saving session. It's generally works even without any patches > > > > (except Qt patch https://codereview.qt-project.org/#/c/140115 I've > > > > applied > > > > much earlier). Works fine. > > > > > > > > 2. Saving session with several "modified" clients — in my case it was > > > > KWrite > > > > with
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 --- Comment #61 from Alexey Chernov <4er...@gmail.com> --- (In reply to John Stanley from comment #60) > (In reply to Alexey Chernov from comment #56) > > I've just applied and quite intensively tested two patches John attached. > > > > At first for patches: I've actually looked through them before applying, and > > there're a couple of questions: > > > > 1. I've modified kxmlgui patch a little — at first I've replaces close event > > stuff for calling queryClose() method. Following XSM protocol one is not > > allowed to close windows on the saving state as a) this is not necessary > > shutdown that save-yourself is triggered , it is explicitly stated in the > > documentation, and b) shutdown, if any, could normally be cancelled and > > session would continue, and closing some windows would just spoil this > > user's session. > Agreed. But, the close event here is actually "fake", no windows are > actually closed. In tracing queryClose(), it seemed appropriate to hook > KMainWindow::closeEvent() in KMainWindow::commitData() to pick up the "auto > save" functionality in KMainWindow::closeEvent(). KMainWindow::closeEvent() > potentially does some KMainWindow-specific auto saving, and then simply > calls queryClose(). > Anyway, I'm happy to go with your call on this, but have a look at > KMainWindow::closeEvent() if you haven't already. Yeah, I've looked at it just briefly applying the patch and now have looked closer. As far as I can see, it still can close window as soon as queryClose() returns true (as it accepts the event). But you're right that there's some code of auto-saving, yes. Another problem arises in that basically the client should ask session manager a permission to interact with the user to get the monopoly attention, but it's not so, as queryClose doesn't have any clue of session manager, it just shows the dialog. But still such things are minor, we need to bring back session restore first. > > Another thing I removed is restore() method which is obviously the same as > > before, but always returns false. Is there any reason for it? > > > The KMainWindow::restore() currently always returns false, which is not > useful for apps that choose to iterate over windows for multi-window > restorations (using a false return code terminate iteration). My change is > to return true on successful restoration, and false otherwise. Oh, yes, didn't notice, thanks for pointing out. > > 2. KSMServer patch is what I first have tried not to apply at all. Except > > the first edit, which seems to be right as it's just follows the comment, > > other stuff seems to be redundant. Could you please explain you ideas behind > > these changes? Anyway, everything works even without it (see below). > > > Yup, the first edit is the only important one. The others, well, I was > tinkering a bit, and thinking of doing more, but its a bit time-consuming; I > should have removed them before posting. The final two edits are merely code > restructuring, no functional changes, should've removed 'em. The remaining > edits, associated with "Phase 2 for non-WM clients", are an attempt to allow > non-WM apps which want to do their shutdown processing in Phase 2 to do so > before the WM is shutdown (also in Phase 2). I don't specifically know of > any such apps, but, in principle there could be. OK. > > As for testing, I've tested the following use cases: > > > > 1. Plain saving session. It's generally works even without any patches > > (except Qt patch https://codereview.qt-project.org/#/c/140115 I've applied > > much earlier). Works fine. > > > > 2. Saving session with several "modified" clients — in my case it was KWrite > > with unsaved document and Konsole with "vim" running in one of the tabs. On > > logging out I was gently and sequencially asked for both KWrite and Konsole. > > Saved nothing and logged out. Works fine. > > > > 3. Triggering session save with several "modified" clients and cancel > > logging out in one of them. In my case they were KWrite again with an > > unsaved document and Kate with an unsaved document. Here I tried two > > sub-clauses: > > > > a) at first, say "don't save" to KWrite and "Cancel" to Kate. Session > > continued successfully, no data is lost in both programs. Just KWin moved > > both of them to "Any virtual desktop" — it's apparently the default > > behaviour, appropriate for now. So works fine; > > > > b) finally, say "save" to KWrite and "don't save" to Kate. Session > > finished and then restored successfully except Kate crashed, which is > > apparently separate bug in Kate, which I will address, too. In terms of SM > > works fine. > > > > As a conclusion, I think, this patch can be candidate for merge right now > > without even waiting for Qt patch — there's no harm in saving documents > > beforehand, but, of course, without Qt changes of this report: > > https://codereview.qt-project.org/#/c/140115 applications won't
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 --- Comment #59 from Alexey Chernov <4er...@gmail.com> --- (In reply to John Stanley from comment #58) > First, thanks so much for looking at this issue. > No I haven't posted to the KDE Reviewboard ; give me a day or two max to > orient myself, and I'll do so. Yes, no problem. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 --- Comment #57 from Alexey Chernov <4er...@gmail.com> --- Created attachment 96997 --> https://bugs.kde.org/attachment.cgi?id=96997=edit KXmlGui patch with my modifications - sending close event was replaced with calling queryClose() as the earlier violates XSMP (http://www.x.org/releases/X11R7.6/doc/libSM/xsmp.html) - changes in restore() method were removed -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 --- Comment #56 from Alexey Chernov <4er...@gmail.com> --- I've just applied and quite intensively tested two patches John attached. At first for patches: I've actually looked through them before applying, and there're a couple of questions: 1. I've modified kxmlgui patch a little — at first I've replaces close event stuff for calling queryClose() method. Following XSM protocol one is not allowed to close windows on the saving state as a) this is not necessary shutdown that save-yourself is triggered , it is explicitly stated in the documentation, and b) shutdown, if any, could normally be cancelled and session would continue, and closing some windows would just spoil this user's session. Another thing I removed is restore() method which is obviously the same as before, but always returns false. Is there any reason for it? 2. KSMServer patch is what I first have tried not to apply at all. Except the first edit, which seems to be right as it's just follows the comment, other stuff seems to be redundant. Could you please explain you ideas behind these changes? Anyway, everything works even without it (see below). As for testing, I've tested the following use cases: 1. Plain saving session. It's generally works even without any patches (except Qt patch https://codereview.qt-project.org/#/c/140115 I've applied much earlier). Works fine. 2. Saving session with several "modified" clients — in my case it was KWrite with unsaved document and Konsole with "vim" running in one of the tabs. On logging out I was gently and sequencially asked for both KWrite and Konsole. Saved nothing and logged out. Works fine. 3. Triggering session save with several "modified" clients and cancel logging out in one of them. In my case they were KWrite again with an unsaved document and Kate with an unsaved document. Here I tried two sub-clauses: a) at first, say "don't save" to KWrite and "Cancel" to Kate. Session continued successfully, no data is lost in both programs. Just KWin moved both of them to "Any virtual desktop" — it's apparently the default behaviour, appropriate for now. So works fine; b) finally, say "save" to KWrite and "don't save" to Kate. Session finished and then restored successfully except Kate crashed, which is apparently separate bug in Kate, which I will address, too. In terms of SM works fine. As a conclusion, I think, this patch can be candidate for merge right now without even waiting for Qt patch — there's no harm in saving documents beforehand, but, of course, without Qt changes of this report: https://codereview.qt-project.org/#/c/140115 applications won't be restarted. I'm attaching the patch with my modification. If there's no objection, John, I'd suggest you as original author to post it to https://reviewboard.kde.org so that we can have it reviewed and potentially merged as soon as possible. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 346768] After login only one tab is present, when several tabs where opened before logout.
https://bugs.kde.org/show_bug.cgi?id=346768 Alexey Chernov <4er...@gmail.com> changed: What|Removed |Added CC||4er...@gmail.com --- Comment #55 from Alexey Chernov <4er...@gmail.com> --- (In reply to John Stanley from comment #51) > (In reply to Wolfram from comment #50) > > (In reply to John Stanley from comment #47) > > > (In reply to Wolfram from comment #46) > > > > (In reply to John Stanley from comment #43) > > > > > Sorry about the the links in Comment 41, (3); there are two links > > > > > there, > > > > > separated by a comma: > > > > > https://bugreports.qt.io/browse/QTBUG-49241 > > > > > https://codereview.qt-project.org/#/c/140115/ > > > > > > > > > > As far as building, you need to rebuild three packages: > > > > > qtbase-5.5.1 ( > > > > > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtbase- > > > > > opensource-src-5.5.1.tar.xz ) > > > > > kxmlgui-5.15.0 ( > > > > > http://download.kde.org/stable/frameworks/5.15/kxmlgui-5.15.0.tar.xz ) > > > > > plasma-workspace-5.4.2 ( > > > > > http://download.kde.org/stable/plasma/5.4.2/plasma-workspace-5.4.2.tar.xz > > > > > ) > > > > > Assuming you already have these installed, the build order is > > > > > immaterial, > > > > > otherwise build in the order shown. > > > > > > > > are the patches included in the tarballs ? > > > > > > The 3 patches, three separate files, one for each package/tarball, are > > > given > > > in Comment 44; they have to be applied before building/rebuilding each > > > package. > > > > Is your patch implemented in KDE by now ? > > > > Because I was not able to compile the environment until now (see Comment > > 48), I just installed Kubuntu 15.10 in a virtual machine with > > 'kubuntu-ppa/staging-plasma' activated. There they use the newest plasma > > version 5.5.3. As result I can say, that the the session management problems > > still exist in that version. > > Sorry, for the delay. I've pretty much given up on both KDE and Qt regarding > this, no movement at all, no one appears to care -- so, no, the patches are > not in the latest KDE (5.5.3/5.18.0). It'd be nice, at least, if someone > would explain why there's no interest.. I think it's partially due to some bugs were closed as duplicate of bug #341930 which continued as bug #354724, there've happened to be several discussions recently, with somewhat contradictory approach with which I personally disagree. I tend to fully support you review request to Qt, set +1 there, and you KDE patches look good as well, it's a shame I just came accross these reports, just after you posted a link in Gerrit. I've got all the KDE stuff compiled from sources, so it's no problem to try and test you patches which I plan to do right away and give them some time of every day work. Just one question: have you posted a review request with these patches on KDE Reviewboard? I'm not sure if I have enough rights to vote there in case patch testing is OK, but still there's better chance to have your patches merged with the review request there. Anyway, thank you for your efforts and apparently right fixes of this whole problem. -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 358315] Typo in .desktop file leads to KRunner freeze
https://bugs.kde.org/show_bug.cgi?id=358315 --- Comment #5 from Alexey Chernov <4er...@gmail.com> --- (In reply to Adrian Piotrowicz from comment #4) > Changing desktop file didn't work for me. It could also be that some other version is caught up in KRunner. In this case cleaning up ~/.local/share/applications worked for me (but be sure you don't have anything useful there, back it up beforehand). -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 358658] .desktop files of agents are read in the incorrect encoding
https://bugs.kde.org/show_bug.cgi?id=358658 Alexey Chernov <4er...@gmail.com> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Latest Commit||http://commits.kde.org/akon ||adi/1e164ae8d50b38c36159539 ||0543ebdeb45231777 Resolution|--- |FIXED --- Comment #3 from Alexey Chernov <4er...@gmail.com> --- Git commit 1e164ae8d50b38c361595390543ebdeb45231777 by Alexey Chernov. Committed on 28/01/2016 at 11:52. Pushed by chernov into branch 'master'. Fix encoding of reading *.desktop files of Akonadi agents Explicitly set UTF-8 encoding of QSettings when reading *.desktop files of agents to prevent any encoding issues. Code parts of string conversion are also removed as now it's done in QSettings internally. REVIEW: 126911 M +3-8src/akonadicontrol/agenttype.cpp http://commits.kde.org/akonadi/1e164ae8d50b38c361595390543ebdeb45231777 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 358658] .desktop files of agents are read in the incorrect encoding
https://bugs.kde.org/show_bug.cgi?id=358658 Alexey Chernov <4er...@gmail.com> changed: What|Removed |Added Latest Commit|http://commits.kde.org/akon |http://commits.kde.org/akon |adi/1e164ae8d50b38c36159539 |adi/de588dc7fd459449ccc1d29 |0543ebdeb45231777 |fb30cee1774837140 --- Comment #4 from Alexey Chernov <4er...@gmail.com> --- Git commit de588dc7fd459449ccc1d29fb30cee1774837140 by Alexey Chernov. Committed on 28/01/2016 at 12:00. Pushed by chernov into branch 'Applications/15.12'. Fix encoding of reading *.desktop files of Akonadi agents Explicitly set UTF-8 encoding of QSettings when reading *.desktop files of agents to prevent any encoding issues. Code parts of string conversion are also removed as now it's done in QSettings internally. REVIEW: 126911 M +3-8src/akonadicontrol/agenttype.cpp http://commits.kde.org/akonadi/de588dc7fd459449ccc1d29fb30cee1774837140 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 358658] .desktop files of agents are read in the incorrect encoding
https://bugs.kde.org/show_bug.cgi?id=358658 --- Comment #1 from Alexey Chernov <4er...@gmail.com> --- Created attachment 96876 --> https://bugs.kde.org/attachment.cgi?id=96876=edit Sample screenshot of the issue. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 358658] .desktop files of agents are read in the incorrect encoding
https://bugs.kde.org/show_bug.cgi?id=358658 --- Comment #2 from Alexey Chernov <4er...@gmail.com> --- Here's a review request link: https://git.reviewboard.kde.org/r/126911/ -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 358658] New: .desktop files of agents are read in the incorrect encoding
https://bugs.kde.org/show_bug.cgi?id=358658 Bug ID: 358658 Summary: .desktop files of agents are read in the incorrect encoding Product: Akonadi Version: GIT (master) Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: server Assignee: kdepim-b...@kde.org Reporter: 4er...@gmail.com It turned out that .desktop files which hold settings of Akonadi agents are read in the incorrect encoding which leads to broken strings in applications (e.g. KMail or Akonadiconsole) when using localized version of KDE (see the screenshots). There's a fix for that, so the review request link is about to be applied. Reproducible: Always Steps to Reproduce: 1. Set some non-English locale in System settings. 2. Start e.g. Akonadiconsole. 3. Notice type string of agent summary. 4. Click "Add" button and notice descriptions of agents are with broken symbols. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 358573] Unable to enter fraction part when decimal point of current locale differs from "."
https://bugs.kde.org/show_bug.cgi?id=358573 --- Comment #1 from Alexey Chernov <4er...@gmail.com> --- Here's a review request for it: https://git.reviewboard.kde.org/r/126888 -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 358573] New: Unable to enter fraction part when decimal point of current locale differs from "."
https://bugs.kde.org/show_bug.cgi?id=358573 Bug ID: 358573 Summary: Unable to enter fraction part when decimal point of current locale differs from "." Product: kmymoney Version: unspecified Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: kmymoney-de...@kde.org Reporter: 4er...@gmail.com It's impossible to enter decimal separator to the fields of cash amount, so even entering the sum in calculator prints nothing to the field. As it turned out, the problem was in kMyMoneyMoneyValidator, the patch will follow. Reproducible: Always Steps to Reproduce: 0. Select some affected locale, e.g. German or Russian (they have "," as a decimal point). 1. Go to "Ledgers" view, select any account. 2. Create another operation or edit some existing one. 3. Try to enter some sum in the "Amount" field, either manually or with calculator opened. Actual Results: Notice that you can't enter decimal point sign, when you close the calculator, nothing is entered in the field. Expected Results: The sum should have been entered successfully. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionSave
https://bugs.kde.org/show_bug.cgi?id=354724 --- Comment #30 from Alexey Chernov <4er...@gmail.com> --- (In reply to Andreas Hartmetz from comment #29) > We cannot change Qt in a way that breaks existing applications. Qt5 has not > exactly just been released, and commercial customers value stability very > much. Some of them even pay for Qt licenses, which is good for all Qt users, > so really, we should not make things worse for them. The same way commercial customers or applications would be affected with API changes. I think, this issue (and fix) more concerns the environment than the application itself. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionSave
https://bugs.kde.org/show_bug.cgi?id=354724 --- Comment #28 from Alexey Chernov <4er...@gmail.com> --- (In reply to Thomas Lübking from comment #26) > (In reply to Alexey Chernov from comment #25) > > > According to what? > According to "This is not fixed in years and each and every session > management code was ported as "#if 0"" > If there was some relevant interest, it would be fixed long time, since it's > really not that hard. Rather interesting indicator. Why don't you apply it to Qt5 or KF5 then? What a selective vision :) > > > Loosing your data is however relevant for everyone. And the latter is the > > > by > > > far more severe issue. Restarting applications is merely an annoyance, > > > loosing your work is truely expensive. > > > Hey, how could session management be "apparently relevant for only a > > minority of users", but fixes in its behaviour be crucial for a lot of them? > [...] > > Fully agree here, but we should confirm that nobody said in the beggining > > that upstream changes were about to break session management for KF5 > > applications. It was just broken. > > Errr... what? > Session management (in terms of "please restore the desktop as I left it") > doesn't seem very important, but if you click "logout" and *booom*, gone is > your work of the last two hours because the application had no chance (or, > well, listened to the wrong events) to ask you to save it, that's pretty > important... Hmmm... so session management "doesn't seem very important", but there're applications which expect a) to be closed gently, and also b) to have an opportunity to interact to the user the very special way, so that the rest of the world is waiting for them and doesn't logout, but it's surely not session management. Nice. Following this way we have, I think, thousands of apps which don't use X, kernel etc. and other not so important stuff. > We're apparently talking past each other. > There're two steps: > a) logout, clients ask to save your stuff. That works (because of the close > event) > b) login, clients should restart. That's broken (because the close event is > not just an event, but the window "illegally" being withdrawn during logout) > > You propse to fix (b) by breaking (a) and I'm trying to convince you that > this is a really bad idea. The matter is just that if you like the fruitful results of some service or protocol, you need to follow the rules of it. If you violate them and currently it just works, it's natural that anyone can change something internally and you are going to fail. Rather atomic thing. My proposal is just to have library code of Qt following the proper interaction process, which is expected by anyone who haven't read this discussion and just wants to support session management in the application. Nothing against any workarounds in KSMServer, KF wrappers or anywhere else downstream. > > bugs which should be fixed either in library and its clients. It's better to > > fix them when no one really relies on the stability too much. It looks like > > this time is now for KF5-based application and environment. > Yes, we should fix KMainWindow now (if faking close events is finally not > considered a permanent behavior despite the majority of clients will > probably do that in return to the data commit request - with a fair share > actually just calling close() ...) but that has absolutely no implications > on whether it's ok to easily break away from established (even though maybe > wrong) behavior. There's no one accepted fix of Qt to fix anything against. There's a way to fix applications to interact with session manager properly though and add some fixes and workarounds to make it work somehow, at least with any local Qt patch. According to the comments of https://codereview.qt-project.org/#/c/146566/, that's something what Andreas is doing. > > No, that's just postponing and messing up the whole problem. If, as you > > stated, almost no one implemented easy and pretty simple interaction > > appeared in Qt5, even less would care of possible bugs and corner cases of > > the workaround, more complex protocol with close event you propose. There > > would be just another argument that it's just too messy, not to mention > > already existing argument that no one uses session management. > > Sorry, but I really cannot read any sense into this paragraph. > Please try to rephrase it. The above isn't English grammar at all. Again. Please try to reread it: https://www.kde.org/code-of-conduct/. Hopefully, it's English would impress you more. > > It won't be fixed until it's broken > So you demand to jeopardize userdata because otherwise code won't be fixed. > Sorry, but there's no way you're ever gonna convince me in this. > Any solution that builds upon "jeopardize userdata" is not a solution at > all. It's malicious. Just one workaround to close the clients gently (with timeout or whatever) in session server would save anyone who is afraid of "jeopardize
[ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionSave
https://bugs.kde.org/show_bug.cgi?id=354724 --- Comment #23 from Alexey Chernov <4er...@gmail.com> --- (In reply to Thomas Lübking from comment #22) > > 5. I completely don't like the proposed way to preserve the compatibility > > with (4) and make > > the use case of broken session management client implementation legal and > > default, but > > also try to allow proper-written apps to still survive somehow, adding some > > strange > > workarounds to Qt as closing all the windows, but not too much, or API > > properties to enable > > proper processing of SM messages. > > No ofense, but what you "like" is completely irrelevant. Comments like this clearly don't help the discussion or solving the problem, especially when you start your reply with them. I won't answer you the same style, but given that it's not the first one from you, my earnest request to you is to please respect each other and avoid such comments in future. In case of any questions feel free to consult https://www.kde.org/code-of-conduct/. Thank you. > You propose to intentionally break clients by library changes in some minor > update Never mentioned minor update or particular version. Please don't distort. > to teach developers to do right No intention to do it, but any specs probably means something like that. > but while you might aim their face, you're gonna hit the users (and probably > yours) Users were already hit when the significant part of functionality important for someone's every day use case is broken. I just can't get why it's OK to break everything for one part of users and ultimately save broken implementation to preserve some ephemeral compatibility for another. That's probably the biggest question for me in this thread. Maybe I'm wrong and those who use sessions are somewhat less important than users that sometimes save their data on quitting? It's worth mentioning then, and I'll immediately give up. > We had that (I kindly remind of the qDeleteAll fix ...) and it cooked up > hell. Still better than a couple of API methods like "enableSpecifiedBehaviour()" or deleting and trying to catch SIGSEGV, right?) > commitDataRequest hardly shows up in lxr.kde.org, what means it's probably > not used at all and aboutToQuit (which isn't used but could come to rescue) > isn't used too much either. > > The BY FAR! omnipresent pattern is to listen to queryClose() which is > called/emitted on -guess what- close events from KMainWindow. > And that's for pretty much sure why the (wrong) behavior in QSessionManager > exists. If it wasn't done before for some reason, it's better to just fix the applications, especially given that you don't need any changes in Qt to have just the same functionality with the new approach. If it's still too much to change while porting to Qt5/KF5, I really wonder what porting is. Once again: we all could already apply the fix of Andreas and be busy fixing the necessary applications rather than keep discussing here. > Is this behavior correct? No. > Does this matter? NO! > > It's ok to spam a #warning that this behavior is shit and deprecate and kill > it for Qt6 On the Qt6 release you would say that everyone already rely on the workaround there was in Qt5 etc. etc. That's an endless story. By the way, do you really think it's so much major change that it can't be changed before Qt6? Seriously, with no API change and with just removing unexpected actions? > and we might even bail out (aka "fix") KMainWindow applications > NOW by invoking queryClose() on QGuiApplicationPrivate::commitData() but > regardless, we MUST assume this to be a global default pattern that > applications (also beyond KDE) rely on (also because it's absolutely natural > to intercept closing to save data and not think of closing on session end > could be something entirely different - actually the illegal behavior > happens to be the most sane one...) I just kindly remind your description of current Plasma 5 and it's application state: https://bugs.kde.org/show_bug.cgi?id=341930#c30. It was written months ago, but nothing changed too dramatically from then. Even if the proper fix could break some apps, they all are *already in* transition process, Wayland is just around the corner with another transition process, so now it's the perfect time to fix something to make it finally working properly rather than make life easier for now and have this pain for years again and again. > > Now, *actually* closing windows to test interaction on session end is of > course just as wrong - if the user cancels the logout by such incident, we > should not have closed random other windows before (letting alone that it > causes this but) - therefore I frankly do not understand what's so > complicated about just faking a close event to serve the present "save your > stuff" pattern in a majority in clients without causing the destructive > close itself which may not only be a bit premature, but also triggers this > bug. > > It's the
[ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionSave
https://bugs.kde.org/show_bug.cgi?id=354724 --- Comment #25 from Alexey Chernov <4er...@gmail.com> --- (In reply to Thomas Lübking from comment #24) > (In reply to Alexey Chernov from comment #23) > > > Comments like this clearly don't help > Seriously, you asked for breaking clients because that's what you'd "like" > to do - what did you expect to hear? That's simply not an acceptable stance. No one here presents any absolutely true point, otherwise there were no discussion. I just wrote my point of view and emphasized that it's just mine and not some ultimate truth. > > Never mentioned minor update or particular version. Please don't distort. > So you meant to schedule this for Qt6? No. I just stated that I didn't mention any particular version, no other implications. As to your question, I'd prefer properly test the patch, including success scenario for the default not-aware-of-session-management application, and release it as soon as possible. > > Users were already hit when the significant part of functionality important > > for someone's every day use case is broken. > Let's be honest: session restorage is apparently relevant for only a > minority of users. According to what? Your assumption? It's not too evident for me, sorry. > Loosing your data is however relevant for everyone. And the latter is the by > far more severe issue. Restarting applications is merely an annoyance, > loosing your work is truely expensive. Hey, how could session management be "apparently relevant for only a minority of users", but fixes in its behaviour be crucial for a lot of them? Don't you contradict with yourself in these two points? Anyway, it's very subjective and I wouldn't argue on what's more important. I agree that data loss is the worst thing which could happen. I just think it doesn't mean it should result in some messy API or library code when someone's relying on the undocumented side-effects. Just because it will surely lead to more bugs and more data loss in the future. It's just the bugs which should be fixed either in library and its clients. It's better to fix them when no one really relies on the stability too much. It looks like this time is now for KF5-based application and environment. > Also there's absolutely NO reason why we should not care about both - except > that you'd "like" to break client code and risk data loss for some reason > that completely escapes me. No, that's just postponing and messing up the whole problem. If, as you stated, almost no one implemented easy and pretty simple interaction appeared in Qt5, even less would care of possible bugs and corner cases of the workaround, more complex protocol with close event you propose. There would be just another argument that it's just too messy, not to mention already existing argument that no one uses session management. > > Still better than a couple of API methods like "enableSpecifiedBehaviour()" > > I fully agree on that proposal to be of little help - it will be mostly > ignored or used w/o accounting the implications. Ok. > > Once again: we all could already apply the fix of Andreas and be busy fixing > > the necessary applications rather than keep discussing here. > > It does NOT only affect KDE applications, there're hundreds of Qt > applications which might have adopted this pattern - or simply don't care > about session management itfp. > Also the proper order is to fix and roll out clients, *then* remove the > deprecated upstream code. That's why "=> Qt6" for this approach. Fully agree here, but we should confirm that nobody said in the beggining that upstream changes were about to break session management for KF5 applications. It was just broken. Since we have what we have, there's no other way than to start fixing it on both sides. I think nobody is against if it would be synchronized. > > On the Qt6 release you would say that everyone already rely on the > > workaround there was in Qt5 etc. etc. > > No. Because you would tell people during Qt5 don't do this and don't rely on > it because it's not gonna work with Qt6, so that when things are ported to > Qt6, client code has to be fixed. Oh, you're too optimistic here. Why it's still not fixed during porting on Qt5? Only because it just works. It won't be fixed until it's broken or would be planned to fix as we discussed above. > Breaking it now and depending client behavior on whether it's linked against > Qt 5.6 or Qt 5.7 is plain wrong and begging for trouble. That's again due to your assumption that session management is of lower priority. I'm pretty sure there would be packages that would require just most recent Qt version, and it would be acceptable. What's wrong in relying on changes in recent Qt release and informing the maintainer of it with more strict requirement? There're backports if someone is interested in special cases. > > I just kindly remind your description of current Plasma 5 and it's > > application state:
[ksmserver] [Bug 354724] missing some clients or windows when storeSession and performLegacySessionSave
https://bugs.kde.org/show_bug.cgi?id=354724 Alexey Chernov <4er...@gmail.com> changed: What|Removed |Added CC||4er...@gmail.com --- Comment #21 from Alexey Chernov <4er...@gmail.com> --- I'm actually aware of the problem with session management since last summer, now I've upgraded my stuff to have more KF5-based applications and suprisingly found it still just doesn't work. So I've dived deeper into it this time, reading all the discussion here and last part of bug #341930, both Andreas's change proposals and the thread in the mailing-list. I likely agree with comment #18 of Andreas and in my point of view it is the following: 1. As a whole it's a massive regression since KDE4 which affects all Qt5 applications, most of which behave correctly as a session clients. Even server parts of both KWin and KSMServer now behave correctly, thanks to Thomas's fixes, I think. But as a whole it just doesn't work at all. 2. This problem is caused by some bug in processing session management messages in Qt, which earlier wasn't a big pain and could be avoided, but due to significant changes in the whole interaction process, in the API etc. now it can't be avoided and lead to (1). 3. There's initial change (https://codereview.qt-project.org/#/c/142232/) by Andreas, which perfectly fixes the problem with any observable problems. It also fixes a fault in the session management protocol implementation for at least two OSs, which is good for Qt itself. 4. There could be potentially affected client applications which: a) were already been ported to/written for Qt5; b) process some valuable data which shouldn't be lost; c) would like to use session management to prevent loss of unsaved data; d) still don't care to follow session management protocol correctly and just exploit old hacks and errors in its implementation, which exist historically, but now is moved to a new place. Unfortunately, this term is a little objectless since it wasn't mentioned any real-life application like this. 5. I completely don't like the proposed way to preserve the compatibility with (4) and make the use case of broken session management client implementation legal and default, but also try to allow proper-written apps to still survive somehow, adding some strange workarounds to Qt as closing all the windows, but not too much, or API properties to enable proper processing of SM messages. To sum it all up, I've applied the patch (3) and have all the session management things back again without any other changes to KDE or whatever, it's already released versions (KF-5.18.0, Plasma-5.5.3, applications-15.12.1). I'll also test Windows behaviour with some toy application. Unless any problems arise, I see no reason why this tiny and simple (and right) fix isn't applied and merged. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358300] Plasma crashed during xdg-utils-1.1.1 unit testing
https://bugs.kde.org/show_bug.cgi?id=358300 --- Comment #3 from Alexey Chernov <4er...@gmail.com> --- They are triggered too fast one by one, but I'm trying to find the reproducing one, so I hope to detect it and write here. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358300] New: Plasma crashed during xdg-utils-1.1.1 unit testing
https://bugs.kde.org/show_bug.cgi?id=358300 Bug ID: 358300 Summary: Plasma crashed during xdg-utils-1.1.1 unit testing Product: plasmashell Version: 5.5.3 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: 4er...@gmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Application: plasmashell (5.5.3) (Compiled from sources) Qt Version: 5.5.1 Operating System: Linux 4.3.3 x86_64 -- Information about the crash: - What I was doing when the application crashed: I've been testing xdg-utils-1.1.1 package before installing it, it interacts with DE during this and one of these test cases crashed Plasma. -- Backtrace: Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f2749e2e7c0 (LWP 2137))] Thread 7 (Thread 0x7f272df0b700 (LWP 2142)): #0 0x7f274140edbd in poll () from /lib/libc.so.6 #1 0x7f2747acc152 in _xcb_conn_wait () from /usr/X11R6/lib64/libxcb.so.1 #2 0x7f2747ace2e9 in xcb_wait_for_event () from /usr/X11R6/lib64/libxcb.so.1 #3 0x7f272fe8aaf9 in QXcbEventReader::run (this=0xfee0f0) at qxcbconnection.cpp:1229 #4 0x7f27420081e0 in QThreadPrivate::start (arg=0xfee0f0) at thread/qthread_unix.cpp:331 #5 0x7f27407703e4 in start_thread () from /lib/libpthread.so.0 #6 0x7f2741417d0d in clone () from /lib/libc.so.6 Thread 6 (Thread 0x7f27271cf700 (LWP 2153)): #0 0x7f274140edbd in poll () from /lib/libc.so.6 #1 0x7f273ca31fe4 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #2 0x7f273ca320ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x7f27422471fb in QEventDispatcherGlib::processEvents (this=0x7f2728c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f27421ec622 in QEventLoop::exec (this=this@entry=0x7f27271cedf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f2742002693 in QThread::exec (this=this@entry=0x10ed1e0) at thread/qthread.cpp:503 #6 0x7f27464c2235 in QQmlThreadPrivate::run (this=0x10ed1e0) at qml/ftw/qqmlthread.cpp:141 #7 0x7f27420081e0 in QThreadPrivate::start (arg=0x10ed1e0) at thread/qthread_unix.cpp:331 #8 0x7f27407703e4 in start_thread () from /lib/libpthread.so.0 #9 0x7f2741417d0d in clone () from /lib/libc.so.6 Thread 5 (Thread 0x7f271dd38700 (LWP 2170)): #0 0x7f2740775f5f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f2724998a8a in radeon_drm_cs_emit_ioctl () from /usr/X11/lib/dri/r600_dri.so #2 0x7f27249982b7 in impl_thrd_routine () from /usr/X11/lib/dri/r600_dri.so #3 0x7f27407703e4 in start_thread () from /lib/libpthread.so.0 #4 0x7f2741417d0d in clone () from /lib/libc.so.6 Thread 4 (Thread 0x7f2718fd2700 (LWP 2171)): #0 0x7f274140edbd in poll () from /lib/libc.so.6 #1 0x7f273ca31fe4 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #2 0x7f273ca320ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x7f27422471fb in QEventDispatcherGlib::processEvents (this=0x7f27140008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f27421ec622 in QEventLoop::exec (this=this@entry=0x7f2718fd1df0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f2742002693 in QThread::exec (this=this@entry=0x13cafc0) at thread/qthread.cpp:503 #6 0x7f27464c2235 in QQmlThreadPrivate::run (this=0x13cafc0) at qml/ftw/qqmlthread.cpp:141 #7 0x7f27420081e0 in QThreadPrivate::start (arg=0x13cafc0) at thread/qthread_unix.cpp:331 #8 0x7f27407703e4 in start_thread () from /lib/libpthread.so.0 #9 0x7f2741417d0d in clone () from /lib/libc.so.6 Thread 3 (Thread 0x7f2713454700 (LWP 2173)): #0 0x7f273ca82c70 in g_mutex_lock () from /usr/lib/libglib-2.0.so.0 #1 0x7f273ca31375 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #2 0x7f273ca31f13 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #3 0x7f273ca320ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0x7f27422471fb in QEventDispatcherGlib::processEvents (this=0x7f270c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #5 0x7f27421ec622 in QEventLoop::exec (this=this@entry=0x7f2713453df0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #6 0x7f2742002693 in QThread::exec (this=this@entry=0x1458f90) at thread/qthread.cpp:503 #7 0x7f27464c2235 in QQmlThreadPrivate::run (this=0x1458f90) at qml/ftw/qqmlthread.cpp:141 #8 0x7f27420081e0 in QThreadPrivate::start (arg=0x1458f90) at thread/qthread_unix.cpp:331 #9 0x7f27407703e4 in start_thread () from /lib/libpthread.so.0 #10 0x7f2741417d0d in clone () from
[plasmashell] [Bug 358300] Plasma crashed during xdg-utils-1.1.1 unit testing
https://bugs.kde.org/show_bug.cgi?id=358300 --- Comment #4 from Alexey Chernov <4er...@gmail.com> --- Unfortunately, I didn't manage to reproduce it with running unit tests again — seems that it was caused my some collision when I tried to close windows it opened during tests while it kept opening more windows. I tried to repeat this as well, but never managed to get this crash again. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 358316] New: KRunner becomes frozen and is shown when app with incorrect .desktop file is started
https://bugs.kde.org/show_bug.cgi?id=358316 Bug ID: 358316 Summary: KRunner becomes frozen and is shown when app with incorrect .desktop file is started Product: krunner Version: 5.5.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: m...@vhanda.in Reporter: 4er...@gmail.com KRunner hangs and is shown until the application is closed when it was used to start the applications with absent service is defined in X-DBUS-ServiceName item of its .desktop file (for reproduce scenario see bug #358315 for Skrooge-2.2.0 with such a typo in this field). When the application is closed, "KDEInit couldn't launch " error message is shown and KRunner continues to run normally. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 358315] Typo in .desktop file leads to KRunner freeze
https://bugs.kde.org/show_bug.cgi?id=358315 --- Comment #1 from Alexey Chernov <4er...@gmail.com> --- Created attachment 96768 --> https://bugs.kde.org/attachment.cgi?id=96768=edit Patch fixing the typo and certain problem. -- You are receiving this mail because: You are watching all bug changes.
[skrooge] [Bug 358315] Typo in .desktop file leads to KRunner freeze
https://bugs.kde.org/show_bug.cgi?id=358315 --- Comment #3 from Alexey Chernov <4er...@gmail.com> --- Thank you very much for merging it! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358325] New: Plasma crashed when trying to drag a file to the grouped application item
https://bugs.kde.org/show_bug.cgi?id=358325 Bug ID: 358325 Summary: Plasma crashed when trying to drag a file to the grouped application item Product: plasmashell Version: 5.5.3 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: 4er...@gmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Application: plasmashell (5.5.3) (Compiled from sources) Qt Version: 5.5.1 Operating System: Linux 4.3.3 x86_64 -- Information about the crash: - What I was doing when the application crashed: I just dragged a file from Dolphin (15.12.1) to an item standing for two KMail windows (main and letter editing, wanted to add a file as attachement by dragging), and Plasma suddenly crashed. I attached two more files, one before and one after the crash without any issues. No applications were opened or closed during it, i.e. item set of the task bar wasn't changed while I dragged or just before it. Sorry if it's another duplicate, but decided to report if in case it would help. The crash does not seem to be reproducible. -- Backtrace: Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f6f8bbed7c0 (LWP 17787))] Thread 7 (Thread 0x7f6f6fcca700 (LWP 17791)): #0 0x7f6f831cddbd in poll () from /lib/libc.so.6 #1 0x7f6f8988b152 in _xcb_conn_wait () from /usr/X11R6/lib64/libxcb.so.1 #2 0x7f6f8988d2e9 in xcb_wait_for_event () from /usr/X11R6/lib64/libxcb.so.1 #3 0x7f6f71c49af9 in QXcbEventReader::run (this=0x8db110) at qxcbconnection.cpp:1229 #4 0x7f6f83dc71e0 in QThreadPrivate::start (arg=0x8db110) at thread/qthread_unix.cpp:331 #5 0x7f6f8252f3e4 in start_thread () from /lib/libpthread.so.0 #6 0x7f6f831d6d0d in clone () from /lib/libc.so.6 Thread 6 (Thread 0x7f6f6d02e700 (LWP 17793)): #0 0x7f6f831cddbd in poll () from /lib/libc.so.6 #1 0x7f6f7e7f0fe4 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #2 0x7f6f7e7f10ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x7f6f840061fb in QEventDispatcherGlib::processEvents (this=0x7f6f68c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f6f83fab622 in QEventLoop::exec (this=this@entry=0x7f6f6d02ddf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f6f83dc1693 in QThread::exec (this=this@entry=0x9ddaa0) at thread/qthread.cpp:503 #6 0x7f6f88281235 in QQmlThreadPrivate::run (this=0x9ddaa0) at qml/ftw/qqmlthread.cpp:141 #7 0x7f6f83dc71e0 in QThreadPrivate::start (arg=0x9ddaa0) at thread/qthread_unix.cpp:331 #8 0x7f6f8252f3e4 in start_thread () from /lib/libpthread.so.0 #9 0x7f6f831d6d0d in clone () from /lib/libc.so.6 Thread 5 (Thread 0x7f6f65687700 (LWP 17818)): #0 0x7f6f82534f5f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f6f66761a8a in radeon_drm_cs_emit_ioctl () from /usr/X11/lib/dri/r600_dri.so #2 0x7f6f667612b7 in impl_thrd_routine () from /usr/X11/lib/dri/r600_dri.so #3 0x7f6f8252f3e4 in start_thread () from /lib/libpthread.so.0 #4 0x7f6f831d6d0d in clone () from /lib/libc.so.6 Thread 4 (Thread 0x7f6f5ae00700 (LWP 17841)): #0 0x7f6f831cddb2 in poll () from /lib/libc.so.6 #1 0x7f6f7e7f0fe4 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #2 0x7f6f7e7f10ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x7f6f840061fb in QEventDispatcherGlib::processEvents (this=0x7f6f540008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f6f83fab622 in QEventLoop::exec (this=this@entry=0x7f6f5adffdf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f6f83dc1693 in QThread::exec (this=this@entry=0xcc1b60) at thread/qthread.cpp:503 #6 0x7f6f88281235 in QQmlThreadPrivate::run (this=0xcc1b60) at qml/ftw/qqmlthread.cpp:141 #7 0x7f6f83dc71e0 in QThreadPrivate::start (arg=0xcc1b60) at thread/qthread_unix.cpp:331 #8 0x7f6f8252f3e4 in start_thread () from /lib/libpthread.so.0 #9 0x7f6f831d6d0d in clone () from /lib/libc.so.6 Thread 3 (Thread 0x7f6f5931c700 (LWP 17843)): #0 0x7f6f7e7f0751 in g_main_context_query () from /usr/lib/libglib-2.0.so.0 #1 0x7f6f7e7f0f5f in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0 #2 0x7f6f7e7f10ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x7f6f840061fb in QEventDispatcherGlib::processEvents (this=0x7f6f4c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f6f83fab622 in QEventLoop::exec (this=this@entry=0x7f6f5931bdf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f6f83dc1693 in QThread::exec
