KWin rules

[bmihaila]

I am using the kwin special application rules for some programs. The rules I have are to put an application on all activities when it is first started. When the workflow plasmoid is active it makes the windows with the above mentioned kwin rules also appear on all workspaces, which they should not. Without the plasmoid the windows are back to the previous behaviour. I guess it has something to do with the fact that in the plasmoid it is only to possible to have the "all workspaces" + "all activities" state but not only "all activities". I think these two should definitely be separated and togglable on their own.

[psifidotos]

I know. The Everywhere state was created for user simplicity. The plasmoid when finds a window that is only OnAllActivities state and not OnAllDesktops it triggers that change for convenience.

I would like a lot to open a discussion about that. In a WorkAreas space can you explain me your user case? What is the meaning of having a window in all Workareas in the same row?

I am not arguing I just want to take ideas....

[bmihaila]

Hi again

Then lets start the discussion. I will try to explain my use case, let's see if it is reasonable ;). First of all to get things clear with "WorkAreas space" you mean Activities, don't you?

I will first describe how I use activities and virtual desktops: I use the activities to separate the bigger tasks I am working on and thus group together certain apps, settings and applications. The desktops I use to arrange the application windows, i.e. to further group together and put next to each other the applications that I need to switch between more often. To put this in a more visual way, activities group logically and provide the "background setting" and virtual desktops enable spacial grouping as they provide the layout you imagine your applications should be put next to each other. Of course one desktop alone can hold more applications and then the spacial layout is how you arrange the applications on this desktop, but I mostly use maximized applications so need more than one desktop if I do not want to only use the alt+tab to cycle through them all the time. I use the keyboard shortcuts for desktop up/down/left/right and the ones for activities all the time. I have the desktops arranged in a 3x3 matrix and with the above shortcuts I am much faster and know better where an application is than switching through a stack of e.g. 9 windows with alt+tab. Remember the "cube desktop switcher", well that is also a good spacial metaphor for how you arrange your windows, although I do not use it ;). I would have guessed that this is the way most people use activities+virtual desktops but might be wrong with it.

So now to my use case for "OnAllActivities" but not at the same time "OnAllDesktops": I have some programs (e.g. mail, messenger, notes app, music player) that I want to use on all activities as they are not bound to a special task but are handy during all tasks (activities). Now when I open such an application (e.g. mail) and use it I might realize that I should switch from the "work activity" to the "browsing" activity cause I got a link with a funny video from someone and would want to watch it in the browser. So this motivates the fact that I want the mail application on all my activities to be able to take it with me when switching activities. At the same time I want my mail window to not be on all desktops as it would be on top of all the other open windows whenever I start it. So "fire and leave in the background" is much more difficult for the "on all activities" windows as they start also covering all desktops. As well these windows are now not anymore arrangeable spacially as they are now everywhere and really everywhere. In the use case above with the mail application I would maybe want to watch the video while putting the mail application aside (i.e. on the virtual desktop to the right) and come back to the mail application if I find the video funny enough to answer the mail. In the meantime I might switch back to the "work activity" and still not want to close the mail application but also not want to have it be on all my desktops.

So to repeat the things said in the first paragraph, activities group things together logically as they work all towards solving the same task. Desktops group or separate things in a spacial way to keep everything organized (tidily) inside your activity. You need more room for more application windows -> add a virtual desktop. But you only start a new activity if you know that it means you start doing a new thing that has nothing to do with your current task. Thus activities are longer living than desktops in my view. Activities are like projects and desktops the tools and space you use during the project. Now putting a window of an application on all activities because it is cross-cutting would mean I want it to be available during all my projects. Nevertheless, having it with me does not mean it should lay everywhere and cover everything. I want to be able to arrange it the way I like depending on the space I have. In real life think of the mobile phone as something you want to have with you nearly everywhere you go and whatever you just do. At the same time you want to put it to your pocket or on your desk or .... but it should not always be in front of your face all the time and demand your attention.

Ok, the last one might be a bit far fetched analogy but I hope I could get my point illustrated a bit better.

[psifidotos]

Ok, I understood, you are using Activities and VDs at a next level :)

So you keep some VDs in every Activity to put windows that you want everywhere but only when you need them in order to remove clutter(this use case goes in parallel with extensive use of keyboard).

About the "WorkAreas space", for me a WorkArea is a next-generation VD but in Activities era space, you can read more in last years idea in: http://www.opentoolsandspace.org/en/contributions/116-plasmadrastiriotites BTW, I use Activities and VDs in a very similar way as you can read in the previous link.

So I think that your use case should be supported in the next major release(0.3) but the question is in what way? I am very skeptic about supporting 4 shown states in the windows instead of 3 (even though this is what KDE does). I think that a good approach would be to support the 4th state(onAllActivities but not onAllDesktops) as an enable-by-the-settings approach for the advanced users.

What do you think?

P.S. In Christmas I will find some time in order to give a boost in the project because nowadays is a little difficult to develop. If in the Christmas days the approach in not that radical I could ship it possibly for version 0.2 also...

[bmihaila]

Hi

