Re: CList "keyfocus"

[Mudiaga Obada <mudi obada de>]

Tim Janik wrote:

> event chain might be broken? can you extend on that?

The patch that was posted was not clean at all.  I was yet
to decide what key masks to use.  On my PC for example Alt+x
would have been swallowed by the CList widget instead of going
somewhere else.  In the version I'm now using (see other mail 
for patch) a key press is only processed when neither control or mod1
is down.

> gtk_clist_find_row_from_text() should probably take a
>        gint (*strncmp) (const gchar *, const gchar *)
> argument to let the user decide whether he wants
> strncasecmp() or strncmp() (and to support customized versions).

I was thinking more of using something like (if not the already 
existing)
 gtk_clist_set_compare_func (GtkCList *clist,
			    GtkCListCompareFunc  cmp_func)

> in general, i don't think we should provide default key-press-jump-focus
> (or whatever you wanna call it ;) especially since the column you
> want to match varies from application to application.

I don't agree on that. The user should get the hang of it in no time.
If the rows are sorted, match on sort_column. Else the first column
with text in it. (that's where gtk_clist_set_compare_func comes in)
It should be possible to disable this feature by setting the 
keyfocus_timeout to zero though.

> the proper way to implement this is probably by adding a new signal
> to clist that provides the key focus string built up over time,
> users can then take appropriate actions (like moving the focus or
> beeping if no match is found) in such a handler.

This feature is not for gtk users (i.e. programmers) but users of the 
gtk application.  Applications do not need recompiling to benefit from
this feature (my file selection dialogs are much more friendly already).
Further, the behavior of this feature should not depend on the
application as this will lead to inconsistency - mostly where most List 
boxes can't be scrolled by key press. Either is works or doesn't.  
If a gtk programmer wants some other behavior (which the app user
probably won't like) he can always subclass CList :-)

For me it's "default or leave it out". I see this as a look & feel
issue. It's almost like leaving it up to the developer to decide if 
scroll bars are needed or not in the CList.

> also, i don't see the usefullness in aborting after a certain timeout,

This is a must! We don't want to annoy the user.

> rather the key focus string should be reset if a non-letter key is
> pressed (cursor-up/down) or a mouse event occours such like button
> presses.

These the non letter key is a good one that will be added
(although the timeout usually would have gone off by then).  

The one with the mouse is tricky since we cannot assume that the mouse
pointer is within the CList. (Besides most users don't have three hands
to type
and move the mouse within the timeout :-)


> > +        g_free(clist->keyfocus_string);
> > +        clist->keyfocus_string = NULL;
> 
> i don't see you freeing this in the finalize() handler.

Opps! That pig in me!

> > +          }
> 
> is this a brace nesting contest? ;)

Just practicing GNU Bracing Style :-) 
Actually it's a TODO place holder.


-- 
Mudiaga Obada
mudi@obada.de