leleat/tiling-assistant

An extension which adds a Windows-like snap assist to GNOME. It also expands GNOME's 2 column tiling layout.

Tiling Assistant

Tiling Assistant is a GNOME Shell extension which adds a Windows-like snap assist to the GNOME desktop. It expands GNOME's 2 column tiling layout and adds many more features.

Features

Please visit the wiki for a list of all features. You'll also find videos and explanations for each of them there.

Supported GNOME Versions

The metadata file lists all currently supported GNOME Shell versions. Generally, only the most recent GNOME Shell is supported. That means older releases may not include all features and bug fixes. You can look at the revisions of the wiki articles to find out when a feature was added, changed, or improved. The changelog will show all changes in chronological order.

Here is a table showing the GNOME Shell releases and the latest extension version supporting them.

GNOME Shell	Tiling Assistant
45	44
44	43
43	43
42	36
41	32
40	32
3.38	23
3.36	23

Installation

You can install it via https://extensions.gnome.org/extension/3733/tiling-assistant/. Alternatively, or if you want an up-to-date version, download / clone the repository and run the scripts/build.sh script with the -i flag. Make sure to have gettext installed. If you've manually installed the extension, you need to reload GNOME Shell afterwards (e.g. by logging out). It's also on the AUR but that repository is maintained by a 3rd party.

Translation

Translations are welcome! If you are already familiar with how it works, feel free to directly open a pull request with a YOUR_LANG.po file at translations/. Don't worry, in case you don't know how to create a .po file. Just open an issue and I'll set everything up. You'll only need a text editor and your language skills 🙂.

License

This extension is distributed under the terms of the GNU General Public License, version 2 or later. See the license file for details.

tiling-assistant's Issues

Window position isnt restored correctly when the window wasnt maximized (horizontally & vertically) - workaround available, needs more testing

19fc239 should provide a (hacky) solution. But I noticed a bad restore animation or something similiar. So I changed the code a bit and I no longer noticed it. This needs more testing though...

Before:

After:

MPV's windows resize completely wrong when tiled

Describe the bug
MPV's windows resize with completely wrong dimensions and position when I tile them. MPV should add black borders to the image to adapt the window to the desired sizes, but it does not happen when Tiling Assistant is enabled. Whatever media file I open, it can't resize the window correctly.

Steps To Reproduce
Open a MPV window and tile it.

Screenshots/-captures

video_2021-03-09_18-38-05.mp4

System Info:

• Distro (incl. version): Arch
• GNOME version: 3.38.4
• Extensions version: 12
• XOrg/Wayland: X11

Unmaximizing a fully maximized window via DND will add some barrier at the top as long as you hold the initial grab

Describe the bug

Unmaximizing a fully maximized window via DND will add some barrier at the top as long as you hold the initial grab.

Steps To Reproduce

1. Have a (vert. + horiz.) maximized window
2. Unmaximize it via DND but don't release the grab
3. Try to maximize the window via DND -> barrier at the top

Screenshots/-captures

Gap when placing terminal

Describe the bug
When placing the terminal in a quarter or half there stays a small gap.

Steps To Reproduce
Open gnomw terminal and drag it to corner or side.

Screenshots/-captures

System Info:

• Distro (incl. version): Fedora 34
• GNOME version: 40

• Extensions version:
• XOrg/Wayland:

Journalctl logs

Additional context

Unable to remove keybinding

Describe the bug
After assigning a key bind, there doesn't appear to be a way to put it in the unbound "Disabled" state again.

Steps To Reproduce

• Bind a key to ALT + Left
• Now try to clear it, right clicking, pressing escape or delete - none of which will clear it.

System Info:

• OS: Pop!_OS 20.10
• GNOME version: 3.38.3
• Extensions version: 13
• XOrg/Wayland: XOrg

Reduce maximize activation area when top panel is disabled

Description
Please correct me if I'm wrong.
Window maximize action in Gnome is triggered when the cursor's center touches the top panel or, if it's not there, the top edge of the screen. Tiling Assistant uses a much larger trigger area. The problem is that Tiling Assisting doesn't care if the top panel is actually there or not.
This means that, if I use an extension like Dash to Panel, or Bottom Panel, or I simply disable the top panel, Tiling Assistant won't change it's trigger points, giving back a weird UX. It becomes literally impossible to drag windows on the top of the screen, cause there's this large area I can't use without triggering the maximize action. On classic Gnome, I can drag any window all the way to the top from its headerbar/titlebar without problems.

