- please provide the outpu of "qdbus org.kde.kwin /KWin supportInformation"

- Does it happen with any window or some (kind of) in particular?

- Does the window not "activate" (colors, oxygen blue halo) or fail to receive the keyboard focus (only, the window looks like being active but kbd input doesn't end up there)?

- Does it happen with the "laptop" decoration? (don't ask, i'll explain in case ;-)

Created attachment 78457 [details]
support information

(In reply to comment #1)
> - please provide the outpu of "qdbus org.kde.kwin /KWin supportInformation"
> 
> - Does it happen with any window or some (kind of) in particular?
every window
> 
> - Does the window not "activate" (colors, oxygen blue halo) or fail to
> receive the keyboard focus (only, the window looks like being active but kbd
> input doesn't end up there)?
it remains an inactive window, so neither mouse nor keyboard work. the 3rd time you consecutively hit the program icon in the task manager the window will not minimize anymore; you'd have to activate another window first.
> 
> - Does it happen with the "laptop" decoration? (don't ask, i'll explain in
> case ;-)
yes it does

(In reply to comment #1)

> - Does it happen with any window or some (kind of) in particular?
sorry, not every window, only qt based windows; firefox, eclipse or inkscape are working correctly.

What do you mean by "neither mouse" - all your commands for inactive windows are set to pass the click - mouse interaction should work regardless.

-> can you "click through" the window?
"kcmshell4 kwincompositing", 3rd tab. set "keep window thumbnails" to "only for shown windows"
-> what happens in return (does the window hide/unhide)

(In reply to comment #5)
> What do you mean by "neither mouse" - all your commands for inactive windows
> are set to pass the click - mouse interaction should work regardless.
clicking on such an "inactive" window does not give the window focus
> 
> -> can you "click through" the window?
> "kcmshell4 kwincompositing", 3rd tab. set "keep window thumbnails" to "only
> for shown windows"
> -> what happens in return (does the window hide/unhide)

ok, this solves the problem.

(In reply to comment #6)

> > are set to pass the click - mouse interaction should work regardless.
> clicking on such an "inactive" window does not give the window focus
Yes, i understood that - but i assume the window below receives the click?

(In reply to comment #7)
> (In reply to comment #6)
> 
> > > are set to pass the click - mouse interaction should work regardless.
> > clicking on such an "inactive" window does not give the window focus
> Yes, i understood that - but i assume the window below receives the click?

nop, the application is quite functional; actually, I have to correct myself - keyboard also works. The only reason why I realized it, was because I recently activated "Dim Inactive" effect. So 3 things do bother me about the situation, the none-working minimization, the dimmed window state and the none-working dbus menu (actually the menu plasmoid).

ok, sum up, w/ thumbnail keeping set to always:

a) at some point un/minimization of windows does no longer work through the taskbar (the minimize button in the titlebar works, yesno?)

b) a window unminimized through the taskbar keeps the dimmed state

c) there's some appmenu issue (what in particular, the correct menubar not showing up or remaining inoperative)?

(In reply to comment #9)
> ok, sum up, w/ thumbnail keeping set to always:
> 
> a) at some point un/minimization of windows does no longer work through the
> taskbar (the minimize button in the titlebar works, yesno?)
minimizing from titlebar keeps working. the "at some point" can be specified: it happens after a consecutive min-max (2 mouse clicks) from the taskbar. If you focus on some other window between min-max then everything is ok.
> 
> b) a window unminimized through the taskbar keeps the dimmed state
yep, but it must have previously been minimized through the taskbar
> 
> c) there's some appmenu issue (what in particular, the correct menubar not
> showing up or remaining inoperative)?
the menus for the application are not shown at all

Ok, tried with plasma and can confirm this happens.
Then tried with "alternative taskbar" and it's no problem there.

-> moving to plasma/taskbar, maybe libtaskbar issue.

Just curious: Does the effect you describe also happen when you create a window rule for everything contain the word "plasma" and focus - force - no?

Created attachment 80397 [details]
the rule I used (comment #12)

the rule did not change the behaviour

I do not see how this can be related to libtaskmanager. It simply asks for windows to be shown or minimized using KWindowSystem. you can look in kde-workspace/libs/taskmanager/task.cpp for the code (e.g. in setIconified .. ooh, what a throw-back of a name!).

What might be more useful is if the reporter can try with a window manager other than kwin and try to replicate the problem.

(In reply to comment #14)
> I do not see how this can be related to libtaskmanager. It simply asks for
> windows to be shown or minimized using KWindowSystem. you can look in
> kde-workspace/libs/taskmanager/task.cpp for the code (e.g. in setIconified
> .. ooh, what a throw-back of a name!).
> 
> What might be more useful is if the reporter can try with a window manager
> other than kwin and try to replicate the problem.

I did, and the other window manager (openbox) didn't have the problem.

as openbox does neither composite nor allow to not unmap minimized windows...
"surprise"

as mentioned, it wasn't a problem with other taskbars (tried cairo-dock, lx-panel and be.shell, back then)

i'll look into it later this day.

Ok, what happens is that with the plasma taskbar (for some reason, i don't know, but it does also happen w/ unmapping minimized clients) activateNext() on minimizing the window does not take place, thus the client being minimized becomes inactive (since it's minimized...) but keeps the input focus (because it's not unmapped) what we should fix (to support the "false" minimization mode) and what will fix this bug.

I however assume the core issue of not passing the focus to the next client in the focus chain on minimizing windows isn't desired behavior either, right?

Git commit 89c5e5762af820bbbb53c2270b6f7712dfad33fc by Thomas Lübking.
Committed on 15/06/2013 at 20:34.
Pushed by luebking into branch 'master'.

drop inputFocus on internalKeep

unmapping would do the same, but does not take
place to keep the window alive for the compositor
this breaks re-activation which takes place on
inputFocus events which won't occur since the
window got deactivated, but never lost the focus
FIXED-IN: 4.11
REVIEW: 111046

M  +2    -0    kwin/client.cpp

http://commits.kde.org/kde-workspace/89c5e5762af820bbbb53c2270b6f7712dfad33fc

(In reply to comment #18)
> Git commit 89c5e5762af820bbbb53c2270b6f7712dfad33fc by Thomas Lübking.
> Committed on 15/06/2013 at 20:34.
> Pushed by luebking into branch 'master'.
> 
> drop inputFocus on internalKeep
> 
> unmapping would do the same, but does not take
> place to keep the window alive for the compositor
> this breaks re-activation which takes place on
> inputFocus events which won't occur since the
> window got deactivated, but never lost the focus
> FIXED-IN: 4.11
> REVIEW: 111046
> 
> M  +2    -0    kwin/client.cpp
> 
> http://commits.kde.org/kde-workspace/89c5e5762af820bbbb53c2270b6f7712dfad33fc(In reply to comment #18)
> Git commit 89c5e5762af820bbbb53c2270b6f7712dfad33fc by Thomas Lübking.
> Committed on 15/06/2013 at 20:34.
> Pushed by luebking into branch 'master'.
> 
> drop inputFocus on internalKeep
> 
> unmapping would do the same, but does not take
> place to keep the window alive for the compositor
> this breaks re-activation which takes place on
> inputFocus events which won't occur since the
> window got deactivated, but never lost the focus
> FIXED-IN: 4.11
> REVIEW: 111046
> 
> M  +2    -0    kwin/client.cpp
> 
> http://commits.kde.org/kde-workspace/89c5e5762af820bbbb53c2270b6f7712dfad33fc

great, it works for me now.

on another note, could this Bug 315390 be pretty close to what you did here? just asking ...

If that's about the visual animation when changing activities, there's somewhere a dupe and with bug #302060 fixed, one can easily write a scripted effect animation.

Personal blocker: bug #318153 - until fixed i personally don't care about activities at all - except for crashes caused by it or obvious bugs by not ignoring windows that are invisible for being on other activities only.

(In reply to comment #20)
> If that's about the visual animation when changing activities, there's
> somewhere a dupe and with bug #302060 fixed, one can easily write a scripted
> effect animation.
no I don't mean the animation. The problem I have is that when I switch to a window in another activity it will get minimized rather than it just getting focus.
> 
> Personal blocker: bug #318153 - until fixed i personally don't care about
> activities at all - except for crashes caused by it or obvious bugs by not
> ignoring windows that are invisible for being on other activities only.
I don't know if that falls into that regime ...

(In reply to comment #21)

> no I don't mean the animation. The problem I have is that when I switch to a
> window in another activity it will get minimized rather than it just getting
> focus.

Doesn't happen here (kdelibs & plasma from 4.10, kwin git master)
Is it related to the thumbnail keeping as well?

(In reply to comment #22)
> Doesn't happen here (kdelibs & plasma from 4.10, kwin git master)
> Is it related to the thumbnail keeping as well?

Ok, I might see a pattern. I think if gtk applications (firefox, eclipse, ...) are involved in the switching then I get this behaviour; between KDE apps it is working fine. does that make sense?

btw. I have switched off previews and even used different task managers. no change.

(In reply to comment #23)
> Ok, I might see a pattern. I think if gtk applications (firefox, eclipse,
> ...)

Neither FF nor eclipse are actually gtk+ applications.
Still doesn't happen here - nor wouldn't make much sense (since neither KWin nor Plasma look at the window beyond it's X11 id)

Whether a window is to be activated/risen/minimized is determined by the taskbar.

The only thing that could be is a gap between the assumption whether the window is on all activities (the hint changed)
Compare bug #314881 (which is about not showing windows from other activities but may have the same source)

(In reply to comment #24)
> (In reply to comment #23)
> > Ok, I might see a pattern. I think if gtk applications (firefox, eclipse,
> > ...)
> 
alright, that was the wrong assumption. I think it happens when the window is in a different activity context AND on a different virtual desktop.

(In reply to comment #25)

> alright, that was the wrong assumption. I think it happens when the window
> is in a different activity context AND on a different virtual desktop.
Has no impact here either.

FTR: last comments all OT but on bug #315390