maemo.org - Talk - [Announce] Queen BeeCon Widget: Super powerful and customizable Widget Generation Engine

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

Queen BeeCon Widget: [HowTo] Copy Exported Instance Data to Phone's Clipboard

http://i46.tinypic.com/1zn04fm.pngQueen BeeCon Widgethttp://i46.tinypic.com/1zn04fm.png
[HowTo] Copy Exported Instance Data to Phone's Clipboard

Best way (to me): Just use N900 Microb Browser to open page with Exported Instance Data and Copy to clipboard according to this simple procedure:

http://i41.tinypic.com/2lkplxj.png

http://i42.tinypic.com/rtkljn.png

Then proceed with Instance Advanced Settings Dialog operations.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

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.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Quote:

Originally Posted by Patola (Post 579737)

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.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Quote:

Originally Posted by No!No!No!Yes! (Post 579861)

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.

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.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Quote:

Originally Posted by Patola (Post 580749)

Hi ... with these settings you can prevent Beecon from executing unless the button is explicitly pressed manually. No other event will trigger execution (neither startup of system/widget)

http://i39.tinypic.com/eiwjms.png

But help me model your use case...

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

Quote:

Originally Posted by Patola (Post 580749)

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

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

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Quote:

Originally Posted by No!No!No!Yes! (Post 580977)

But help me model your use case...

How would you trigger the two different scripts?
A timer?
Two different hot-spots on the Beecon surface (Maybe center for execute (script) and peripheral for status (script))?
Same triggering logic for both states/scripts?
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?

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.

Cheers,

Cláudio (Patola)

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.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Quote:

Originally Posted by Patola (Post 581092)

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.

Cláudio, would you mind trying with different scripts? Have a look at this topic: http://talk.maemo.org/showpost.php?p...&postcount=100 and please report back here results...

other suggestion:
why don't you just set "enable on startup" and programmatically skip first run from within your script like:

Code:

   if [! -f /tmp/1st_run ]

   then

      touch /tmp/1st_run

   else

      <your code here>

   fi

Quote:

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.

This is not a bug ... it is standard behaviour for text entry fields. Needs to be programmatically changed soon after entry text creation.
Thanks to querty12 tip this has already been changed in 0.1.5 still in internal testing on my N900

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

I made some test last night and it seems to me that when fmtx switches on the radio, and no sound is sent through it, after a while the FM radio gets automatically switched off.
I believe it is not easy for Beecon to track this kind of behaviour unless continuously polling with very short rest time... being a real Battery squeezer.

Re: [Announce] Queen BeeCon Widget: Customizable and flexible monitoring tool.

Yes, that's why I think the click script and update content script should be different! My "show" script could just get the battery status from fmtx_client polling every x minutes, while my "update" script could change it to what I want.

And thanks for the response, I'll try for the time being using the temporary file but I'd really prefer the feature of separate scripts.