Bug 268259 - Maximized windows appear in each screen's task manager when they should not
Summary: Maximized windows appear in each screen's task manager when they should not
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: master
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
: 249925 335416 346878 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-11 22:25 UTC by Nathan Sala
Modified: 2015-06-23 14:34 UTC (History)
23 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Image showing the bug (817.25 KB, image/png)
2011-03-11 22:25 UTC, Nathan Sala
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Sala 2011-03-11 22:25:57 UTC
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.
Comment 1 Kim Hagedorn 2011-06-27 07:19:10 UTC
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
Comment 2 Myriam Schweingruber 2012-05-23 09:14:41 UTC
Is this still valid for KDE 4.8.3 or trunk?
Comment 3 MacJariel 2012-06-24 20:08:29 UTC
Yes, I still experience this problem on KDE 4.8.4. I can provide any details that you need to identify the problem.
Comment 4 Myriam Schweingruber 2012-07-17 10:22:55 UTC
Thank you for the feedback and sorry for my late reply.
Comment 5 MacJariel 2012-07-17 11:35:46 UTC
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.
Comment 6 Myriam Schweingruber 2012-09-05 07:25:15 UTC
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.
Comment 7 Szef 2012-11-15 06:28:39 UTC
I can confirm that on KDE 4.8.5 problem remains.
Comment 8 Szef 2013-01-11 07:32:18 UTC
KDE 4.9.3: bug is still there.
Comment 9 Christoph Feck 2013-01-22 01:27:39 UTC
Reopening based on recent comment.
Comment 10 cornfeedhobo 2013-01-28 01:02:53 UTC
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!
Comment 11 Pekka Helenius 2013-02-23 11:12:13 UTC
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!
Comment 12 Pekka Helenius 2013-02-23 11:58:40 UTC
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]...)
Comment 13 Szef 2013-04-30 15:46:37 UTC
Bump!!!
KDE 4.10.1: bug is not gonna leave us!
Is anybody on it?
Comment 14 Pekka Helenius 2013-05-01 00:34:45 UTC
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.
Comment 15 Szef 2013-06-13 14:43:45 UTC
Time flows by.
KDE 4.10.3.
Bare changes.
Comment 16 Olle Gustafsson 2013-09-19 19:06:38 UTC
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).
Comment 17 Pekka Helenius 2013-09-23 11:30:28 UTC
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.
Comment 18 Rafael Souza 2013-12-02 18:03:05 UTC
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.
Comment 19 Rafael Souza 2013-12-02 18:05:57 UTC
But thanks to this report I found this workaround! So thanks!
Comment 20 Rafael Souza 2013-12-03 16:20:35 UTC
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.
Comment 21 Thomas Lübking 2014-01-30 21:28:19 UTC
*** Bug 249925 has been marked as a duplicate of this bug. ***
Comment 22 Thomas Lübking 2014-01-30 21:30:57 UTC
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.
Comment 23 Christoph Feck 2014-02-09 19:06:06 UTC
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.
Comment 24 Christoph Feck 2014-05-27 19:33:47 UTC
*** Bug 335416 has been marked as a duplicate of this bug. ***
Comment 25 Aleksey Midenkov 2014-05-28 05:08:18 UTC
Somebody, please change Status to CONFIRMED and Product to 'dekorator'.
Comment 26 Aleksey Midenkov 2014-05-28 05:20:41 UTC
(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!
Comment 27 Aleksey Midenkov 2014-05-28 08:42:35 UTC
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).
Comment 28 Christoph Feck 2014-05-28 11:18:57 UTC
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
Comment 29 Aleksey Midenkov 2014-05-28 11:23:56 UTC
As I said before, this is a bug of deKorator. Please, move it to appropriate location since you know the link.
Comment 30 Aleksey Midenkov 2014-05-28 11:28:20 UTC
Replace my 'dekorator' with 'kwin'. I'm new to KDE4 therminology.
Comment 31 Christoph Feck 2014-05-28 11:41:30 UTC
It's not a KWin bug, but a bug in the decorations, which could be worked around in the taskmanager code.
Comment 32 Aleksey Midenkov 2014-05-28 11:44:16 UTC
(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?
Comment 33 Christoph Feck 2014-05-28 11:47:44 UTC
Because Thomas investigated this bug, see comment #21 and comment #22.

You can ask on the kwin mailing list if you need more information.
Comment 34 Alberto Mattea 2014-05-28 11:52:47 UTC
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.
Comment 35 Aleksey Midenkov 2014-05-28 12:01:38 UTC
(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.
Comment 36 cornfeedhobo 2014-05-28 12:32:17 UTC
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?
Comment 37 Aleksey Midenkov 2014-05-28 12:36:14 UTC
(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.
Comment 38 Christoph Feck 2014-05-28 12:51:34 UTC
> 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.
Comment 39 Aleksey Midenkov 2014-05-28 12:57:38 UTC
(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...
Comment 40 Aleksey Midenkov 2014-05-28 13:02:50 UTC
My guess: 5 is hardcoded value. KWin ignores real decoration settings and assumes that frame border is 5. Ask them...
Comment 41 Alberto Torres Ruiz 2014-08-20 23:41:45 UTC
I can confirm this bug for the default Oxygen window decoration, with "Very large" border setting. KDE 4.13.2
Comment 42 Aleksandar Vasilev 2015-01-23 12:40:16 UTC
I have the same issue with kde 4.14.2. Anyone found a solution?
Comment 43 Aaron 2015-02-05 18:28:48 UTC
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.
Comment 44 Markus 2015-04-08 10:53:41 UTC
I can confirm the bug on plasma-desktop 5.2.2-3. Aaron's approach solved the issue after a reboot.
Comment 45 Alberto Torres Ruiz 2015-04-08 12:10:49 UTC
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.
Comment 46 Jens Müller 2015-05-31 20:06:51 UTC
I can confirm for 4:5.2.2-0ubuntu3, see also bug 346878.
Comment 47 Jens Müller 2015-05-31 20:16:40 UTC
(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.
Comment 48 Jens Müller 2015-05-31 20:22:32 UTC
(In reply to Jens Müller from comment #47)
> I can try rebooting later.

OK, this workaround is indeed successful after reboot.
Comment 49 Eike Hein 2015-05-31 20:32:23 UTC
*** Bug 346878 has been marked as a duplicate of this bug. ***
Comment 50 Eike Hein 2015-06-02 16:56:50 UTC
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