When multiple instantiations of wbar or flwm are running updates malfunction

[bigpcman]

When two instantiations of wbar or flwm are running, updates to icons or menu items malfunction. I think this situation arises anytime  DISPLAY 0.0 and DISPLAY 1.0 are both active and making use of wbar and flwm.

I really like using the virtual remote desktop but knowing the rules would help. I can live with the idiosyncrasies as long as I know what they are. For instance installing applications via the remote display stops the local wbar, and vice-versa. Installing local applications adds menu items to the remote menu but not the local one. 

Note once wbar is stopped there is no convenient way to activate aterm since it's not in the menu anymore. 

[Lee]

I was fooling around with multiple wbars recently (on a single display) and ended up with /usr/local/bin/wbar0 (and wbar1 and wbar2) as symlinks to the real wbar and ~/.local/bin/wbar0 as a script to kill and restart wbar0 (and similar wbar1 and wbar2 scripts).  The idea of having a distinct name for each instance was to make it easier to kill and restart each one - I was doing loads of testing of various command line options, as opposed to just adding/removing icons so right clicking wasn't enough.

I manually maintain ~/.wbar1 and ~/.wbar as the icon lists and let wbar0 use the default icon list (so loaded extensions with icons will be recognized).

At the same time I added a start (" Tiny ") button (with menu) to the jwm tray with an item to execute the each wbar? script in .local/bin.

Annoyingly, typing wbar0 at the command line executes /usr/local/bin/wbar0 instead of .local/bin/wbar0, even though.local/bin is listed first in $PATH.  Perhaps because .local is a "hidden" directory?

In any case, running multiple wbars doesn't seem to be a problem in and of itself.  I don't know what issue one might run into if multiple instances use the same icon list.

[bigpcman]

I was fooling around with multiple wbars recently (on a single display) and ended up with /usr/local/bin/wbar0 (and wbar1 and wbar2) as symlinks to the real wbar and ~/.local/bin/wbar0 as a script to kill and restart wbar0 (and similar wbar1 and wbar2 scripts).  The idea of having a distinct name for each instance was to make it easier to kill and restart each one - I was doing loads of testing of various command line options, as opposed to just adding/removing icons so right clicking wasn't enough.

I manually maintain ~/.wbar1 and ~/.wbar as the icon lists and let wbar0 use the default icon list (so loaded extensions with icons will be recognized).

At the same time I added a start (" Tiny ") button (with menu) to the jwm tray with an item to execute the each wbar? script in .local/bin.

Annoyingly, typing wbar0 at the command line executes /usr/local/bin/wbar0 instead of .local/bin/wbar0, even though.local/bin is listed first in $PATH.  Perhaps because .local is a "hidden" directory?

In any case, running multiple wbars doesn't seem to be a problem in and of itself.  I don't know what issue one might run into if multiple instances use the same icon list.

Perhaps you are on to the only way to handle multiple instantiations of wbar. I'm not sure I understand what you did.
I'm not that familiar with how wbar works. I suppose it's the naming convention that is confusing me.
I figured there was a wbar executable and a wbar config file that contains the icons. So a little clarification would help.

I have the following wbar files on my system:

./usr/bin/wbar
./usr/bin/wbar.sh
./usr/local/tce.wbar
./usr/local/tce.wbar.bak
./usr/share/wbar
./usr/share/wbar/dot.wbar

So do you mean:

1. /usr/local/bin/wbar0 (and wbar1 and wbar2) ->/usr/bin/wbar

2. /home/tc/.local/bin/wbar0.sh (and wbar1.sh and wbar2.sh) to stop/restart each wbar instantiation

3. "I manually maintain ~/.wbar1 and ~/.wbar as the icon lists and let wbar0 use the default icon list (so loaded extensions with icons will be recognized)."  This is where I am confused by what you are describing.

Also, how does the app browser installer figure into all this? For instance with two DISPLAYs open, each having flwm active and each able to install apps how are the icon updates handled?

[Lee]

/usr/bin/wbar
    is the wbar executable

/usr/bin/wbar.sh
    looks like a script to kill and restart wbar.  I have never directly used this
    script but I suspect tce-load calls it after adding an app that has an icon.

/usr/local/tce.wbar
    is the "config file" (list of icons, labels and programs)  I was trying not to
    call it a config file since wbar is "configured" using command line
    arguments so I called it an "icon list".  Sorry for any confusion caused.

/usr/local/tce.wbar.bak
    I suppose this is a backup of the config file.  It currently doesn't exist on
    my system.

/usr/share/wbar
    directory containing the icons for cpanel, appbrowser and the terminal

/usr/share/wbar/dot.wbar
    looks like the default content of /usr/local/tce.wbar

/usr/local/bin/wbar0 and /usr/local/bin/wbar1 and /usr/local/bin/wbar2 are all symbolic links to /usr/bin/wbar

Code: [Select]

ln -s /usr/bin/wbar /usr/local/bin/wbar0
ln -s /usr/bin/wbar /usr/local/bin/wbar1
ln -s /usr/bin/wbar /usr/local/bin/wbar2

/home/tc/.local/bin/wbar0, /home/tc/.local/bin/wbar1 and /home/tc/.local/bin/wbar2 start/restart/kill scripts for their respective counterparts in /usr/local/bin.

I would have put these in /home/tc/bin (and I may yet) except I noticed there's some code in ~tc/,profile to add this directory to the front of $PATH if the directory exists.  If I determine that the "." in ".local" is masking this directory from the executable search path, I'll use ~tc/bin and adjust .profile.

My earlier post should have read:

I manually maintain ~/.wbar1 and ~/.wbar2 as the icon lists...

On the command line for /usr/local/bin/wbar1 and /usr/local/bin/wbar2 (in the scripts), I specify the config file as ~tc/.wbar1 and ~tc/wbar2.  Since these files are not mentioned in any other scripts, no icons are automatically added to them (I initialize them to the default content of /usr/local/tce.wbar) the only changes that are made to them are those that I manually make with a text editor.  I do not specify a config file for /usr/local/bin/wbar0, allowing it to use the default config file (/usr/local/tce.wbar) which -is- maintained by the TC system (icons/apps/added as extensions are loaded with tce-load).

I haven't been loading a lot of apps with this setup in place, but I suspect tce-load will restart the "real" /usr/bin/wbar every time I load an app that has an an icon.  Then I'll have to figure a nice automatic way to kill it... or maybe just use that instead of wbar0 and insert my command line options into /usr/bin/wbar.sh.

Caveat: I'm using jwm, not flwm and not using multiple displays or vnc or anything like that...  but it seems to me that the the icons ought to be available as long as they get into the config file.  Getting the proper display updated might be a different matter.

[bigpcman]

Thank you for the detailed explanation. It will come in handy. I have determined the fundamental problem I am having is that the wbar.sh update script is killing all instantiations of wbar when an update is made. I'm trying to figure out how to change the script so that it will restart both display 0.0 and 1.0 wbars if two were active before the update was made.