EdgeSnap snaps windows to the screen edges, the way Windows and macOS do. It already exists for AmigaOS 4 and MorphOS, this is the first preview for AROS x86_64: two programs, no installer. Tried on AROS One under emulation only.

https://drive.goo...sp=sharing



Drag a window by its title to an edge or a corner: a blue frame appears, let go and the window lands there.
Two tiled windows share a draggable seam. Preferences in SYS:Prefs/EdgeSnap.

If it does nothing: start it from a Shell without >NIL:, try one drag, press ctrl alt d and send me what it prints, with your AROS version, native or hosted, screen mode and graphics driver.

After the tests AROS will get the edgesnap.library like the other systems. Until then this is for testing only: please do not include it in any distribution.

Michele Dipace, https://github.co...1/edgesnap

EdgeSnap works on AROS One 1.3 (why are you using the old version?), but you have to put it in User-startup; add Run >nil: before EdgeSnap.

The only problem is that when you start it up on Wanderer, a CLI will open, and when you move windows, black artifacts appear in the window.

Hi,

Okay, I will delete my post. I have not been able to update for a long time but hope to get 1.4 soon.

I ran a test on the latest version of AROS in VirtualBox. It looks good. I can confirm that there are black artifacts on the Wanderer windows.

https://www.youtube.com/watch?v=I467pPLyshk

Overall, I really like this feature and I’m a big fan of this project

Looks like a cool project. :-)

Good job, mate!

Do you plan to add proper tiling on top of the engine - automatic layouts, keyboard-driven control, i3/Hyprland style - perhaps as another policy or as a client of edgesnap.library?

I'm asking because I'm looking at exactly that for AROS x86_64, and I'd rather build on your API than duplicate the Intuition plumbing.

Thank you all for trying it so quickly.

@AMIGASYSTEM @retrofaza The black artifacts were the preview frame. On some graphics drivers reading the screen back returns zeros, and the frame rebuilt black where the background should have come back. There is a new build at the same Drive link, please use it instead of the first one: it checks what it reads, and where the reads cannot be trusted it draws a plain inverted frame instead, which reads nothing. On those systems the frame will be inverted rather than blue. If you start it from a Shell without redirections, the log says once "frame: pixel reads not trusted, drawn as a plain inversion". That line, plus your graphics driver and screen depth, is what I would like to see.

@coffeecat Yes, that is exactly what the library is for. The commodity is the first client, and a tiling policy would be the second real one, which is what I want before freezing the ABI. The API is in include/edgesnap.h, the reasoning and the roadmap in docs/DESIGN.md. On AROS the preview still links the core statically; the AROS edgesnap.library is the next stage, and your plan moves it up my list. What a tiler needs and the API does not give yet is on the pre-freeze list already: placing a window into an arbitrary rectangle with the registry semantics of SnapWindow, work areas and layout groups with names, divider tokens instead of one global seam, and a rule for two frontends sharing one engine so they do not overwrite each other. Would you open an issue on GitHub with the calls a tiler would want, in the order you would need them? I would rather shape those signatures with a real client on the other side than guess.

IIRC the iconlist class used by Wanderer is (or was) kinda broken regarding rendering. It tries to optimize the case where the object gets bigger in horizontal and/or vertical direction. And then (re)draw only in those new areas. But theoretically even if an object gets bigger there could still be stuff to redraw in the "old" areas for example if layer damage happened there after a "wild" ChangeWindowBox() (window resize and move to different place at the same time).

Thank you, that pointed the right way. Three things in the end, all fixed in the new build at the Drive link: my seam handle, a small window that followed the pointer and uncovered strips nobody repainted, is gone on AROS, the seam is drawn on the screen now; during a seam drag only the line follows the pointer and the two windows change on release, the way AROS moves its own windows; and the library now shrinks the shrinking window before it grows the other one, so the growing one gets its new size with the area already free. The console and the iconlist clear a window when its size changes, never an area uncovered later, which is what your note describes.

@AMIGASYSTEM @retrofaza New build at the same link, with edgesnap.library inside: copy edgesnap.library LIBS: first, then the commodity. The black bars should be gone; if anything is left, a screenshot helps.

When I launch it from User-Startup, the CLI window still appears, and the black artifacts are still there as well.
From WBStartup, however, no CLI appears; EdgeSnap works, but the artifacts are still there.

