Re: glib: GTimer patch for elapsed time

[Gavin Baker <gavinb antonym org>]

Greetings, 

On Wed, 2002-07-17 at 02:36, Owen Taylor wrote: 
> 
> Gavin Baker <gavinb antonym org> writes:
> > I have rewritten the patch.  The existing behaviour is not changed.  I
> > have added code to g_timer_stop() to accumulate the total elapsed time,
> > and I have added a new function called g_timer_total_elapsed() that will
> > return the true elapsed time (between start-stop calls) since the last
> > g_timer_reset() (instead of modifying g_timer_elapsed()).
> > 
> > I also added g_timer_is_active() to return whether or not the timer is
> > running.  In the process, I also added docstrings for all the functions,
> > that are consistent with the API reference on the web.  I can update the
> > web reference if someone tells me where the source lives.
> > 
> > I have tested and verified that it works according to both the old and
> > the new ways.  Is this ok?  Shall I file this in bugzilla?
> 
> Filing patches in bugzilla is the best way to make sure they don't
> get lost.

I have filed a patch in bugzilla, which also has complete doc comments
(as per Matthias' feedback).

    http://bugzilla.gnome.org/show_bug.cgi?id=88768

> Isn't it a little confusing to introduce the idea of a GTimer containing
> two different times; the current elapsed time and the total elapsed
> time?

No, I don't think so.  You are always starting and stopping the clock; you
just choose if you want the last interval or the total elapsed time.  I
really think that most people will want the total elapsed time anyway.

> That's why I suggested g_timer_continue() ...  it seems to me to keep
> model simple.

Yes... I started to do it that way, but ended up realising that the
original interface was more natural.  Using start/stop/reset is just
like a stopwatch, which is just what you'd expect (and is precisely the
semantics that this patch provides).

I think having g_timer_continue() is less orthogonal than the original
interface, and would be more confusing to the user (eg. do you do a
continue after a reset or only after stop?).  Also, it belies the
implementation somewhat, since it effectively exposes state to the
user.  Client code would potentially need some logic to decide whether
to call start if it was the first time since a reset, or continue of
start has already been called.

I've tested my patch and written some client code; it looks and works
just fine.  Simple usage where the timer is being used inside the one
function to time a single event doesn't make much difference.  But when
you create a timer that belongs to a window, start and stop it based on
user events, and display the elapsed time on window updates, that's when
you need this sort of API.

Thanks -

::Gavin


-- 
Gavin Baker // gavinb*antonym_org // Linux|Python|Esperanto|MIDI|Cheese