Closed kupiqu closed 7 years ago
Weird, I've never been able to break tiling so hard a simple script restart didn't fix the problem. Might indeed be an issue with sleep, I'll investigate this as soon as possible. Thanks a ton for your help with the script, I really appreciate it!
This happened to me 3 times as far as I recall, but didn't happen since I reported the issue here. I wonder if this could come from a dissonance between the number of virtual desktops in settings and the actual number of desktops, maybe?
Resume from sleep doesn't seem to do it, at least systematically.
I can confirm this happening before, but sadly I could not reproduce it consistently. Rarely the script just breaks completely.
In case this helps anyhow, I'm on a dual-screen setup (2×1080p).
It happened again. This time I could identify what triggered this behavior. It started after restoring a maximized window.
I think it could be related to a conflict with kwin's setting: hide titlebar on maximization (that I have enabled via the active window control applet).
Window was restored from maximization, but titlebar didn't come back and tiling and shortcuts stopped working.
Might be Active Window Controls and the script trying to force different border rules, might be something else. @Crendgrim, are you by any chance using Active Window Controls plugin?
I am using AWC, and I do have that setting enabled. It may actually be the cause.
After a failure, if I disable "hide titlebar on maximization" in active window control applet and I replace the kwin process, then tiling and shortcuts come back to normal.
I can't reproduce this with active window controls. Are you both on a multi-screen setup?
I can't reproduce this with active window controls
I don't think this happens all the time in a consistent manner. Perhaps it's a combination of things, which is more difficult to track. In my case this happened with multiple windows spanned across different virtual desktops and then maximizing and then restoring one of them.
Alternatively, try the same as above and before restoring, open a third app, then restore, to see if that triggers the issue.
Are you both on a multi-screen setup?
I am not in a multi-screen setup.
Thanks a ton for helping out, unfortunately I've had no luck reproducing it yet. I'll keep using active window control and maximize windows more than I usually do. Hopefully it'll happen at some point.
Still haven't been able to reproduce the bug but I found a similar bug with active window controls. Apparently active window controls forces the border rules after maximizing & unmaximizing so if borders were set to false via the script and you used the active window control setting an unmaximized window would have borders again.
As of the latest commit, the script forces the border rules after a window is unmaximized. If we're lucky, it might fix this issue but I highly doubt it.
I am experiencing the same, using Active Window Control which hides titlebar on maximization.
Whenever I open an application that doesn't seem to work correctly with the script (sometimes it just opens and floats regurarly, and the script is fine.). I use two monitors, where the secondary is vertical. My latest example of the script crashing was when I opened Software Center in KDE Neon. Usually this application ignores the script and floats (without crashing anything). Other windows like widget-settings also ignore the script without crashing it. However, this time the Software Center app was opened on the secondary monitor, and had it's size changed so it would fit next to my single chrome-window on the vertical display. However, it was not in the correct position, and the chrome-window was still spanning the whole screen. At this point, the script had crashed.
I have never experienced any other keybinds than the "Move Up/Down/.." to work, but these also stopped working once the script had crashed. I do not know if a restart of the script would solve the problem, as I do not know how to do that.
It would be so nice if after restarting kwin (kwin --replace), all open windows would apply the script right away, however, I need first to close them all before tiling starts applying to windows.
@kupiqu, I just tried kwin --replace
and the script did not like it one bit. I'll see if I can make it apply the script right away but I can't promise there is a way.
@vegarab, the reason some applications ignore the script without crashing is a manual exclusion from the script. I've excluded most settings and pop-up windows from tiling for obvious reasons. Until I fix the issue, you can manually exclude Software Center via the script settings. Currently the best way (for me) to restart the script is going to "Kwin Scripts", unchecking "Quarter Tiling", applying the changes and then re-checking "Quarter Tiling" and applying the changes again (like I mentioned in the Reddit comment, posted here too if someone happens to be reading).
Distribution shouldn't matter as we all are running the same version of Active Window Controls, but I'm currently failing to reproduce the bug with Fedora 26, which I find curious. I'll keep trying and install KDE Neon if needed. Wonder which distributions (versions of KWin) are @kupiqu and @Crendgrim running?
Only ~40 hours until I'm back home and can start fixing bugs more actively. Sorry for the slow development this week and thanks for all the help!
As I said, Software Centre usually works fine. It was just this once when it opened on the secondary monitor, and had its dimensions change as if it was not excluded from the script. From what I can tell, that is what crashed the script.
I use KDE neon User Edition as well
I find the fact that Software Centre usually ignores the script and floats curious in the first place (unless you've manually excluded it, which to my understanding, you are not). I don't think it belongs into any ignored category (thus, should at least try to tile). Even stranger is the fact it suddenly wanted to tile on the other screen. I'm curious if you already had four windows on the "main" screen and the Software Centre was forced to the second screen, if you manually opened it on second screen, or if it was forced to the second screen while the first one was not even full. If you don't remember, no problem. I won't be able to fix the bug until I get my hands on KDE Neon and I'm most likely able to reproduce the bug on it.
Unfortunately, there are multiple programs that don't tile well and while some can be fixed, some have to be completely excluded from the script. I'll exclude said programs as fast as I can find them as they tend to break or crash the script if not properly ignored. Thanks for reporting one.
I've tried extremely hard to avoid the easy way out, but Active Window Controls' "Hide Maximized Borders" option interferes with my "Borders" option big time. I have two choices here. I can either remove the Borders option of my script or add a Hide Maximized Borders option of my own. I don't like either choice but I've tried everything and both the script and Active Window Controls force the border rules left and right. Sometimes my script wins the fight and sometimes Active Window Controls succeeds (f.ex. if borders are set to false through my script and you launch Firefox or Atom, Active Window Controls gives it a border, despite never maximizing the window). Honestly, in it's current state, it's a mess and I have to compromise.
Edit: Never mind, pretend I never posted this. I'm so dumb. if you're using the "Hide Maximized Borders", you obviously have "Borders" set to True. I feel like an idiot trying to debug this with and without the borders. Just don't set borders to false and hide maximized borders or the borders will go crazy.
I tried to recreate the situation where Software Centre broke the script.
I filled the main monitor with 4 tiles, and a single tile (chrome) on my secondary monitor. I opened Software Centre and expected it to float on the main monitor. Instead, Chrome on the secondary monitor was moved to cover half the screen (as expected IF Software Centre was working with the script). Software Centre was placed in the top-right tile on the main monitor, covering the window already there (Konsole). When I move Software Centre, I realize it is not floating, and actually working with the script. I move it once, and then the script breaks and all windows are floating.
I restarted the script and tried again, this time with the same four tiles on the main monitor, but no window on the secondary monitor. Software Centre opened floating on the main-monitor, and as soon as I moved it, it snapped over to cover the whole secondary monitor. I could then move it back to the main monitor and it acted as if it was working with the script.
I closed the Software Centre and attempted a second time: Same four tiles on the main monitor, no window on the secondary monitor. This time it overlayed a tile on the main monitor (not initially floating this time). When I moved it initially, it snapped over to cover half of the secondary monitor. I then tried to move it towards the top of the secondary monitor to have it snap to cover the whole thing, without success. I then tried to move one of the four windows on the main monitor over to cover half of the secondary monitor (remember, the secondary monitor is split into two halves, with Software Centre covering 1/2. Acting as if there were two windows there.). It filled the empty space. Now, 1/4 of the main monitor is open, and the window that was supposed to cover 2/4 of the screen is still set to cover 1/4 of the main monitor. Attempting to move any other window there fails, and it just snaps back to where it was. Closing Software Centre then crashed the script.
Attempted the same on a single monitor: Four tiles on screen, then open Software Centre. It opens on the next desktop (expected) and works normally with the script. Shortcuts work. I can move windows between the two desktops and move them around on the desktops. Software Centre is working as it should with the script. Seems like it is a problem with dual monitors?
This confirms my theory. Software Centre is not actually excluded from the script. It just acts up with tiling. Until I get my hands on KDE Neon, you should exclude Software Centre from the script manually. To do so, right click the window border of Software Centre > Special Window Settings > Window Matching (Tab) > Detect Window Properties > Select the Window > Press OK > Copy the Class Name and add it to "Ignored Programs" in the script settings.
Sorry for the inconvenience, I'll start working on it as soon as possible.
I would not say the urgent problem is Software Centre, but rather the multi-monitor support. As I found in my last reply, Software Centre works as should when there is only a single monitor.
I'd also like to add that I really appreciate your work and enthusiasm on this project! I truly love the script. I guess I need to pick up on Javascript to work on KWin-scripts myself!
If you mean the exclusion of a screen (the vertical one in your case), it should not be a problem at all. I've got multiple easy multi-screen features waiting for me once I get home and I should be able to breeze through them quite quickly.
I'd still recommend excluding the Software Centre as it can cause multiple other problems while it's not properly excluded. I'll hardcode the exclusion of it later if I can't fix it.
As for the enthusiasm, I'm easily motivated by people using something I've created. It's some of my first code and people being able to make use of it is very satisfying. I'm also learning a ton and it's unbelievable how far I've come since I started working on it a bit over month ago. Thanks for filing issues and keeping my motivation up!
I have completely removed the border manipulation from the script as it was causing a ton of bugs and interferences, while being redundant (there are better and more reliable ways to disable borders). Report back if you're still experiencing this issue and I'll keep investigating it with KDE Neon.
I reactivated the feature in AWC and the tiling script didn't break since these changes were committed. Should we close this issue?
Probably. I don't think it'll happen again as the script doesn't do anything to the borders anymore.
@kupiqu:
It would be so nice if after restarting kwin (kwin --replace), all open windows would apply the script right away, however, I need first to close them all before tiling starts applying to windows.
Script should be able to notice any pre-existing windows now and start instantly if there are any. In other words, kwin --replace
should apply the script to all existing windows.
That's awesome.
I couldn't test this yet, but looking forward
--
Enviat des del telèfon
On Aug 17, 2017 10:43, "Jasu" notifications@github.com wrote:
@kupiqu https://github.com/kupiqu:
It would be so nice if after restarting kwin (kwin --replace), all open windows would apply the script right away, however, I need first to close them all before tiling starts applying to windows.
Script should be able to notice any pre-existing windows now and start instantly if there are any.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jazqa/kwin-quarter-tiling/issues/18#issuecomment-323007574, or mute the thread https://github.com/notifications/unsubscribe-auth/ADshfFlcDupmf9Y5MF62QgJ0SC_9B7_bks5sY_1IgaJpZM4OuvtJ .
Sometimes tiling stops working and keyboard shortcuts fail to be activated. I don't know what triggers this behavior, so it's going to be difficult to fix, I guess.
When this happens I replace kwin, reconfigure it, etc. Same with plasmashell and latte dock. Nothings seems to work. Only restarting the session does, which is painful.
I'll try to figure out what triggers this, to see if it can be reproduced.
For the time being I attach my settings:
Maybe the wrong behavior of the system comes after resuming from sleep. I'll check it out...