works on master and I'm quite sure about it as I'm using it myself

Is it possible to be the nvidia drivers? or
that I am using 4.10.1 packages from opensuse and not master?

> Is it possible to be the nvidia drivers?
very unlikely
> or
> that I am using 4.10.1 packages from opensuse and not master?
it's of course possible that we broke slideback in 4.10 branch, but slideback 
hasn't changed in the branch since March last year so it has to be identical 
to 4.9

> it's of course possible that we broke slideback in 4.10 branch, but
> slideback 
> hasn't changed in the branch since March last year so it has to be identical 
> to 4.9
Maybe some of the needed signals:
    connect(effects, SIGNAL(windowAdded(KWin::EffectWindow*)), SLOT(slotWindowAdded(KWin::EffectWindow*)));
    connect(effects, SIGNAL(windowDeleted(KWin::EffectWindow*)), SLOT(slotWindowDeleted(KWin::EffectWindow*)));
    connect(effects, SIGNAL(windowUnminimized(KWin::EffectWindow*)), SLOT(slotWindowUnminimized(KWin::EffectWindow*)));
    connect(effects, SIGNAL(tabBoxAdded(int)), SLOT(slotTabBoxAdded()));
    connect(effects, SIGNAL(stackingOrderChanged()), SLOT(slotStackingOrderChanged()));
    connect(effects, SIGNAL(tabBoxClosed()), SLOT(slotTabBoxClosed()));

didnt trigger and that was fixed in master?

I will wait for 4.10.2 then to be sure that the behavior remains...

make "xprop" on a notification and attach it.

I dont know if you mean a notification window from the panel if that's the case:
------------------------------------------------
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
WM_CLIENT_LEADER(WINDOW): window id # 0x2800004
_NET_WM_PID(CARDINAL) = 7261
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NAME(STRING) = "plasma-desktop"
WM_LOCALE_NAME(STRING) = "el_GR.UTF-8"
WM_CLASS(STRING) = "Plasma", "Plasma"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                bitmap id # to use for icon: 0x280020f
                window id # of group leader: 0x2800004
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified size: 56 by 1016
                program specified size: 56 by 1016
                window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "TouchSuse"
WM_COMMAND(STRING) = { "plasma-desktop" }
michail@TouchSuse:~> xprop
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_KDE_NET_WM_ACTIVITIES(STRING) = "ALL"
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 41945462
_NET_WM_USER_TIME(CARDINAL) = 16083349
_NET_WM_STATE(ATOM) = _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP
_KDE_SHADOW_OVERRIDE(_KDE_SHADOW_OVERRIDE) = 0x1
_KDE_SLIDE(_KDE_SLIDE) = 0xffffffff, 0x0
_NET_STARTUP_ID(UTF8_STRING) = "0"
_KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 7, 5, 426, 1, 6, 6, 428, 1, 5, 7, 430, 123
_KDE_NET_WM_SHADOW(CARDINAL) = 0, 0, 0, 41945105, 41945111, 41945101, 0, 0, 0, 0, 1, 0
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
WM_CLIENT_LEADER(WINDOW): window id # 0x2800004
_NET_WM_PID(CARDINAL) = 7261
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x4, 0x0, 0x0, 0x0
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NAME(STRING) = "plasma-desktop"
WM_LOCALE_NAME(STRING) = "el_GR.UTF-8"
WM_CLASS(STRING) = "plasma-desktop", "Plasma-desktop"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0x2800004
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 64, 810
                program specified location: 64, 810
                user specified size: 440 by 130
                program specified size: 440 by 130
                program specified minimum size: 440 by 130
                program specified maximum size: 440 by 130
                window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "TouchSuse"
WM_COMMAND(STRING) = { "plasma-desktop" }
-------------------------------------------------------------------------------

ummm... sorry about this one - thought you were referring the "sliding popups" effect

slideback is fundamentally different in git master, whether it works in 4.10 i can't say atm, but eg. using libkwineffects from master along kwin from 4.10 would certainly not