Regarding the icon set we discussed on the Italian forum, I’m attaching the AROS One, OS4, and MOS-style icons here:

I recorded a video of today's version. I get the impression that this version glitches more than the previous ones.

https://www.youtu...qihhiVIgRU

I realized after pushing the new version that it was still glitching. I’m working hard on it now and will push a fix as soon as possible.

@AMIGASYSTEM @retrofaza Thank you for the patience, and for the video: it showed the problem exactly. aros-sg was right. Wanderer's icon list repaints only the areas a window gains when its size changes, so whatever the snap uncovered in the old area stayed black, in any order I moved and resized. The library now waits for the window to settle and then has Wanderer repaint the whole window at its final size. Ten snaps in a row of overlapping drawers, also starting off-screen, come out clean here.
New build at the same Drive link, now a full package: double-click Install. It puts the commodity in SYS:WBStartup, so no CLI window, and the library in LIBS:. If you had the previous preview, remove the Run line from S:User-Startup and delete C:EdgeSnap first.
The black areas should be gone. A short flash while the window repaints is expected. There may still be smaller glitches I cannot see under emulation: if anything is left, a screenshot or a short video with your AROS version and graphics driver is all I need.
@AMIGASYSTEM thank you for the icons: the AROS ones are in this build, on the commodity and on the preferences program.

It's working great now! Thanks!
There are just a few minor color glitches left along the seam you're dragging

Ran it on VirtualBox, using the VMWareSVGA driver:

https://www.youtu...11kfiupldM

Maybe something to consider:


Can have a look at Magnet or Rectangle

The “Black Rectangles” artifacts in the icon windows are still there; they are more noticeable if the icons are DualPNG.

@retrofaza Thank you, and the video helped again: the colour left along the seam was the seam line itself. It is drawn on the screen and taken away with the pixels it read when it lit up; if a window repainted underneath in between, the erase painted the wrong colours. It now puts back only what is still its own, and stays dark after a seam move until the pointer moves again. New build at the same Drive link. The VMWareSVGA driver reading the screen back correctly is good to know.

@coffeecat Thank you for the picture, that is the macOS tiling menu on the zoom button. Its first half, the four halves, is what ctrl alt with the cursor keys does already, and quarters come from the corners. The second half is the interesting one: it lays out several windows at once, and PlaceWindowsA in library 2.5 was added for exactly that, so an "arrange the top two, three or four windows" action is a small client of it. Intuition gives no menu on hover over the zoom gadget, but a popup on a hotkey, under the pointer, with the zones and the arrangements, is a good candidate for 0.4. From Rectangle I would take thirds and two thirds, and moving a window to the next display once the work areas exist.

@AMIGASYSTEM Thank you for checking again. Before I chase this, one thing to rule out: the first preview lived in C:EdgeSnap with a Run line in S:User-Startup, and that copy starts before WBStartup at boot. The new one then finds the name taken and does not start, so what runs is the old code. Please open a Shell and type: Version SYS:WBStartup/EdgeSnap, then SYS:WBStartup/EdgeSnap QUIT, then delete C:EdgeSnap and the Run line, reboot, and try again. The build I am uploading now does that cleanup by itself.

If the black rectangles are still there after that, a screenshot right after the snap plus your graphics driver and screen depth would tell me the rest, and one more test helps: drag any other window over an open drawer and away again, without EdgeSnap. If black appears there too, it is the drawer's repaint on that driver and not the snap.

Great, the color issue on the seam is gone!

There's still a minor issue with rendering on the edge of the frame; a video would best illustrate this. The problem is more noticeable with the NVIDIA Nouveau driver. With VMwareSVGA, it's barely visible.

Nouveau:
https://www.youtu...2koaFBccns

VMWareSVGA:
https://www.youtu...7XAvqWHq0U

@retrofaza Thank you, the videos show it. On Nouveau the frame is drawn as a plain inversion, which is what EdgeSnap falls back to when the screen cannot be read back reliably; on VMware it reads the pixels and paints the frame blue. Two questions would settle the rest: if you start EdgeSnap from a Shell, does the log say "frame: pixel reads not trusted" on Nouveau? And do the thin lines stay on the desktop after you release the window, or only show while you drag? Your screen depth on Nouveau helps too.

Yes, the log says: “frame: pixel reads not trusted” on Nouveau (I'm attaching the entire log in a file)

Thin lines remain on the desktop after the window is released

Screen depth on Nouveau: 24 bpp