Active Topics

 



Notices


Reply
Thread Tools
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#31
Queen BeeCon Widget
[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:





Then proceed with Instance Advanced Settings Dialog operations.
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras
 

The Following 3 Users Say Thank You to No!No!No!Yes! For This Useful Post:
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#32
Release 0.1.4 is now in Extras-Testing repository.

Testers and a bit of promotion needed for taking it to Extras.

Anybody can help?
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras
 
Posts: 267 | Thanked: 183 times | Joined on Jan 2010 @ Campinas, SP, Brazil
#33
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.
 
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#34
Originally Posted by Patola View Post
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.
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.
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras
 
Posts: 267 | Thanked: 183 times | Joined on Jan 2010 @ Campinas, SP, Brazil
#35
Originally Posted by No!No!No!Yes! View Post
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.
 
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#36
Originally Posted by Patola View Post
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.
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)



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?
Originally Posted by Patola View Post
...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?
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras
 
Posts: 267 | Thanked: 183 times | Joined on Jan 2010 @ Campinas, SP, Brazil
#37
Originally Posted by No!No!No!Yes! View Post
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?
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.

Last edited by Patola; 2010-03-24 at 22:42.
 
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#38
Originally Posted by Patola View Post
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.
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
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
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras

Last edited by No!No!No!Yes!; 2010-03-24 at 23:38.
 

The Following User Says Thank You to No!No!No!Yes! For This Useful Post:
No!No!No!Yes!'s Avatar
Posts: 700 | Thanked: 846 times | Joined on Nov 2009
#39
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.
__________________
Have a look at Queen BeeCon Widget (WIKI) Customizable and flexible widget-based multi-instance monitoring, alerting and interactive tool for the N900
Please provide comments and feedback for having QBW supported and enhanced further - (DONATE) - v1.3.3devel / v1.3.3testing / v1.3.3extras
 
Posts: 267 | Thanked: 183 times | Joined on Jan 2010 @ Campinas, SP, Brazil
#40
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.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 11:33.