Re: to subclass, or not to subclass...

[Tristan Van Berkom <tristan van berkom gmail com>]

On Sat, 29 Jan 2005 20:28:57 -0800, Ben Johnson <ben blarg net> 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