Re: Deprecations for 3.x
Am Wed, 12 May 2010 09:29:29 +0200 schrieb Cody Russell brats...@gnome.org: I think it would be kind of nice to deprecate GtkStatusbar. It's one of the more useless widgets we have, imo. It basically serves two purposes: 1/ Pushing and popping text messages. This is a really terrible way to communicate information to users, imo. 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. It just consumes precious vertical space without giving us much. / Cody I am curious, as GtkStatusbar is used in every second application, about your suggestions on how to replace it in the typical use cases. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On 05/12/2010 09:29 AM, Cody Russell wrote: I think it would be kind of nice to deprecate GtkStatusbar. It's one of the more useless widgets we have, imo. It basically serves two purposes: 1/ Pushing and popping text messages. This is a really terrible way to communicate information to users, imo. 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. 3/ Providing contextual information on what document the user is currently working on, eventually allowing some tweaks on a per-document basis. gedit's use case of GtkSideBar is 2/ and 3/: it uses the statusbar to display some properties of the current document (like language, indentation style, etc.) and invented GtkStatusArea for pushing important messages. In that regard, it would probably be nice to add some API in GtkStatusBar to cover the third use case mentionned here. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, May 12, 2010 at 11:44 AM, Christian Dywan christ...@lanedo.comwrote: I am curious, as GtkStatusbar is used in every second application, about your suggestions on how to replace it in the typical use cases. I don't actually have thoughts on this yet.. most of the apps I can think of that use statusbars don't really seem to be communicating useful information in statusbars using the push/pop API. xchat-gnome wastes precious pixels to show network lag, although apparently you can disable this in recent versions but it still seems completely pointless. gedit seems to do nice things in the statusbar, but by packing other widgets in.. not sure if they're using the text message push/pop API. Maybe apps should just be patched to remove useless statusbars, but I still wouldn't mind thinking about if there could be more useful APIs for this widget. The message pushing/popping really doesn't seem to be very useful IMO. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Mi, 12.05.2010 12:49, Cody Russell wrote: On Wed, May 12, 2010 at 11:44 AM, Christian Dywan christ...@lanedo.comwrote: I am curious, as GtkStatusbar is used in every second application, about your suggestions on how to replace it in the typical use cases. I don't actually have thoughts on this yet.. As GTK+ is supposed to be a general purpose toolkit, removing the status bar widget seems like a bad idea to me. Policies ala should not use status bar for use-case XY should go into a per-project HIG, not into the toolkit. Holger ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote: 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. Is anybody actively working on this? Are there ways of doing this that don't a) require vertical padding a'la GtkStatusBar, or b) unilaterally cover up whatever is in the bottom right corner? A lot of document-viewing applications have a GtkScrolledWindow that hit the bottom right. If both the vertical and horizontal scrollbars are visible, there's some really nice dead space there. But if only the vertical is visible (very common), you certainly don't want to cover up the scroll-down button. Could GtkScrolledWindow know that there's a resize grip there and do something like this: +--+ |^ | || | || | || | || | |v | |//| +--+ I suppose we could add API like always_show_blank_corner, but it would be really nice if it were automatic. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, May 12, 2010 at 4:24 PM, Shaun McCance sha...@gnome.org wrote: On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote: 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. Is anybody actively working on this? Are there ways of doing this that don't a) require vertical padding a'la GtkStatusBar, or b) unilaterally cover up whatever is in the bottom right corner? A lot of document-viewing applications have a GtkScrolledWindow that hit the bottom right. If both the vertical and horizontal scrollbars are visible, there's some really nice dead space there. Yeah, I've got some code for this. I've got some I was working on as part of client-side-decorations, and I've also got some that's independent of that branch. I'm doing some merging and cleaning up of csd code, I'll get some new stuff pushed up into git soon. I'm in Belgium right now, but I'm planning to do this ASAP when I get home next week. For most Gnome and GTK apps, developers are encouraged to use a certain amount of padding, so the grips don't get in the way. But as you point out, scrolled windows are an exception to that and usually go straight up to the window border. My corner-grip branch (without csd) I think does something kind of ugly, and the scrollbar checks the toplevel GtkWindow to find out if it's got a corner resize grip and positions/sizes itself accordingly. It feels slightly hackish, but it looks and behaves find imo. There may be some other situations where something similar needs to be done though. But yeah, if an app fails to set some padding and has, for example, a text editor widget then the corner resize grip would draw over it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
