Re: Making GtkEntry::scroll-offset read/write?
Il Fri, 8 Feb 2013 09:38:44 -0500 Matthias Clasen scrisse: > Would be nice to have such a validating entry subclass in GTK+ itself > too; if you are willing to consider a move from C++ to C. I've a custom widget that performs regex validation providing visual feedback [1] in a similar way of what HRegExEntry does for GTK#. If interested I can GTKfy the code and open a feature request in bugzilla. Ciao. -- Nicola [1] http://dev.entidi.com/p/ntdisp/source/tree/master/src/gtk3/ntd-regex-entry.c [2] http://code.google.com/p/holly-gtk-widgets/wiki/HRegExEntry ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Making GtkEntry::scroll-offset read/write?
On Thu, Feb 7, 2013 at 7:06 PM, David Trowbridge wrote: > I'm trying to port libview (http://view.sourceforge.net/) to Gtk+ 3.x, and > something that I've run into is that the way that view::FieldEntry sets > tabstops into the parent entry's PangoLayout causes the cursor position logic > inside GtkEntry to break quite a bit. The way it's solved today is to have a > notification callback on the scroll-offset field and always set it back to > zero. This was always kind of hinky because the property is theoretically > read-only, but it can't be done at all now that the property is sealed. > > Admittedly, FieldEntry's implementation is pretty ugly. If there's a better > way to implement this widget with all the modern improvements to GTK, I'd > love to hear suggestions. >From what I understand, setting the scroll offset back is just a workaround for lack of sufficient hooks into the entry cursor logic to implement this ? So, maybe we should look at what you need there. In any case, directly poking at the entrys PangoLayout sounds nasty. Would be nice to have such a validating entry subclass in GTK+ itself too; if you are willing to consider a move from C++ to C. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Making GtkEntry::scroll-offset read/write?
I'm trying to port libview (http://view.sourceforge.net/) to Gtk+ 3.x, and something that I've run into is that the way that view::FieldEntry sets tabstops into the parent entry's PangoLayout causes the cursor position logic inside GtkEntry to break quite a bit. The way it's solved today is to have a notification callback on the scroll-offset field and always set it back to zero. This was always kind of hinky because the property is theoretically read-only, but it can't be done at all now that the property is sealed. Admittedly, FieldEntry's implementation is pretty ugly. If there's a better way to implement this widget with all the modern improvements to GTK, I'd love to hear suggestions. Thanks, -David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On Fri, Feb 8, 2013 at 3:05 AM, Torsten Schoenfeld wrote: > Won't gobject-introspection silently turn the (transfer full) annotation > into (transfer none) due to the special handling for GInitiallyUnonwed > descendants? > It seems to pick it up correctly. The problem was actually the rename annotation doesn't work for vfuncs. Also, the list in the bug is missing Gtk.CellRenderer.start_editing (the > vfunc, not the method). Ack, sorry, I will add an additional note. -Simon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On 08.02.2013 04:08, Simon Feltman wrote: I've created a ticket and proposed patch for GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=693393 I am looking for feedback to see if this type of thing is even acceptable and if it's worthy of further pursuit. Won't gobject-introspection silently turn the (transfer full) annotation into (transfer none) due to the special handling for GInitiallyUnonwed descendants? Also, the list in the bug is missing Gtk.CellRenderer.start_editing (the vfunc, not the method). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