I read your description of WorkAreas space some time ago but forgot some details, thx for the link again. I agree with your ideas and have a similar view to the Activities "thing".

About the "onAllActivities but not onAllDesktops" solution. In a way I understand that having 4 states for a window is maybe too much and that having a setting for it in the options would solve my problem but am not sure if it is just a hack. Would you have a boolean setting like "Windows on all activities should also be shown on all desktops [y/n]" or would you split it up in two options, or how would it be the less confusing?

Why I said it would be a hack is because it seems to be added as an extra thing that is not fitting to the main UI. From your description and images of the workareas and the two dimensional array you at the moment only support the window everywhere over two dimensions. Kwin and my usage supports kind of that you can choose between window everywhere in the dimension of activities and everywhere in the dimension of VDs. Don't know how these two separate things could be put nicely in your UI and if the settings solution might still be ok for some time.

Some comments to the current UI. I think there need not be an extra row at the bottom for the "everywhere" state or then make it optional (with a setting). It looks nice and it kind of has something and I know some work went into making it but still it was completely surprising to me and confusing about why I would need it. At least show the "everywhere" windows in your minimaps as it is confusing that when changing the state of a window through the "points button" the window suddenly disappears and is only visible at the bottom in the "everywhere" row. Even after understanding what this bottom row means it is tedious to move the mouse away and click the window down there to change its state back again. Especially that one might cycle through the states by clicking the button until the desired one is reached. You are using lots of animations to give a smooth user experience with continuous feedback about what is going on but this "everywhere" setting is quite surprising because when clicking the button the window just disappears. Even worse when the plasmoid isn't sized big enough the bottom row is not even visible, so one does not know what happened to the window. How about showing the everywhere windows in the minimaps and giving them a special look/attribute like a different color (font or background) or a "pin" icon or something along that way to visually show that this windows are the same and they are on all VDs or activities? Or an even more controversial idea would be to have lines (straight or curved/smoothed) connect this same windows in your wall display. Not sure though if that is detrimental to the clean look and clutters the UI. Should maybe do a mockup but have never done one. What tools did you use for your mockups of the UI that you had in the description link above?

Thanks again for all your work and I hope you'll get your time to continue development as it is a really nice plasmoid. I would want to help but after having a fast look at the code and never having coded anything in QML till now I have to admit that I would need quite some time to be able to help with development. Maybe around Christmas, too ;).

[psifidotos]

Hello again, and thank you a lot you a lot for the creative feedback...

Some explanations. The states for a window in the current implementation are three: 1) only in one workarea 2) in all the workareas in the same activity (all workareas in the same column) 3) everywhere (all workareas in all activities)

What I am thinking i not just an option that changes the current behavior but it activates a 4th state for a window without changing the other three). I was thinking keeping the current implementation for the simple user but for the advanced user the situation would be: 1) only in one workarea 2) in all the workareas in the same activity (all workareas in the same column) 3) in all workareas in the same row (of course a new icon will be created for this state like 0-0-0) 4) everywhere (all workareas in all activities)

---

Everywhere state: I think you are right in both. 1) Showing the minimaps for everywhere state( Much transparency here would help to reduce clutter and an option of course for this in the settings if someone does not want at all that clutter)

2) Hiding the bottom panel (That could definitely be an option in the settings, a bit of work here for the animations, when a window changes states but I think I can handle it)

---

The mockups have been created with inkscape, everything is hand made, but I can upload the file for everyone that wants to play around...

thanks a lot again, I am waiting for your feedback...

[bmihaila]

Hi again

I think your idea of having a setting for a 4th state is ok. In general I am not a friend of too many hidden settings if it is possible to integrate things into the normal UI but here it might be one window state too much in the UI, don't know. Maybe other people should tell their opinion. For now I am completely happy with your proposal, especially the last two points about the minimaps and the bottom panel. About how to best style the everywhere windows so that they stand out but are not cluttering the minimaps I am not sure but I think your idea using transparency is nice and if you experiment a bit you will find something that fits the rest of the UI style.

If you could upload the mockup file it would be nice. I will try to then explain my next ideas with a mockup maybe ;). Although at the moment there are not any good ideas in the pipeline ...

Thanks for all the hard work

[psifidotos]

So, you can find the mockups file here: http://www.opentoolsandspace.org/Art/mockups/mockups.svg some screenshot images are missing but all the other elements are there....

As for the development status I has focused in the following: 1)I am currently working to create the Workareas data engine, which is going to clear the code a lot for future maintenance (both the C++ and QML part) - removes logic from the QML part.

2)All the hacks that do not exist in the official libraries eg. activity cloning, finding the activity's background, showing the widgets explorer etc. will be coded as separate classes(like plugins). The code will be cleaned more with this (both the C++ and QML part)

• removes logic from the QML part.

3)Comment almost all the C++ code and the logic that remains in the QML

4)After that I can run for enhancements and bugs

I believe that until Christmas most of the 1,2,3 will be finished, so Christmas is going to be a lot of fun... :)

[bmihaila]

