Re: Default timeouts

On Tue, 2006-06-06 at 10:41 -0500, Federico Mena Quintero wrote:
> In gtksettings.c we have
> for the "gtk-timeout-initial" and "gtk-timeout-repeat" settings,
> respectively.  This means we wait for a fifth of a second before we
> start repeating, but then we try to repeat 50 times per second.
> Isn't the repeat timeout way too short?  This is why clicking on a
> calendar arrow takes you back tens of months in no time, and also makes
> it hard to use spin buttons.

Yes, that's way too short. When doing the settings patch, I unified
timeouts without actually changing them (the 20 ms was there before).

However in some places I introduced a factor of 5 so all existing
timeouts could be done with the two values from GtkSettings.

See comment #10 of

Actually, it may make sense to simply use the user's configured
key repeat and delay for these two setting values. What do you


> Also, Michael Meeks has the following words of wisdom in a Novell bug
> about the calendar in gnome-panel's clock:
> > In essence the timeout is way too short for switching days; also -
> > in the panel applet the timeout has a higher priority than the 
> > queued resize of the display (and hence the redraw) - so in 
> > essence we skip days even faster since we never have to render
> > them.
> >
> > Lowering the priority there, and lengthening the timeouts gives
> > a far more reasonable, usable experience without getting rid
> > of the whole auto-repeat principle [...]
> I.e. instead of using g_timeout_add() in gtkcalendar, we would use
> g_timeout_add_full (G_PRIORITY_DEFAULT_IDLE, ...), or perhaps
> (GDK_PRIORITY_REDRAW + positive_constant): both are lower priority than
>   Federico
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]