GLib 2.12.12 released
GLib 2.12.12 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.12/ http://download.gnome.org/sources/glib/2.12/ glib-2.12.12.tar.bz2 md5sum: 0b3a42098243d054475ff6eb51ed2be1 glib-2.12.12.tar.gzmd5sum: 6c6a61e4b08fb4b110ca7953f71c8b5e This is a bug fix release in the 2.12 series. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.12.11 to GLib 2.12.12 = * Bug fixes: 418862 g_base64_decode will give critical warning when first par... 356843 make check fails if /bin/sh is pdksh 418217 g_unichar_toupper/_totitle broken for single to multiple ... 432895 param_string_validate() frees and modifies static strings 420686 g_key_file_to_data alters original data * Translation updates: (da,es,eu,gl,ja,ro,ru,sr, [EMAIL PROTECTED],ta,zh_CN) A list of all the fixed bugs can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=418862,420686,418217,356843,432895 Thanks to everybody who contributed to this release: Halton Huo Chris Wilson Denis Jacquerye Paul Jarc Tor Lillqvist Michael Natterer Matthias Clasen May 1, 2007 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk on directfb problem
Hi, I just posted in directfb mailing list without answer :). This is a brief of the problem: I'm trying to change the colormap only for a widget but I think that exists only one surface for rendering. I don't understand why during the inizialization the directfb doesn't create a surface that matches my frame buffer setting. Example: If I set RGB16 in the directfbrc, I hope that the surface has the same mapping. The problem can not be solved by setting to RGB16 because other things don't work correctly. // window visual = gdk_directfb_visual_by_format (DSPF_RGB16); cmap = gdk_colormap_new (visual, FALSE); gtk_widget_push_colormap (cmap); main_window = gtk_window_new(GTK_WINDOW_TOPLEVEL); If I set this one my gdk_draw_pixmap is fast, but text and icons have trouble otherwise the application is slow. Is there an answer? Regards Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
On Tue, 2007-05-01 at 14:41 +0100, Damon Chaplin wrote: [...] - a markup for building trees of items would certainly be handy, just as glade is handy Ideally GtkBuilder would support this. Most of the standard items are configured with GObject properties. The only issue is that GObject doesn't have generic support for child properties, so GtkBuilder would need special code to handle them. Drifting slightly off-topic here... these GtkBuilder patches[1] do have generic support for child properties, plus, if we want to get the ball rolling, its really a sinch to implement a GContainerIface and implement it by GtkContainer without breaking any api/abi and getting container/child support right into GObject... things may have been stagnating with the lack of core gtk+ maintainers but for my part I'm still ready to lay the effort down for this item. Cheers, -Tristan [1]http://bugzilla.gnome.org/show_bug.cgi?id=383035 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 17:03 +0100, Peter Clifton wrote: I've found myself wanting GObject derived GList. The idea is to have a list of things with some GType, and make the API which modifies that list emit changed, deleted, inserted signals, etc. I coded a GObject derived class to do most of this. One thing missing with GList is type safety of course, but if you want, you can add run-time type safety with a class around it. That sounds a bit like you want an MVC data model in GLib. For instance, we could move GtkTreeModel and its associated model parts down. I've been wanting that for a while now, personally. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On Tue, 2007-05-01 at 12:34 -0500, Michael Lawrence wrote: Hi, I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Nod, very interesting project also IMO, unfortunate that we dont have the resources to bring all the good ideas to completion ;-) Here are somethings IMHO need to be considered before introspection is ready for prime-time: 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. I dont know much about this project status but I think some people have already managed to generate gobject library based language bindings based on the description format - from what I understood its just the generation of the GIDL description from source files that was missing from the project. But on that note, one thing I thought would be a really cool thing to do with this stuff is translate source code statements from one language to another (or mostly from C to another) - particularly, I was hoping that Anjuta could use this to generate a signal handler stub in the language of choice when a user added a signal to an object in the glade plugin... anyway that was my pie in the sky idea ;-) Anyway, ^5 to anyone who actually writes the code :) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
Hi, Michael Lawrence wrote: I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Rob Taylor started working on it again, see http://bugzilla.gnome.org/show_bug.cgi?id=363228 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. b) To support run-time introspection by accessing a binary blob of metadata. Combining a) and b) I would say part of the goal is run-time binding generation, i.e. right now most of the bindings involve a couple megs of static function stubs, ideally this could be replaced with perhaps a couple hundred K of generic code that built binding objects on demand (much as e.g. dbus-python works) 2) How is the GIDL/metadata generated? The Vala project has some scripts that generate GIDL from header files. This is obviously a difficult task, because things like memory management, in/out parameters, etc cannot be automatically derived from header files. Thus, human annotation is necessary. My preference is this pipeline: - Scan headers (or code in other language) and generate a base IDL file (or in-memory parse tree) - Allow magic comments in the headers to modify the IDL that would otherwise have been created. Similar to gtk-doc comments. - Allow a merge file, a lookaside IDL file that overrides or adds to the scanned IDL - similar to magic comments but not in the C code itself - Output (or keep in-memory parse tree, as appropriate) the resulting IDL - Output a binary type lib containing the same information A pipeline should also be possible where you write the IDL file first and then a C header is generated. This is useful when the IDL file is part of a spec or shared between multiple apps. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Michael Lawrence wrote: I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Rob Taylor started working on it again, see http://bugzilla.gnome.org/show_bug.cgi?id=363228 Ok thanks for pointing that out. The original bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=139486 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. b) To support run-time introspection by accessing a binary blob of metadata. Combining a) and b) I would say part of the goal is run-time binding generation, i.e. right now most of the bindings involve a couple megs of static function stubs, ideally this could be replaced with perhaps a couple hundred K of generic code that built binding objects on demand (much as e.g. dbus-python works) My thoughts as well. 2) How is the GIDL/metadata generated? The Vala project has some scripts that generate GIDL from header files. This is obviously a difficult task, because things like memory management, in/out parameters, etc cannot be automatically derived from header files. Thus, human annotation is necessary. My preference is this pipeline: - Scan headers (or code in other language) and generate a base IDL file (or in-memory parse tree) - Allow magic comments in the headers to modify the IDL that would otherwise have been created. Similar to gtk-doc comments. I made some suggestions along those lines a while ago on the GtkDocFuture page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the bottom of the page. Michael - Allow a merge file, a lookaside IDL file that overrides or adds to the scanned IDL - similar to magic comments but not in the C code itself - Output (or keep in-memory parse tree, as appropriate) the resulting IDL - Output a binary type lib containing the same information A pipeline should also be possible where you write the IDL file first and then a C header is generated. This is useful when the IDL file is part of a spec or shared between multiple apps. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
Michael Lawrence wrote: On 5/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Michael Lawrence wrote: I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Rob Taylor started working on it again, see http://bugzilla.gnome.org/show_bug.cgi?id=363228 Ok thanks for pointing that out. The original bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=139486 Hmm, I'll try and link all these together in some sensible dependancy. 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. b) To support run-time introspection by accessing a binary blob of metadata. Combining a) and b) I would say part of the goal is run-time binding generation, i.e. right now most of the bindings involve a couple megs of static function stubs, ideally this could be replaced with perhaps a couple hundred K of generic code that built binding objects on demand (much as e.g. dbus-python works) My thoughts as well. Ditto :) 2) How is the GIDL/metadata generated? The Vala project has some scripts that generate GIDL from header files. This is obviously a difficult task, because things like memory management, in/out parameters, etc cannot be automatically derived from header files. Thus, human annotation is necessary. My preference is this pipeline: - Scan headers (or code in other language) and generate a base IDL file (or in-memory parse tree) - Allow magic comments in the headers to modify the IDL that would otherwise have been created. Similar to gtk-doc comments. I made some suggestions along those lines a while ago on the GtkDocFuture page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the bottom of the page. Yeah, hmm, my take is that the introspection data should live in the code, and gtk-doc should pick these up for the docs (just like signals and object hierarchy). I'll be able to tell more after hashing out my prototype. One point I'm interested in from that POV: are there any plans for gtk-doc to document signals/properties on interfaces? (e.g. by instantiating objects pretending to implement them?) Michael - Allow a merge file, a lookaside IDL file that overrides or adds to the scanned IDL - similar to magic comments but not in the C code itself - Output (or keep in-memory parse tree, as appropriate) the resulting IDL - Output a binary type lib containing the same information A pipeline should also be possible where you write the IDL file first and then a C header is generated. This is useful when the IDL file is part of a spec or shared between multiple apps. I really don't want force people not coding dbus applications down this path of IDL-driven development. I'm aiming to get introspection such that, if need be, you could code it by hand but have some useful tools and macros to help make life easier. The current plan for dbus-glib is to have a tool that generates introspectable GInterfaces from annotated xml (or dbus-doc xml and a separate glib type annotation). The provider object would implement the Ginterface, the remote end could then be a factory-produced object implementing the GInterfaces corresponding to the dbus interfaces on the object. Again, we seem to be discussing dbus-glib issues in the wrong forum, so I've cc'd in the dbus mailing list. Thanks, Rob Taylor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.12.12 released
GLib 2.12.12 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.12/ http://download.gnome.org/sources/glib/2.12/ glib-2.12.12.tar.bz2 md5sum: 0b3a42098243d054475ff6eb51ed2be1 glib-2.12.12.tar.gzmd5sum: 6c6a61e4b08fb4b110ca7953f71c8b5e This is a bug fix release in the 2.12 series. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.12.11 to GLib 2.12.12 = * Bug fixes: 418862 g_base64_decode will give critical warning when first par... 356843 make check fails if /bin/sh is pdksh 418217 g_unichar_toupper/_totitle broken for single to multiple ... 432895 param_string_validate() frees and modifies static strings 420686 g_key_file_to_data alters original data * Translation updates: (da,es,eu,gl,ja,ro,ru,sr, [EMAIL PROTECTED],ta,zh_CN) A list of all the fixed bugs can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=418862,420686,418217,356843,432895 Thanks to everybody who contributed to this release: Halton Huo Chris Wilson Denis Jacquerye Paul Jarc Tor Lillqvist Michael Natterer Matthias Clasen May 1, 2007 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
On Thu, 2007-04-26 at 23:40 +0200, Kristian Rietveld wrote: I was actually planning to push in (x, y) relative to the widget-window. The new tooltips code is supposed to do the same (however that documentation says otherwise at this moment, it will be fixed RSN). If we use this, the window in question will also be known, since the coordinates will always be relative to widget-window. Most widgets handle this already and usually have code/functions to translate from widget-window to something else. If they have not, this functionatily should be added to those widgets IMHO. Hmm, if you make it relative to widget-window, I suppose it's okay. It's cumbersome when you have more than one subwindow, though (we have had this inconvenience since the DnD API was introduced). Passing a GdkEventButton instead does not really seem beneficiary to me; we cannot use the original GdkEventButton we get from the button-press since the event time and coordinates will likely be wrong, so we will end up with a synthesized event anyway. Another point: for tooltips we don't pass in motion events or something similair either ... The point is that you *do* need a timestamp that makes sense :) Let's say you tap-and-hold; the program will likely want to pop up a tooltip-like window (or popup menu or similar) and those require a timestamp. It could simply be the timestamp from the initial tap, or from the latest motion event that is still considered part of the arming period. I am not really sure if having different tap-n-hold actions for different mouse buttons is worth supporting. I think I would prefer tap-n-hold to run the same action for any button, since it's about tapping and holding something on the screen, whether this is a stylus, a finger or the back of wacom pen is left in the middle. Pen computers will likely not care since the stylus has no buttons, but for a Wacom tablet I can very well imagine a tap-and-hold action that is different for the brush than for the eraser. Maybe such sophisticated apps will be content implementing tap-and-hold by hand anyway :) I don't think having widget-specific tap-n-hold animations is a good idea; I would say that this is really a theme issue and it would be good if every tap-n-hold operation looks the same the to user. You have two tap-and-hold actions: pop up a menu and pop up a tooltip with extra info. Should those have the same I'm armed animations? Another questionable point is whether we should allow for tap-n-hold actions to be triggered via the keyboard. This is probably a good thing to do and would involve adding a gboolean triggered_by_keyboard to the signal signature, just like the new tooltips API has. Does anyone have better suggestions here? But then you would need to bind a key to the tap-and-hold action, and that gets messy. I think that depends on the way you want to implement it. For tooltips you can activate the show-help binding which will display the tooltip for the focussed widget immediately, without any delay. For tap-n-hold I was thinking of something similiar, a keyboard shortcut which will activate a binding -- this binding will trigger the tap-n-hold action immediately (iff the query succeeded of course). Oh, so this would be global? Sort of tap-and-hold-keysym = FunkyKey in your ~/.gtkrc? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/1/07, Rob Taylor [EMAIL PROTECTED] wrote: Michael Lawrence wrote: On 5/1/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Michael Lawrence wrote: I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Rob Taylor started working on it again, see http://bugzilla.gnome.org/show_bug.cgi?id=363228 Ok thanks for pointing that out. The original bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=139486 Hmm, I'll try and link all these together in some sensible dependancy. 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. b) To support run-time introspection by accessing a binary blob of metadata. Combining a) and b) I would say part of the goal is run-time binding generation, i.e. right now most of the bindings involve a couple megs of static function stubs, ideally this could be replaced with perhaps a couple hundred K of generic code that built binding objects on demand (much as e.g. dbus-python works) My thoughts as well. Ditto :) 2) How is the GIDL/metadata generated? The Vala project has some scripts that generate GIDL from header files. This is obviously a difficult task, because things like memory management, in/out parameters, etc cannot be automatically derived from header files. Thus, human annotation is necessary. My preference is this pipeline: - Scan headers (or code in other language) and generate a base IDL file (or in-memory parse tree) - Allow magic comments in the headers to modify the IDL that would otherwise have been created. Similar to gtk-doc comments. I made some suggestions along those lines a while ago on the GtkDocFuture page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the bottom of the page. Yeah, hmm, my take is that the introspection data should live in the code, and gtk-doc should pick these up for the docs (just like signals and object hierarchy). I'll be able to tell more after hashing out my prototype. I'm thinking that gtk-doc-like markup may be a more convenient way to express some of the metadata. There is already too much code required to create a GObject class. Then again, meta-languages like Vala would take care of this stuff behind the scenes anyway. I'll wait to see your prototype. One point I'm interested in from that POV: are there any plans for gtk-doc to document signals/properties on interfaces? (e.g. by instantiating objects pretending to implement them?) Michael - Allow a merge file, a lookaside IDL file that overrides or adds to the scanned IDL - similar to magic comments but not in the C code itself - Output (or keep in-memory parse tree, as appropriate) the resulting IDL - Output a binary type lib containing the same information A pipeline should also be possible where you write the IDL file first and then a C header is generated. This is useful when the IDL file is part of a spec or shared between multiple apps. I really don't want force people not coding dbus applications down this path of IDL-driven development. Some sort of interface description is required for language bindings as well, which means this applies to pretty much every GObject-based library. I'm aiming to get introspection such that, if need be, you could code it by hand but have some useful tools and macros to help make life easier. The current plan for dbus-glib is to have a tool that generates introspectable GInterfaces from annotated xml (or dbus-doc xml and a separate glib type annotation). The provider object would implement the Ginterface, the remote end could then be a factory-produced object implementing the GInterfaces corresponding to the dbus interfaces on the object. Again, we seem to be discussing dbus-glib issues in the wrong forum, so I've cc'd in the dbus mailing list. Thanks, Rob Taylor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
What about auto mounting things such as USB devices? Are we going to
have an abstraction around those, where you could refer to device by
uuid or something?
`uuid-of-device://path/to/file`
This uuid could be private to GVFS and there would be a lookaside table
uuid - {USB_STICK, Sandisk, Cruzer Micro, 4GB, Raptor,
FALSE /* is removable */,
/org/freedesktop/Hal/device/volume_uuid_1234}
allowing you to put up dialogs such as
+--+
| The application Frobnicator is trying to access a file on a |
| device that is not available right now. To continue please |
| attach the device|
| |
| logo 4GB file system labeled Raptor|
| Sandisk Cruzer Micro (in small grey font) |
| |
| [Cancel] [Continue] |
+--+
(for removable media it would say insert the media rather than
attach the device)
This should be a piece of cake to do (assuming HAL) and if people think
it's a good idea (I'm not entirely convinced it is) I'd be happy to take
a stab at it when GVFS is ready for this. Alex?
David
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