Steps To Reproduce
Install Dash to Panel extension and drag a window to the top edge of the screen from its headerbar/titlebar.

Screenshots/-captures
Tiling Assistant ON:

Tiling Assistant OFF:

Here, just a couple of pixels higher and I would trigger the maximize action. But, at this point, nothing happens (and nothing should).

System Info:

• Distro (incl. version): Arch Linux
• GNOME version: 3.38.4
• XOrg/Wayland: X11

"Raise Group" setting not working

Describe the bug
The "Raise Group" setting always returns to being ON after closing extension settings. In addition, the setting does not seem to have any effect even if the extension setting window is left open to ensure that it remains OFF.

Steps To Reproduce

1. Open extension settings
2. Switch "Raise Group" off
3. Close extension settings
4. Re-open extension settings
5. Observe, that "Raise Group" is on again

Screenshots/-captures

Forgive the jump in the GIF. I believe it illustrates the problem anyway.

This shows the other problem. When gedit is focused, the terminal gets focus too.

System Info:

• Distro (incl. version): Fedora 33
• GNOME version: 3.38.5
• Extensions version: 14
• XOrg/Wayland: XOrg

Journalctl logs
I can update these logs later, if needed.

Additional context
I have a couple of other extensions, but none of them are related to window management.

Window gaps

Oh, what a lovely extension! ^^

Seriously, amazing work, works flawlessly out of the box on gnome 3.36. Wanted to confirm that for you, I'm on 'buntu 20.04.

What do you think about supporting gaps between windows in your extension? It's something I would really love for my gnome experience. Something like pop-os shell gaps or i3-gaps. Because I use dark theme everywhere, windows can blend together, and that looks kinda weird. I also think having that gap is very aesthetically pleasing, and would make your extension unique. It's something that's not easy to get on gnome currently, without extra baggage.

My JS is very weak, but I would be willing to try to implement this if you are interested.

And you should absolutely share this on the Reddit or HackerNews, better tiling for Gnome is a must-have I believe!

Unable to quarter tile windows, if I move the window to a horizontal edge first

Describe the bug
After moving a window from its untiled location to a centre horizontal edge of screen, the window will fail to quarter tile if moved there afterwards. Strangely this doesn't appear to be an issue when trying this on a vertical edge.

Steps To Reproduce

• Open window
• Move to centre horizontal edge of screen
• Try moving it to a corner, without hitting the top area of screen

Screenshots/-captures

System Info:

• Pop!_OS 20.10
• 3.38.3
• xorg 7.7

[QOL] Clean up inconsistencies and settings

Some naming consistencies need to be addressed to better identify which feature-set an associated method/data member belongs to. The settings needs a little bit of cleaning up to address readability and aesthetics.

Default Shortcuts Super+1 to Super+9 for tiling

Describe your idea
Put Windows, uses Super keys + numlock number keys, Tiling Assist should also use those keys for keyboard driven tiling,
Additional context
here's the file: https://github.com/negesti/gnome-shell-extensions-negesti/blob/develop/schemas/org.gnome.shell.extensions.org-lab21-putwindow.gschema.xml

I've set these manually:

Breaks touchscreen tiling, btw. no touchscreen support at all

Describe the bug
When activated, gnome-shell's builtin functionality of dragging a title bar with a finger to left/right edge for tiling stops working.

Steps To Reproduce
Install on a touchscreen device of your choice and try to tile using touchscreen

Screenshots/-captures

• Extension disabled:
  https://user-images.githubusercontent.com/62787185/111128890-b9cfc000-8575-11eb-87e7-7b1822b4eab4.mp4

• Extension enabled:
  https://user-images.githubusercontent.com/62787185/111128896-bb998380-8575-11eb-8435-774354941ccd.mp4
  Touch tiling broken, mouse tiling ok.

System Info:

• Distro (incl. version): Manjaro 20.2.1 (Linux 5.11)
• GNOME version: 3.38.3
• Extensions version: 13
• Wayland

Overlayed icons when tiling to half

Hello,

I noticed a small issue when tiling a window the left/right side. After moving the window to the edge a set of icons appears on the other side. This icons are overlaying. Please see my screenshot.
Maybe a screen resolution problem? I am using a 4K screen, 200% scaled.

Move tiled windows to their own workspace on initial tiling