Hi again, thx for implementing the feature, I was just about to delete all my custom windows rules as the everywhere windows got really annoying and always in the way. Now only one more wish. When you move a "on all activities" window from one desktop to another by drag&drop in the plasmoid the window is then suddenly not "on all activities" anymore but only on the one that it was dropped to. This seems not to be consistent with the current plasma/kwin behavior. When you move a "on all activities" window through kwin from one desktop to another then it stays "on all activities" but also moves in the other activities one desktop further. If the other activity does not have that many virtual desktops it just is not shown there. Don't really know if kwin is good here, it just seems to implement a "move as row" behavior but I would say windows should not disappear. So my wish would be at least to have the kwin behavior (maybe the easiest to implement) but better would be to move these "on all activities" windows independently, thus when moved in one activity it does not change the position in any of the other activities. This has the benefit of not making windows disappear. Of course there are some tiny details to think about, like when opening an "on all activities" window on a desktop "row" that does not exist in some activity. Here the window should then be positioned in the first desktop I guess.

What do you think and how difficult it is to implement? Or then point me to the piece of code that takes care about this and I will see if I can do fiddle with it myself.

[psifidotos]

Correct me if I am wrong... What you mean is that when you drag n' drop a window in state (sameWorkareas - that is onAllActivities but spesific desktop(row) ) that window shouldnt loose the onAllActivities state? Right? You believe the same also for allWorkareas state? (AllDesktops but on one activity)

[bmihaila]

Hi

Yes I mean exactly that as plasma/kwin has this behavior and it somehow seems for me right. I will give some examples why. If you grab and drag a window and you put it back to the same desktop+activity (a no operation) then it should not lose any of its properties, but it does that at the moment. When I want a window to be onAllActivities (forming a row) and suddenly want to move it away from the current desktop then it again should not lose its properties. I only want to move it away from the current desktop if I would not want it onAllActivities then I would change the property setting for that. Analogous for onAllDesktops, just checked, plasma/kwin behaves consistent there, too. So the idea would be to always move the whole row (onAllActivities) and whole column (onAllDesktops) at one. But here we start to get into complications, what to do when moving the onAllActivities (a column of the same window) to another activity that has less desktops? Keep the row consistent (like plasma/kwin) and make the window disappear on that activity or break the row and leave the window on one of the desktops there? I would favor the last as it keeps the onAllActivities promise true always but it might seem a bit hacky.

What do you think?

[psifidotos]

About keeping the configuration I am positive, the plasmoid is more consistent that way... But I can not understand "break the row and leave the window on one of the desktops there?" ... Is that the current implementation? or you are describing to create new windows instances?

[bmihaila]

The "break the row" was more a visual metaphor, that I will now try to explain with some ascii art ;) (btw. it is not the current implementation and it is not about creating a new window instance) Ok, so you have 3 activities (a,b,c) where a, b have 3 desktops and c only 2 (a.k.a rows) as shown below:

  a  b  c
1|  |  |  |
2|  |  |  |
3|  |  |

Now lets have the onAllActivities with window x like this:

  a  b  c
1|x |x |x |
2|  |  |  |
3|  |  |

When moving that window (row) down till desktop 3 the window would not appear on activity c as there is no desktop 3 there:

  a  b  c
1|  |  |  |
2|  |  |  |
3|x |x |

This is the current behavior. I was just curious and asking your opinion if it would be better to not make the window vanish on activity c but have something like this instead:

  a  b  c
1|  |  |  |
2|  |  |x |
3|x |x |

This was my "break the row" metaphor. But I am not sure how hacky it is and if it matters so much. On the other side it would just again enforce that "onAllActivities" means that the window is present on all activities. As said already the current plasma/kwin does not do this.

[psifidotos]

Óôéò 29/01/2013 06:35 ìì, ï/ç bmihaila Ýãñáøå:

This is the current behavior. I was just curious and asking your opinion if it would be better to not make the window vanish on activity c but have something like this instead:

a b c 1| | | | 2| | |x| 3|x|x|

This was my "break the row" metaphor. But I am not sure how hacky it is and if it matters so much. On the other side it would just again enforce that "onAllActivities" means that the window is present on all activities. As said already the current plasma/kwin does not do this.

---

Reply to this email directly or view it on GitHub https://github.com/psifidotos/workflow-project/issues/29#issuecomment-12843635.

Ok the above is not possible because KDE doesnot support having the same window in different desktop in different activities...

[bmihaila]

Ok, then I think the "break the row" idea is moot. Although would have maybe been nice to not have the window disappear. Issue is then resolved.

[psifidotos]

there is already an orphaned windows list (this is for windows in desktops that do not have a corresponding workarea), It is not difficult to show them there....

[bmihaila]

Humm, where is this list? In your plasmoid or do you mean KDE? And what do you mean by show them there? Where exactly? ;) If this would add another list or an "orphaned" workspace or the like then I am against it as it adds more noise with no value. Having the window shown in the last desktop available in the activity before it would disappear like in my last example above was only meant to maintain the "onAllActivities" invariant although it does not add much value. That's why I was not sure if this is needed. So all in all it is not worth the hussle I think. That's why if there would be some extra space for orphaned windows I would say better not.

[psifidotos]

this is ready in the tempsync branch....

[bmihaila]

Ok, thx works great.