| Summary: | Kwin hinders brush cursor in krita making the window move while painting | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Raghavendra kamath <raghu> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | halla, tsujan2000 |
| Priority: | NOR | Flags: | mgraesslin:
ReviewRequest+
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| URL: | https://phabricator.kde.org/D3151 | ||
| Latest Commit: | http://commits.kde.org/kwin/2e3c6c92e94e9902a9c808f6af92aa3afc797fdc | Version Fixed In: | 5.8.3 |
| Sentry Crash Report: | |||
| Attachments: |
demo showing the bug
demo showing the bug with breeze theme xev output xev krita output |
||
|
Description
Raghavendra kamath
2016-10-20 12:32:53 UTC
Created attachment 101659 [details]
demo showing the bug
Which window/widget style are you using? I cannot properly recognize in the video. It looks a lot like the widget style is triggering a window move. This is something that breeze and oxygen do. The explanation for openbox not triggering it would be that this window manager doesn't support the respective hint. If that's the case we need to bounce the bug back to krita as they need to properly mark the widget as interactive. I am using default breeze theme , I have windows can cover option enabled in the pannel and moved its position to the top. I have enabled no border on the window , moved the close maximise and minise buttons to left and kept the buttons to small in the settings apart from this I haven't modified anything that is in default breeze theme. Due to some technical reasons krita uses fusion theme hence it looks different. The default style for Krita is Fusion, and it's in fact really hard to use Breeze or Oxygen because both of those styles are too broken to be used, at least in the versions currently shipped by distributions. So, Krita on startup forces Fusion, which doesn't have that move-by-clicking-on-empty-space-drag feature. I can try to explicitly set the canvas widget to interactive: what is the flag for that? to add to the information. I have enabled move windows by using title bar only option , and kept the trigger key to Meta(windows) + drag . Are you pressing the Alt key anywhen during interacting with the window? Could you please provide the output of: qdbus org.kde.KWin /KWin supportInformation Also could you please switch to the default breeze cursor theme and rerecord the video? The "drag" cursor icon is confusing to me as KWin doesn't use it. I need to see the which cursor icon is used during the drag to evaluate whether that's actually KWin moving the window. (In reply to Boudewijn Rempt from comment #5) > The default style for Krita is Fusion, and it's in fact really hard to use > Breeze or Oxygen because both of those styles are too broken to be used, at > least in the versions currently shipped by distributions @boud: can we please get this fixed? Having a consistent look and feel is very important for us and Krita is a very important application for our ecosystem. Let's try to work together and prioritize any issues in breeze and oxygen and also get all distributions to ship the fixes. We can do that! "Are you pressing the Alt key anywhen during interacting with the window?" No I am just left clicking on the canvas with pentip (wacom) .( Although I can reproduce this with mouse too .) I have re assigned Alt to meta key for moving windows i will share the other information in an hour or so. thank you very much for the response. Created attachment 101663 [details]
demo showing the bug with breeze theme
re recorded demo shaowing the bug with breeze theme in krita
output of qdbus org.kde.KWin /KWin supportInformation as reqested 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.8.2 Qt Version: 5.7.0 Qt compile version: 5.7.0 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: 11804000 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.breeze Theme: Blur: 0 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 5, 3, 4 decorationButtonsRight: 9 borderSize: 0 gridUnit: 10 font: Noto Sans,10,-1,5,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: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 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 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: false glPreferBufferSwap: 0 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: no Number of Screens: 1 Screen 0: --------- Name: DVI-D-0 Geometry: 0,0,1920x1080 Refresh Rate: 60 Compositing =========== Compositing is active Compositing Type: OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 370.28 OpenGL platform interface: GLX OpenGL shading language version string: 4.50 NVIDIA Driver: NVIDIA Driver version: 370.28 GPU class: Unknown OpenGL version: 4.5 GLSL version: 4.50 X server version: 1.18.4 Linux kernel version: 4.8.2 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --------------- zoom slidingpopups kwin4_effect_login slide screenshot minimizeanimation desktopgrid kwin4_effect_fade kwin4_effect_maximize kwin4_effect_morphingpopups presentwindows highlightwindow blur contrast startupfeedback kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: slide: screenshot: minimizeanimation: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true kwin4_effect_fade: kwin4_effect_maximize: kwin4_effect_morphingpopups: presentwindows: layoutMode: 0 showCaptions: true showIcons: true doNotCloseWindows: false ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 150 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: blur: blurRadius: 12 cacheTexture: true contrast: startupfeedback: type: 0 kscreen: Thanks for the updated video, looks like it is KWin which is moving the window. I have absolutely no idea how that can happen. KWin itself only triggers the window moving when you interact with the decoration, but that's not what you are doing. So something must be triggering the window move and normally that would come from the application. Could you please run: xev -root > xev.out Trigger the problem, terminate xev and attach the output. This records all X events, so please don't type to not get any sensitive data in. Created attachment 101667 [details]
xev output
I logged into plasma , then opened krita , xterm , I then ran xev and reproduced the problem and then stopped xev by Ctrl + c . the xev output is attached in above comment. Thanks, I expected to see:
ClientMessage event, serial 21, synthetic YES, window 0x3000005,
message_type 0x132 (_NET_WM_MOVERESIZE), format 32
which is not there. That means KWin does trigger the move. But why? There are three different ways how KWin could trigger the move itself:
1. Right click window decoration -> More Actions -> Move
2. Click window decoration
3. Modifier+click anywhere on the window
Given the videos we can clearly rule out option 1. So somehow we go into possibility 2 or 3. First thing: could it be that your tool triggers the meta key? I have heard that some tablets do that. To rule out please change the setting back to Alt.
For the possibility 2: please use xev again but slightly different. Use xwininfo, click on krita. That will give you a window id. Now pass that to xev with:
xev -id <id from xwininfo>
This will record all motion events. Thus we should hopefully be able to reconstruct where the actual mouse events are, whether they go into the window decoration, but we just don't see it.
I would like to add that i can reproduce this issue with mouse too. so tablet sending meta key press may be doubtful. nevertheless I will reset it back to alt and try this again just to be sure. Created attachment 101669 [details]
xev krita output
I have set the move window key to Alt and reproduced the problem. I ran xwininfo and xev as you suggested. please take a look at the attachement in the above comment I don't see any key press/release or pointer events there. Shot in the blue. Please restart KWin with the following command: KWIN_NO_XI2=1 kwin_x11 --replace & I have now installed krtia on my system and are (of course) not able to reproduce the problem. When using the wacom tablet the cursor never turns into a mouse cursor. In fact I cannot leave the drawing area at all while drawing. Which I think is what is expected. Some investigation results: if one removes the window decoration the problem is not triggered. Krita starts as a normal window and directly maximizes. This might cause a problem with the decoration not having a correct geometry and then accepting events. I triggered the bug! Yay! (On the breeze topic, we've got a plan to see if there are any more issues. See https://bugs.kde.org/show_bug.cgi?id=361811 -- and then we can re-enable it, maybe with a version check.) Possible fix at https://phabricator.kde.org/D3151 *** Bug 371725 has been marked as a duplicate of this bug. *** Git commit 2e3c6c92e94e9902a9c808f6af92aa3afc797fdc by Martin Gräßlin. Committed on 28/10/2016 at 14:06. Pushed by graesslin into branch 'Plasma/5.8'. Trigger resize of input window when deco size changes Summary: Client::updateInputWindow operates with the decoration size. The method gets called from various points when changing the window geometry. If at that moment the decoration has not updated yet, the borders might be at a wrong position. This behavior could be triggered when a window requested to change the state to maximized. During maximization the decoration still had the wrong size when updateInputWindow was called, thus an interactive area inside the window was created. To circumvent this problem updateInputWindow is now also called whenever the window decoration changes. As a note: that a maximized window has resize only borders is wrong. Kwin should be protected against that. FIXED-IN: 5.8.3 Test Plan: Checked xwininfo for the deco extends window Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3151 M +2 -0 client.cpp http://commits.kde.org/kwin/2e3c6c92e94e9902a9c808f6af92aa3afc797fdc |