Closed flying-sheep closed 4 years ago
Yes, you're correct - the way to do this is to turn our tiling[desktop][screen] into a tiling[activity][desktop][screen], with activity being a string. Then we need to fix every case of "currentScreen == tile.screen && currentDesktop == tile.desktop" to also check for activities.
better abstract this all to getCurrentLayout()
or so i think, but i only glanced at the code so far.
_getLayouts
, sure, but that's not used everywhere.
I've been waiting to clean that up, and unify the way desktops are indexed along the way.
should i have a look or will you do this soon? i’m becoming annoyed by this :)
It'd be nice if you tried, I don't have too much time right now.
OK, any hints? what exactly did you mean by
clean that up
and
unify the way desktops are indexed along the way.
besides: is there a quicker way to reload the script than the kwing configuration UI?
We have a method called _getLayouts
in tilingmanager, but it's not used everywhere - there are plenty of places that access the array directly. Also, in some parts of the code, the first desktop has index 0, in others 1.
besides: is there a quicker way to reload the script than the kwing configuration UI?
I used to symlink the script, it may also be possible to do a kwin dbus call.
thanks!
besides, my typo “kwing” really sounds good, don’t you think? maybe for a KDE flight simulator? :stuck_out_tongue:
Heya, I just pushed 1c9e61a4882911be2b600c9c52a962e8453, which touches some of the code you would need to touch for it, and may improve the index situation at least a bit.
Also, kwing might be a flight simulator, but kwind would be a wind tunnel simulator.
thanks! i might just look at it tonight :D
hmm, i’m already stuck not being able to do
qdbus org.kde.plasma-desktop /MainApplication showInteractiveKWinConsole
there is no org.kde.plasma-desktop
in plasma5…
What I do now:
plasmapkg2 -t kwinscript -u . && kwin_x11 --replace
the downside is since workspace.clientList is currently non-functional pre-existing windows won't get tiled.
On the other hand, it works.
(Also, depending on what you change, be prepared to kill kwin from a vt and run DISPLAY=:0 kwin_x11 --replace
)
Had any success? Otherwise, I'd like to clean up the indexing stuff.
sorry, too much work recently :|
any chances of progress on this?
No progress.
Any chance you'll work on this?
@WyohKnott: For me personally, basically none. I've had a look at this a while back and... I just don't get activities, so I don't quite know how this should work. It's also a bunch of work for something I personally don't use.
I'd happily review any PR, though!
Hello! I'd also like to use Tiling, but currently I cant, because Tiling+Activities don't play well together. I'd like to use Tiling just in some activities, like in my Coding activity, where snapping Konsole windows together would be an easy task with Tiling.
Seems that @flying-sheep isn't working on this anymore. @WyohKnott do you know any JavaScript? Or maybe we could find someone, who would like to implement this? I personally am too busy to learn new things, altough I think learning how to write KWin scripts would be a lot of fun.
I know a few JS but not much. I looked into adding it, but I failed. I don't know much about the kwin API.
@WyohKnott the Kwin scripting API can also be used similary in JavaScript. Basically what you would need it workspace.currentActivity
to get the activity and workspace.activities
to get an array of activities. An activity is just a UUID string (e.g. my main activity is b1742df9-0458-4f47-85b2-8ec2222b95fd
). I think thats all you need to do with the KWin API.
Everything else is just about letting tiles know in which activity they are and let them overlap if they're in different activities.
Since I didn't have the time to understand how this script works, I just have an unfinished non-working prototype (https://github.com/jklmnn/kwin-tiling/commit/2ef8da50da7aa7cbdd1793eeeff9fa1623b213c4). But maybe you can take some hints from it about the KWin API.
Thank you very much for your contribution, @jklmnn! I just read your commit, so didn't fully understand, in what way it is non-working. Seems that you added a new dimension for activities to various arrays and made sure they are walked through in loops. Something I imagined would be about enough. Would you mind describing a little bit, what is a problem?
If there is just some additional work needed, I think we should find a way to solve any problems. I will offer my help as well at least for testing an maybe also contributing some code.
EDIT: heck, I just installed this, and at least for me it seems to work: tiled windows only show up in a desired activity. I will test this more and report my findings. Should additional discussion go to your fork or continue here?
Oh, well then it seems I just wasn't able to install it properly (or remove the old version properly), for me it didn't work. But I have never created a kwin script, so I'm completely new to the tooling.
I think the discussion should go on here since I most probably won't have time to maintain my own fork. If you want, I create a pull request to this repo and mention this issue in it.
Wait, i was wrong. It doesn't work or then i had the same problem with installing. For me it treated all activities as the same: activity A Desktop 1 and Activity B Desktop 1 shared the same tiling.
9.8.2017 5.13 ip. "JK" notifications@github.com kirjoitti:
Oh, well then it seems I just wasn't able to install it properly (or remove the old version properly), for me it didn't work. But I have never created a kwin script, so I'm completely new to the tooling.
I think the discussion should go on here since I most probably won't have time to maintain my own fork. If you want, I create a pull request to this repo and mention this issue in it.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/faho/kwin-tiling/issues/37#issuecomment-321267733, or mute the thread https://github.com/notifications/unsubscribe-auth/AAx8-v021vkJsK_DR1cbRC5gVxmqTcSDks5sWb5-gaJpZM4DLpde .
Well now you know what isn't working ;) As I said before, I have no experience creating kwin scripts and this is just kind of a draft. What I did is basically add a activity dimension and read the current and all activities from the workspace. But I didn't understand how and where the tiling decisions were made so I couldn't integrate it.
What I understand from the code, there is this tiling.js that describes a tiling for a single screen/desktop. Screen layout is handled by a separate class layout.js that has several special cases. As far as I understand, Tiling.js keeps track of layout type and list of tiles on that tiling. Layout object does the actual calculation how to move and resize windows (tiles).
Then there is this Tilelist.js that has list of all tiles (windows) in the system. Those tiles are described as Tile objects, and those seem just to contain information about themselves. I think they are connected to the rest of the script mainly through signals. Tile object should carry information, in what activities tile is. I don't know how it would use that information, but any window can be in more than just one activity at the same time.
Tiling class is called every time when tiling is made, and I think that class should also understand activities, ie in what activity a certain tile resides. At tilingmanager in line 469 a new Tiling is created with no sign about any activities. There I think is a problem. On should pass this.activity to Tiling.js. Then Tiling calculates This.Screenretangle with util.getTilingArea, and somehow that part of the code should take activities in the consideration I think.
At tilingmanager.js there is this onTileAdded which I think is called every time when a new window is created on the screen. That method should also be made aware of activities. Maybe even this place is actually the main problem as to why the code isn't working.
there is this tiling.js that describes a tiling for a single screen/desktop. Screen layout is handled by a separate class layout.js that has several special cases. As far as I understand, Tiling.js keeps track of layout type and list of tiles on that tiling. Layout object does the actual calculation how to move and resize windows (tiles).
Yes, with the exception of gaps.
Then there is this Tilelist.js that has list of all tiles (windows) in the system.
Yes. It is also responsible for deciding whether to tile a window or not, including connecting to signals that affect that decision (fullscreenChanged and such).
Those tiles are described as Tile objects, and those seem just to contain information about themselves. I think they are connected to the rest of the script mainly through signals.
Yes. The Tile class also does the actual resizing, and there's some (ugly) signal ping-pong going on, where a tile will resize a window and in response to that send a signal, which might result in that tile being resized (which won't happen because we have a "lock" variable).
Tile object should carry information, in what activities tile is.
Yes.
Tiling class is called every time when tiling is made, and I think that class should also understand activities, ie in what activity a certain tile resides. At tilingmanager in line 469 a new Tiling is created with no sign about any activities. There I think is a problem.
Yes.
At tilingmanager.js there is this onTileAdded which I think is called every time when a new window is created on the screen. That method should also be made aware of activities.
Almost every place in the code that does anything with screen or desktop needs to be changed to take an activity as well.
And activities will need to be used as one dimension in the matrix.
Then Tiling calculates This.Screenretangle with util.getTilingArea, and somehow that part of the code should take activities in the consideration I think.
util.getTilingArea basically just calls clientArea(ClientAreaOption option, int screen, int desktop) with the PlacementArea option, meaning it will get back the area that windows can be placed on. In practice this is the resolution of the screen minus the areas occupied by panels.
As you might notice, that function does not take an activity argument, so if the activity can change anything about the placementarea (by having different panels), then this needs to not be called while on the wrong activity. That seems to be the right thing to do anyway.
@heikkiket
You first note this
Those tiles are described as Tile objects, and those seem just to contain information about themselves.
and then you state the following:
Tile object should carry information, in what activities tile is.
The latter is not consistent with the former. Information what activity given tile object belongs to is not information "about itself" but about outside world. This should be a task of some container class.
The latter is not consistent with the former. Information what activity given tile object belongs to is not information "about itself" but about outside world. This should be a task of some container class.
The way the code currently works, it should definitely be in there. Tile objects also have their desktop and screen, after all.
It's possible that that could be removed, but then it should be removed for all.
It's possible that that could be removed, but then it should be removed for all
Agree. I have a few days off and I'm planning to work on this project. I'm planning to refactor code and write tests first.
Wonderful!
I hope you will succeed with refactoring.
I made some changes to the code last night, mainly to the TilingManager.prototype._getLayouts function but couldn't get it working. I realized, that window can belong to several different activities, so the code must have a loop looping through all the activities. Something like this:
TilingManager.prototype._getLayouts = function(desktop, screen, activities) {
result = null;
for int(i = 0; i < activities.size; i++) {
var result = [];
if (desktop > 0) {
if (screen != null) {
result.push([this.layouts[activities.at(i)][desktop - 1][screen]]);
} else {
result.push(this.layouts[activities.at(i)][desktop - 1]);
}
} else if (desktop == 0) {
print("Invalid desktop 0");
return [];
} else if (desktop == -1) {
if (screen != null) {
for (var j = 0; j < this.desktopCount; j++) {
result.push(this.layouts[activities.at(i)][j][screen]);
}
} else {
result.push(this.layouts[activities.at(i)]);
}
}
}
return result;
};
Is there some good link about how to debug kwin scripts? I couldn't find any way to get errors or debug prints visible, and I didn't succeed even loading the script.
I came here quite by a chance, but @flying-sheep :
hmm, i’m already stuck not being able to do
qdbus org.kde.plasma-desktop /MainApplication showInteractiveKWinConsole
there is no org.kde.plasma-desktop in plasma5…
Plasma5 equivalent is: qdbus org.kde.plasmashell /PlasmaShell showInteractiveKWinConsole
right now, tiling assumes that “workspace ID” and “screen ID” correctly identify an area to tile windows in.
but there is a third dimension: activity ID is orthogonal, so windows that are on the same screen and workspace should only be tiled with each other if they are also on the same activity.