On Sat, 29 Jan 2005 20:28:57 -0800, Ben Johnson <ben@xxxxxxxxx> wrote:
> I need some advice. I'm used to working in C, so I'm not used to making
> decisions about when to create sub-classes and when I should just use
> callbacks.
>
> One feature of the app I'm making is a global inactivity timer. When
> the timer goes off the app does a locked screen saver kind of thing.
> The way I've made this work so far is by adding a call to a function at
> the start of almost every callback. The only callbacks that don't reset
> the inactivity timer are those triggered when the user is attempting to
> unlock the app.
>
> So, you probably know what I'm going to ask. It seems like it might be
> easier to maintain and more reliable to (instead of adding cookie cutter
> code to every callback) subclass every widget and overwrite every signal
> in those widgets that I want to reset the timer. Is that a no-brainer?
> I could add other code in these shims as well such as security/consistency
> checks or functions that log all events if a debug/security level is
> turned up high enough, etc.. (I'm making a POS.)
>
> I've used Glade to do most of the layout and design work so far. I
> don't know if that has to influence my decision. It is a large app with
> lots of callbacks. What would you do?
If you are not extending the functionality of a GObject, dont bother subclassing
it, thats what signals are for.
I program a point-of-sales system as well (a jukebox), we timeout to
an "attract"
screen or a screen-saver; each of which we connect to button-press-event to
re-animate the "timed-out" jukebox, and we reset the timer any time the screen
is touched in any of the UI's (when significant buttons are pressed, or just
backgrounds).
Cheers,
-Tristan
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
