how to app run all the time

Che_M · February 22, 2007, 2:44am

I want to make a GUI app that is meant to be run at startup and
then run all the time in this way:

allow user interaction via the GUI at any time.
have an icon in the notification area (“system tray”) when app is hidden.
create pop-up windows as alarms/prompts to user based on date/time
or analyses that have gone on “behind the scenes”.

Of these, I can manage #1 at the moment. Any advice on the general
approach to #2 and #3? It seems like 1 and 3 are doing two different

processes, so I don’t know if threading is required or not, or if so, how
to do that. I’m a level 2 novice so pardon my cluelessness.

TIA-

Rich · February 22, 2007, 2:50am

Isn't this what you have when you boot into runlevel 5 and use kdm or gdm
to load the GUI interface?

Rich

···

On Wed, 21 Feb 2007, C M wrote:

1. allow user interaction via the GUI at any time.
2. have an icon in the notification area ("system tray") when app is hidden.
3. create pop-up windows as alarms/prompts to user based on date/time
or analyses that have gone on "behind the scenes".

--
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

Stephen_Hansen2 · February 22, 2007, 4:32am

I want to make a GUI app that is meant to be run at startup and
then run all the time in this way:

allow user interaction via the GUI at any time.

This should be no problem, if you can accomplish the others; being able to run at startup – if you’re on windows, put it into the Startup menu?

have an icon in the notification area (“system tray”) when app is hidden.

In your App’s OnInit:

    self.icon = wx.TaskBarIcon()
    self.iconBitmap= wx.IconFromBitmap(wx.Image(PATH_TO_IMAGE).Scale(16,16).ConvertToBitmap())
    self.icon.SetIcon

(self.iconBitmap)

    wx.EVT_TASKBAR_LEFT_DCLICK(self.icon, self.OnDClickIcon)
    wx.EVT_TASKBAR_RIGHT_UP(self.icon, self.OnRightClick)

… Etc. And then you capture those various events, and such, to deal with interaction with the icon

create pop-up windows as alarms/prompts to user based on date/time
or analyses that have gone on “behind the scenes”.

Check out wxTimer to do a periodic action and in that action check on date/time and … whatever else you want.

···

On 2/21/07, C M cmpython@gmail.com wrote:

Che_M · February 22, 2007, 2:32pm

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could work on
such long time scales as, say, weeks or months. But I’ll look into it.

···

On 2/21/07, Stephen Hansen shansen@advpubtech.com wrote:

On 2/21/07, C M cmpython@gmail.com wrote:

I want to make a GUI app that is meant to be run at startup and
then run all the time in this way:

allow user interaction via the GUI at any time.

This should be no problem, if you can accomplish the others; being able to run at startup – if you’re on windows, put it into the Startup menu?

have an icon in the notification area (“system tray”) when app is hidden.

In your App’s OnInit:
    self.icon = wx.TaskBarIcon()
    self.iconBitmap= wx.IconFromBitmap(wx.Image(PATH_TO_IMAGE).Scale(16,16).ConvertToBitmap())

    self.icon.SetIcon
(self.iconBitmap)
    wx.EVT_TASKBAR_LEFT_DCLICK(self.icon, self.OnDClickIcon)
    wx.EVT_TASKBAR_RIGHT_UP(self.icon, self.OnRightClick)
… Etc. And then you capture those various events, and such, to deal with interaction with the icon

create pop-up windows as alarms/prompts to user based on date/time

or analyses that have gone on “behind the scenes”.

Check out wxTimer to do a periodic action and in that action check on date/time and … whatever else you want.

Che_M · February 22, 2007, 2:33pm

I’m using WinXP. Eventually I’d like to see if I can have the app run on Linux

too, so this is good to know about. Thank you.

···

On 2/21/07, Rich Shepard rshepard@appl-ecosys.com wrote:

On Wed, 21 Feb 2007, C M wrote:

allow user interaction via the GUI at any time.

have an icon in the notification area (“system tray”) when app is hidden.

create pop-up windows as alarms/prompts to user based on date/time

or analyses that have gone on “behind the scenes”.

Isn’t this what you have when you boot into runlevel 5 and use kdm or gdm
to load the GUI interface?

Stephen_Hansen2 · February 23, 2007, 12:35am

