flwm classic forgets my menu entries

[philip]

I have TC 3.1 (lovely), installed simply by replacing some previous initramfs with the latest copy of tinycore.gz from the "Distribution Files" part of the download area. I'm using flwm classic, and all my applications are up-to-date.

To add entries to my flwm menu, I create symbolic links in the directory /home/tc/.wmx. They work. BUT when I want to leave my workspace and secure my machine, I select "Logout" and then "Exit to Prompt" from the flwm menu. The GUI goes away, flwm stops, and the symlinks are still there ready for next time. Then I type "exit" at the prompt so that the session of user "tc" ends and a login prompt is displayed. When I log in again, X starts automatically (it's Xorg for me) and the symlinks are gone!

Can anyone explain what is zapping my symbolic links and help me make them more resilient? Thanks!

[maro]

I don't think that files from '/home/tc/.wmx' are meant to "survive" a reboot. For starters they are excluded by the '.wmx' entry in '/opt/.xfiletool.lst' from the backup file and hence won't be restored. But looking at '/usr/bin/flwm_topside_initmenu' reveals that even if they would be restored they are "zapped" at the startup of 'flwm'.

So what you could do is to create a file in '/home/tc/.X.d' that re-creates your custom menu entries whenever 'flwm' has been started. Please check that this script is included in the backup (which it should normally), or is on a persistent 'home'.

[philip]

I hesitate to call my sequence of steps a reboot, because the machine is continuously powered on and TinyCore keeps running throughout. The standard TC backup/restore operations are never executed. But there is a stop/start cycle of the X server, and that causes a stop/start cycle of flwm (the original, not flwm_topside, in my case). Therefore I think your direction to look at /usr/bin/flwm_initmenu and create a custom file .X.d are going to be enough for me to sort things out. Thank you!

[maro]

Well I did not consider multiple X server cycles, but as '..._initmenu' gets called in '/usr/bin/startx' the "zapping" happens at each of the X server starts. At the end control is handed over to '.xsession' which then starts the WM. So a '.X.d' script would be running "hot on the heels" of all that action.

[philip]

Putting some files with link-creation commands into my directory ~/.X.d was indeed enough to rebuild the flwm menu before I need it. Perfect. But, on this topic, do you think the TinyCore FAQ is accurate enough to help others understand all this? Here's a snapshot, taken minutes ago.

How do I start X apps on boot?
Add them to files in /home/tc/.X.d, one per file, backgrounded. Here's how to start Opera at boot:
opera &

The first sentence in the response makes sense, but the second one doesn't conform to the pattern. To start Opera at boot, you should create a file with any name you like in ~/.X.d -- startopera, say -- then put the single line "opera &" into that file. At least, this is the principle that worked for me. Should we try to alert the FAQ maintainer to this possibility for improvement?

[curaga]

Please post what you think would be better wording. Anyone on the team can change it.