Set default desktop pattern in themes in such a way that they can be overridden

[morgant]

I've recently discovered that a System 6-like black & white 'gray' desktop pattern can be easily set using xsetroot -gray, so would like this to be the default desktop pattern. Naturally, I'd want it to be set in such a way that it can be easily overridden by the user.

I think that xsetroot -gray would be a good default for the System7 theme, but would lean towards xsetroot -fg \#6f6f6f -bg \#bfbfbf -bitmap /usr/X11R6/include/X11/bitmaps/gray for the MacOS8 & MacOS9 themes.

[morgant]

See this Mastodon thread where I explore & demonstrate some of the options I've tried on OpenBSD.

[morgant]

I've taken a quick look at the MLVWM source and the following is my current understanding:

• SetStartFunction() in config.c handles the parsing of InitFunction & RestartFunction built-in functions and:
  • Only parses InitFunction blocks in config files if MLVWM is not restarting
  • Only parses RestartFunction blocks in config files if MLVWM is restarting
  • Appends parsed parsed lines to Scr.StartFunc
• DoStartFunc() in mlvwm.c executes the function lines stored in Scr.StartFunc
• Scr.StartFunc appears to be only cleared at initial launch

So, I believe this means that InitFunction/RestartFunction built-in commands always append to Scr.StartFunc. If correct, that should mean that each theme (e.g. .mlvwm/theme/System7) could have it's own InitFunction which has an xsetroot call to set the default X11 root window background pattern/color. If we then make sure that we're loading/inlcuding our .mlvwm/.initrc file (which contains our InitFunction block) after the theme is loaded, then it should first execute our theme-level actions followed by our general configurations, allowing users to override theme defaults (at least in terms of xsetroot calls and such).

[morgant]

Unfortunately, I must have missed or misunderstood something in the mlvwm source, as it appears that only the last defined InitFunction block is executed. Honestly, that's what I initially expected to find, so was feeling pleasantly surprised that it wasn't the case and -- while knocked back down -- not exactly disappointed.

So, I'll review the code again and rethink my approach, which may ultimately require changes to mlvwm itself.

[morgant]

Upon reviewing the MLVWM source again, specifically the implementation of SetStartFunction() in mlvwm/config.c, I believe I now understand what I missed:

• When the new variable is initialized (new = &Scr.StartFunc;) it will point to Scr.StartFunc
• If InitFunction/RestartFunction has already been executed, Scr.StartFunc will point to the first ShortCut in the linked list, otherwise it should be null from the initial launch
• The first iteration of the while loop will allocate memory for a new ShortCut into new (*new = calloc( 1, sizeof( ShortCut ) );).
• If Scr.StartFunc already points to an existing ShortCut from a prior parsing of InitFunction/RestartFunction built-in, it replaces the first ShortCut, links all subsequent InitFunction/RestartFunction lines to the new ShortCut, and orphans the original linked list of ShortCuts

I'll report this issue in the mlvwm repo as it certainly shouldn't leak memory like that and maybe should allow multiple InitFunction/RestartFunction calls to append. That said, maybe there should be separate built-in functions for creating, appending, and destroying InitFunction/RestartFunction lines/commands/shortcuts.