I found this issue https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/58

It's an interesting read and I like the idea of moving tiled windows to their own workspace. This would also simplify the "grouping" of tiled windows since I won't need to worry about it. This requires me to implement #8 first.

What I plan to do:

• make it optional since it diverges from the Windows-like style I was originaly going for
• only move the windows on the initial tiling. Normal workspace workflow won't be impacted. You can still move windows to the workspace with tiled windows.
• Untiling a window won't move it back to its old workspace. (this is a maybe)

How to swap windows?

In an android tablet, one can swap split-screen apps top to bottom or left to right by just tapping the split bar and picking swap.

Question:
What would be a simple way to do something similar with this extension?

Thanks for the nice work!

Show all open windows on the suggestions dash (instead of just the windows on the current workspace)

Currently only the open windows will be shown in the suggestions dash. It may be uesful to show windows across all workspaces. Some things to consider:

• should this be optional since it may clutter the dash too much?
• what should the design look like? Currently the dash is a list (filled from the left to the right). If there isn't enough screen space the dash will create a new row. Should this also apply, if windows from all workspaces are shown? Or should each workspace also get a new row? It may look weird.
• initially I chose to only show the windows from the current workspace for simplicity. I didn't need to worry about 1 app having multiple windows open too much. But if all windows are shown, it is likelier for this to happen. So for ex. a browser could have 5 open windows. How should the user know which app icon in the dash represents which window (I don't expect the user to remember which windows they put on which workspace)?

I'd like to have some second opinions on this.

Add proper touch support (for Wayland only)

If I am understanding https://gitlab.gnome.org/GNOME/mutter/-/issues/295 correctly, there is no proper way for me support touch on a Xorg session.

As for Wayland, I don't know how touch works and I also don't have a touch device, so I cannot implement and test it. Someone else needs to do this.

Add some kind of window preview

As of now I only show a dash with icons representing the open windows of the current workspace. That means if 1 app has multiple windows open there is no way to distinguish them on the dash (dash is sorted by window stacking order).

For me this is currently no problem since I only show windows from the active workspace. If I implement #8, it may become a problem though.

To solve this I plan to show a preview of the currently focused icon above the dash.

Allow to tile a 4th window even if one window already occupies half the screen

Currently my implementation is mostly meant to imitate Windows 10's tiling design (i. e. 4 quads). That means, If one window is maximized (either horizontally or vertically), at most only 2 other windows can be tiled (quartered) along side it.

This is fine for most people. But for those with a screen resoultion higher than 2560x1440 adding a 4th window when one already occupies half the screen may be desirable. I am thinking of a simple (1-dimensional) spiral design. Here is a mockup (margins are just for illustration purposes):

A problem occurs with this when the maximized windows follows the orientation of the screen (i. e. maximized horizontally on a horizontal screen; e. g. 1920x1080). A Spiral design doesn't make sense here, since the last 2 windows may end up too small when split horizontally. Instead the last 2 windows could be split vertically in the last quarter to maxmize their available work area. For example:

But this means an inconsistent/unpredictable tiling behaviour, which may be even worse than not allowing more than 4 quads in total...

Another downside is that I'd need to change my code quite a bit since the 4 quads are hardcoded into it currently...

So this whole thing is nothing more than an idea for now.

Known Wayland issues

I am testing this extension with Wayland (via Ubuntu 20.10) on an old machine. On X11 I am having no issues. But on Wayland the following problems occur:

• DND position is off, similiar to #6.... not for all apps though. Should be fixed in latest commit

[Edit: removed those I fixed]

'Automated' layouts with pre-defined apps

Describe your idea:

The current layout implementation just allows the user to define a layout. Upon layout activation the dash with the currently-open-windows will open for each rectangle defined in the layout and the user needs to choose which window goes into which spot.

This may feel too slow for some people and doesn't really help with"setting up a workspace" (e. g. on initial boot)... The solution would be to allow the user to attach apps to the rectangles in the layout and automatically open all apps and immediatly tile them when the layout is activated.

Initially, I had a hack-ish/workaround-ish implementation but I removed it since it wasn't good... need help/ideas on how to properly code this...

---

Related bug report from EGO:

'Tile to empty space' not working as expected.

