Open Vladimir-csp opened 8 years ago
The desklet idea could be implemented through SpaceFM Dialog's interface for dialog creation, drawing the elements on or above the root window instead of a dialog window. That would allow adding an icon/detailed view (file browser) of the desktop dir, as well as buttons and other widgets.
When I added Custom arrangement of icons on the desktop, I did look at the possibility of allowing different or multiple desktop dirs, but the structures and code weren't designed for that level of flexibility. Would need quite a rewrite of the desktop manager code. If added to SpaceFM Dialog, it looks like it might be a bit of work with GDK/GTK windows and details, integrating in some existing classes such as the file browser.
No immediate plans for work in this area but the desktop code is fairly well contained and portable.
One of the few things I remember from my brief and bygone experience with early Plasma interface is desktop icons handling. It was done via transparent desklet that showed contents of $XDG_DESKTOP_DIR by default. It was totally possible to change the location or add more desklets watching different locations, resize them, etc. It was very handy to stick a small area watching /media for example. Containing icons in specific areas is also a neat feature.
Since SpaceFM can support transparency and obviously can draw icons, I assume such feature could be implemented as either modified desktop handler or radically stripped down browser window.
The basic idea is: simple transparent window drawn just above root window bypassing window manager (same way conky behaves when
own_window_type = 'desktop'
is set). That window would contain only:Context menu would contain actions for changing path, adding/removing desklet windows.
Such desklets could be started with
spacefm --desklets
(would show one desklet with $XDG_DESKTOP_DIR by default)Config structure could be something flat like this:
This feature could bypass issues #40, #291, #300 or even replace desktop handler completely, being more flexible. There would be no need to actively match window size with framebuffer size, only work around cases when window goes beyond work area. Wallpaper handling in this case could be redone as one-time root window painting, just repeating on framebuffer size change.