does it never work for you or only sometimes not?
tried deactivating your script?

It never worked for me in KDE 4.10.x, in KDE 4.9.x I had no issue at all.

I tried deactivating, activating return to defaults and enable it afterwards but no success...

> connect(effects, SIGNAL(stackingOrderChanged()), SLOT(slotStackingOrderChanged()));

Where did you get this line?
It's not supposed to exist in 4.10 at all.

Sorry my mistake, I was in master branch in branch 4.10 it doesnt exist in slideback.cpp:

    connect(effects, SIGNAL(windowAdded(KWin::EffectWindow*)), this, SLOT(slotWindowAdded(KWin::EffectWindow*)));
    connect(effects, SIGNAL(windowActivated(KWin::EffectWindow*)), this, SLOT(slotWindowActivated(KWin::EffectWindow*)));
    connect(effects, SIGNAL(windowDeleted(KWin::EffectWindow*)), this, SLOT(slotWindowDeleted(KWin::EffectWindow*)));
    connect(effects, SIGNAL(windowUnminimized(KWin::EffectWindow*)), this, SLOT(slotWindowUnminimized(KWin::EffectWindow*)));
    connect(effects, SIGNAL(tabBoxClosed()), this, SLOT(slotTabBoxClosed()));

This effect is working currently in kwin master branch....

Ops sorry, you reopened it because it is referenced for 4.10.x right?

Sorry for that....

Yupp, nevermind.
I got to switch to 4.10 today or tomorrow anyway and then will check whether and what's wrong there (unless Martin does before ;-)

Well, users have just reported me that "Slide Back" effect and "Dim Inactive" do not work because of my kwin script in 4.10.x . 

What is happening is that when my  kwin script is enabled the windows do not show that gain focus even though you can write in them...

My guess is that because the Dialog in my kwin script is at the top of window stack the previous effects are taking it into account....

So this in not a Plasma Desktop issue, should you close it? On the other hand we could try investigate more what we would like to be the needed behavior...

I have just remembered that this was not an issue in kwin master branch.... 
Well in kwin master the "Slide Back" works just fine with my kwin script but not the "Dim Inactive".

So this issue occurs when there is a kwin script enabled with a Plasma Dialog in it. The "Dim Inactive" darkens the windows that do not have focus, so all the windows are darken (even though you can write in them) except from pop ups from the Plasma Desktop that do not darken at all they work just fine.

master explicitly operates on staorder changes (more because the other way was cumbersome, but that's irrelevant) - so this is fixed for master and cannot fix for 4.10.

however, whatever turns (managed) toplevel windows getting the inputfocus, but not the active state *is* a bug.
-> does this only affect you unmanaged windows or somehow all clients just because your script is running?

Is also "Dim Inactive" going to operate this way in 4.11 ? Because in current master branch is broken with my kwin script.

-> This effects all clients except popups. The behavior is that all clients are darken (Dim Inactive) because my script is running and can not be undarken even when they gain focus. Is there any way to release Active State from my kwin script and gain Active State only when it is shown?

> Is also "Dim Inactive" going to operate this way in 4.11 ?
No, it's about the active state, invoking the stack order doesn't make much sense here ;-)


> This effects all clients except popups.
popup are not managed, they do not turn inactive (or active) ever.

> The behavior is that all clients are darken (Dim Inactive) because my script is running and can not be undarken even when they gain focus.
Ok,
a) "how" do they gain focus (do you pass it from the script)
b) where're the script sources?
c) this happens with every activation method? (eg. also with "focus follows mouse"?)

> Is there any way to release Active State from my kwin script and gain Active State only when it is shown?

There's no point in that. If a managed window gets the inputfocus it should as well become "active". Other behavior is a bug.
The question is why the window does not get active.

> Ok,
> a) "how" do they gain focus (do you pass it from the script)
I just hide the dialog in the kwin script so it disappears
dialog.visible="false"