Well, consider: There’s no way your app is going to be running for weeks or months. Not really. It is windows People are going to need to reboot. But, as long as the app is running, you can make the timer fire every so often-- every minute? Thirty seconds? Do it as rarely as you can so you don’t impact general performance too much, depending on how much you’re doing.

Then every cycle, you just do a series of checks. See if ‘now’ (as defined by time or mx.DateTime, my preference) happens to have any events scheduled for it, and if so, toss up a dialog. If not, do nothing and wait for the next cycle. That sorta thing.

Etc.

···

On 2/22/07, C M cmpython@gmail.com wrote:

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could work on
such long time scales as, say, weeks or months. But I’ll look into it.

Che_M · February 23, 2007, 2:43am

Thank you. That makes sense.

So as I understand it, while the timer of wxTimer is running the user can still
interact with the controls on a panel while the timer is counting down
in the background?

···

On 2/22/07, Stephen Hansen shansen@advpubtech.com wrote:

On 2/22/07, C M cmpython@gmail.com wrote:

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could work on
such long time scales as, say, weeks or months. But I’ll look into it.

Well, consider: There’s no way your app is going to be running for weeks or months. Not really. It is windows People are going to need to reboot. But, as long as the app is running, you can make the timer fire every so often-- every minute? Thirty seconds? Do it as rarely as you can so you don’t impact general performance too much, depending on how much you’re doing.

Then every cycle, you just do a series of checks. See if ‘now’ (as defined by time or mx.DateTime, my preference) happens to have any events scheduled for it, and if so, toss up a dialog. If not, do nothing and wait for the next cycle. That sorta thing.

Etc.

Stephen_Hansen2 · February 23, 2007, 8:19am

Essentially, yes. The timer will just stroll along in the background and when it comes time to fire, toss an event out into the system for you to catch and do things. During this time, the rest of the app is perfectly intractable and won’t be bothered by the timer running along.

(There are reports that on OSX if you’re doing certain actions right when a Timer should fire, that event might never appear; but it’s never bothered me in any of my uses of the timer in my apps)

···

On 2/22/07, C M cmpython@gmail.com wrote:

Thank you. That makes sense.

So as I understand it, while the timer of wxTimer is running the user can still
interact with the controls on a panel while the timer is counting down
in the background?

On 2/22/07, Stephen Hansen <shansen@advpubtech.com > > wrote:

On 2/22/07, C M cmpython@gmail.com wrote:

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could work on
such long time scales as, say, weeks or months. But I’ll look into it.

Well, consider: There’s no way your app is going to be running for weeks or months. Not really. It is windows People are going to need to reboot. But, as long as the app is running, you can make the timer fire every so often-- every minute? Thirty seconds? Do it as rarely as you can so you don’t impact general performance too much, depending on how much you’re doing.

Then every cycle, you just do a series of checks. See if ‘now’ (as defined by time or mx.DateTime, my preference) happens to have any events scheduled for it, and if so, toss up a dialog. If not, do nothing and wait for the next cycle. That sorta thing.

Etc.

–
Stephen Hansen
Development
Advanced Publishing Technology

shansen@advpubtech.com
(818) 748-9282

Che_M · February 23, 2007, 1:19pm

Thank you again for your helpful explanation, I’m looking forward to giving it a try.

···

On 2/23/07, Stephen Hansen < shansen@advpubtech.com> wrote:

Essentially, yes. The timer will just stroll along in the background and when it comes time to fire, toss an event out into the system for you to catch and do things. During this time, the rest of the app is perfectly intractable and won’t be bothered by the timer running along.

(There are reports that on OSX if you’re doing certain actions right when a Timer should fire, that event might never appear; but it’s never bothered me in any of my uses of the timer in my apps)

On 2/22/07, C M cmpython@gmail.com wrote:

Thank you. That makes sense.

So as I understand it, while the timer of wxTimer is running the user can still
interact with the controls on a panel while the timer is counting down
in the background?
On 2/22/07, Stephen Hansen <shansen@advpubtech.com > > > wrote:

On 2/22/07, C M cmpython@gmail.com wrote:

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could work on
such long time scales as, say, weeks or months. But I’ll look into it.

Well, consider: There’s no way your app is going to be running for weeks or months. Not really. It is windows People are going to need to reboot. But, as long as the app is running, you can make the timer fire every so often-- every minute? Thirty seconds? Do it as rarely as you can so you don’t impact general performance too much, depending on how much you’re doing.

