idea (wish): "spacemenu" spaceFM companion app

[sandax]

Daily, dual-booting between winXP and various linux distros, I'm continually chagrined by the comparatively inflexible "application menu" provided by various linux DEs. Pipe menu? Really? No, that's not an acceptable "workaround", nor is hand-editing various "xdg compliant directory menu files". How did the "linux desktop" arrive at such an inane status quo? The freakin' "menu" represents a BARRIER between the user and the content of his system.

With (seeming) only slight modificaton, the spaceFM codebase could serve as a wonderfully flexible menuing solution.

-- launched via desktop right-click, or keybind, or desktop icon, or (TBD)
-- displays a spaceFM single pane (minimal, editable toolbar) (no multipane support)
-- displays content of (TBD)(configurable?) ~/home/spacemenu
-- paints a scrollbar, if appropriate
-- default view would suppress most columns (TBD) other than icon + filename
-- column headers (inherited from spaceFM) would be displayed (to facilitate sort)
-- window dimensions for of this top-level window are read from config file
-- optionally, esc keypress closes a focused spacemenu window

The app would bear no responsibility for populating "menu items" ~~ that's up to the user
(or items might be preseeded, in /opt, by distro developer).

Content could be DRAGGED into place.
User could freely populate his "menu" directories with actual files and/or symlinks !
User could right-click RENAME "menu" items. Heh, imagine that!
User could arbitrarily add/remove nested levels at will (as it should be, dammit!)

proposed behavior (differing from spaceFM):

user clicks a (sub)directory item:
set focus on the dir item

user double-clicks directory item:
open a new spacemenu window displaying the content of this dir at a TBD x/y mouse offset
and
original (top-level) window remains open
(user can minimize, move, resize, close it... without affecting other window instances)

spacemenu config file:
store 2 sets of "last used" window dimension variables; one set for top-level, another for last closed subdirectory window (dimensions stored to config each time a panel is closed

=============
As a "menu" construct, should hovering a directory display its nested content?
Some users would chafe at an "extra" click in order to view nested content?
Well, some of us mouse-twitchy users would find it BENEFICIAL to have sticky submenu panels instead of dealing with the frustration of opening/closing flyouts disappearing from view.

[sandax]

Additionally, by accepting command-line switches (x/y pos, width, height, target path, icon/detail view)
customized "spacemenu" launchers could supplant:
-- "KDE plamoids" (?)
-- roxdesktop "slit"
-- various "dock" and "tray/stack" devices

Rox desktop... didn't quite get it right.
(roxpanel lacks support for deeply nested organization)
(rox "menu", aka application directory window, forced a large icon view)

kornelix "mystuff" device... isn't designed to support multiple instances.

gnome, kde, mate... chasing "xdg compliance" and toying with extended [ Desktop Action %s ]
^-- laughable, compared to the functionality provided by spacefm/spacemenu "design mode"