> b) where' re the script sources?
the script can be found at:
https://github.com/psifidotos/kwin-script-workflow
it is installed normal with "plasmapkg -i ." in the package folder

> c) this happens with every activation method? (eg. also with "focus follows
> mouse"?)
yes same behavior with "focus follows mouse". To give an example
I have two kwrite windows side by side and they can gain focus (by hovering
with the mouse) I can write in them but they do not become active.
To add here that a newly created window becomes active and remains active all
the time even though the focus move to other windows until it is minimized. When
it is minimized it becomes inactive, only new created windows become active until
they are minimized.

In my code I use some times mainView.forceActiveFocus() 
// mainView is the root item not the item in the dialog 
// (I do this in order to handle all keyboard signals from one place)
is there a chance that this creates that issue?

Do you want to make you a video to see the behavior?

> 
> There's no point in that. If a managed window gets the inputfocus it should
> as well become "active". Other behavior is a bug.
> The question is why the window does not get active.
I see...

I disabled all mainView.forceActiveFocus() in order to check if this was creating the issue, but it didnt change anything

(In reply to comment #18)
> 
> > Ok,
> > a) "how" do they gain focus (do you pass it from the script)
> I just hide the dialog in the kwin script so it disappears
> dialog.visible="false"

Humm?
Ok, but that should not impact the currently active window at all since the dialog is unmanaged.
-> does the behavior "normalize" afterwards ie. eg. when alt+tabbing through the windows the active one becomes bright again?

> with the mouse) I can write in them but they do not become active.
What happens if you press "alt+f3" - do you get a menu?
If so and you say "maximize" - does the expected window get maximized?

Well, I tracked it down....

BTW Alt+F3 was not working.... Well it was in my code and more specific. I was using in one of my qml plugins the taskmanager library. by disabling one line:
m_taskManager = TaskManager::TaskManager::self();

everything worked... Both "Slide Back" and "Dim Inactive" . But I have to replace all the code from taskmanager to KWindowSystem. I hope that there will not be any issue or a missing behavior... we'll see... 

Sorry for all this, but the whole process with the kwin script is something new for me and the effort to present the WorkFlow in a kwin script it is a very big milestone for the project...

Well some more technical information....
I replaced taskmanager code with KWindowSystem, well the following happens, everything works but
by just one line of code:
 connect( kwinSystem, SIGNAL(windowChanged(WId, const unsigned long *)), this, SLOT(windowChangedSlot(WId,const ulong*)) );

the behavior returns (my slot is empty for testing purposes),

one more thing, because I didnt know how to close a window from KWindowSystem I added again a code from taskmanager:
    TaskManager::Task *t = TaskManager::TaskManager::self()->findTask(id.toULong());
    t->close();
well what happens is that everything works ok until the first time I will close a window from inside the kwin script, then the behavior returns... :) I think that taskmanager is a not use case for kwin scripts, but why windowChanged signal creates this problem? Maybe my kwin script reserves the signal somehow?

To add that all the code is used in the plasmoid and no problems occur....

Yes, i thought you understood that by your last comment.

---> Using KWindowSystem from within the KWin process is a giant no-go.
It simply doesn't work.
Both eventfilters will completely mess up each other.

Usually it's not required at all because KWin knows far more about the windows than KWindowSystem would ever export, but of course you cannot hook onto internal events and signals from your component (since you don't "link" kwin core)

You'll either have to use the signals provided by the script or (if this would become inevitable) we'd have to check for emitting special signals from the application object or similar (you could eg. already hook onto workspace signals, you only need to find the workspace singleton, but they emit Client* pointers for internal use)