When opening a new window/app and then selecting 'Tile to empty space' (I've put it on Super+x) the window will just maximise or minimise but not place itself into an empty space. I first need to apply a layout template and then click on each window to place into the desired space. I think the possibility of assigning a default layout template on startup would solve that issue.

Wide window grab is anchored outside of the window itself

https://streamable.com/zizr4y

DND of tiled windows is hacky and needs improvement.

Code starts in onGrabBegin(_metaDisplay, metaDisplay, grabbedWindow, grabOp).

If the grab started in the top panel, I restoreWindowSize after the mouse left the panel. I do this by ending the grab in code and recursively calling shouldStartGrab which checks wether the mouse left the panel and if LMB is still being held. If that is the case the window size is restored and the grab is restarted in code.

If the grab started on the window titlebar, I restore the window size after the mouse moved a bit. Before restoring the window size, I needed to end the grab in code and restart it after having restored the window size.

Suggestions for a better implementation would be helpful.

Option to pre-select Layout on startup

After starting up the desktop and opening an app (eg browser) it will occupy part of the screen (usually last size and position). When opening a second app (eg terminal) it will sit on top of the browser. When I then initiate 'Tile to empty space' the terminal will just maximise and occupy the whole screen. Any other additional app will just place itself randomly on the screen on top of each other. I then have to manually select a defined 'Layout x' and click through the apps in the Dash to place them.

I suggest to perhaps have an option to pre-select a Layout by default when starting up the desktop. Opening up applications should then result in being automatically placed in the defined tiles.

My assumption is that a lot of users probably start up their working day with the same application to start with (in my case usually a browser and a terminal.

Corner detection to quarter windows via DND isn't consistent

When moving windows from the edge to the corner slowly the corner detection doesn't work properly. It seems global.get_pointer() doesn't return the right value (or at least not the value I expect).

Need some help. Relevant code is in onWindowMoving(window).

[Multi-monitor] Grace period before snapping to new display

Issue
When dragging a window to the edge of screen, it's practically impossible to avoid going into the next screen.

Solution
Provide a grace period so that it doesn't attempt to snap into the next screen as soon as you enter it. Which is not only frustrating, it's time consuming and interrupt.

All window snapping implementations across all DE's and OS's seem suffer from this design flaw.

I'll be making a pull request for it.

Test

Describe the bug

To Reproduce

Screenshots

System info:

• Distribution (incl. version):
• GNOME version:
• Wayland (y/n):
• Extension version (if from master please provide a commit or a rough date of download):

Additional context

I need Wayland testers

I tested this extension on Fedora 32 (GNOME 3.36) using GNOME Boxes.

Using X11 the extension seem to work just fine. Thus I have updated the README with 75d7e51 to include support for GNOME 3.36 again.

On Wayland I have some inconsistent behaviour. Some times the Dash opens correctly and after some tries it doesn't anymore... using the same open windows and same tiling position.

Journalctl gives me some libinput(?) errors telling me my system is too slow. I don't know if this is related, so I need tester who use Wayland on their actual system.

Some other tiling extension seem to have issues because of Wayland. shelltile/issues/98

Oops, didnt know that linking to other repos also generates a mention over, sorry.

Inconsistent triggering when dragging a window to screen edges

description

Window tiling should not be triggered when the window is close to the top screen edge, but only when the pointer is.
It's not obvious when dragging a window by its decoration (top bar), but it is when dragging with Super key.

It is now triggered when:

• the pointer is close to bottom / left / right screen edge
• the window is close to top edge

environment

GNOME Shell: 3.38.2 (Xorg or Wayland)
OS: Arch Linux
Tiling-Assist: commit 66c29d3

demo

https://streamable.com/7rg4it

When unmaximizing a window via DND the window will snap to the previous left position (even though it seems like the window is positioned correctly at first)

No idea what is causing this. Need help.

restoreWindowSize(window, restoreFullPos = false) is where the restoration of the old window size and position is calculated.

It happens in GNOME 3.36 and 3.38.

Annoying window focus bug when 2+ windows are snapped against each other

Describe the bug
[This issue doesn't happen when the tiling assistant plugin is disabled]

I've been coming across a rather frustrating bug which stops another window from staying ontop of a pair of snapped windows below.

Steps To Reproduce

• Open 3+ windows.
• Snap one window to the left and right halves of screen.
• Now pull up the third window and reposition it somewhere between them.
• Click on one of the two snapped windows and then they'll both come into focus, instead of just the one you've clicked.

Screenshots/-captures

System Info:

• Distro (incl. version): Pop!_OS 20.10
• GNOME version: 3.38.3
• Extensions version: 13
• XOrg/Wayland: Xorg 7.7

Preference to disable the select window popup when snapping a window

When snapping a window to a half (whether left/right or top/bottom), this extension pops up a selector to chose another window to snap in the other half.

It would be very nice to disable this, as most often I don't want to snap a specific window to the other space.

It doesn't do this when snapped to a quarter, which is ideal.

Layouts with apps don't work properly on Wayland

Loosely related to #28.

Layouts with app attachments (i. e. the last 3 layouts) don't work on Wayland.

How I implemented it:
After getting the layouts and the apps, I call openAppTiled for each app one after the other.

Some maximized Window, which was tiled with the appDash, will have their size restored to their maximized rect instead of their non-maxmized rect

Describe the bug
See the title.

Steps To Reproduce

1. Maximize window 1.
2. Tile window 2 to open the appDash. Choose window 1 to tile to the free space.
3. DND window 1 to restore its size.

Screenshots/-captures

System Info:

• Distro (incl. version): -
• GNOME version: -
• XOrg/Wayland: Wayland only

Code to open an app in a tiled state needs improvement. Predefined layouts with apps (which currently don't work on Wayland) depend on this

Currently I basically just tile (with move_resize_frame) a window once it emits its first-frame signal. This means that the window will be opened and then animate to its final tiled position. This is ugly.

I need help to improve this. Any PR or tip is welcome.

Tile to center AND Tile to center 50% or 75%?

I did not start playing around with the Layouts tab, but in the Keybindings tab, I thought it would be cool if I could assign a keyboard shortcut to "tile center" a window to the middle of the screen, OR even perhaps tile center and resize to 75%. I really like how you can tile to bottom right corner, or top left corner but why not be able to replicate that tile in middle of monitor?

:)

p.s. - it could be cool.

UPDATE: It looks like in Layouts tab, you can copy paste 0.25--0.25--0.5--0.5 into an area, save and you'll get the center 50% tile effect... 🤔 😂

Window selector popup appears on wrong screen

When snapping a window to a half (whether left/right or top/bottom), this extension pops up a selector to chose another window to snap in the other half.

The grouped program selector appears in the correct location, but the individual window expansion always appears on the left monitor.

List of incompatible apps / known issues / limitations

General

• Maximizing by double-clicking the titlebar (or using a maximize button) can't be handled by this extension, because that happens in mutter and not GNOME Shell. So everything related to it, like for instance gaps on maximized windows, doesn't work. First reported in #86
• Windows, which change the size by themselves: Nothing I can do about it as an extension. I can't 'force' re/size limitations/constraints. For example, GNOME Terminal when the tab bar gets hidden/shown (reported here: #65)
• Windows with "custom resizing": Similiar thing applies here. Same example: GNOME Terminal. It can only resize in full rows/columns. So there will be a small gap around those windows when they are tiled.
• always-on-top windows will be put below a tiled window the first time. You need to focus a different window to pull the always-on-top window to the top again.
• Moving tiled windows across monitors doesn't work, if the size of the tiled window is way too big for the new monitor. A workaround is to untile the window before moving it to a new monitor.
• No 'tiling styles' (#198): pretty much the same reason as the other issues. T-A can only do 'fake tiling', i. e. move/resize floating windows. In the end the windows are still just floating windows and will look like it.

Apps

• mpv: See #40 for the original report. Add no-keepaspect-window to your mpv.conf. That isn't necessary on Wayland.

Tiling animations aren't displaying while another un/tiling animation is playing

Tile a window to the left of screen and then to the right, eventually the animations will be gone and it'll instantly maximize.

Focusing of the appIcon after opening the Dash needs improvement

Currently I just make the first AppIcon grab_key_focus() after opening the Dash. Sometimes the just-tiled window grabs the focus away; especially problematic if opening a window in a tiled state.

As a workaround I just call grab_key_focus() again after the opening anim is done playing. While it seems to work, it doesn't look good...

Suggestions for a better implementation would be helpful.

Need animations when tiling from a Meta.Window.get_maximized() state or when un-tiling via keyboard shortcuts.

tileWindow(window, newRect) handles the first case, restoreWindowSize(window, restoreFullPos = false) the other. restoreWindowSize will be called with restoreFullPos = true when untiling via keyboawrd shortcuts.

[Multi-monitor] Add option to disable full screen snapping on portrait setups

Describe your idea
Hi, I've just set up my dual screen setup.

One feature which appears strange in portrait mode is that it's difficult to vertically tile due to the full screen gesture.

What works for landscape should work for the longest edge in portrait mode. As some people might want the full screen gesture, I think such a feature would be best in the settings panel.

Additional context
As it doesn't make sense to disable this on landscape (default), perhaps limiting the setting to only screens with landscape activated or select screens to activate it on.

Saving layouts

Another killer feature I can think of, and it would be a real life-changer, saving/remembering layouts.

Instead of configuring every display you have, tiling everything perfectly on all monitors, every time you turn on your PC, it would be amazing to just load certain configurations. Because for the most things, you always need the exact same setup. For example code editor + 2 terminals + 1 browser (same sizes and location always), etc.

It's nice if you can load a certain configuration, close it after you finish your work, and open another one, without the hassle of snapping everything in place.

This is also incredibly useful if you often reset the gnome shell (glitches with custom setup, dev work), and all your snapped windows are lost. Or if you reset your PC often, or when gnome gets confused after resuming from suspension..

Especially in multi monitor setups, when some monitors always have the same fixed layout, this would be a huge time saver.

I haven't checked the code yet, and I'm not sure how feasible this feature would be at the moment. It would probably be a huge amount of work. What do you think?

Edit:
For example, terminator has this feature for terminal layouts, splits and different configurations. It's amazing ^^

Chrome's scrollbar isn't aligned when tiling right

Describe the bug
When tiling Chrome against the right edge of screen, the scrollbar isn't aligned to be accessible at the screens edge. Like GTK apps typically are. Requiring you to move your mouse a few pixels to the left, to use the scroll bar.

Steps To Reproduce

• Open Chrome
• Tile to the right
• Hold down the mouse at the right edge of screen, you'll be instead resizing the window.

Screenshots/-captures

System Info:

• Pop!_OS 20.10
• 3.38.3
• xorg 7.7

Additional context
I'm certain this issue is due to Chrome using a custom scrollbar, but I'm also concerned this may happen for many other apps.

Some apps don't work properly (some Terminals?)

So far only gnome-terminal doesn't seem to work... no idea why.

Smaller middle gap.

I was wondering if it would be possible to decrease the innermost x-gap by half for each window so the middle gap matches the others.

As you can see the middle gap kinda sticks out right now.

Updated version on GNOME extensions

Hello, I think this extension is the perfect middle ground option between a full tiling windows manager and plain GNOME (not to mention the only one that seems to consistently work in Wayland). Thanks for this amazing work!

Unfortunately I would not have noticed how good this extension is if I had not been committed enough as the version on the GNOME extensions portal is seriously crippled. I don't know if it is only a matter of some days delay (it does not seem the case), but please consider updating the version on GNOME extensions the benefits are many:

• More users will enjoy the full version and realize how good it is: the half baked version on GNOME extensions is not much better that the other alternatives (which is to say that it is not very good).
• The description on GNOME extension does not match the feature set of the extension that actually gets installed, which is a bit sketchy
• As a user I would like automatic updates... Of course I could write a script that git clones on right folder whenever there is a new version, but I would say that the update process of extension on extensions.gnome.org is smoother!

Toggle whether to display 'fill remaining space' app list

Hopefully you're open to small ideas. This is to avoid an extra stage which is somewhat distracting while working.

Describe your idea
Add a setting's toggle (like Windows 10), which allows you to hide displaying other open apps following a tile snap.

Layouts with predefined apps

Moved feature request from #19 to this issue as that issue got sidetracked.

---

Describe your idea

Layouts should allow the attachment of apps to the rectangles (each rectangle would need an app). When activating a layout, a (new) window of each app will be opened in a tiled state in their respective spot (i. e. no interactivity and instantaneous tiling).

This allows an easy setup/restoration of "workspace".

Conky causes preview not to disappear after first DnD

description

If a conky window is running, first time I tile with DnD the preview does not disappear after drop. Following DnD do not show this behaviour.

environment

• GNOME Shell: 3.38.2 (Wayland)
• OS: Arch Linux
• Tiling-Assist: commit bb675a8

steps

• enable Tiling-Assist
• start conky
• drag-and-drop a window on screen edge

demo

https://streamable.com/jgu5xi