Notices

Originally Posted by Patola

Is there a possibility of different scripts for showing the information on the beecon and updating it? Like, say, I have a VPN status script which shows on the beecon, but if I click it, it changes the status. Or I have a FM transmitter status which shows on the beecon, but if I click it, it changes the status. This would be greatly useful.

Originally Posted by No!No!No!Yes!

Absolutely Yes, if I understand your use case correctly.
Your script can handle statuses persistence...
for example (and in metalanguage) the script could perform like this:

Code:

Beecon pressed
isFmOn() { // check some kind of system status indicator
           // (test presence of a file or ps|grep process)
   // Its on, turn it off
   turnFmOff()
   touchOffFlag() // if necessary
   handleError()  // if necessary
   exit(1) //Beecon will sense 1 Exit Code and show relevant icon/color
} else {
   // Its off, turn it on
   turnFmOn()
   touchOnFlag() // if necessary
   handleError() // if necessary
   exit(0) //Beecon will sense 0 Exit Code and show relevant icon/color
}

You can also set a very short timer interval for handling unexpected status changes.

Everything depends on the amount of persistence logic or complexity you can handle via your script/command.

Originally Posted by Patola

Thanks for the response. Actually I've made this with Desktop Command Execution, but there is a problem nevertheless with the design decision of updating and showing being activated by the same script.

Namely, the problem is that, to show the status, you have to update. And sometimes you just don't want that; for example, when I reconfigure anything on the desktop, it reinitializes all widgets, and the script on Desktop Command Execution toggles my FM transmitter again, which I didn't want. Or when I reboot, it does the same thing - it toggles - I had to add some logic to verify from /proc/uptime whether 100 seconds have passed so that it could update only after that.

That's why I am asking for such a feature on Queen Beecon itself. It would ve very useful to me.

Originally Posted by Patola

...when I reconfigure anything on the desktop, it reinitializes all widgets,...

Originally Posted by No!No!No!Yes!

But help me model your use case...

1. How would you trigger the two different scripts?
2. A timer?
3. Two different hot-spots on the Beecon surface (Maybe center for execute (script) and peripheral for status (script))?
4. Same triggering logic for both states/scripts?
5. How would you like to handle status persistency across reboots?

Could you please clarify this more? Seems some sort of bug to me. Does it happen to QBW as well?

Originally Posted by Patola

Sorry, I think I confused my script running under Desktop Command Execution and Queen Beacon Widget. Most of the issues aren't there with QBW indeed. If I edit the desktop, the widget is not reinitialized. If I reboot, it is not auto activated either.

However, due to the nature of my script a small problem still rests. Since the update script is also the script that shows state, I can't get it activated on reboot because it will toggle the FM transmitter. And if I don't get it activated, it will show "Not updated" on the widget.

The script is this one:

Code:

result=$( /usr/bin/fmtx_client -p$( /usr/bin/fmtx_client | /bin/grep -q '^state=enabled' ; echo $? ) | /usr/bin/awk -F '=' '($1=="state") {print $2}' ); echo $result; [ $result = "enabled" ]

Answering your questions:

• The first script would toggle the state of FM TX, as my script does. The other would just show the result of the fmtx, using fmtx_client with no parameters and grepping the state.
• Timer? No, no timers or periodic execution are needed on my script. What I did for the Desktop Command Execution version was an if with /proc/uptime to update or not, so that it wouldn't trigger on boot but also wouldn't trigger with a click until 100 seconds had passed.
• Well, I don't think that would fit for a workaround...
• No, the one would trigger when clicked, the other would trigger e.g. on reboot or repaint when the option for the first not triggering on boot was activated.
• I wouldn't. I'd rely on the device (FM TX) behaviour to get and set its status, as I did on the script.

EDIT: BTW, I noticed a small bug. When entering the text in the input line, sometimes it capitalizes the first letter of some word. With the unix shell being case-sensitive, this results in the script failing. I've noticed that there are programs which do not capitalize any letter, maybe you need to set a flag or something in the input box properties.