Re: A model/buffer for GtkEntry
- From: Christian Dywan <christian imendio com>
- To: gtk-devel-list gnome org
- Cc: stef memberwebs com
- Subject: Re: A model/buffer for GtkEntry
- Date: Fri, 27 Mar 2009 01:02:03 +0100
Am Thu, 26 Mar 2009 21:38:26 +0000 (UTC)
schrieb Stef Walter <stef-list memberwebs com>:
> Tristan Van Berkom wrote:
> >> * gtk_entry_buffer_get_visibility
> >> * gtk_entry_buffer_set_visibility
> >> * gtk_entry_buffer_get_invisible_char
> >> * gtk_entry_buffer_set_invisible_char
> >> * gtk_entry_buffer_unset_invisible_char
> >> * gtk_entry_buffer_have_invisible_char
> >
> > I have a feeling these apis should be handled by
> > the view (multiple entries on the same buffer
> > should be able to control these attributes independently).
>
> That may be the case, and I thought about this myself. One thing in
> favor of doing the conversion of 'real text' -> 'display text' in the
> model is that it allows subclassed models to do some quite interesting
> stuff in the conversion.
>
> For example, you could do what cell phones do as you enter a phone
> number: format it automatically as the user enters it. I haven't
> explored this idea properly though, but I believe it would be good to
> consider while implementing this model infrastructure for GtkEntry.
>
> > Rather than creating a whole new class, is there any reasons
> > why a GtkTextBuffer doesnt satisfy the needs of a GtkEntry ?
>
> I guess the same reason why GtkEntry isn't itself based on
> GtkTextView: It's too heavy weight and far more complex than what is
> needed for a single line text field?
Hey,
this looks a little bit more complex than it should be, from my first
impression anyway. Essentially I would think you need this kind of
'workflow' in the application code, once you have a buffer implemented:
entry = gtk_entry_new ();
buffer = gnome_keyring_entry_buffer_new ();
gtk_entry_set_buffer (GTK_ENTRY (entry), buffer);
g_object_unref (buffer);
You should not have to care any more than this about the buffer you are
using. It should just work.
And the buffer itself, as you said, should be an interface or a
subclass, with a number of virtual methods for obtaining, storing and
displaying the stored text.
That way all text storage related code will be hidden in GtkEntryBuffer
and the lot of GTK developers won't even notice the difference.
Just my 2 pfennig,
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]