Sorry, i did not understand you were about to waste your time this way :-(

> one line: m_taskManager = TaskManager::TaskManager::self();
we need to document somewhere that libtaskmanager or any Tasks Engine provided 
by Plasma may not be used in KWin Scripts. Need to talk to Marco whether we 
can notice the tasks engine or even be able to explicitly exclude it from 
being loaded. Better an error on load than a broken KWin

(In reply to comment #23)
> ---> Using KWindowSystem from within the KWin process is a giant no-go.
> It simply doesn't work.
> Both eventfilters will completely mess up each other.
> Usually it's not required at all because KWin knows far more about the
> windows than KWindowSystem would ever export, but of course you cannot hook
> onto internal events and signals from your component (since you don't "link"
> kwin core)
> You'll either have to use the signals provided by the script or (if this
> would become inevitable) we'd have to check for emitting special signals
> from the application object or similar (you could eg. already hook onto
> workspace signals, you only need to find the workspace singleton, but they
> emit Client* pointers for internal use)

I see, what I will try for the next release is to make a workaround, I can not drop
all the code for windows handling from the qml plugin yet.... but I will disable
the windowAdded,windowRemoved, windowChanged from the qml plugin
only for the kwin script and I will trigger their code from  signals
catched by the workspace object. The only thing I need from the relevant signals
is the WId... Let's see how this will go....

> Sorry, i did not understand you were about to waste your time this way :-(
Doesnt matter, I accumulate knowledge for plasma which is something good... :)

That was likely too ambiguous either.
You can use the static systems from KWindowSystem - no problem.
Just don't create an instance (implying to be not able to connect its slots)

Just a confirmation,

based on: http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9

there is no windowChanged signal, so I dont think I can get a signal related to Client that has changed Desktops or Activities from workspace object. Is that correct?

If that's the case then I dont think that for 4.10 I can publish the kwin script... : (

> there is no windowChanged signal, so I dont think I can get a signal related
> to Client that has changed Desktops or Activities from workspace object. Is
> that correct?
For desktop there's the desktopChanged signal on Client. For Activity it's 
missing - I noticed that myself in the ClientModel work. I will have to add it 
and if it's not too invasive (I expect that it will be just one emit in one 
method) I can add the signal also to 4.10

> For desktop there's the desktopChanged signal on Client. 
perfect, I can try it, I believe that this is triggered also for onAllDesktops right?

> For Activity it's 
> missing - I noticed that myself in the ClientModel work. I will have to add it 
> and if it's not too invasive (I expect that it will be just one emit in one 
> method) I can add the signal also to 4.10
Martin if this is possible for 4.10 you are saving  the release.

For the ClientModel I have just seen the mails, when I find some time
I will check it out...

> > For desktop there's the desktopChanged signal on Client.
> 
> perfect, I can try it, I believe that this is triggered also for
> onAllDesktops right?
Q_PROPERTY(bool onAllDesktops READ isOnAllDesktops WRITE setOnAllDesktops 
NOTIFY desktopChanged)

so yes :-)

Well, an update from my side:

I implemented it... :) and it works just fine without creating issues to KWin :)
but I have the following small issues:
1) because I can not catch onAllActivities and activitiesChanged yet if a window
changes its activities outside my kwin script interface then the kwin script is not updated.
If the user uses the kwin script for this there are no issues because I was updating instantly my inner models to create some nice animations with the windows.

2)closeWindow? Is there a way to implement this without KWindowSystem?
there is a function for closeWindow in public slots in the Client but it is not exposed in qml..
any ideas? I tried use XWindow way of doing it but if there are changes in the window, the window
closes instantly with prompting, this is why I have to use the kwin way of doing it... :)

> 2)closeWindow? Is there a way to implement this without KWindowSystem?
> there is a function for closeWindow in public slots in the Client but it is
> not exposed in qml..
have a look at the two qml files I uploaded in the review request - it closes 
windows ;-)

> have a look at the two qml files I uploaded in the review request - it
> closes 
> windows ;-)

Martin thanks a lot, it worked :) we will have a release for 4.10 in around 10 days through GHNS :)

I will wait any news from you in case you manage to add the activitieschanged signal in 4.10

Thanks a lot one more time...

You guys rock...

changing to invalid as the bug itself was by including incompatible libs.