Created attachment 57889 [details] Image showing the bug Version: unspecified (using KDE 4.6.1) OS: Linux I use 2 screens and I have a task manager configured to show only windows of the current screen on each one of them. It works fine, except for maximized windows that appear in both task managers. Reproducible: Always Steps to Reproduce: Place a task manager on 2 different screens. Configure them to show only the current screen's windows. Open any window and maximize it. Actual Results: The maximized window appears on the 2 task managers. Expected Results: The maximized window should only appear on the current screen's task manager. It might be related to a geometry issue caused by shadow or something.
I can confirm this on Kubuntu 11.04, KDE 4.6.2 and NVidia Driver 270.41.06. I have a dual monitor setup using TwinView and maximized windows will show up on both taskbars. Allthough not obviously so, this seems to be related to overlapping issues. I added a 10px gap between both screens, using nvidia-settings, which seemed to fix this. Adding a gap between screens seems a reasonable quick fix, but I think it is still annoying especially for new users
Is this still valid for KDE 4.8.3 or trunk?
Yes, I still experience this problem on KDE 4.8.4. I can provide any details that you need to identify the problem.
Thank you for the feedback and sorry for my late reply.
This bug mysteriously disappeared for me. I was doing some investigation because the bug was really annoying. First I tried to switch from opensource radeon driver to fglrx driver but it did not help, so I switched back to the opensource driver. Then I tried to change window decorations and all of the sudden the bug disappeared with some of them. I was happy about that so I didn't investigate more. Now that you responded to the bug report I decided to provide more info, at least the list of window decorations that cause the bug, but to my big surprise, it is now working with all window decorations. So for me the problem is solved although I think that there's still something strange. If the problem reappears I will try to investigate more and provide more details. By the way I even tested it with clean .kde4 directory and it is still OK.
Thank you for the fast feedback and sorry again for the late reply. Please feel free to reopen the report if the problem reappears with KDE 4.9.0 or later.
I can confirm that on KDE 4.8.5 problem remains.
KDE 4.9.3: bug is still there.
Reopening based on recent comment.
I would like to give this another bump. This is pretty annoying. I am running KDE 4.9.4, still here. I have two screens, both 1920x1080, with a taskbar on each, but when windows are maximized, they show up on both taskbars. Could this be edge detection? Thanks in advance!
I have five screens in my computer setup, all having the task manager on a bottom panel. I can confirm the bug still appears. With maximized windows opened in multiple screens, this bug is annoying and I can't really figure out how to fix it. I have suffered from it over a year or so. Currently using: KDE 4.8.5 AMD Radeon HD 7970 with the latest fglrx drivers installed. Screens: 2x 1920x1080 3x 1280 x 1024 I suspect the bug is related to egdes of a maximized window which has a minimal overlay on the second monitor (due to decorations). Task manager on the second monitor interprets of having the specific window opened there (which is absolutely not true) and thus the bug appears. According to this explanation the behavior of task manager is logical, of course. However, it's neither expected nor desired by a multi-screen user. The bug really hinders a power user in work. Let's make an example: I have Virtualbox opened on one screen, Libreoffice on the second one and Firefox on the third one. Because of the bug, I actually have - Virtualbox in two task managers (practically the window is represented on 1 screen) - Libreoffice in three task managers (practically the window is represented on 1 screen) - Firefox in two task managers (practically the window is represented on 1 screen) And this is not really desired. I wish someone has a real solution for this bug. Thanks!
As additional information for those who are interested in investigating the bug: Source code of Plasma task manager is available via git clone git://anongit.kde.org/kde-workspace.git and then locate necessary task manager source files: cd ./kde-workspace/plasma/desktop/applets/tasks/ User-related task manager settings are located at /home/<user>/.kde/share/config/plasma-desktop-appletsrc (in the file, plugin is called "plugin=tasks" without quatation marks. Notice that each setting for every applet are separated by bunch of titles known as [Containments]...)
Bump!!! KDE 4.10.1: bug is not gonna leave us! Is anybody on it?
I'm still waiting for fix for this, too. This is [unofficially] CONFIRMED bug and the status should change to correspond with that. Does anyone have even a patch file for this bug? I'm able to compile the code if fix can be provided by someone.
Time flows by. KDE 4.10.3. Bare changes.
I have the same problem in KDE 4.11.1. However, it depends on what window decoration I use. The problem does not exist when using the any of the "standard" decorations that come with (my) KDE installation (B II, Laptop, Oxygen and Plastik). All window decorations I've noticed has this behaviour on are ones I've downloaded. And all of those who behave wierd, have some sort of "glow" or extra large or funky window border on them. So, I'm thinking this isn't a KDE bug but a case of poorly made window decorations? To further confirm this. Try an application that can switch KDE's window decorator on/off, and this becomes quite obvious (Chromium or Chrome for example).
So this bug is linked to window decorations. Is it possible to make the source code somehow "decoration-free" by removing/modifying code parts which are related to window decorations? So it wouldn't matter whichever decoration style you decide to use, all decoration styles would be ignored in the source code level? Could this be done without seriously affecting task manager operations? It would be a great improvement.
As a workaround I change my window decoration for a similar one where the issue do not present itself! But it sure would be better to not be dependent on window decoration implementation.
But thanks to this report I found this workaround! So thanks!
Just a follow up. The fix seems temporary and somewhat not realiable. I rebooted my system today and the issue came back even with the new window decoration. So I had to switch again to fix it again, but this time, somehow, it did not work for all windows like before. At this moment I am trying to workaround it again.
*** Bug 249925 has been marked as a duplicate of this bug. ***
This will likely only happen with activated compositing and is then because of the "internal" shadows some decorations use (the shadow is part of the decoration, not the compositor) This includes oxygen and aurorae, but should not be the case for bespin (in case you want to verify) Solution could be to measure KWindowInfo::geometry() rather than KWindowInfo::frameGeometry() ie. only the client and ignore the decoration altogether.
Right. grep says: taskmanager/taskmanager.cpp:556: const QRect window = wi.frameGeometry(); I am unsure, however, if I can simply replace that with "wi.geometry()", since the code around that line mentions frames.
*** Bug 335416 has been marked as a duplicate of this bug. ***
Somebody, please change Status to CONFIRMED and Product to 'dekorator'.
(In reply to comment #23) > Right. grep says: > > taskmanager/taskmanager.cpp:556: const QRect window = wi.frameGeometry(); > > I am unsure, however, if I can simply replace that with "wi.geometry()", > since the code around that line mentions frames. You have to don't do anything with task manager. Maximized windows must have no borders! If window manager tells that borders exist and calculates geometry for them that go over the screen bounds -- this is the bug of window manager!
The bug is reproducible on: * dekorator theme Crystal 2.2.1; * border width 6 px or more. So, 5 px is still OK for it! In Crystal theme you can choose border width (Configure Decoration).
If you can only reproduce it with Crystal theme, please report it to http://kde-look.org/content/show.php/Crystal?content=75140 deKorator is http://kde-look.org/content/show.php/deKorator?content=87921
As I said before, this is a bug of deKorator. Please, move it to appropriate location since you know the link.
Replace my 'dekorator' with 'kwin'. I'm new to KDE4 therminology.
It's not a KWin bug, but a bug in the decorations, which could be worked around in the taskmanager code.
(In reply to comment #31) > It's not a KWin bug, but a bug in the decorations, which could be worked > around in the taskmanager code. Why it's not KWin bug?
Because Thomas investigated this bug, see comment #21 and comment #22. You can ask on the kwin mailing list if you need more information.
BTW, I can confirm that the approach of comment 23 (that is, replacing frameGeometry() with geometry()) fixes the bug for me (qtcurve decoration), with no side effects that I can notice.
(In reply to comment #33) > Because Thomas investigated this bug, see comment #21 and comment #22. > > You can ask on the kwin mailing list if you need more information. (In reply to comment #34) > BTW, I can confirm that the approach of comment 23 (that is, replacing > frameGeometry() with geometry()) fixes the bug for me (qtcurve decoration), > with no side effects that I can notice. So what? I know that it works. And it's wrong! The right is when frameGeometry() and geometry() return same value for maximized windows. Where KWindowInfo is? KWin? Then, it's KWin! P.S. Your fix with replacing frameGeometry() with geometry() makes another bug.
Ignoring the decoration(In reply to comment #35) > (In reply to comment #33) > P.S. Your fix with replacing frameGeometry() with geometry() makes another > bug. What bug?
(In reply to comment #36) > Ignoring the decoration(In reply to comment #35) > > (In reply to comment #33) > > P.S. Your fix with replacing frameGeometry() with geometry() makes another > > bug. > > What bug? Frame will be ignored.
> The right is when frameGeometry() and geometry() return same value for maximized windows. This is nonsense, but please discuss it on the KWin mailing list.
(In reply to comment #38) > > The right is when frameGeometry() and geometry() return same value for maximized windows. > > This is nonsense, but please discuss it on the KWin mailing list. Except for titlebar of course. Why non-sense, if there is no visual border for maximized windows? You calculate borders that are absent. THIS is non-sense! Discuss it yourself if you want. I don't have time just right now! Maybe, later...
My guess: 5 is hardcoded value. KWin ignores real decoration settings and assumes that frame border is 5. Ask them...
I can confirm this bug for the default Oxygen window decoration, with "Very large" border setting. KDE 4.13.2
I have the same issue with kde 4.14.2. Anyone found a solution?
I too was affected by this bug running a near clean install of Linux Mint 17.1 KDE edition 64bit with dual 1920x1080 monitors. I am pretty much running the stock install at the moment having adjusted only my fonts, window decorations and desktop theme. While running Air Black window decorations, if I went to System Settings -> Workspace Appearance -> Window Decorations -> Configure Decoration and adjusted the border size to Tiny, it solved the issue for me.
I can confirm the bug on plasma-desktop 5.2.2-3. Aaron's approach solved the issue after a reboot.
Yes, setting the border to tiny solves the issue but it's very difficult to resize windows with mouse in a hi-DPI screen, not to mention almost impossible using the touch screen.
I can confirm for 4:5.2.2-0ubuntu3, see also bug 346878.
(In reply to Aaron from comment #43) > While running Air Black window > decorations, if I went to System Settings -> Workspace Appearance -> Window > Decorations -> Configure Decoration and adjusted the border size to Tiny, it > solved the issue for me. In 5.2.2, that is in System Settings > Application Style > Window Decorations > Border Size (at the bottom of the window). Without reboot, nothing changes for me. I can try rebooting later.
(In reply to Jens Müller from comment #47) > I can try rebooting later. OK, this workaround is indeed successful after reboot.
*** Bug 346878 has been marked as a duplicate of this bug. ***
Git commit 5af70417027276e7a75fba0f632475c1470c0996 by Eike Hein. Committed on 02/06/2015 at 16:56. Pushed by hein into branch 'Plasma/5.3'. Drop magic values and use window geometry sans frames for intersection test. Don't construct another KWindowInfo, either. M +2 -2 libtaskmanager/task.cpp M +0 -18 libtaskmanager/taskmanager.cpp M +0 -5 libtaskmanager/taskmanager.h http://commits.kde.org/plasma-workspace/5af70417027276e7a75fba0f632475c1470c0996