DSL Ideas and Suggestions :: Two versions of DSL

OK. I am going to process only one mydsl menu for the current wm. Then upon switching managers, rebuild the mydsl menu for the newly selected wm. This should complete the opening of the mydsl menu processing code.

Is that done by having each wm specific code inside DSL, or by having the script in the extension under a standard name like "create-menu" or something?

I am supporting it all under /opt. This way it supports legacy mode.
You are correct to assume a common single simple name of the scripts that code in the core DSL will look for and process.

/opt/.mydsl_menu/jwm/ directory contains:

make - the code to make the mydsl menu include
restart - the code needed to restart/refresh to make the menu updates visible
menu_template - the "empty" or starting menu usually has a placeholder used as the target of insertion for the make script.

I did not use any extension (.lua, .sh, .pl) on the script names so that you can write your scripts in any supported language.

To remain backward compatible the default remains fluxbox menu specifications.

/opt/.mydsl_menu/fluxbox directory contains the same three named files but with content specific to fluxbox.

This way a .tar.gz (legacy able) extension can write to /opt/.mydsl_menu and the dynamic mydsl menu creation, update, and cleanup will all work.

For the main system menu (static) I am now using a bash include
to there is a fluxbox.inc and a jwm.inc. This include file is the code snippet that would have been needed inside the .xinitrc case statement.

Nice.

So all new wm extensions (with menus) would have to have those?

You should also post this in the sticky "Note to extension builders" thread..

Does this mean i can get back those retro 48x48 icons again? that would be way cool!

And what would the live cd default to ?

Next Page...
original here.