Am Wed, 8 Sep 2010 07:31:58 -0400
schrieb Matthias Clasen matthias.cla...@gmail.com:
On Wed, Sep 8, 2010 at 7:10 AM, Christian Dywan
So a possible idea would be to turn GtkEditable into a clipboard
interface, where entry specific features are removed.
Which features do you consider
On Wed, Sep 8, 2010 at 7:10 AM, Christian Dywan
So a possible idea would be to turn GtkEditable into a clipboard
interface, where entry specific features are removed.
Which features do you consider entry-specific ? As far as I'm
concerned, the editable interface could just be implemented by
So,
I've been busy the last few days making all expose events use Cairo
contexts exclusively and while doing that had to wander into the
cobwebbed regions of Gtk code and other exciting places. While doing
that a few questions about general cleanup occured to me:
1) How to handle old-school
Hi Benjamin,
Great that you bring this up for discussion.
I think another trade-off you want to make in this discussion is what
amount of backwards compatibility you want to have with GTK 2.x. In
the original GTK+ 3 plans a few years ago it was argued to have a very
smooth migration path by
I'd say a useful emphasis is to focus on enabling deprecation by
adding the new way, rather than on actually removing the old way.
e.g. on my pixbuf patch, the changes allow dropping any actual use of
the old format. But going on a compile with
GDK_PIXBUF_DISABLE_DEPRECATED spree just in pixbuf
