GitLab

Closes #13
Additionally, correctly release memory after launching.

What are the effects of traversing the directory tree in
findXDGDirectories() (at startup time) rather than loadXDGDirectories()
(also called on .desktop rescan)? It might be faster, since we only do a
recursive rescan once, but it's flawed since we don't pick up changes to
*which* directories are present.

One theoretical advantage of having a recursive directory scan, followed
by a linear file scan, is that if XDG_DATA_DIRS contains both a
directory and its child, we won't process those .desktop files twice.
But in practice we can avoid duplicated files (and also be more
standards-conformant [1]) by not pushing /usr/local/share and /usr/share
if we find a non-empty XDG_DATA_DIRS.

[1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

nyanpasu64 authored Nov 23, 2021 and David Keogh committed Nov 26, 2021

Previously dragging a launcher towards the right would leave it 1 icon
to the left of the position you dragged it to. And you couldn't drag a
launcher to the rightmost position in the dock. This fixes it.

I'm not sure why the -1 was added in the first place. Is there now a
risk of now dropping an icon at position "length", which is an invalid
position? I haven't seen any malfunctions in my testing though.

This doesn't change the behavior, since `id = id.substr(0, 0xffffffff)`
is a no-op. But this still improves the code and makes it slightly
faster.

This fixes many cases of windows mapping to incorrect .desktop files
(Docklike shows the wrong icon, and pinning pins the wrong app).
Specifically this fixes windows whose WM_CLASS matches a .desktop file's
StartupWMClass (but not name), but Docklike ignores the StartupWMClass
so can't find the right .desktop file.

In many cases the timeout's stop method was being called more than once raising GLib warnings.

GLib provides a GAppInfoMonitor object that allows us to detect desktop file changes.

This should work on non-linux systems, anywhere GNOME does.

The previous effect can still be achieved with CSS:

#docklike-plugin .hover_group { background-color: alpha(@menu_item_bgcolor_hover, 0.1); }

Better debugging instructions and long desctiption.

Related #14
It can be restored by using css or a future option.

Related #9

Closes #4
"gtk-close" is deprecated

The leave-notify-event needs to return false (propogate event) for gtk to remove the hover state of the button.

new string: "Remove"

Closes #41

The last two conditions do the same thing.