[calligracommon] [Bug 314638] Text Tool doesn't handle input method correctly.
https://bugs.kde.org/show_bug.cgi?id=314638 --- Comment #5 from Yichao Yu --- I'm just testing this and it seems that the artistic text tool has been removed? If that is the case than this can be closed. The current text tool has a popup window to edit the text and it interacts with input method mostly correctly. The only issue I was able to find is that it does not draw the preedit text when the input is empty. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 318450] Selecting by double click at end of line should stop at the last character of the line instead of the last printable character
https://bugs.kde.org/show_bug.cgi?id=318450 --- Comment #3 from Yichao Yu --- Yes, this is still an issue. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 430235] New: UI regression: Very difficult to configure per-event notification
https://bugs.kde.org/show_bug.cgi?id=430235 Bug ID: 430235 Summary: UI regression: Very difficult to configure per-event notification Product: systemsettings Version: 5.20.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_notify Assignee: k...@privat.broulik.de Reporter: yyc1...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY AFAICT, there has never been an easy way to disable sound notification for all/most of the events. However, it was OK before since the per-event notification setting are very easy to see and change. It takes a single key press or click to go from event config for one program to the next and the icon makes it clear at a glance which one potentially have sound on. However, since a few versions ago (I only noticed this when I want to change this setting again after getting a new computer) the per-event config is now in its own popup window while leaving a lot of empty space in the parent window that can easily contain the event config even for the smallest window size allowed. Given this, I believe the event config should be put back to the parent window instead of having to be it's own window (allowing it to popup when accessed from somewhere else (if that's the goal) is certainy fine and AFAICT the two can coexist with little duplicated code). SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 427569] Thumbnail view pops out as new window on Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=427569 Yichao Yu changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/grap ||hics/gwenview/commit/e73755 ||4c9faff3be27083497c26675155 ||bcf8122 --- Comment #7 from Yichao Yu --- Git commit e737554c9faff3be27083497c26675155bcf8122 by Yichao Yu. Committed on 13/10/2020 at 00:19. Pushed by ngraham into branch 'release/20.08'. Set visibility after setting parent This avoids recreating native window, which should be generally good, and works around QTBUG-87345. M +3-1app/viewmainpage.cpp https://invent.kde.org/graphics/gwenview/commit/e737554c9faff3be27083497c26675155bcf8122 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 427569] Thumbnail view pops out as new window on Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=427569 --- Comment #4 from Yichao Yu --- I've reduced the test case in the Qt bug report so I'm fairly sure it's a Qt bug now. https://bugreports.qt.io/browse/QTBUG-87345?focusedCommentId=530782&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-530782 Also submitted https://invent.kde.org/graphics/gwenview/-/merge_requests/17 as a workaround as well as general improvement... -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 427569] Thumbnail view pops out as new window on Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=427569 --- Comment #2 from Yichao Yu --- Ref https://bugreports.qt.io/browse/QTBUG-87345 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 427569] Thumbnail view pops out as new window on Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=427569 --- Comment #1 from Yichao Yu --- I'm still not sure what's changed but the issue seems to be caused by showing a widget before a parent is set. In `app/viewmainpage.cpp`, `mThumbnailBar` was created without a parent and may be set to visible immediately after creation before it is added to `mThumbnailSplitter`. This caused a toplevel `QXcbWindow` to be created for it. The following patch fixes/works around the issue. ``` diff --git a/app/viewmainpage.cpp b/app/viewmainpage.cpp index 35c5ce59..d1faa431 100644 --- a/app/viewmainpage.cpp +++ b/app/viewmainpage.cpp @@ -148,7 +148,6 @@ struct ViewMainPagePrivate mThumbnailBar = new ThumbnailBarView; ThumbnailBarItemDelegate* delegate = new ThumbnailBarItemDelegate(mThumbnailBar); mThumbnailBar->setItemDelegate(delegate); -mThumbnailBar->setVisible(GwenviewConfig::thumbnailBarIsVisible()); mThumbnailBar->setSelectionMode(QAbstractItemView::ExtendedSelection); } @@ -330,6 +329,7 @@ struct ViewMainPagePrivate mThumbnailSplitter->addWidget(mAdapterContainer); mThumbnailSplitter->addWidget(mThumbnailBar); mThumbnailSplitter->setSizes(GwenviewConfig::thumbnailSplitterSizes()); +mThumbnailBar->setVisible(GwenviewConfig::thumbnailBarIsVisible()); QVBoxLayout* layout = new QVBoxLayout(q); layout->setContentsMargins(0, 0, 0, 0); ``` This seems to be fairly harmless. I'm not sure though if this is supposed to be working. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 427569] New: Thumbnail view pops out as new window on Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=427569 Bug ID: 427569 Summary: Thumbnail view pops out as new window on Qt 5.15 Product: gwenview Version: 20.08.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: yyc1...@gmail.com Target Milestone: --- SUMMARY When openning some images (seems to mainly affect JPG) if the thumbnail bar is set to be enabled by default, it'll pop up as a new window instead of embedded in the main one. Closing it and reopenning it cause the issue to go away. I believe this is a new issue and wasn't there a few months ago. Testing a commit from Jan 2020 still shows the issue so I think it's likely to be caused by upgrading to qt 5.15. It's quite hard for me to downgrade qt for testing though I may try to compile a debug version... STEPS TO REPRODUCE 1. Open a jpg image OBSERVED RESULT Thumbnail view bar pops up as new window. EXPECTED RESULT It shouldn't be SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux x86_64 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenetwork-filesharing] [Bug 422554] permission order in usershare_acl
https://bugs.kde.org/show_bug.cgi?id=422554 --- Comment #4 from Yichao Yu --- Have to say I don't really like the windows behavior you described though having an aggressive warning would at least fix my initial confusion. I think my bottom line is that there should be a way to set the permission such that it is denied for every (current and future) user but allowed for one user. This seem to be a setting that is allowed by samba. As long as the UI allows this (and similar setting for groups maybe) and avoid confusion I'd be fairly happy about it... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422554] New: permission order in usershare_acl
https://bugs.kde.org/show_bug.cgi?id=422554 Bug ID: 422554 Summary: permission order in usershare_acl Product: frameworks-kio Version: 5.70.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kio-bugs-n...@kde.org Reporter: yyc1...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY To be fair, I'm not sure if this should be frameworks/kio or network/kdenetwork-filesharing . The permissiong window shows an "everyone" as well as an entry for each samba users with the "everyone" being the first one. The GUI strongly suggests that different permissions can be configured for different users with the everyone as fallback. However, in the generated usershare_acl, everyone (S-1-1-0) is also the first one, before any user ones. Even though I haven't been able to find the document for this configure field yet, from local testing, this field is order sensitive and samba will use the first match. This essentially means that as long as the "fallback" is set, it'll be used for everyone... STEPS TO REPRODUCE 1. Configure samba usershare 2. Share a directory from dolphin properties dialog 3. Change everyone to deny and the user to read/write (note: might need to workaround https://invent.kde.org/network/kdenetwork-filesharing/-/commit/447735830b0749f0d896dd9408c3287f66d496e9#note_56261) OBSERVED RESULT The user will not be able to access the share. Moving the `S-1-1-0:d` in usershare_acl in the samba usershare configure file to the end fixes this. EXPECTED RESULT The user should have read/write permission whereas no one else should. SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION Samba version 4.12.3 -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 417310] Incorrect resolution with HiDPI scaling on
https://bugs.kde.org/show_bug.cgi?id=417310 --- Comment #2 from Yichao Yu --- Note that there is a fix from a year ago waiting for review @ https://phabricator.kde.org/D20790. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 411326] krunner hangs on first start
https://bugs.kde.org/show_bug.cgi?id=411326 --- Comment #10 from Yichao Yu --- Uninstalling or disabling is the workaround now. However it shouldn’t be the permanent solution. There are so many different made application packages (which is great on itself) and remembering what to install is next to impossible. If the disk space is not a problem (very common these days) I just use meta packages to install all of them and doing less than that actually requires installing more packages manually. It is also very hard for a non programmer to figure out what is wrong leading to very bad user experience. As for a fix, it seems that the issue is just that the iced integration module doesn’t register the dubs interface before ktp is loaded and ready. If as you said the client side can’t be made asynchronous easily and since I believe KDE fully control *this* interface, can the dubs interface be made available unconditionally and make anything that rely on defecting the availability of this interface based on making a call on this interface again? The client would still not be very robust this way and I still think that’ll be good to fix but at least the server won’t be messing with it by default. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 411326] krunner hangs on first start
https://bugs.kde.org/show_bug.cgi?id=411326 Yichao Yu changed: What|Removed |Added CC||yyc1...@gmail.com --- Comment #7 from Yichao Yu --- I'm not sure if it is exactly the same issue as originally reported but I've experienced the same issue as Martin Droessler on ArchLinux after a recent upgrade to 20.04.0. It is definately caused by ktp-contact-runner or one of it's dependencies. Using a combination of debugger and dbus inspection the hang is in `KTp::GlobalPresence::GlobalPresence (ktp-common-internals/KTp/global-presence.cpp)` which did a synchrnous call to `org.freedesktop.Telepathy.Client.KTp.KdedIntegrationModule`. The destination is not owned by any process on my computer probably because I'm not using ktp and it only returns after few second when the dbus call timed out. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #40 from Yichao Yu --- > Some times when I type out my comments they appear much too harsh than I > intend them to be. This is something that I'm working on ;-). For this I > apologize and would like to clear the slate on this topic. I know that you > have spent a great deal of your personal time on this project including > several other projects. No problem. Thanks for understanding. > I understand that this window decoration is more complex than the average > widget. Now this isn't necessarily the case. (I would even say window decorator is simpler since there's a single program (kwin) that it interacts with.) However, I never claimed that I fully understand all the options in the widget style either. It's just that the qt4->qt5 transition has virtually no API change so the porting doesn't need any understanding. As I fixed a few bugs over the years I am getting a better understanding of it, but I won't even say I've touched/used more than 20% of it = = ... > Can you post on your GIT site that you're looking for help. Bye. The best reference is https://community.kde.org/Infrastructure/Git . It's the kde:qtcurve git repo (using the alias on that page) and that probably won't change. There seems to be quite a bit change on the infrastructure in the past few years (gitlab (invent.kde.org)?) so I honestly don't know what's the lastest way to access all the KDE git repos at this point, let along in another 2 years = = ... (I'm just keep using the URL I've been using until someone tells me I'm using another one) -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #36 from Yichao Yu --- > I give up. There are a number of people that would have helped you when I > first mentioned this to you four years ago. It's a shame. I won't comment on > this anymore. Since you are making it sound like I intentionally did nothing and asked for no help I'll make it clear even though I think I'm not really obligated to give an explaination otherwise. First, there are times (ok, twice maybe) that I was offered help privately in terms of actually contributing code but then didn't hear back. I see this both as a missing opportunity to get it ported and a sign of maybe it is not as trivial as I thought it was. Secondly, I've also looked at the help in terms of documentation and the issue, as mentioned above, is that the complexity from the qtcurve side. I can see that if one know the qtcurve side of things well, the port shouldn't be very hard. (In case it is not clear, I did not write the qt4 version of the kwin theme.) It is trivial to use the template implementation to get something working while throwing away everything qtcurve currently have. The difficulty is in large part to figure out what the code in qtcurve is doing and I assume none of the help are in that area. Note that this is very different from the widget theme, where basically everything has a 1-1 mapping, the porting is much more mechanical and fixes afterwards can be done mostly incrementally. Now those are my accessments, most if not all of the conclusions are actually scattering among the few comments I've already made above. They may or may not be accurate but that's what I find and why I determined it is harder than I want to spend much time on any time soon. If any of the assumptions/findings I had above are not accurate making this easier than what I thought, I'm certainly open to constructive suggestions. > Do you want to close this bug report and mark it as WONTFIX? No, I've left this open as an acknowledgement that this is a nice to have feature. This can be close if it doesn't make sense to have, which is not the case. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #34 from Yichao Yu --- Err, assuming you are still talking about the kwin support (you changed how you talked about it so I assumed you were talking about something else), I've already mentioned above that I've given it my fair try and I don't think it's something that is possible to have a clear timeline for due to the complexity. It's a fairly low priority wishlist item. I'm not planning to work on it any time soon but pull requests are and has always been welcome. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #32 from Yichao Yu --- I don't know what you meant by qtcurve-qt. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 322037] quick tile preview rectangle have wrong size.
https://bugs.kde.org/show_bug.cgi?id=322037 Yichao Yu changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #6 from Yichao Yu --- Not an issue on KF5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389109] Desktop settings window should not be reopened when "ok" button is clicked to apply "layout" change
https://bugs.kde.org/show_bug.cgi?id=389109 --- Comment #3 from Yichao Yu --- Oh, search function on bugzilla is so hard to use = = ... Anyway, if anyone more familiar with QML wants to have a look see the debugging I did at https://bugs.kde.org/show_bug.cgi?id=419866. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 419866] New: Desktop configure dialog does not close after clicking "OK" when changing containment plugin type.
https://bugs.kde.org/show_bug.cgi?id=419866 Bug ID: 419866 Summary: Desktop configure dialog does not close after clicking "OK" when changing containment plugin type. Product: plasmashell Version: 5.18.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Desktop Containment Assignee: notm...@gmail.com Reporter: yyc1...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY It's unclear if this is a plasma-desktop bug, or a plasma-workspace bug, or a Qt bug... See the debug note below. STEPS TO REPRODUCE 1. Right click on desktop and bring up the desktop configure dialog from the right click menu. 2. Change the desktop type. The warning for applying immediately should appear. 3. Click "OK". OBSERVED RESULT The configure should apply and the dialog is opened again. EXPECTED RESULT The configure should apply and the dialog should close. DEBUGGING As far as I can tell, the sequence of event when clocking on the OK button is that. [`accptAction.trigger()`](https://github.com/KDE/plasma-desktop/blob/3e8c7dada73ed838a93b0b0ffcd5c679627ffa54/desktoppackage/contents/configuration/AppletConfiguration.qml#L396) calls a chain of functions which calls [`root.saveConfig()`](https://github.com/KDE/plasma-desktop/blob/3e8c7dada73ed838a93b0b0ffcd5c679627ffa54/desktoppackage/contents/configuration/ConfigurationContainmentAppearance.qml#L38) When [changing the containment type](https://github.com/KDE/plasma-desktop/blob/3e8c7dada73ed838a93b0b0ffcd5c679627ffa54/desktoppackage/contents/configuration/ConfigurationContainmentAppearance.qml#L49) which through a chain of events recreated a new `ContainmentConfigView` (didn't save backtrace, sorry) and then closed the old one. After `root.saveConfig()` returns, the call to [`configDialog.close()`](https://github.com/KDE/plasma-desktop/blob/3e8c7dada73ed838a93b0b0ffcd5c679627ffa54/desktoppackage/contents/configuration/AppletConfiguration.qml#L397) appears to be calling the destroyed `ContainmentConfigView` and the new one is left open. However, since the `ContainmentConfigView` constructor appears to be [setting the `configDialog`](https://github.com/KDE/plasma-workspace/blob/5545214d4420eccc8013331697259974affc7283/shell/containmentconfigview.cpp#L64) I'm not sure why it doesn't get picked up by the `configDialog.close()`. Is that supposed to be asynchronous or not show up until the next call for some reason? Or is it a qml compiler bug? P.S. somehow I never got a breakpoint firing on the destructor of `ContainmentConfigView` so they apears to be leaked? SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 362908] New stable release (or git tag)
https://bugs.kde.org/show_bug.cgi?id=362908 Yichao Yu changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #30 from Yichao Yu --- > Why didn't you finish the window decoration? You had over six years to finish > it. I'm not sure what you are trying to suggest by "six years". If it was easy it would have happened a long time ago. AFAICT, it was significantly harder than porting the widget style. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #28 from Yichao Yu --- As I said, pull requests are more than welcome. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 419436] New: Picture of the day (potd) background does not work in greeter
https://bugs.kde.org/show_bug.cgi?id=419436 Bug ID: 419436 Summary: Picture of the day (potd) background does not work in greeter Product: kscreenlocker Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: greeter Assignee: plasma-b...@kde.org Reporter: yyc1...@gmail.com CC: bhus...@gmail.com Target Milestone: --- SUMMARY If POTD is selected as the background for screen locker, a black background is shown instead. This is due to a failure on `open` in the following call chain with `EPERM`. #0 createUnnamedFile (file=@0x5635d3cf2638: -1, tfn=..., mode=384, error=error@entry=0x7fff3facf9a8) at io/qtemporaryfile.cpp:307 #1 0x7fb41161153d in QTemporaryFileEngine::open (this=0x7fb3f0007bb0, openMode=...) at io/qtemporaryfile.cpp:367 #2 0x7fb4115f9ced in QFile::open (this=this@entry=0x7fff3facfb00, mode=mode@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:120 #3 0x7fb41161228c in QTemporaryFile::open (this=this@entry=0x7fff3facfb00, flags=flags@entry=...) at io/qtemporaryfile.cpp:969 #4 0x7fb40d8baa5e in QTemporaryFile::open (this=0x7fff3facfb00) at /usr/include/qt/QtCore/qflags.h:118 #5 KIO::ConnectionBackend::listenForRemote (this=this@entry=0x5635d3cf2470) at /usr/src/debug/kio-5.68.0/src/core/connectionbackend.cpp:143 #6 0x7fb40d8bce5a in KIO::ConnectionServer::listenForRemote (this=0x5635d3cfc210) at /usr/src/debug/kio-5.68.0/src/core/connectionserver.cpp:56 The error code causes the temp file creator to not use the fallback mechanism but at least in this case it probably won't help. >From reading `greeter/seccomp_filter.cpp`, it seems that write capability is intentionally dropped for the greeter which is probably why the creation of the tmp file failed. Judging by the comment at the start of the file about OpenGL it seems that the correct fix would be somehow initialize kio so that one don't need to create the file after seccomp is initialized? I'm not sure how to do that for KIO or I'll probably have submitted a patch instead... STEPS TO REPRODUCE 1. Set screen lock greeter backgroud to picture of the day (default black picture background). Both Bing and Unsplash shows this problem. Others probably do too. 2. Start the greeter either normally or just by running `/usr/lib/kscreenlock_greeter` (or whatever path it is in, possibly with `--testing`) OBSERVED RESULT The background is black. If the command is run from cmdline directly, one should see output like, ``` kf5.kio.core: KIO Connection server not listening, could not connect kf5.kio.core: KIO Connection server not listening, could not connect kf5.kio.core: couldn't create slave: "Can not create socket for launching io-slave for protocol 'https'." ``` which is how I tracked down the location of the error. There's also another error ``` UdevQt: unable to create udev monitor connection ``` after that that is probably unrelated to this issue but might have the same cause? EXPECTED RESULT POTD background should work. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION I found this bug from debian with the same issue but I can't find a corresponding kde bug report. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906148 -- You are receiving this mail because: You are watching all bug changes.
[kmines] [Bug 402412] Restart Failed KMines Game
https://bugs.kde.org/show_bug.cgi?id=402412 Yichao Yu changed: What|Removed |Added CC||yyc1...@gmail.com Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Yichao Yu --- Just browsing the issue tracker after submitting my patch to see if anyone reported the bug that I was fixing. I believe the patch is submitted and I've been using this function for a while now. Thanks for the report and the feature addition. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 417077] Single Click not working/available.
https://bugs.kde.org/show_bug.cgi?id=417077 Yichao Yu changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 417310] New: Incorrect resolution with HiDPI scaling on
https://bugs.kde.org/show_bug.cgi?id=417310
Bug ID: 417310
Summary: Incorrect resolution with HiDPI scaling on
Product: krdc
Version: 19.12
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: uwol...@kde.org
Reporter: yyc1...@gmail.com
Target Milestone: ---
SUMMARY
This issue has come up some time ago, got fixed but is appearing again. There
does seem to be some changne WRT scaling in the latest Qt5/KF5 since a few
other applications also changed (usually for the better).
STEPS TO REPRODUCE
1. Enable scaling in systemsettings (e.g. 2)
2. Set rdp screen resolution to be "Current KRDC size"
OBSERVED RESULT
The RDP view will be half the size of the window instead of the full size as
expected.
This is not limited to this particular setting. Changing the size to be larger
than this cause the scroll bar to appear even though it's not needed. I highly
suspect this to be the same for other connection backend as well but I cannot
test myself...
EXPECTED RESULT
At least the size of the remote display and the size of the window should
agree, i.e. when the apparent display size on the screen is smaller than the
widget size it fits in, there should be no scrollbar. I can see argument for
both using the scaled or unscaled resolution for the remote connection so I
think it might be good to add an option for that. (This basically depend on
whether the remote side is aware of how to deal with HiDPI). This is of course
assuming that the backend actually support this. xfreerdp does seem to have
related options...
Personally I prefer having a high resolution remote and I've tested that the
following completely incorrect patch works for my setting.
```
diff --git a/rdp/rdpview.cpp b/rdp/rdpview.cpp
index 4adc4cc..925eca0 100644
--- a/rdp/rdpview.cpp
+++ b/rdp/rdpview.cpp
@@ -183,7 +183,7 @@ bool RdpView::start()
if (versionOutput.contains(QLatin1String(" 1.0"))) {
qCDebug(KRDC) << "Use FreeRDP 1.0 compatible arguments";
-arguments << QStringLiteral("-g") << QString::number(width) +
QLatin1Char('x') + QString::number(height);
+arguments << QStringLiteral("-g") << QString::number(width * 2) +
QLatin1Char('x') + QString::number(height * 2);
arguments << QStringLiteral("-k") <<
keymapToXfreerdp(m_hostPreferences->keyboardLayout());
@@ -276,8 +276,8 @@ bool RdpView::start()
qCDebug(KRDC) << "Use FreeRDP 1.1+ compatible arguments";
arguments << QStringLiteral("-decorations");
-arguments << QStringLiteral("/w:") + QString::number(width);
-arguments << QStringLiteral("/h:") + QString::number(height);
+arguments << QStringLiteral("/w:") + QString::number(width * 2);
+arguments << QStringLiteral("/h:") + QString::number(height * 2);
arguments << QStringLiteral("/kbd:") +
keymapToXfreerdp(m_hostPreferences->keyboardLayout());
```
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux latest as of 2/8/2020 (testing enabled)
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.1
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[QtCurve] [Bug 417077] Single Click not working/available.
https://bugs.kde.org/show_bug.cgi?id=417077 --- Comment #1 from Yichao Yu --- You need to be much more specific about what you are talking about. A few points to consider. 1. QtCurve is a theme/style. While it is not completely unrelated to clicking, it is not itself something that you click. Reporting that you have to double click on QtCurve doesn't really make that much sense. 2. I'm 99.9% sure you don't have to "double click on everything". As in, I'm sure single click does something in some cases. It may just not be what you want it to do. 3. In any case, you should mention what program(s) you are talking about and what you are trying to do. I just looked at my system setting for input device/mouse. It doesn't seem to have the single click/double click setting that used to be there for at least KDE4. It's not a setting I need but if that's the option you are talking about you have reported it to the wrong component. I'm too lazy to figure out what would be the right component but `systemsettings` would be a good start. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 408286] Build fails with GCC9
https://bugs.kde.org/show_bug.cgi?id=408286 Yichao Yu changed: What|Removed |Added Latest Commit||https://commits.kde.org/qtc ||urve/ee2228ea2f18ac5da9b434 ||ee6089381df815aa94 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Yichao Yu --- Git commit ee2228ea2f18ac5da9b434ee6089381df815aa94 by Yichao Yu. Committed on 05/06/2019 at 13:05. Pushed by yuyichao into branch 'master'. [utils/gtkprops] Remove unnecessary constexpr, this is not allowed in C++14 M +1-1lib/utils/gtkprops.h https://commits.kde.org/qtcurve/ee2228ea2f18ac5da9b434ee6089381df815aa94 -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 398021] qtcurve dosn't save settings
https://bugs.kde.org/show_bug.cgi?id=398021 --- Comment #3 from Yichao Yu --- And if it's a generic issue rather than something that each users has to fix, the component is likely framework-kconfig. Of course even in that case it could still be caused by your local configuration (like if the config directly doesn't have the right write permission etc.). -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 398021] qtcurve dosn't save settings
https://bugs.kde.org/show_bug.cgi?id=398021 --- Comment #2 from Yichao Yu --- QtCurve uses KConfig for saving the setting. I'll keep this open since that's what was requested in the other issue but in the mean time I'm not sure what we could do differently to fix/workaround it -- You are receiving this mail because: You are watching all bug changes.
[plasma4] [Bug 333601] The width of the tooltip for adding new widget keeps growing when switching between widgets.
https://bugs.kde.org/show_bug.cgi?id=333601 --- Comment #4 from Yichao Yu --- This was actually one of the first things I checked when switching to plasma 5 and it was working without this problem as far as I remember. -- You are receiving this mail because: You are watching all bug changes.
[kfile] [Bug 327898] KFileDialog locationEdit reset undo history when there are more than one characters
https://bugs.kde.org/show_bug.cgi?id=327898 --- Comment #3 from Yichao Yu --- Actually I can't reproduce this for the location but I can for the filename box. -- You are receiving this mail because: You are watching all bug changes.
[kfile] [Bug 327898] KFileDialog locationEdit reset undo history when there are more than one characters
https://bugs.kde.org/show_bug.cgi?id=327898 --- Comment #2 from Yichao Yu --- I'm actually pretty confused by the version number scheme right now so I'm not really sure which version I have. The kdialog package version is 17.12.1 installed from Feburary and kdialog --version gives me 2.0. I can still reproduce exactly this problem with these version. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 387795] error: ‘Q_FALLTHROUGH’ was not declared in this scope
https://bugs.kde.org/show_bug.cgi?id=387795 Yichao Yu changed: What|Removed |Added Latest Commit||https://commits.kde.org/qtc ||urve/14eec32771fc3384009d74 ||c13c3557925a93c749 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Yichao Yu --- Git commit 14eec32771fc3384009d74c13c3557925a93c749 by Yichao Yu. Committed on 11/12/2017 at 14:17. Pushed by yuyichao into branch 'master'. Introduce QTC_FALLTHROUGH (from LLVM) * Fix compilation on gtk2, qt4, and possibly old version qt5 (< 5.8). * Fix a few more fallthrough warnings. M +10 -0lib/utils/utils.h M +9-4qt4/style/qtcurve.cpp M +19 -19 qt5/common/common.cpp M +2-2qt5/style/qtcurve.cpp M +1-1qt5/style/qtcurve_api.cpp https://commits.kde.org/qtcurve/14eec32771fc3384009d74c13c3557925a93c749 -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 387795] error: ‘Q_FALLTHROUGH’ was not declared in this scope
https://bugs.kde.org/show_bug.cgi?id=387795 Yichao Yu changed: What|Removed |Added Component|qt4 |qt5 -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 387795] error: ‘Q_FALLTHROUGH’ was not declared in this scope
https://bugs.kde.org/show_bug.cgi?id=387795 --- Comment #1 from Yichao Yu --- It is not used in qt4 version. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added CC||egorov_e...@bk.ru --- Comment #72 from Yichao Yu --- *** Bug 382182 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 382182] kdialog crached when called from google-chrome in qtcurve
https://bugs.kde.org/show_bug.cgi?id=382182 Yichao Yu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Yichao Yu --- As mentioned in https://bugs.kde.org/show_bug.cgi?id=363753 this is a upstream bug. *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 380804] hardcoded version is still 1.8.18
https://bugs.kde.org/show_bug.cgi?id=380804 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||https://commits.kde.org/qtc ||urve/a1ec5f813fefb1fbae444f ||a1bf1dc5ee65daf01b --- Comment #2 from Yichao Yu --- Git commit a1ec5f813fefb1fbae444fa1bf1dc5ee65daf01b by Yichao Yu. Committed on 04/06/2017 at 19:20. Pushed by yuyichao into branch 'master'. Bump version number to 1.9.0-rc1 M +2-2CMakeLists.txt https://commits.kde.org/qtcurve/a1ec5f813fefb1fbae444fa1bf1dc5ee65daf01b -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 380804] hardcoded version is still 1.8.18
https://bugs.kde.org/show_bug.cgi?id=380804 --- Comment #1 from Yichao Yu --- = = ... Too many numbers to change.. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 380519] Building without KDE integration fails.
https://bugs.kde.org/show_bug.cgi?id=380519 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/qtc ||urve/392e1db034708efb5921ac ||4577588f959f99fb27 Resolution|--- |FIXED --- Comment #1 from Yichao Yu --- Git commit 392e1db034708efb5921ac4577588f959f99fb27 by Yichao Yu. Committed on 03/06/2017 at 19:08. Pushed by yuyichao into branch 'master'. Add missing include when KDE integration is disabled. M +1-0qt5/style/qtcurve.cpp https://commits.kde.org/qtcurve/392e1db034708efb5921ac4577588f959f99fb27 -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #55 from Yichao Yu --- Works for me so far. Haven't got a chance to figure out what's causing the (absence of) mmap yet... I assume you'll submit a pull request with this? -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #52 from Yichao Yu --- Yes the latest version looks fine though I'd like to test it for some time. > but if I understand the DBus protocol well enough they'd have to send exactly > the "right" signals (one of those QtCurve subscribes to) and exactly at the > "right" moment. That seems a bit far-fetched. It's more complicated than that. IIRC the segfault happens when the qdbus connection walks some internal data structures for dispatch, which touches some unmapped memory (vtables and alike). > the overall complexity of KDE and Qt is becoming so big that it's not always > possible to do certain things like proper clean up because of race conditions. I hope that's not the case but maybe it is > That's probably why Qt no longer unloads (all) plugins explicitly. Except > apparently the style plugin, or that too is handled by some automagic > mechanism. Hmmm. That's interesting because I've never seen anything being unloaded before 5.8 (or 5.7?). > Presuming that each dlopen adds to a counter that prevents unmapping and each > dlcose decreases that counter you could do it in the Style ctor and dtor. Yes. If I can find the right function... > But are you sure the unmapping was performed by Qt? I've never looked into > this aspect of the code but I would expect them at most to dlclose libraries > and plugins. That should of course also invalidate the image of the library > to some degree but not necessarily unload everything. What Qt does is of course `dlclose`, the unmmap I've seen happens in the dlclose call. > Maybe your kernel is configured to do very strict cleanup, or RAM is so tight > that it tends to unload resources that are no longer needed immediately? I was hopping this to be a glibc thing but those low level detail is beyong me. > But: it'd be a severe bug if Qt somehow unloaded or even dlclosed a plugin > before having destroyed all class instances created through it. It's clearly doing the dlclose before they destructed the Style* > I've never seen an example showing that code must delete Style instances > itself, so I think the application instance takes ownership. It almost feels like that Qt should delete all QObjects before deleting the style plugin but that also seems like a terrible idea > If that also means that the file is completely removed from memory will > probably depend on circumstances, but should be a moot question. Right, my confusing is just that why it sometimes (well, previously) unmmap and sometimes not >> __attribute__((destructor)) function attributes. See the gcc info >> pages for information on these. Con‐ This I'm acutally not worrying too much. I still have a faith that the plugin destructor will be closed before dlclose (confirmed in the debugger) so using it as the last resort should still be ok. > You could add some trace output to stderr (better not via Qt code ;)) in the > library destructor and see if that confirms your hypothesis (let it print the > number of plugin and style instances that are still open, for instance). I have confirmed in the debugger that the single dlopen on qtcurve have been dlclosed. I might get a glibc with debug simple and check internal logic later... > Other things to do (as soon as you can reproduce the crash) would be to Let's hope I don't and the patch just work. > I have never seen a backtrace of the kind of crash you are seeing, but I > think that with my current implementation you should no longer be seeing it. I actually mean the stack trace in this bug report, not mine. For that I agree that adding a safe guard that's called earlier (i.e. abouttoquit) should work. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753
--- Comment #48 from Yichao Yu ---
> I cannot reproduce that - with my patch in place. If your reasoning is
> correct that patch should make me vulnerable to the crash.
Yes it'll make you vulnerable but it won't actually crash unless some unknown
conditions are met. I suspect it's related to other plugins that are also using
dbus but I'm not sure.
> What I can confirm is that Style::connectDBus() is called (exactly once in
> this case), but not the Style dtor. That's a bit surprising to me, somewhere
> I was under the impression that class dtors were always called even if you
> don't delete them explicitly.
Exactly. Good to know at least you can observe this. I can only say that I've
seen this leads to crashes before and I don't really think this should happen.
I've just checked that this doesn't crash for me anymore but I've also noticed
that it is because the library is somehow not ummaped anymore, meaning if it
does in some case the crash I saw before will come back again. Not sure why.
(OTOH, another way to work around this is to dlopen the library itself so that
the dlclose won't actually unmmap the library code. Not sure how that can be
done though)
> There's no way to use something like a Q*Pointer class to get automatic
> deleting of those Style instances?
= = I actually have no idea who created them and how the memory is managed
by either qt or the application
> But good, if you can reproduce it you can also try to figure out what other
> methods there are to avoid it.
The problem now is that I can't reproduce the crash at the moment anymore but
almost everything that leads to it are still reproducible (i.e. the distructor
is not called before the library is dlclosed) which means it's hard for me to
tell if any alternative solution can work I'm checking why is dlclose
not unmapping the library, though don't expect that to be very easy
> What Qt version are you using?
5.8.0 ATM
> I believe that's effectly the same. The closure isn't what's causing the
> crash.
> Effectively the same but with the closure we don't really know where the
> Style instance pointer comes from. That's what I hinted at earlier; if the
> cleanup closure is registered twice for the same instance it's not certain
> how valid the this pointer ("data") is when called the 2nd time. Seems
> farfetched, I know, but we're dealing with an issue here that we don't really
> understand, so the mechanism to prevent it should be as easy to understand
> and verify as possible.
Sure, I'll be certainly fine with that. Though given many (all?) of the
backtrace points to `QDBusConnection::sessionBus` I don't think that'll solve
the problem...
--
You are receiving this mail because:
You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #45 from Yichao Yu --- > Maybe that has to do with the kind of signals we're connecting to but I don't > understand how this could happen. I don't see how QtCurve could be unloaded > without calling the Style dtor; dlclose'ing it seems certainly something that > shouldn't be happening in normal applications while they are still running. I just tested it and it seems to still happen on 17.04 It can be triggered by any programes I've tested that end up not showing a UI by itself `konsole --help` for example. > I've never seen that kind of crash happen with the attached patch but I would > guess it must be something else that we should be able to address more > properly than with the current cleanup callbacks. Clearly Breeze and Oxygen > aren't affected so it must be possible. It'll be strictly worse for the case I described though might be better at working around the Qt bug. > There's always the possibility of storing the plugin instance in each Style > instance, and maintaining a list of Style instances in each plugin instance. > If the Style dtor tells its plugin instance to remove it the plugin dtor can > know if there are still "open" Style instances and delete those first. I > think that's cleaner (and easier to debug!) than the current approach with a > closure (lambda). I believe that's effectly the same. The closure isn't what's causing the crash. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #43 from Yichao Yu --- > fWhat callback are we talking about here? The slots connected to the DBus signals. > The function in which the crash occurs is called from the plugin dtor, not > directly from the application. Correct, because if this is not done, the application (or other plugins) can trigger DBus signals that segfaults. This is exactly the crash I mentioned very early on. https://bugs.kde.org/show_bug.cgi?id=363753#c2 -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #41 from Yichao Yu --- > I maintain that the plugin shouldn't trigger callbacks if it cannot be sure > that those callbacks are safe. Sure, the plugin is not the one triggerring the callback, the applications is, which makes the clean up not optional in some cases. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #39 from Yichao Yu --- (Sorry, not sure why I commented twice, definitely didn't refresh page and not sure how to remove it.) -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #38 from Yichao Yu --- > What is it that doesn't work in that approach? What I've seen happens is 1. Plugin was unloaded 2. Callback triggers 3. Jumps to the plugin code section which is unmmapped. 4. Segfault > Possibly, but in that case one should apparently not try to clean up. The above sequence will still segfault so the clean up has to be done before the plugin is unloaded. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #37 from Yichao Yu --- > What is it that doesn't work in that approach? What I've seen happens is 1. Plugin was unloaded 2. Callback triggers 3. Jumps to the plugin code section which is unmmapped. 4. Segfault > Possibly, but in that case one should apparently not try to clean up. The above sequence will still segfault so the clean up has to be done before the plugin is unloaded. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #34 from Yichao Yu --- FWIW, doing things just in the destructor doesn't work and that's exactly why I need to do this complicated mess. Apparently some application doesn't desctruct the Style before unloading the plugin.. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 379175] kactivitymanagerd crashes in QtCurve code
https://bugs.kde.org/show_bug.cgi?id=379175 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Yichao Yu --- *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added CC||luke-jr+kdeb...@utopios.org --- Comment #27 from Yichao Yu --- *** Bug 379175 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 377353] Crash on login while using "QtCurve".
https://bugs.kde.org/show_bug.cgi?id=377353 Yichao Yu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Yichao Yu --- *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #26 from Yichao Yu --- *** Bug 377353 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 378723] Dolphin crashes while logging out.
https://bugs.kde.org/show_bug.cgi?id=378723 Yichao Yu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Yichao Yu --- *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added CC||jodr...@live.com --- Comment #25 from Yichao Yu --- *** Bug 378723 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376155] "Quick tile window to the left/right" de-maximizes the window without tiling as a first action since plasma 5.9.0
https://bugs.kde.org/show_bug.cgi?id=376155 --- Comment #8 from Yichao Yu --- No, there's a slightly different behavior that I cannot fix even with my patch so I didn't submitted it (the behavior might be new in 5.2). This time, instead of simply untile (and doesn't move), it does not resize (and didn't receive any restore size signal as printing in kwin code shows) when I drag it but restores it's original (untiled) size when I try to tile it. The difference of the end result is that the window is moved, but the size is still wrong. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 --- Comment #10 from Yichao Yu --- I assume by that you mean https://phabricator.kde.org/D3602 ? I didn't want to comment on a merged pull request so I opened a bug report. I'll comment there instead. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 --- Comment #8 from Yichao Yu --- Right, there are a lot of shortcuts that shouldn't be used with autorepeat, but the change turns these ones from autorepeatable to not autorepeatable and therefore one of the most important statements in the usability feedback namely > Those who would not expect the wrap-around behavior would not expect anything > to happen at all, and therefore not even press the shortcut if they are at the > left-/rightmost window. is wrong. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 --- Comment #6 from Yichao Yu --- Yet another acceptable solution would be to expose the new `switchWindow` function in the KWin scripting interface (I thought it's possible to trigger script with hotkey/add hotkey from a script?). I'm happy to implement and add test with either methods though I'll need some help for how to add a test for it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 Yichao Yu changed: What|Removed |Added Summary|Provide an option to|Revert wrapping in window |disable wrapping in window |swithing |swithing| -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 --- Comment #5 from Yichao Yu --- Also, although I'm not that familiar with how the auto testing is done on X11, it seems that this should be a relatively easy thing to test for both options and should not be strongly coupled to other options so detecting breakage should be possible. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Revert wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 Yichao Yu changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #4 from Yichao Yu --- In that case, consider this a request to revert the behavior since I don't think the usability feedback considered the effect of keyboard autorepeating. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] Provide an option to disable wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 --- Comment #2 from Yichao Yu --- What's the usability feedback? I've seen https://phabricator.kde.org/D3602#70700 but it doesn't seem to make sense for me. > Those who would not expect the wrap-around behavior would not expect anything > to happen at all, and therefore not even press the shortcut if they are at > the left-/rightmost window. This is omitting the fact that keyboard can autorepeats. Also, I've already tried that for more than a week and still couldn't get used to it. Other behavior changes that are indeed possible to get used to usually takes less than a day of continuous using. Why would this increase maintainer overhead? Is there anything very bad about adding such an option? Code wise it should be a one line change (other than adding the option itself) to skip the retry block. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 362856] [Frameworks] Wrong render resolution, possibly caused by Plasma 5 "Scale Display"
https://bugs.kde.org/show_bug.cgi?id=362856 Yichao Yu changed: What|Removed |Added CC||yyc1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376155] "Quick tile window to the left/right" de-maximizes the window without tiling as a first action since plasma 5.9.0
https://bugs.kde.org/show_bug.cgi?id=376155 --- Comment #4 from Yichao Yu --- Does KWin support automatic testing on X now? Also does that change look correct? The symptom AFAICT is definitely that `m_quickTileMode` is changed from `0` to `1` (or the other way around, don't remember) after `setMaximize` returns. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376457] New: Provide an option to disable wrapping in window swithing
https://bugs.kde.org/show_bug.cgi?id=376457 Bug ID: 376457 Summary: Provide an option to disable wrapping in window swithing Product: kwin Version: 5.9.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: yyc1...@gmail.com Target Milestone: --- Ref https://phabricator.kde.org/D3602. TL;DR. I can see the usefulness of this behavior but it's also very annoy when you don't expect it. As the title says, I'd like an option to revert back to the old behavior. Longer version: Here's why I think the old behavior is not "useless" as described in the patch that adds this feature. It is indeed conceptually more consistent with desktop/screen switching behavior but at least one of the big difference is that screen and desktops do not overlap. It is common for windows to overlap and of wildly different sizes to it's already harder to begin with to predict with window is the next one and this behavior makes it even harder. I use these shortcut to navigate between windows quickly and with this change it takes a lot more effort to count the number of times I pressed the key because I can't hold down the key for 1s and expect it to end up in one of the two windows on the left side of the screen anymore. It's true that it should only about double the targets on average on my setup since my windows are usually either left or right tiled but tracing a semi randomly moving focus takes much more effort. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376155] "Quick tile window to the left/right" de-maximizes the window without tiling as a first action since plasma 5.9.0
https://bugs.kde.org/show_bug.cgi?id=376155 --- Comment #2 from Yichao Yu --- I suspect that this is caused by ``` commit 9934f5b57537feae54afd0c4366c90253638ada2 Author: Martin Gräßlin Date: Fri Sep 16 14:27:50 2016 +0200 Properly implement maximize of ShellClient Summary: This brings some more checks from Client to ShellClient. Thus the states are better adjusted. Unfortunately the X11 implementation is also slightly adjusted, so could create regressions in worst case. BUG: 368393 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3507 ``` And I assume this might be one of the "worst case". The following patch seems to fix the issue for me locally though I'm not sure if it's the right solution. I'll submit a review if no one proposed a better solution in a few days. ``` diff --git a/geometry.cpp b/geometry.cpp index 64b5d67ca..420549aeb 100644 --- a/geometry.cpp +++ b/geometry.cpp @@ -,11 +,11 @@ void AbstractClient::setQuickTileMode(QuickTileMode mode, bool keyboard) m_quickTileMode = QuickTileNone; // Temporary, so the maximize code doesn't get all confused setGeometry(electricBorderMaximizeGeometry(keyboard ? geometry().center() : Cursor::pos(), desktop()), geom_mode); } +setMaximize(false, false); + // Store the mode change m_quickTileMode = mode; -setMaximize(false, false); - emit quickTileModeChanged(); return; ``` -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 376155] "Quick tile window to the left/right" de-maximizes the window without tiling as a first action since plasma 5.9.0
https://bugs.kde.org/show_bug.cgi?id=376155 Yichao Yu changed: What|Removed |Added CC||yyc1...@gmail.com --- Comment #1 from Yichao Yu --- I'm seeing this behavior too, though for the tiling behavior by dragging the window to a screen edge. It happens also for windows that were tiled when opened and not just the maximized ones. This is ArchLinux package. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 376340] Le impostazione crashano non appena provo ad aprire le impostazioni di QtCurve
https://bugs.kde.org/show_bug.cgi?id=376340 --- Comment #6 from Yichao Yu --- Is the master version ok? I cannot reproduce this somehow -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 376164] GTK3 Engine
https://bugs.kde.org/show_bug.cgi?id=376164 --- Comment #1 from Yichao Yu --- The stabilized API apparently has all the APIs used by most theme engines removed so it's much harder to implement anything for GTK3 now. There was a debate on the thread where they decide to deprecate the API by keeping the symbol and make them no-op. The bottom line is that it's unlikely that QtCurve will have a GTK3 port before Oxygen does (and Oxygen-GTK3 doesn't work anymore for some GTK versions already AFAICT). -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style
https://bugs.kde.org/show_bug.cgi?id=374224 --- Comment #49 from Yichao Yu --- By homogeneous I mean the setting is a single color. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style
https://bugs.kde.org/show_bug.cgi?id=374224 --- Comment #47 from Yichao Yu --- > Is what you're asking in any way different from launching the QtCurve theme > editor via `kcmshell5 style`, setting menu opacity to 50%, confirming they > indeed become translucent (I had to detach the preview for that) and then > putting the opacity back to 100%? I usually use a different application. The effect to avoid is a completely transparent background and IIRC this can happen if the application/qt stops rendering the background since the style tells it not to by setting the attribute and then QtCurve also stops rendering it since it's the application/qt's job for non-translucent window. This should only happen for homogeneous background. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style
https://bugs.kde.org/show_bug.cgi?id=374224 --- Comment #45 from Yichao Yu --- > Yichao, what do you think, can I commit this patch? Using WA_TranslucentBackground for QMenu sounds safe. Be sure to check if flipping the menu opacity setting to 100% after application started doesn't regress. (I can't remember which case(s) are correctly handled and which are not but I'm pretty sure it's one of the side effects related to setting the attribute) The interaction between WA_TranslucentBackground with other settings is AFAIK still present in latest version of qtbase so I wouldn't use it for all widgets. That said I have main window opacity setting to 100% for a while so I didn't noticed that there are a few regressions there (most noticeably menubars) so more investigation is needed. I assume the freeze only happens in kdialog 16.12? (I can't reproduce it on 16.08). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style
https://bugs.kde.org/show_bug.cgi?id=374224 --- Comment #29 from Yichao Yu --- The usage is basically unsupported by Qt and is a hack from the very beginning so unless Qt provide a proper way to do it this is always a bug of the style. The only question is that what's a better way to hack it. Setting `WA_TranslucentBackground` was indeed what I started with https://github.com/QtCurve/qtcurve/blame/58a4438b901311914d0d453c3987bfabbf258047/qt5/style/qtcurve.cpp#L406 . However, (at least in Qt 5.0/5.1) it causes many side effects that needs to be undone and calling the private API/interact with the backend directly caused much less trouble so I decided to switch to the current approach in https://github.com/QtCurve/qtcurve/commit/c1543d2f27e5ac6f6424537a53e3764233967e68 The main issue with setting `WA_TranslucentBackground` is that applications actually test/set it and messing with it creates lots of confusions in the application/high level libs (iirc kwin and plasma together with their widget libraries caused a lot of issues). OTOH, there are much fewer backends so backend specific hacks are much easier to write without worrying about application specific behaviors. Therefore, IMHO, the best solution (other than having deeper support from Qt) is to interact with the backend directly and make sure the native windows created have the correct events etc. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 374568] Applications crash when menu bar is accessed
https://bugs.kde.org/show_bug.cgi?id=374568 --- Comment #23 from Yichao Yu --- > I have nothing against your initial explicit cast to a QObject*, what about > you Yichao? Sounds good to me too. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 374568] Applications crash when menu bar is accessed
https://bugs.kde.org/show_bug.cgi?id=374568
--- Comment #10 from Yichao Yu ---
I agree the code is likely UB. Still curious why it only crashes on your setup
and what code the compiler actually generate. When the method is protected,
would the following work?
```
struct HackedMenu: public QMenuBar {
static void send(QMenuBar *menubar, QMouseEvent *event)
{
menubar->event(event);
}
};
if (((HackEvent*)event)->adjust()) {
HackedMenu::send(menu, event);
return true;
}
```
This should not be UB (I hope?) and does not have any of the casts.
--
You are receiving this mail because:
You are watching all bug changes.
[QtCurve] [Bug 374568] Applications crash when menu bar is accessed
https://bugs.kde.org/show_bug.cgi?id=374568 --- Comment #4 from Yichao Yu --- That patch looks correct. IIRC that hack was probably needed since the method was protected. (maybe on qt4? My internet connection is too terrible before Jan. 10 for me to do a detail check) Just curious, why would the old version not work? Is it accidentally defining a virtual method? -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #19 from Yichao Yu --- > I use Qt 5.6.1 with the patch under review at > https://codereview.qt-project.org/161056 Forgot to say that it's great to know the patch is working for you. What's blocking the patch right now? > (I'm setting this report to "closed" as it certainly isn't "resolved" IMHO) Sorry. Too many states to remember ;-p -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #17 from Yichao Yu --- Not sure how to find the public link to the patch but it basically revert the commit you link above. Th Qt bug is in 5.6+ IIRC, this is the Qt version that starts to unload (unmap) the plugin file which cause segfault if the callbakcs are not removed. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #15 from Yichao Yu --- It's wrong mainly in the sense that causes segfault in situation that doesn't segfault, i.e. it causes segfault on my setup due to (I'm guessing) interaction with other plugins. It is possibly the best a distro can do (other than avoiding the buggy qt versions) to minimize the number of users that sees the segfault so I think it's okay for debian to use it. However the current master should be more likely the right long term solution since with the qt patch it is very likely still segfault in the case fixed by the commit on the qtcurve master. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM --- Comment #13 from Yichao Yu --- > Is this the same bug for which Beojan sent a patch (created by a Debian > package maintainer)? Yes, but the debian patch is wrong. > I think, the bug "added" in commit 3d8622c > https://quickgit.kde.org/?p=qtcurve.git&a=commitdiff&h=3d8622c419a32033e36e940e8cb09b591ad93e29 (The "bug" was added**). It's not a qtcurve bug, it's a QtDBus one and should be fixed there. It just happens that in some configuration the QtDBus is unloaded before QtCurve and after in other cases. The commit should only be reverted if 1. Qt guarantees that any callback registered will not be called again automatically (i.e. without unregistering in the destructor) when the plugin is unloaded (noted that the destructor of the Style itself is never called AFAICT) and/or, 2. the plugin is never unloaded (i.e. never unmap'd) > The patch by the Debian maintainer(s) does something else; it removes the > cleanup mechanism. I haven't checked when that mechanism was introduced (or > exactly why) but it does seem to introduce complexity that is probably > supposed to be unnecessary. The reason is that `Style` is never destructed so doing clean up in the destructor doesn't work. It can't be removed if this is not fixed in Qt, after which the Debian patch won't work anymore. Close as upstream bug for now. Feel free to request for reopening/opening a new one if the bug persists after the Qt bug is fixed (see PR linked above) or there's consensus from upstream how the global destruction order can be handled in another way (possibly by **not** doing destruction, including the two bullet points I mentioned above.) -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 362907] kwin_x11 crashes in QtCurve::Style::disconnectDBus()
https://bugs.kde.org/show_bug.cgi?id=362907 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Yichao Yu --- See more detail at https://bugs.kde.org/show_bug.cgi?id=363753 AFAICT it's a Qt5 bug. *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added CC||tehnic...@yandex.ru --- Comment #9 from Yichao Yu --- *** Bug 362907 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 Yichao Yu changed: What|Removed |Added CC||edisonalvari...@bol.com.br --- Comment #8 from Yichao Yu --- *** Bug 366815 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 366815] Systemsettings crashes when reloading reopening
https://bugs.kde.org/show_bug.cgi?id=366815 Yichao Yu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Yichao Yu --- Dup of https://bugs.kde.org/show_bug.cgi?id=363753 It's a Qt5 bug. *** This bug has been marked as a duplicate of bug 363753 *** -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 353216] qtcurve-qt5 is missing the qtcurve window decoration in Plasma 5
https://bugs.kde.org/show_bug.cgi?id=353216 --- Comment #10 from Yichao Yu --- > Status please The status is that I was told the API change should be sane and therefore expecting relatively straightforward upgrade path and thought I could finish it relatively quickly. However, I've made a few attempt to do the upgrade but all of them failed since I couldn't really find any document (as of a few month ago at least) about the API change or the upgrade (in particular, there are a few component in the kwin4 decoration that I couldn't easily find a replacement in the new API). It would be helpful if anyone with the knowledge about the new API or the upgrade path to provide some document on those. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #5 from Yichao Yu --- I don't thinkt he crash is OSX specific (fwiw I think this is a dup of https://bugs.kde.org/show_bug.cgi?id=362907). I'm guessing this can be due to other plugins here that uses dbus too which is why I smell a global destruction ordering issue and (as mentioned above) I'm not sure how to guess the right behavior. (i.e. if qdbus is destructed before us then I don't need to disconnect the connection since it's better been disconnected already). I'm interested to know if the Qt patch helps. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #3 from Yichao Yu --- > not really sure what's the right solutions As in not sure what action to take here. From the description in the qt review you linked, it seems that this can be fixed properly on Qt side. -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 363753] crash-at-exit in QtCurve::Style::disconnectDBus
https://bugs.kde.org/show_bug.cgi?id=363753 --- Comment #2 from Yichao Yu --- I guess that makes sense. OTOH, the commit that introduces this is due to the observation that the dbus callbacks are being called **after** qtcurve is `dlclose`d which segfault on the function call (after all the code isn't there anymore). I'm not really sure what's the right solutions here (or what changed on Qt 5.6 that's causing this). -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 362907] kwin_x11 crashes in QtCurve::Style::disconnectDBus()
https://bugs.kde.org/show_bug.cgi?id=362907 --- Comment #1 from Yichao Yu --- The commit fixes segfault on a Qt upgrade. I do have to workaround a number of bugs so maybe it's fine to disable it on 5.5 -- You are receiving this mail because: You are watching all bug changes.
[akregator] [Bug 356978] New: Clicking any article cause all articles to be set to read when only unread articles are shown.
https://bugs.kde.org/show_bug.cgi?id=356978 Bug ID: 356978 Summary: Clicking any article cause all articles to be set to read when only unread articles are shown. Product: akregator Version: GIT (master) Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: yyc1...@gmail.com Version is 5.1 included in kde 15.12 but I can't find that version in the list above. See step to repro below. Reproducible: Always Steps to Reproduce: 1. Set to only show unread articles 2. Click any article 3. Actual Results: All articles are set to read one by one very quickly Expected Results: Only one article should be set to read. This is a regression from the previous version (15.08) -- You are receiving this mail because: You are watching all bug changes.