Then every cycle, you just do a series of checks. See if ‘now’ (as defined by time or mx.DateTime, my preference) happens to have any events scheduled for it, and if so, toss up a dialog. If not, do nothing and wait for the next cycle. That sorta thing.

Etc.

–
Stephen Hansen
Development
Advanced Publishing Technology

shansen@advpubtech.com
(818) 748-9282

Chris_Mellon · February 23, 2007, 2:09pm

If you're looking at these sort of timescales you're better off using
the OS level scheduled task interfaces (you can use single instance
techniques to have it start your app if neccesary or communicate with
a running instance) than relying on a wxTimer.

···

On 2/22/07, C M <cmpython@gmail.com> wrote:

Thanks, this helps. I'll have a look at wxTimer; I wasn't sure if it could
work on
such long time scales as, say, weeks or months. But I'll look into it.

Che_M · February 23, 2007, 6:07pm

Can I ask you:

Why is this a better approach for these timescales?
Could you point me in the direction of some Python entity that corresponds to

“OS level scheduled task interfaces”? I have no sense of how to approach
this in that way using Python. (again, I’m pretty new to this).

TIA

···

On 2/23/07, Chris Mellon arkanes@gmail.com wrote:

On 2/22/07, C M cmpython@gmail.com wrote:

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could
work on such long time scales as, say, weeks or months. But I’ll look into it.

If you’re looking at these sort of timescales you’re better off using
the OS level scheduled task interfaces (you can use single instance
techniques to have it start your app if neccesary or communicate with

a running instance) than relying on a wxTimer.

Chris_Mellon · February 23, 2007, 6:30pm

> > Thanks, this helps. I'll have a look at wxTimer; I wasn't sure if it
could
> > work on such long time scales as, say, weeks or months. But I'll look
into it.
>
> If you're looking at these sort of timescales you're better off using
> the OS level scheduled task interfaces (you can use single instance
> techniques to have it start your app if neccesary or communicate with
> a running instance) than relying on a wxTimer.

Can I ask you:

1. Why is this a better approach for these timescales?

Because any interruption in your application will interfere with your
scheduling. You can build infrastructure to fix this, but the OS
scheduled task already has it and will be more robust.

2. Could you point me in the direction of some Python entity that
corresponds to
"OS level scheduled task interfaces"? I have no sense of how to
approach
this in that way using Python. (again, I'm pretty new to this).

There's nothing in the standard library as far as I know. You don't
really need to do it from Python, though, it's a system configuration
issue.

···

On 2/23/07, C M <cmpython@gmail.com> wrote:

On 2/23/07, Chris Mellon <arkanes@gmail.com> wrote:
> On 2/22/07, C M <cmpython@gmail.com> wrote:

TIA

Stephen_Hansen2 · February 23, 2007, 6:38pm

Thanks, this helps. I’ll have a look at wxTimer; I wasn’t sure if it could

work on such long time scales as, say, weeks or months. But I’ll look into it.

If you’re looking at these sort of timescales you’re better off using
the OS level scheduled task interfaces (you can use single instance
techniques to have it start your app if neccesary or communicate with

a running instance) than relying on a wxTimer.

Can I ask you:

Why is this a better approach for these timescales?

This depends on what you mean; I interpreted your original question to mean you have a number of possible events that could be fired, be they scheduled events at certain times, or “other factors” dependent upon something that hs been going on in the background. If this is the case, then a scheduled task along on the operating system is actually not the better choice IMHO. Too much dynamic stuff in the mix of when events are processed and how often they are.

It also depends on how critical the events are, how often they change, and on what scale they happen. Is this a system maintenance thing where its important for an event to fire at a specific time? Or is this a reminder type situation? How much reliability is nessecary for the events?

Sometimes its enough to architect your program so that it never misses an event (meaning that if the time for an event has passed and for whatever reason the program didn’t catch it, then when it next does its cycle looking for events it’ll still find it) then that’s often plenty.

For reference, in our product I implemented my own task-scheduler for
internal actions to our product to be fired at configurable
rates/intervals. It basically is a timer that scans a configuration table in our database regularly to see if any events need firing. When it finds a match, it dispatches a message to the appropriate component in the system to perform the action.

Originally since most events were rare (once a day; once a week, etc) we were using Windows Scheduled Tasks to get them going. In the end, though, that became a pain. It didn’t mesh well with the product and was hard to programatically interact with and control. So I’ve ended up doing both approaches, depending.

Could you point me in the direction of some Python entity that corresponds to

“OS level scheduled task interfaces”? I have no sense of how to approach
this in that way using Python. (again, I’m pretty new to this).

That’s a bit of a pain. You can go into the Scheduled Tasks under control panel to set it up… to do it from your program … uh, er. You’ll probably have to install win32all and do it via the windows API. And at that point, I bow out-- I dun do windows api

···

On 2/23/07, C M cmpython@gmail.com wrote:

On 2/22/07, C M cmpython@gmail.com wrote:
On 2/23/07, Chris Mellon < > arkanes@gmail.com> wrote:

Che_M · February 23, 2007, 7:09pm

This depends on what you mean; I interpreted your original question to mean you have a number of possible events that could be fired, be they scheduled events at certain times, or “other factors” dependent upon something that hs been going on in the background. If this is the case, then a scheduled task along on the operating system is actually not the better choice IMHO. Too much dynamic stuff in the mix of when events are processed and how often they are.

That is how I meant it. The events would be of two sorts:

a) either a reminder pop-up scheduled by the user, like a reminder for a 10am meeting or “don’t forget wife’s birthday” sort of thing. These to be set by user, such as Google or Yahoo calendar, et al.

