RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. One recent example is on Planet GNOME right now[1]. Other examples were posted on Planet GNOME in the past, and still exist in applications like OpenOffice.o

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

Am Mon, 25 Aug 2008 09:00:05 +0200 schrieb Mathias Hasselmann <[EMAIL PROTECTED]>: > Hi, > > The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES > and GTK_STOCK_NO encourages creation of horrible user interfaces. One > recent example is on Planet GNOME right now[1]. Other examp

Re: Lacking of a ref-counted string.

On Sat, 23 Aug 2008 09:58:12 -0400 "Havoc Pennington" <[EMAIL PROTECTED]> wrote: > If you're talking about converting existing APIs to refcounted > strings, that's a very different proposal from just adding some kind > of refcounted string feature. It would break thousands of apps, or > else dupli

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

2008/8/25 Mathias Hasselmann <[EMAIL PROTECTED]>: > Hi, > > The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES > and GTK_STOCK_NO encourages creation of horrible user interfaces. What a terrible idea! First, GTK_RESPONSE_YES and GTK_RESPONSE_NO do not imply much about user int

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

Morten Welinder wrote: 2008/8/25 Mathias Hasselmann <[EMAIL PROTECTED]>: Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. [..] (For the record, I seem to have lots of _RESPONSE_ lying around, but no

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

At the least, any Yes/No stuff in the API reference documentation should have a note saying that they are generally a bad idea, probably with a link to the GNOME HIG. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing li

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

Am Mon, 25 Aug 2008 14:12:38 +0200 schrieb Murray Cumming <[EMAIL PROTECTED]>: > At the least, any Yes/No stuff in the API reference documentation > should have a note saying that they are generally a bad idea, > probably with a link to the GNOME HIG. If we want to keep people from doing stupid t

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

On Mon, Aug 25, 2008 at 8:22 AM, Christian Dywan <[EMAIL PROTECTED]> wrote: > Am Mon, 25 Aug 2008 14:12:38 +0200 > schrieb Murray Cumming <[EMAIL PROTECTED]>: > >> At the least, any Yes/No stuff in the API reference documentation >> should have a note saying that they are generally a bad idea, >> p

Inter process communication.

Hi, How can two Gtk based top level windows communicate with each other using (message passing)? How can we add a user-defined signal and how can we emit this signal? Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.

RE: [Vala] Lacking of a ref-counted string.

I think it has what you ask for, if a class doesn't inherit from gobject then internally it inherits from gtypeinstance which is what you said. Sometimes people don't distinguish between the two, though. However I want compact non-gobject non-gtype instance (I want I want... Never satisifed wit

Re: Lacking of a ref-counted string.

On Wed, 2008-08-20 at 21:07 -0400, Havoc Pennington wrote: > Hi, > > On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > > First, it is very difficult to manage a string without a reference > > count. The current vala implementation is to assume that strings are > > immutable, an

Re: Lacking of a ref-counted string.

On Wed, 2008-08-20 at 21:18 -0400, Colin Walters wrote: > On Wed, Aug 20, 2008 at 9:07 PM, Havoc Pennington <[EMAIL PROTECTED]> wrote: > > > > What about a libvala? I guess vala is supposed to have this property > > that it doesn't create dependencies in distributed tarballs, but that > > design go

Re: Lacking of a ref-counted string.

On Wed, 2008-08-20 at 21:49 -0400, Colin Walters wrote: > On Wed, Aug 20, 2008 at 9:39 PM, Jamie McCracken > <[EMAIL PROTECTED]> wrote: > > > > Are you saying Yacc/Bison and lex/flex source files which generate c > > files are also incompatible with GPL? > > Of course not; it's perfectly valid in

Re: Inter process communication.

You might want to look at DBus: http://freedesktop.org/wiki/IntroductionToDBus 2008/8/19 Yasir <[EMAIL PROTECTED]> > Hi, > > How can two Gtk based top level windows communicate with each other using > (message passing)? > How can we add a user-defined signal and how can we emit this signal? > > T

getting and setting a pointer to a c++ class in a multi-level glib object hierarchy

folks, hi, i have a particularly horrendous implementation requirement that i can't quite get my head round and need some gobject advice for the webkit-gtk implementation to provide DOM access (which will then percolate to pywebkitgtk). webkit's c++ DOM object hierarchy is multi-level, is inherited

Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}

Am Montag, den 25.08.2008, 14:12 +0200 schrieb Murray Cumming: > At the least, any Yes/No stuff in the API reference documentation should > have a note saying that they are generally a bad idea, probably with a > link to the GNOME HIG. And also, please mention that some languages don't even have p

[REMINDER] GTK+ Team Meeting - August 26th

hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. the points are: o 2.14 release o non-x11 backends readiness o 2.90/3.0 plan o miscellanea eventual changes will be notified on the wik