[plasmashell] [Bug 473170] Plasma crashes when dragging desktop files to Firefox (in native Wayland mode)
https://bugs.kde.org/show_bug.cgi?id=473170 --- Comment #3 from Tsu Jan --- > Ahh of course, it's Bug 470925. It's fixed in Qt 6.6. Thanks for the info! We needed it in LXQt. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 473170] Plasma crashes when dragging desktop files to Firefox (in native Wayland mode)
https://bugs.kde.org/show_bug.cgi?id=473170 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #1 from Tsu Jan --- This might be related if the issue happens with Qt6: Qt 6.5.2 seems to have a serious regression regarding drag-and-drop under Wayland (not just Plasma-Wayland). I can reproduce its DND problem under various Wayland compositors and with all Qt6 apps which support DND; it can easily result in crashes in those apps. See https://github.com/lxqt/pcmanfm-qt/issues/1800#issuecomment-1671294865 for a general backtrace. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kimageformats] [Bug 463951] PCX image issues
https://bugs.kde.org/show_bug.cgi?id=463951 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #2 from Tsu Jan --- KDE's GWenview has the same behavior. The problem is independent of the Qt viewer (I tried 3). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #7 from Tsu Jan --- After a long search in Qt's code and finding no problem in it, I started to get suspicious of the old dragging code of Breeze/Kvantum/QtCurve and, finally, succeeded in replacing it with another code structure that solved the problem in Kvantum, under both X11 and Wayland, and also under all Wayland compositors. Long story short, with Qt ≥ 5.11, the event filter should be installed on QWindow, not QWidget, and the mouse press event of QWindow should be "eaten up" to start the drag (the long story is in the latest git source 'Kvantum/style/drag/windowmanager.cpp'). The same approach can be used with Breeze (and QtCurve). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #6 from Tsu Jan --- Oh, I'd added a code comment to Kvantum: It started to happen with Qt5.11. Before 5.11, the code worked fine everywhere: Breeze, Kvantum and QtCurve used it with some variations (I think the original code came from QtCurve or Bespin?). I can't report the problem to Qt because they need a code sample to reproduce it and I don't know exactly where the problem is :( If I find the time, I'll try to compare the sources of Qt 5.10 and 5.11. Will add a comment here if I find the cause. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #4 from Tsu Jan --- It isn't related to resuming. You should put the mouse cursor over widgets that have a hover effect (like toolbar buttons). Actually, it isn't limited to Breeze; it happens with QtCurve too. It also happened with Kvantum but I added a workaround for X11 to Kvantum. Sadly, the workaround can't be used for Wayland. I recently added 'QWindow::startSystemMove()' to Kvantum for Wayland and dragging had the same problem under Wayland. I even tried sending enter events to no avail. So, I think the problem should be in Qt. As a matter of fact, it started to happen after a Qt upgrade but I don't remember which version. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #2 from Tsu Jan --- This may be a Qt issue because now, with Qt 5.15, the drag code uses QWindow::startSystemMove() and yet, the problem exists under both X11 and Wayland. The structure of the drag code is very old (a mouse press sends a mouse move event, which triggers dragging under appropriate conditions, and a mouse release event is sent after the drag is finished) but I couldn't find a problem in it. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 427871] home key does not work right away in Dolphin
https://bugs.kde.org/show_bug.cgi?id=427871 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #3 from Tsu Jan --- The current behavior of the Home key (which is its default behavior in Qt) is consistent with that of arrow keys as well as PgUp and PgDn. For example, when the top left index is already the CURRENT item but not selected, up/left arrow, PgUp and Home shouldn't and don't select anything because there's nothing beyond it. Selecting the tope left CURRENT item with Home would be inconsistent with the behavior of other navigation keys. Space can be used to select the current item (and Ctrl+Space to deselect it). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 346687] The Zero-width_non-joiner character does not work.
https://bugs.kde.org/show_bug.cgi?id=346687 --- Comment #7 from Tsu Jan --- Yes, this was a Qt issue. It was fixed a long time ago, after this old report. The Zero-width_non-joiner character is OK. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #20 from Tsu Jan --- > Is it scheduled for 5.16 series I hope? That's my question too -- I'm just a kwin user. I only know that the patch isn't applied to kwin 5.16.2. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #18 from Tsu Jan --- > It's really annoying because It's already fixed under X11. You could apply the patch or wait for it to come to your distro. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #15 from Tsu Jan --- OK, tested and saw the bug was present under Wayland too -- the patch had no effect there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #14 from Tsu Jan --- Here, the patch fixed the issue. Thanks a lot! I haven't tested KWin 5.16.1 under Wayland though. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408915] New: Blur effect: too much darkness with dark translucent backgrounds
https://bugs.kde.org/show_bug.cgi?id=408915 Bug ID: 408915 Summary: Blur effect: too much darkness with dark translucent backgrounds Product: kwin Version: 5.16.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: tsujan2...@gmail.com Target Milestone: --- Created attachment 121001 --> https://bugs.kde.org/attachment.cgi?id=121001&action=edit Comparison with older KWin The new KWin blur effect (dual blur algorithm?) is much better than the older one but, after upgrading to KWin 5.16, something has changed, so that dark translucent backgrounds look too dark with blurring. I've attached a screenshot for comparison: the darkness of a black terminal with an opacity of 60% (40% translucent) seems quite unnatural against the wallpaper, whether it's compared to older KWin versions or to Compiz. There's no difference in darkness when the same terminal is put against a completely white background. There's also another issue, which I should have reported sooner: The new blur effect is too strong, so that even a value of 4 in the blur settings dialog is more than enough in most cases, while the slider supports greater values. Perhaps the blur settings needed to be updated after the new blur effect was implemented. I have Intel graphics and use KWin with X11. SOFTWARE/OS VERSIONS Linux/KDE Plasma (available in About System) KDE Plasma Version: 5.16.0 Qt Version: 5.12.3 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405781] Editing kde widgets crashing plasma session
https://bugs.kde.org/show_bug.cgi?id=405781 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #5 from Tsu Jan --- The crash is prevented in Kvantum 0.11.0 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405801] KWin crashes when trying to configure plasmoids
https://bugs.kde.org/show_bug.cgi?id=405801 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #3 from Tsu Jan --- The crash is prevented in Kvantum 0.11.0 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 399680] Graphical glitch/corruption in menu when transparency effect is enabled
https://bugs.kde.org/show_bug.cgi?id=399680 --- Comment #8 from Tsu Jan --- And I don't recommend an early creation of native handles at all -- it would have bad side effects. Sorry, I didn't have time to read the KDE code. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 399680] Graphical glitch/corruption in menu when transparency effect is enabled
https://bugs.kde.org/show_bug.cgi?id=399680 --- Comment #7 from Tsu Jan --- > Would you mind helping us Tsujan? Your Kvantum does this very well... If this happens with Kvantum too, please report it to Kvantum's github page (although I've never seen it). I don't think I can be of any help here because Kvantum deals with window/menu translucency very differently. In short, when Qt5 came out (or a little later), window translucency became a problem because Qt5 windows are (often) polished after they're created but, for translucency, the surface format of their native handles should be set BEFORE they're created. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 402595] Artifact while moving a transparent window with the wobbly effect
https://bugs.kde.org/show_bug.cgi?id=402595 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #5 from Tsu Jan --- I just wanted to add that this isn't just about the wobbly effect or translucency. You could also see it when showing the desktop cube, sphere or cylinder with opaque windows and opaque title bars. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #16 from Tsu Jan --- For the sake of thoroughness, I should add that it wasn't a driver issue but really a kwin problem, which is fixed in V5.13 somehow (the new blur effect may have a role in that). My reason is that no driver was upgraded when kwin was upgraded to V5.13 (now, 5.13.3). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #15 from Tsu Jan --- > Marking as upstream as it looks quite a lot like a driver issue. Most probably. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #13 from Tsu Jan --- Sorry, I meant DRI2 -- copy/paste typo. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #12 from Tsu Jan --- Switching to DDR2 (with modesetting) and choosing "OpenGl 2.0" as well as "Full screen repaints" in System Settings had a considerable positive effect. DDR3 seems to have bugs, whether with modesetting or with the Intel driver. Looking forward to a fully usable Wayland plasma. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 346687] The Zero-width_non-joiner character does not work.
https://bugs.kde.org/show_bug.cgi?id=346687
--- Comment #5 from Tsu Jan ---
> could give some inspirations for a fix in Kate
Don't know about Kate's code but, for example, inside keyPressEvent(QKeyEvent
*event) this can be done for a text-edit:
if (event->key() == 0x200c)
{
insertPlainText (QChar (0x200C));
event->accept();
return;
}
It shouldn't be needed after the Qt fix but, apparently, Kate's behavior is
different from that of QPlainTextEdit.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 346687] The Zero-width_non-joiner character does not work.
https://bugs.kde.org/show_bug.cgi?id=346687 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #3 from Tsu Jan --- The issue is in Kate's view. The search line-edit, for example, is OK now because the same issue is fixed in Qt-5.9. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #12 from Tsu Jan --- A very different method. Anyhow, it's great that Dolphin has it :) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #10 from Tsu Jan --- Thank you very much! Sorry that I wasn't able to do it! IMHO, this is one the 2 "important" problems of Dolphin -- none of which is very important -- the other one being the random 1-s delay at startup. If I find enough free time, I'll look into the second issue -- this time on phabricator. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #8 from Tsu Jan --- > are you willing to let me take over the patch? Oh, that would be very kind of you! Yes, please! I haven't touched the patch for a long time; it may need to be updated. As far as I remember, at that time, some changes in Dolphin made the job very easy; just a few changes was enough for this functionality to be implemented. Thanks for your attention! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #6 from Tsu Jan --- This isn't about advertising: I know for sure that GitHub is very practical, makes the contribution easy and doesn't waste anyone's time. In comparison, I started to try phabricator with Enlightenment but it wasn't promising. I also wanted to try it with KDE months ago; it was an *obstacle*. Add to this the limited free time each of us may have. KDE devs should have their reasons for not using github for active development, while many devs have their reasons to prefer it. These are facts without judgment. I don't participate in lengthy discussions about reasons. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #4 from Tsu Jan --- If only KDE was developed on GtiHub... Sorry, but the current situation doesn't encourage any contribution. Believe me, KDE needs a lot of contribution. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #11 from Tsu Jan --- > What about switching to breeze window decoration? I sometimes use breeze but there's no difference in this regard. I tested with an older Intel-based Asus laptop and saw that the problem was so mild that it was almost invisible, although I could reproduce it by rotating the desktop cube rapidly on closing Firefox and Thunderbird (with fade effect). My work laptop (Lenovo Ideapad Y700) is newer and the issue can be seen easily with it. Neither on Asus nor on Lenovo, there's no suspicious CPU usage when KWin animations interfere with each other. Is there any theoretical explanation about how KWin animations could interfere with each other or with non-kwin ones? Can Xorg also have a part in this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #9 from Tsu Jan --- I tried the Intel Xorg driver again -- its bugs are fixed now -- but it had no effect on this problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #8 from Tsu Jan --- Oh, I forgot to tell you about something that may contain a clue: KWin effects (animation) may interfere with non-kwin ones too. For example, I also use KWin under LXQt. LXQt's hiding panel has an animation and sometimes, when I close a window and make the panel visible, kwin makes the latter (non-kwin) animation choppy too. A few minutes ago, I logged out of KDE and into LXQt and saw the same thing with OpenGL3. Again, this never happens with Compiz; so, something in kwin should be the cause. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #7 from Tsu Jan --- > You could try switching to OpenGL 3 I had tried that before but got error messages in `~/.local/share/sddm/xorg-session.log` (I don't remember them). However, I tried it again a few minutes ago and saw no error message (because of recent fixes?). The performance is better now but the lagging and choppy animation are still reproducible immediately after a window is opened/closed, and that includes cube rotation too; the difference is just that now, one has to try a little harder to see them. The reason why I see it more than others may be because of the way I use desktop. For example, I may open a window and quickly change desktop (with cube animation) to open a terminal. All the bad performance I've seen is about when an animation should be FINISHED and another should be STARTED; otherwise, single animations are always smooth. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817
--- Comment #5 from Tsu Jan ---
It's modesetting ("xf86-video-intel" was VERY buggy here and its use is
discouraged correctly, IMO). As for dri3, `LIBGL_DEBUG=verbose glxinfo | grep
libgl` gives:
...
libGL: pci id for fd 4: 8086:191b, driver i965
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i965_dri.so
libGL: Using DRI3 for screen 0
...
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #3 from Tsu Jan --- Another descriptive info, if it helps: With kwin effects enabled, starting Dolphin (and some other apps that may have a delay on starting -- although I think Dolphin's start delay is a bug) sometimes creates an empty rectangle, inside which Dolphin appears after ~1 second or less. Again, this never happens when Dolphin is started under Compiz with several effects enabled. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 382817] Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 --- Comment #2 from Tsu Jan --- KWin Support Information: The following information should be used when requesting support on e.g. http://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like http://paste.kde.org instead of pasting into support threads. == Version === KWin version: 5.10.4 Qt Version: 5.9.1 Qt compile version: 5.9.1 XCB compile version: 1.12 Operation Mode: X11 only Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_INPUT: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 11903000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.kwin.aurorae Theme: __aurorae__svg__KvAmbience Blur: 1 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 9 decorationButtonsRight: 3, 4, 5 borderSize: 0 gridUnit: 10 font: Noto Sans,10,-1,0,50,0,0,0,0,0 smallSpacing: 2 largeSpacing: 10 Options === focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5019 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 1 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 1 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 glSmoothScale: 2 xrenderSmoothScale: false maxFpsInterval: 1666 refreshRate: 0 vBlankTime: 600 glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: false glPreferBufferSwap: 101 glPlatformInterface: 1 windowsBlockCompositing: false Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight
[kwin] [Bug 382817] New: Choppy and, generally, problematic KWin effects
https://bugs.kde.org/show_bug.cgi?id=382817 Bug ID: 382817 Summary: Choppy and, generally, problematic KWin effects Product: kwin Version: 5.10.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: effects-window-management Assignee: kwin-bugs-n...@kde.org Reporter: tsujan2...@gmail.com Target Milestone: --- Since KWin(X11) V5.10 (or maybe 5.8) and with kwin effects enabled, when I open a window (like that of Konsole) and try to move it immediately after that, or when I close a window and try to open a menu immediately after that, or when I close a window and try to open another one immediately after that, or..., in the first case, the movement is very jerky, in the second case, the menu is opened badly depending on the effect (with the fade effect, it's semi-transparent and unusable for a second), in the third case there's a tangible delay, etc. Generally, kwin effects have recently been interfering with other jobs. This happens with all sorts of effects, for example, those I've made with translation, rotation, fading, etc. The bad performance is visible in both Manjaro (Testing) and Debian (Unstable). None of this happens with Compiz (https://github.com/compiz-reloaded) on the same computer and with the same Linux distro (Manjaro Testing). Actually, that old Compiz and its various effects work like a charm after so many years! Graphical info: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:3802] Flags: bus master, fast devsel, latency 0, IRQ 139 Memory at 9200 (64-bit, non-prefetchable) [size=16M] Memory at a000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: i915 Kernel modules: i915 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.5 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 17.1.5 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.1.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #18 from Tsu Jan --- @Martin This time the patch works like a charm :) Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #16 from Tsu Jan --- > unfortunately I can confirm that this theme still doesn't work. Actually, any theme, with or without bottom border because even if there's a bottom border, although the titlebar text and buttons will be shown correctly, the bottom shadow height will be added to the bottom border on shading -- which is a new bug with the patch in question. To test, use a theme with large shadows -- like the attached one -- and with a bottom border. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #14 from Tsu Jan --- Created attachment 106653 --> https://bugs.kde.org/attachment.cgi?id=106653&action=edit An Aurorae theme without border Attached is an Aurorae theme without (bottom) border but with large shadow. If I make a theme like it but with a bottom border of 1px, the shaded window will show a bottom border as thick as the shadow + 1px. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #12 from Tsu Jan --- Created attachment 106652 --> https://bugs.kde.org/attachment.cgi?id=106652&action=edit Problem with patch+Aurorae I'm afraid the patch doesn't work well with Aurorae (although it works with Plastik). First, it doesn't do anything when BorderBottom=0. Second, if BorderBottom is set to a positive value -- even 1 -- the patch "works" weirdly because the whole bottom shadow will be given to the shaded window, as the attached screenshot shows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #10 from Tsu Jan --- Happy to see there's an activity about this; just wanted to emphasize that the issue isn't specific to Plastik and, theoretically, any fix should solve the same problem in Aurorae too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 --- Comment #5 from Tsu Jan --- This bug has been there for a long time. The problem is that Breeze's look is so elementary and it doesn't support translucency or fine-tuning, so many KWin users use Aurorae instead. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 344326] Buffer objects (VBO, FBO) need remapping after suspend/vt switch with NVIDIA
https://bugs.kde.org/show_bug.cgi?id=344326 --- Comment #133 from Tsu Jan --- I'm not a KDE dev and I completely agree with Martin. It doesn't seem fair to see KDE responsible for the behavior of a closed-source program like nvidia. KDE devs did what the could (and I'm sure they will) but this issue seems to be really an nvidia problem. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377411] Created Items Are Not Selected In Parent Folder
https://bugs.kde.org/show_bug.cgi?id=377411 --- Comment #5 from Tsu Jan --- The problem of url's with double slashed is more fundamental than https://git.reviewboard.kde.org/r/130001/. For example, Folder View creates such url's easily. I think something basic in KDE's url handling is a little buggy. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #2 from Tsu Jan --- Added a patch here: https://git.reviewboard.kde.org/r/130002/diff/1/ -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377411] Created Items Are Not Selected In Parent Folder
https://bugs.kde.org/show_bug.cgi?id=377411 --- Comment #4 from Tsu Jan --- Added the patch at https://git.reviewboard.kde.org/r/130001/ -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377411] Created Items Are Not Selected In Parent Folder
https://bugs.kde.org/show_bug.cgi?id=377411 --- Comment #3 from Tsu Jan --- BTW, this is a just workaround; why that double slash, in the first place? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377411] Created Items Are Not Selected In Parent Folder
https://bugs.kde.org/show_bug.cgi?id=377411 --- Comment #2 from Tsu Jan --- There's no registration button at https://phabricator.kde.org/differential/diff/create/ (for now?) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377411] New: Created Items Are Not Selected In Parent Folder
https://bugs.kde.org/show_bug.cgi?id=377411
Bug ID: 377411
Summary: Created Items Are Not Selected In Parent Folder
Product: dolphin
Version: 16.12.0
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: dolphin-bugs-n...@kde.org
Reporter: tsujan2...@gmail.com
Target Milestone: ---
This is about dolphin-16.12.2-1 in Arch.
Created items are selected correctly at first. However, after going up from a
folder to its parent, created items aren't selected in the parent folder
anymore.
I played with the code and found the cause. After going up, for some reason
unknown to me, the url argument of "DolphinView::observeCreatedItem(const QUrl&
url)" gets a double slash before its last part, like this:
QUrl("file:///home/pedram/Documents//Text File")
The issue can be fixed (worked around) by using "QUrl::adjusted()", like this:
void DolphinView::observeCreatedItem(const QUrl& url)
{
if (m_active) {
QUrl realUrl = url.adjusted(QUrl::NormalizePathSegments);
clearSelection();
markUrlAsCurrent(realUrl);
markUrlsAsSelected({realUrl});
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 377392] Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 --- Comment #1 from Tsu Jan --- Never mind! I found an easy way to add the feature in question; will attach a patch after some tests. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 377392] New: Select Folder on Going up (Feature Request)
https://bugs.kde.org/show_bug.cgi?id=377392 Bug ID: 377392 Summary: Select Folder on Going up (Feature Request) Product: dolphin Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: view-engine: icons mode Assignee: dolphin-bugs-n...@kde.org Reporter: tsujan2...@gmail.com Target Milestone: --- It would be nice if Dolphin selected and scrolled to the folder from inside which the user has come up. Currently, when a folder is among many other ones inside a parent folder and the user goes up from inside it, Dolphin shows the start of the parent folder, so that the user can't know from where he/she has come there. Imagine an occasion, when the user wants to get out a older temporarily and go into another folder not far from it quickly. At the present time, that isn't possible visually -- the user should know the name of the second folder and type it in the filterbar. This feature exists in most GTK file managers and also in pcmanfm-qt. I took a look at Dolphin's code and couldn't find the needed tools to implement this behavior but I'm not familiar with the code yet. Can this be implemented in Dolphin or should some other part of KDE be patched? -- 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 #50 from Tsu Jan --- Recently I started to prepare Kvantum for wayland and found something that might be relevant to Qtcurve too: Although setting WA_TranslucentBackground works fine on X11 (with some precautions), it causes a lot of artifacts on wayland. Instead, on wayland, the alpha channel should be forced on the native handle (with or without private headers). I don't know the reason yet but, at least for now, wayland isn't happy with WA_TranslucentBackground. The problem discussed here still exists with KFileDialog menus - and only with them -- on wayland but, fortunately, there's no freeze anymore; the items of those menus can't be selected when menu translucency is enabled by forcing alpha channel. My tests are done under plasma-wayland-session-5.9.2 and also Weston (both on X11 and with its wayland session) on Linux. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 373319] Plastik decoration hides buttons when a window is shaded
https://bugs.kde.org/show_bug.cgi?id=373319 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #4 from Tsu Jan --- The same thing happens to Aurorae. -- 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 #44 from Tsu Jan --- OK. I just wanted to share all facts that I found because, as I said earlier, I owe them to this report. I can't say what should be done in QtCurve (not my responsibility). So, I have nothing to add anymore. -- 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 #42 from Tsu Jan --- > You said somewhere earlier on this ticket that menus don't need what > addAlphaChannel does to be translucent I said that on x11 and for MOST menus, not all. > Windows should still be treated the same way. If you mean translucent windows, the old way is buggy, as I tried to explain before. > translucent menus behave as I would expect (= become unreadable quickly). I didn't get this part. What becaomes unreadable if they they behave as expected? -- 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 #40 from Tsu Jan --- @RJVB My two cents: this may be good for menus on Mac but (1) It's too much, IMO; (2) The windows are made translucent in the old way. I assure you that the are (random) problems with that. You may not use window tanslucency but many Linux users choose QtCurve because of it ;) -- 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 #38 from Tsu Jan --- I pushed the necessary changes to Kvantum. All apps seem happy with translucency :) -- of course, except for those that should have opaque windows (like many video players). I'd like to add that THERE ARE some Qt5 windows that are polished BEFORE being created (like in Qt4) and that most Qt5 menus are so too. The difference between Qt4 and Qt5 regarding translucency is mainly that Qt4 windows were ALWAYS polished before creation. Whether this is a bug in Qt5, I'm not sure now. However, it has surely complicated the translucency support in style plugins. -- 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 #37 from Tsu Jan --- > Setting it [WA_TranslucentBackground] in addAlphaChannel() resolves the > corner issue that made the patch useless on Mac. If so, the solution should work there too. Good news for Mac! -- 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 #34 from Tsu Jan --- > Do you think you could try to get Kvantum to work on Mac? I don't have Mac and changing a code blindly isn't a good practice at all. However, any Mac PR that works fine and whose logic is understandable to me will be welcome :) > ... do you also know why it only happens with its 2 context menus? In this special case, my knowledge is based on experiment and reasonable guesses. On the one hand, the code definitely works without problem. On the other hand, setting "WA_TranslucentBackground" should be quite harmless because the creation of native handles is left to Qt, while an early creation of a native handle cannot be so. In fact, the problem discussed here didn't exist in Kvantum but I still saw weird reproducible effects with window translucency since Qt-5.7.0. And now, with the new method, they're all gone :) That being said, I don't know what part of the kio code (or perhaps Qt's code) causes that freeze; I just guess, with a high probability, that the freeze is is a result of an untimely creation of native handles. KIO developers might know better (if the problem isn't deep in Qt). -- 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 #31 from Tsu Jan --- I forgot to say that I successfully tested this solution on two machines (one very old and with nvidia, the other new and with Intel) and also on virtualbox, with Qt-5.7.1 and Qt-5.5.x. All tests are done with Linux+x11. I happily changed my active Kvantum themes to translucent ones on both machines -- no fear of Qt5 window+menu translucency anymore ;) -- 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 #30 from Tsu Jan --- @ Yichao Yu I didn't work with QtCurve's code but, both practically and theoretically, I'm sure that setting "WA_TranslucentBackground" before widget creation is the safest solution. The code structures of QtCurve and Kvantum are very different from each other. By "before creation" I mean only at "Style::styleHint()". Here, it works flawlessly with Kvantum (I'll push the changes after testing for 2 days). I can't think of a reason why it shouldn't work with QtCurve after some changes to the code structure. -- 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 #28 from Tsu Jan --- Much to my surprise, after playing with various codes, I found out that this is really a QtCurve bug! Let me summarize the problem and its new solution: To make Qt windows translucent, we should set the surface format of their native handles BEFORE they're created. For Qt4, that could be done in "Style::polish()". But Qt5 windows are polished AFTER they're created. Therefore, setting of "WA_TranslucentBackground" in "Style::polish()" would have no effect with Qt5. Early creation of native handles (as is done by QtCurve) could have unpredictable side effects -- for menus if not for windows -- because we don't know how it would affect the complex process of widget creation. However, setting of "WA_TranslucentBackground" in an early stage BEFORE the widget creation sets the alpha buffer size to 8 automatically and safely. When I implemented this logic in Kvantum (offline for now), all problems, that I'd considered as translucency bugs of Qt >= 5.7, were gone :) Doing the same thing for QtCurve isn't so easy because it requires changing of the code structure. (Fortunately, in Kvantum, I'd used "QSet" to track translucent widgets.) I don't know whether setting of "Qt::WA_TranslucentBackground" to "true" before widget creation has the same effect on Mac too but if the answer is no, there won't be a safe way to make Qt5 windows/menus translucent/rounded on Mac. @RJVB Thank you for this report, without which I wouldn't have enough motivation to wrestle with this problem! -- 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 #27 from Tsu Jan --- Although satisfied with the "ensurePolished" solution on x11, I reverted to the freeze code (with Kvantum) under KDE to study the problem a little and found that actually there was a way to close the menu without killing any app. I'd assigned the super key to the Plama main menu; so by pressing that key, the main menu was shown and the KFileDialog menu was closed. I used that opportunity to see which QEvents were triggered on opening the freezing menu and to compare them with those of a normal menu. Freezing menus lacked ChildPolished, PolishRequest and MouseButtonRelease events and instead, had an extra ActionChanged event. -- 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 #25 from Tsu Jan --- OK, I just wanted to know if the freeze was caused by a loop, in which case you'd see a difference. Before using ensurePolished(), I didn't see a high CPU usage either. The freeze -- without ensurePolished() -- is still a mystery to me. I'm not good at tolerating mysteries ;) -- 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 #23 from Tsu Jan --- I have a relatively new laptop with Intel and an old desktop computer with nVidia. All menus are OK on both computers. -- 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 #22 from Tsu Jan --- Any extra CPU usage under wayland or Mac? -- 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 #19 from Tsu Jan --- Created attachment 103238 --> https://bugs.kde.org/attachment.cgi?id=103238&action=edit x11 menus All menus are OK on Linux (x11) now. Qt's behavior should be different in Mac. -- 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 #18 from Tsu Jan --- Strange! The whole point of ensurePolished() is to call `QStyle::polish()` before creation of native windows. Here, on x11, it works not only with menus but also with most top level widgets, although it's safe only with menus. And in "qwidget.cpp" → `QWidget::ensurePolished()`, there isn't any Mac-specific line. -- 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 #15 from Tsu Jan --- Glad to know it works for QtCurve too! The developer(s) of QtCurve should be informed about the whole problem and its solution. -- 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 #13 from Tsu Jan --- OK, I may be wrong but I couldn't find any problem in kio. Of course, someone knowledgeable about kio would know better. I tested with Kvantum and found that ensurePolished() (only at Style::styleHint()) is enough for all menus to have translucency and/or rounded corners (will make a commit after some tests). I think QtCurve can do the same, i.e. it can use ensurePolished() instead of addAlphaChannel() for menus -- although, as I mentioned above, most menus wouldn't need it. In other words, addAlphaChannel() should be used only for window translucency. All this trouble is because of https://bugreports.qt.io/browse/QTBUG-34064 P.S. This question isn't answered yet: why does the creation of a window handle for KFileDialog's menu cause a freeze. -- 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 #12 from Tsu Jan --- I haven't found anything in kio yet but I'm pretty sure about this: The freeze happens when a window handle is going to be created for those menus, whether by setting WA_NativeWindow to `true` temporarily or by using `createTLExtra()` and `createTLSysExtra()`, as QtCurve does. I mean, the freeze isn't related to setting the format -- `setFormat()` -- but to the creation of a window handle for menus. -- 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 #11 from Tsu Jan --- > You'll also have to look in kdiroperator.cpp, that's where the context menu > (for right-clicking on items in the file list) is defined. Thanks! I will soon. > I have rounded corners configured for popup menus, and that required some > translucency. That's correct. Anyway, I'll report back as soon as I find something in those files. -- 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 #9 from Tsu Jan --- @RJVB Actually, I was lead to your report by google, while trying to know why KFileDialog is an exception and which source file I should read. Your patch says "kfilewidget.cpp". That will be a good start :) -- 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 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #7 from Tsu Jan --- I'm on Linux (Manjaro and Debian). This problem happens only when QtCurve menus are translucent. Then, a freeze occurs when an options dropdown submenu of KFileDialog is supposed to be shown by selecting a menu-item. For me, the only way out of this situation has been ctrl+atl+f2 and restarting sddm manually. Qt5 window translucency requires setting of RGBA format before windows have native handles. QtCurve does it in `Style::prePolish()` and `addAlphaChannel()`, using private headers. Kvantum does the same thing in `Style::setSurfaceFormat()` but without private headers. Now, in Kvantum, I encountered exactly the same freeze ONLY WITH KFileDialog. As a workaround, I excluded menus from `setSurfaceFormat()` because most menus didn't need it for translucency (there are rare exceptions when both WA_WState_Created and WA_NativeWindow are set for a menu, in which case, they don't have translucency in Kvantum). It isn't strange that this only happens with QtCurve because no other Qt5 style engine (except for Kvantum, that has a workaround) supports translucent menus. I haven't read the code of KFileDialog but as far as I know, QtCurve doesn't do anything invalid. Therefore, I think the problem is in KFileDialog. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 371725] Cursor Changes to Arrow on Text Editors
https://bugs.kde.org/show_bug.cgi?id=371725 --- Comment #4 from Tsu Jan --- I confirm that the issue is fixed by https://phabricator.kde.org/D3151. Thank you very much! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 371725] Cursor Changes to Arrow on Text Editors
https://bugs.kde.org/show_bug.cgi?id=371725 --- Comment #2 from Tsu Jan --- Still more info: There is definitely a `QEvent::Leave` in QPlainTextEdit when the cursor reaches the horizontal middle line -- I tested with a text editor of mine. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 371725] Cursor Changes to Arrow on Text Editors
https://bugs.kde.org/show_bug.cgi?id=371725 --- Comment #1 from Tsu Jan --- More info: As soon as I resize a left/right tiled window (of a text editor) just a little, the problem disappears, even after I re-tile it. But when I close, open and tile it again, the problem appears exactly on the same horizontal line near the center. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 371725] New: Cursor Changes to Arrow on Text Editors
https://bugs.kde.org/show_bug.cgi?id=371725 Bug ID: 371725 Summary: Cursor Changes to Arrow on Text Editors Product: kwin Version: 5.8.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: tsujan2...@gmail.com Target Milestone: --- Created attachment 101812 --> https://bugs.kde.org/attachment.cgi?id=101812&action=edit Arrow Cursor Inside Kate With compositing enabled, when a text editor is tiled by dragging to a screen edge, the cursor changes from `Qt::IBeamCursor` to `Qt::ArrowCursor` when it's near the center horizontally (and maybe in other places too). That not only makes it impossible to select/edit the text but also moves the window if the left mouse button is pressed. The text editor isn't important in this (the attached screenshot is about Kate). I can reproduce this issue both in KDE Plasma and in LXQt+kwin; so I think the problem is in kwin. The problem only occurs when the window is tiled, as far as I've seen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 351116] Titlebar font should be editable from WM settings
https://bugs.kde.org/show_bug.cgi?id=351116 --- Comment #14 from Tsu Jan --- @Martin Gräßlin I understand your reasoning. It was why I said "Technical problems aside,..."; just wanted to show the problem from another perspective. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 351116] Titlebar font should be editable from WM settings
https://bugs.kde.org/show_bug.cgi?id=351116 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #12 from Tsu Jan --- Technical problems aside, since kwin works well outside KDE too, it's logical to expect a separate titlebar font setting for it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365014] All windows hide on repeating desktop click
https://bugs.kde.org/show_bug.cgi?id=365014 --- Comment #40 from Tsu Jan --- I confirm that this bug is fixed in Plasma-5.8.1. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365014] All windows hide on repeating desktop click
https://bugs.kde.org/show_bug.cgi?id=365014 --- Comment #38 from Tsu Jan --- > There seem to be additional changes OK! That's what I wanted to know. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365014] All windows hide on repeating desktop click
https://bugs.kde.org/show_bug.cgi?id=365014 --- Comment #36 from Tsu Jan --- > I can confirm it works with master So, other commits are also essential to fixing this bug? Which ones? I ask because this bug, together with bug #360219, has made a painful experience out of Plasma for months. > No need to change the status. Martin Gräßlin said in https://bugs.kde.org/show_bug.cgi?id=365014#c33, "We want to have it tested properly before shipping it to the users." I told the result of my test. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 360219] Right Click opens files
https://bugs.kde.org/show_bug.cgi?id=360219 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #31 from Tsu Jan --- For me, both on a desktop computer with nvidia and on a laptop with Intel, the only way of right clicking an item on the desktop without opening it is holding the right mouse button for 1-2 seconds (Manjaro Testing with plasma-workspace-5.7.4). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365014] All windows hide on repeating desktop click
https://bugs.kde.org/show_bug.cgi?id=365014 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #34 from Tsu Jan --- Unfortunately, the commit https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=30b7e3f2423b07b372daffbe09e420ba1ef59ced has no effect here. After compiling plasma-workspace-5.7.4 with it, I still can reproduce the issue easily (on Manjaro Testing). Please change the status! -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 354482] scrolling quickly with the mouse wheel jumps and can even scroll backwards
https://bugs.kde.org/show_bug.cgi?id=354482 --- Comment #9 from Tsu Jan --- I'm almost sure that this bug is about https://bugreports.qt.io/browse/QTBUG-49294 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 344326] Black or corrupted screen on resume from suspend
https://bugs.kde.org/show_bug.cgi?id=344326 --- Comment #113 from Tsu Jan --- Shouldn't the title be changed to "Black or corrupted screen on resume from suspend with nVidia"? I had this issue with nVidia but never with Intel. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 361192] File managers use wrong breeze icons size.
https://bugs.kde.org/show_bug.cgi?id=361192 --- Comment #4 from Tsu Jan --- You could close this report. See https://codereview.qt-project.org/#/c/159800/ -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 361192] File managers use wrong breeze icons size.
https://bugs.kde.org/show_bug.cgi?id=361192 --- Comment #2 from Tsu Jan --- Wrong address! Sorry, the bug is in qiconloader.cpp -> directoryMatchesSize(). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 361192] File managers use wrong breeze icons size.
https://bugs.kde.org/show_bug.cgi?id=361192 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #1 from Tsu Jan --- This is a Qt bug (in qiconloader.cpp -> directorySizeDistance()). -- You are receiving this mail because: You are watching all bug changes.
[korgac] [Bug 250729] korganizer fires remainder event every minute
https://bugs.kde.org/show_bug.cgi?id=250729 --- Comment #16 from Tsu Jan --- @Wulf I think this bug has never been fixed because it occurs once a year, being related to daylight saving time. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 354482] scrolling quickly with the mouse wheel jumps and can even scroll backwards
https://bugs.kde.org/show_bug.cgi?id=354482 --- Comment #5 from Tsu Jan --- I forgot to confirm what Denis said: this is a Qt5 bug and not specific to Kate or KDE. However, it is specific to Linux. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 354482] scrolling quickly with the mouse wheel jumps and can even scroll backwards
https://bugs.kde.org/show_bug.cgi?id=354482 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #4 from Tsu Jan --- I encountered this erratic and annoying behavior since Qt-5.3. In https://bugreports.qt.io/browse/QTBUG-38274, they say it's fixed but it isn't. As far as I know, the problem is in the first QWheelEvent after the enter event. I think a clean Qt bug report is needed. Otherwise, it might not be fixed soon. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 350651] Konsole has scrolling artifacts if HiDPI screen with scaling in Qt
https://bugs.kde.org/show_bug.cgi?id=350651 --- Comment #5 from Tsu Jan --- A part of the issue: https://bugreports.qt.io/browse/QTBUG-48116 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 350651] Konsole has scrolling artifacts if HiDPI screen with scaling in Qt
https://bugs.kde.org/show_bug.cgi?id=350651 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #4 from Tsu Jan --- Is there any report at Qt Bug Tracker? QT_DEVICE_PIXEL_RATIO > 1.0 interferes with transparency in general (artifacts on mouse-over). -- You are receiving this mail because: You are watching all bug changes.