b) a pop-up as a result of behind-the-scenes analyses. Those might be things like doing a daily check of an ongoing user-inputed events (e.g. # of donuts eaten per day by user) and sending a warning if the trendline or total monthly donut consumption passes some pre-set threshold. But the timer would need to tell the app to do the analysis that day in order to check the status. Really in this case it might be fine to just set it to check each day at some point and alert the user the first time each day they interact with the app. Some of this is also intended to be self-referential, in that if the user failed to interact with the app in the appropriate way (didn’t input the donuts eaten yesterday) the app will catch that and ask for it today.

It seems like to do both would be hard or impossible to get the Windows Scheduled Tasks to carry out. Plus I want the app to eventually work on OSX and Linux.

It also depends on how critical the events are, how often they change, and on what scale they happen. Is this a system maintenance thing where its important for an event to fire at a specific time? Or is this a reminder type situation? How much reliability is nessecary for the events?

See above.

Sometimes its enough to architect your program so that it never misses an event (meaning that if the time for an event has passed and for whatever reason the program didn’t catch it, then when it next does its cycle looking for events it’ll still find it) then that’s often plenty.

In the case of analyses as mentioned above, that’d work just fine. For appointment reminders, it’d be more critical to remind the user some pre-set time before the appointment of course.

For reference, in our product I implemented my own task-scheduler for
internal actions to our product to be fired at configurable
rates/intervals. It basically is a timer that scans a configuration table in our database regularly to see if any events need firing. When it finds a match, it dispatches a message to the appropriate component in the system to perform the action.

Thanks for sharing that. It may be tricky for me to figure out a good way to see if events need firing. I’ll have to think about what kind of database queries would pull up what would be needed.

Best,
C

Don_Dwiggins · February 23, 2007, 7:27pm

Stephen Hansen wrote:

    2. Could you point me in the direction of some Python entity that
    corresponds to
        "OS level scheduled task interfaces"? I have no sense of how to
    approach
        this in that way using Python. (again, I'm pretty new to this).

That's a bit of a pain. You can go into the Scheduled Tasks under control panel to set it up... to do it from your program .. uh, er. You'll probably have to install win32all and do it via the windows API. And at that point, I bow out-- I dun do windows api

A while back, I had a web app that involved running scheduled tasks, and I wanted to manage it programmatically. After searching in vain for a good API to the MS Scheduled Tasks, I gave up and switched to Cygwin's port of the *nix "cron" facility (I was already using Cygwin for other things.) Cron works off a straightforward text file, which makes it easy to manage, and you can even put it under version control.

I think there are some Windows cron packages that don't rely on the whole Cygwin infrastructure; if this is the kind of thing you have in mind (scheduling things to run at specified intervals or at specified times/dates), it's worth looking into.

···

On 2/23/07, *C M* <cmpython@gmail.com <mailto:cmpython@gmail.com>> wrote:

--
Don Dwiggins
Advanced Publishing Technology