On kubuntu 16.04 quicktile only cycles through first step of layout

[jmrohwer]

Just installed kubuntu 16.04 beta 2 on a new laptop and tried out quicktile which I use daily. Problem is that upon pressing (say) Ctrl-Alt-KP6 the window gets moved to fill the right half of the screen but repeated pressing of this combination has no effect (the window does not get resized in terms of the cycle but remains at 50% of screen size). When pressing any other combination (e.g. Ctrl-Alt-KP4) the window jumps to fill the left 50% as expected, but again repeated pressing of the combination does not cycle through the remaining steps. Horizontal and vertical maximization work as expected (toggle between maximized and not maximized upon repeated key presses of the combination).

On my old laptop with kubuntu 14.04 everything works as expected. python-xlib is the same version on both. On 16.04 is python 2.7.11, while on 14.04 it is python 2.7.6.

Stdout/stderr gives no output, I attach the debug logs from both. The logs clearly show that the window is not repositioned on 16.04 upon repeated key press (the mappings are different as the new laptop has no numeric KP, but as the logs show the correct command ('right' or 'left') is activated in both cases. Other difference (not sure if it's important); the new laptop is quad HD (3200x800) while the old one is 1600x900.

quicktile1404.txt

quicktile1604.txt

[ssokolow]

Unfortunately, I'm currently finishing up my degree project and won't have time to look into this until May 1st.

However, judging by the 16.04 log, I can say that it's probably a new expression of a design flaw I've been meaning to fix for years but keep getting distracted from. (issue #20, if you're curious)

[jmrohwer]

OK I think it has to do with the resolution of the display and the calculation of the euclid_distance. If I change the threshold in line 1058 to 200, it now works on my quad HD display. Not sure if it breaks lower resolution displays. I suppose this threshold should be set depending on the resolution of the work area, or as you mention refactor it completely. At least it works for me for now, so I'm happy :-)

[kbsali]

same issue here with Ubuntu 16.10 with Unity (on Ubuntu Gnome 16.04 it works ok, I assume it's an issue related to Unity specifically)

[macasieb]

I'm probably doing something very wrong, but this bothered me for a long time.

The following workaround made the app work on a single monitor, and I think the primary monitor on a dual-head setup. The bug will still occur on other monitors.

I also found that the program get really confused if you have a panel between the screens. For example, if I have a panel at the bottom of the top monitor or at the top of the bottom monitor, using the program breaks with or without the workaround.

While debugging, I think I found that the euclid_distance becomes the size of the panel. This means if your panel is smaller than 100px, the bug may not happen.

Also, note that --no-workarea seems to make this bug go away on all screens.

On KDE Plasma 5, this is what I did as a workaround for the primary monitor:

--- a/quicktile.py                                                                                                                                            
+++ b/quicktile.py                                                                                                                                            
@@ -1089,14 +1089,10 @@ def cycle_dimensions(winman, win, state, *dimensions):                                                                                
     dims = []                                                                                                                                                
     for tup in dimensions:                                                                                                                                   
         current_dim = []                                                                                                                                     
-        for pos, val in enumerate(tup):
-            if val is None:
-                current_dim.append(tuple(win_geom)[pos])
-            else:
-                # FIXME: This is a bit of an ugly way to get (w, h, w, h)
-                # from clip_box.
-                current_dim.append(int(val * tuple(clip_box)[2 + pos % 2]))
-
+        current_dim.append( int((tup[0] * clip_box[2]) + clip_box[0] ))
+        current_dim.append( int((tup[1] * clip_box[3]) + clip_box[1] ))
+        current_dim.append( int((tup[2] * clip_box[2]) ))
+        current_dim.append( int((tup[3] * clip_box[3]) ))
         dims.append(current_dim)

     if not dims:
@@ -1124,8 +1120,6 @@ def cycle_dimensions(winman, win, state, *dimensions):

     logging.debug("Target preset is %s relative to monitor %s",
                   result, clip_box)
-    result.x += clip_box.x
-    result.y += clip_box.y

     # If we're overlapping a panel, fall back to a monitor-specific
     # analogue to _NET_WORKAREA to prevent overlapping any panels and```

[ssokolow]

To be honest, my dimensions-calculation code is long overdue for some automated testing and refactoring and I keep ping-ponging between "deadline coming up" and "forgot that I wanted to work on QuickTile".

At the moment, I'm dedicating all my time toward a deadline that's coming up in less than a week, but I'll leave this tab open in my session manager and try to make time to work on this after the 15th.

[ssokolow]

Is this still an issue, either with the last GTK+ 2.x version or the soon-to-be-released GTK 3 version in the gtk3_port branch?

For a while now, it has been using a different approach which should be immune to this bug because it keeps track of its position in the tiling sequence by storing it in an X11 window property.

(Sorry for forgetting to keep up with this issue.)

[ssokolow]

Closing for lack of response after two months.