Re: GNOME 3 cleanup status update
On Mon, Jan 18, 2010 at 11:54 AM, Tor Lillqvist t...@iki.fi wrote: In general I have the feeling that the GTK+ stack on Windows is on a downward slope. Each new release introduces new stuff that never gets fully implemented/tested for Windows, like the client-side windows. Note that I am not blaming anybody, not even myself, just stating the obvious. It might well be that GTK+ 2.16 and GLib 2.20 was the most usable combination there will be, until somebody gets the inspiration / resources to dig into it. Just meant to second Tor here, but from a Mac OS X support point of view. At the moment I don't know how well gobject-introspection works on the Mac. I don't have the resources to look into this in the near future either. It is possible to get glib, pango, gtk+ to build from git master without having gobject-introspection built with some m4 file copying, but even this has caused numerous issues for people building the gtk+ stack from git. I guess the same holds in case glib gets a hard dependency on dbus ... To repeat Tor: not blaming anybody, but just stating the obvious ... regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libnotify
On Wed, Aug 01, 2007 at 12:51:22AM -0700, Christian Hammond wrote: I would love to get libsexy's widgets bundled into GTK+, but that will require some extensions to widgets such as GtkEntry and GtkLabel to allow subclasses to better hook into the PangoLayouts of the widgets (by providing a signal indicating that the layout has been created and can now be modified). This would get rid of some of the hacks we have to use in libsexy, which would increase the chances of getting into GTK+. Any help would be appreciated here. widespread they both are these days? Or just allow libsexy and use that as motivation to getting GTK+ in shape to be able to include its widgets? An item called libsexy cherrypicking has been on the list of features for GTK+ 2.12, but unfortunately didn't make it. If anybody wants to pick up the ball on this, and create a patch against GTK+ that adds the most useful libsexy features (I am thinking of things like adding an icon inside GtkEntry, etc) to GTK+, that would be great. regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote: There's also a new GtkTooltip object. Could we have some more information about how this should be used and if it replaces any existing API, please? Sure ;) As Matthias pointed out in one of his other mails, GTK+ 2.12 has a brand-new API for doing tooltips, replacing the aging GtkTooltips object. There are several ways for showing tooltips using the new API, increasing in complexity as the complexity of the wished tooltip increases: 1. If everything you need is a tooltip displaying a simple text string, with or without Pango markup, the only thing you have to do is just setting the tooltip-markup property. 2. When you need a tooltip with a little more fancy contents, like adding an image, or you want the tooltip to have different contents per GtkTreeView row or cell, you will have to do a little more work: - Set the has-tooltip property on GtkWidget to TRUE, this will make GTK+ monitor the widget for motion and related events which are needed to determine when and where to show a tooltip. - Connect to the query-tooltip signal on GtkWidget. This signal will be emitted when a tooltip will have to be shown. The signature is: gboolean (* query_tooltip) (GtkWidget *widget, gintx, ginty, gbooleankeyboard_tooltip, GtkTooltip *tooltip); The arguments are pretty much straightforward, and here we see where the new GtkTooltip object comes to play. The GtkTooltip is the object that we are about to display as a tooltip, and can be manipulated in your query-tooltip callback using functions like: void gtk_tooltip_set_icon (GtkTooltip *tooltip, GdkPixbuf *pixbuf); there are likewise functions for setting the tooltip's markup, setting an image from a stock icon or even for putting in a custom widget. Important is the return value of query-tooltip: when you return TRUE the GtkTooltip will be shown, when you return FALSE it will not be shown. 3. In the, probably, rare case where you want to have even more control over the tooltip that is about to be shown, you can set your own GtkWindow which will be used as tooltip window. This works as follows: - Set has-tooltip and connect to query-tooltip as under 2). - Use gtk_widget_set_tooltip_window() to set a GtkWindow created by you as tooltip window. - In the query-tooltip callback you can access your GtkWindow using gtk_widget_get_tooltip_window() and manipulate as you wish. The semantics of the return value of query-tooltip are exactly the same as with 2): TRUE will show the tooltip window, FALSE will not show it. In the GTK+ source code you will find a test app testing all of the above methods in gtk+/tests/testtooltips.c. There are examples for simple tooltips on buttons (also insensitive buttons!), tooltips on GtkTreeView rows, tooltips on GtkTextView tags and a small example with tooltips on specific areas of a GtkDrawingArea. (Yes, I know the tree view example is a little broken -- it will be fixed RSN). Some small details are still left to be worked out; think of improving tooltips positioning, probably popup-tooltip-directly-on-demand and at some later stage greater flexibility and customizability. Watch gtk-devel-list for the latest news ;) I hope this gives you enough information to get started! regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, Jul 19, 2006 at 11:36:28AM +0100, Bill Haneman wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... Another thing which needs to be done there is for example setting up the URI handler for GtkLinkButton. There'll always be some things which need to be initialized in a way depending on the platform. As for the URI handler, the handler will differ on UNIX, Win32, OS X, etc. During GUADEC Matthias and I talked about maybe having support for some kind of runtime modules with one for each backend/platform. The module would contain a function that initializes stuff specific to that platform and GTK+ will run that during initialization. Just like what happens with the file system modules right now, we could ship a default simple module for GTK+-only apps on Linux and have some other GNOME package provide a GNOME runtime module, which initializes a11y, sets the bugzilla hooks, etc. Just some thoughts, no real concrete ideas ... regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
