About modal dialog windows
My question in about the differences of behaviour between the modal windows created by gtk_message_dialog_new() and gtk_dialog_new_with_buttons(). I was looking to gtk-demo, the Dialog and message boxes example. In the example, a message dialog and an interactive dialog are generated by clicking the appropriate button. In the source code both dialogs are defined GTK_DIALOG_MODAL. Now, if another window comes to the front, if i click on the main window again, i'm able to reshow again both the main window and the interactive dialog. The same doesn't happen on the message dialog. I click on the main window but only the main windows comes back to the front. the message dialog remains on the background. This sounds strange to me beacuse a modal window should be tightly linkedto the main window: if i put it on the background or the foreground i expect that both the main window and the message window share the same destiny. What's the reason for this different behaviour beetween the windows generated by gtk_message_dialog_new() and gtk_dialog_new_with_buttons()? Is there any way to have a gtk_message_dialog that comes to the foreground togheter with the main window? (it's very annoying to search for a lost message window under other windows. Moreover, being a modal message dialog, the main application seems to be stuck, while in reality, it's only waiting that you click on the message dialog that it's still in the background). Thanks for your help, Marco ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About modal dialog windows
On Wed, May 02, 2007 at 08:40:42AM +0200, Marco Randazzo wrote: My question in about the differences of behaviour between the modal windows Please don't use modal dialog boxes. They tend to upset the users... Very often the user configure the window manager so that modal boxes/windows need a cursor placement and that is *extremly* anoying! -- Göran Hasse Göran Hasseemail: [EMAIL PROTECTED] Tel: 08-6949270 Raditex AB http://www.raditex.se Planiavägen 15, 1tr Mob: 070-5530148 131 34 NACKA, SWEDEN OrgNr: 556240-0589 VAT: SE556240058901 -- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Adding Text to a widget from a button_press_event Or Pop Up window from a time event.
Hi everyone. I don't if is it possible but.. I would like add text everytime i do a button_press_event on a widget(in this case a drawing area), in a text area or what ever that everytime clicks on it, writes the position of the event mean... a history of the clicks im doing of my drawing area. Actually i have a pop up window everytime I click on the drawing area but its not useful cuz quickly the screen get full of annoying popup windows. Another method Im thincking is a time event. I mean, stop the cursor on x,y of the screen.for maybe 2 seconds and this pops up a window telling the x,y information and when you move(change the cursor position) dissapears the the popup window. Exist any widget like this I was looking and in gtk+ it seems like doesnt exits. Anyone has done something like this??? Every tip it would be great. Thank you very much. Nahuel -- View this message in context: http://www.nabble.com/Adding-Text-to-a-widget-from-a-button_press_event-Or-Pop-Up-window-from-a-time-event.-tf3683031.html#a10294112 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.10.12 released
GTK+ 2.10.12 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.10/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/ gtk+-2.10.12.tar.bz2 md5sum: cf969c62134c662ff07e64613ed6c11f gtk+-2.20.12.tar.gzmd5sum: 58787b04190fbf99012460ff79019a46 This is a bug fix release in the 2.10 series. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.10.11 to 2.10.12 * Fixed bugs: 379414 file chooser warnings when changing path in the entry 418585 GtkFileChooserDefault sizing code is not DPI independent 419568 Crash in search if start with special letter 435062 build dies with icon cache validation 379399 Segfault to call gtk_print_operation_run twice. 387889 cups backend has problems when there are too many printers 418531 invalid read to gtkicontheme.c gtk_icon_theme_lookup_icon... 423916 crash in color scheme code 424042 Segmentation fault while quickly pressing Alt+arrows 415260 Protect against negative indices when setting values in G... 419171 XGetVisualInfo() may not set nxvisuals 128852 Gdk cursors don't look good on win32 344657 Ctrl-H doesn't toggle Show Hidden Files setting 345345 PrintOperation::paginate is not emitted for class handler 347567 GtkPrintOperation::end-print is not emitted if it's cance... 369112 gtk_ui_manager_add_ui should accept unnamed separator 392015 Selected menu item invisible on Windows Vista 399253 MS-Windows Theme Bottom Tab placement rendering glitches 399425 gtk_input_dialog_fill_axes() adds child to gtkscrolledwin... 403251 [patch] little memory leak in GtkPrintJob 403267 [patch] memory leak in GtkPageSetupUnixDialog 403470 MS-Windows Theme tab placement other than on top leaks a ... 404506 Windows system fonts that have multi-byte font names cann... 405089 Incorrect window placement for GtkEventBox private window 405515 Minor leak in gtkfilesystemmodel.c 405539 gdk_pixbuf_save() for PNG saver can return FALSE without ... 415681 gdk_window_clear_area includes an extra line and column o... 418219 GtkRecentChooser should apply filter before sorting and c... 418403 Scroll to printer after selecting it from settings 421985 _gtk_print_operation_platform_backend_launch_preview 421990 gtk_print_job_get_surface 421993 gtk_print_operation_init 423064 Conditional jump or move depends on uninitialised value(s... 423722 Fix printing header in gtk-demo 424168 gtk_print_operation_run on async preview 425655 Don't install gtk+-unix-print-2.0.pc on non-UNIX platforms 425786 GDK segfaults if XineramaQueryScreens fails 428665 Lpr Backend gets stuck in infinite loop during gtk_enumer... 429902 GtkPrintOperation leaks cairo contextes 431997 First delay of GdkPixbufAnimationIter is wrong 433242 Inconsistent scroll arrow position calculations 433972 Placing gtk.Expander inside a gtk.TextView() changes gtk 434261 _gtk_toolbar_elide_underscores incorrectly handles some s... 383354 ctrl-L should make 'Location' entry disappear 418673 gtk_recent_manager_add_item 429732 gtk_accel_group_finalize accesses invalid memory 435028 WM_CLIENT_LEADER is wrong on the leader_window 431067 Background of the header window is not updated 338843 add recent files support inside the ui manager 148535 add drop shadow to menus, tooltips, etc. under Windows XP * Updated translations: Belarusian Latin ([EMAIL PROTECTED]) Dzonka (dz) Greek (el) Spanish (es) Basque (eu) Italian (it) Galego (gl) Dutch (nl) Turkish (tr) A list of all bugs fixed in this release can be found here:
libccc (was: Re: goocanvas notes)
Havoc Pennington wrote: If that makes sense, I'd suggest that others review and write up their thinking on GooCanvas, perhaps reading some of the old threads, Piccolo, HippoCanvas, etc. as background material. And also if there are other canvas maintainers who want to put their hat in the ring, they should probably speak up. I'd also propose libccc as a candidate for a GtkCanvas: http://live.gnome.org/Criawips/CriaCanvas Regards, Sven PS: I'm going to release 0.0.5 this week. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
Carl Worth wrote: On Mon, 30 Apr 2007 12:52:55 -0400, Havoc Pennington wrote: The latest commit mentioned there talks about a 0.0.5 release, but I don't know where a tar file for that might exist. Sven? Yves had two small issues with my test-tarball of 0.0.5 and I'm going to fix these things until the weekend and then make a release. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. 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?) gtk-doc documents signals/properties on interfaces already. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
Damon Chaplin wrote: On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Agreed. 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?) gtk-doc documents signals/properties on interfaces already. Ah good! I had the impression it didn't ATM :) Thanks, Rob Taylor ___ 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 Tue, 2007-05-01 at 12:10 -0500, Hans Petter Jansson wrote: 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. /me too that would make libgda, for instance, not have its own model classes, it could use glib's -- Rodrigo Moya [EMAIL PROTECTED] ___ 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: I've been reading back in the discussion this February, about GVFS and Alex's design and such. Read the postings about legacy VFS integration and creating a Fuse mount point into GVFS at ~/.mount or similar. I find that really interesting. What about the reverse? Are we going to use file:/// to access NFS directories and in-kernel CIFS mounts? Or is an abstraction going to be provided around these where appropriate? Or are we simply going to not touch on the problem? I'm not sure what you mean. Access to such files would be through the GFile apis, and will result in normal posix calls. 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` Or are we simply going to consider it `file:///media/usbdisk-1/` and stuff like we do now? I really like the abstraction idea. It would basically be a GVFS mountable that just did whatever pmount work was necessary to get the device mounted, the proxy to the kernel VFS. I haven't planned anything like this. There is an abstraction similar to gnome-volume-monitor for enumerating the devices, but once they are mounted we refer to them as in the filesystem. Then what about arbitrary FUSE file systems? Is it an acceptable solution to write a fuse GVFS backend which auto-mounts? Not sure what you mean. gvfs backends can support mount on demand if that is what you want. But fuse mounts are not really different than any other kind of mounted filesystem, what special needs do you have? How should the translation from GVFS URI to POSIX path be handled? A `posix-path` property on a GFile? It should mount in ~/.mount if it was a pure-GVFS file system, or return the real underlying kernel path if it's just wrapped? I'm not sure what you mean, generally file: uris map to POSIX paths, and no other do. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a notorious vegetarian vagrant looking for a cure to the poison coursing through his veins. She's a brilliant kleptomaniac mermaid who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! ___ 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 Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote: 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? I'm not really convinced it is a good idea. Seems a bit fragile and bound to case trouble in various edge cases. Aliasing filenames is always problematic, so is using filenames in a non-canonical way that not all apps support. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a globe-trotting amnesiac cowboy whom everyone believes is mad. She's a radical green-skinned queen of the dead looking for love in all the wrong places. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk on directfb problem
Right now the gdk backend is pretty much hard coded to use a ARGB surface also the directfb Cairo backend does not work well unless the surface is RGB/ARGB. For overall performance the current setup is the best one reason its not been changed. To really make it work directfb needs something like XRender which can support cairo on any surface format. Note Xrender itself is not even close to fully accelerated. As far as I know integration of a advanced 2D engine like cairo and hardware acceleration is uncommon. Dennis is looking into it. Mike On 5/1/07, Michael Trimarchi [EMAIL PROTECTED] wrote: 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 ___ 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 Tue, 1 May 2007, Federico Mena Quintero wrote: 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). more than one subwindow is always cumbersome, if we delivered subwindow relative coordinates, we'd still have the problem of finding the exact subwindow in the widget code (and depending on the widget implementation, it may or may not already have code to translate back to widget-window). delivering widget-window really is the easiest choice because every widget implementation already knows how to translate from widget-window - subwindow (after all that's needed to correctly position subwindows in the first place) and generic code that has no intrinsic knowledge of a widget's window layout can still make use of the coordinates. 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. ah, an interesting point, worth considering... the case where activate_time stamps are actually required are popup menus: /** * gtk_menu_popup: * @activate_time: the time at which the activation event occurred. * * The @activate_time parameter should be the time stamp of the event that * initiated the popup. If such an event is not available, use * gtk_get_current_event_time() instead. * */ void gtk_menu_popup (GtkMenu *menu, [...] guint32 activate_time); the activate_time parameter is actually used to initiate the mouse/keyboard grabs. X needs that to conflict-resolve grab requests with concurring grab requests by other apps. so tooltip-like windows that don't need to acquire a grab are not affected here. tap-and-hold is often used to popup menus though, which need an activate_time parameter. now the problem is, what time should be passed in here in the case of a tap-and-hold period expiring? usually, the time of the causally related event is used, but in the tap-and-hold case, that time is always too late (since tap-and-hold behavior always needs a hold period 0 to make sense). so we'd actually need something like button_press-activate_time + hold_period (just using button_press-activate_time or last_motion-activate_time directly and assuming hold_period=0 wouldn't be a time stamp suitable for conflict resolution). given that an apropriate hold_period calculation would be fairly complex, and that at the point of the hold_period expiration any timing jitter from the original button-press delivery probably has become quite irrelevant, button_press-activate_time + hold_period would just be a rather bad approximation of now. and now is something that we are actually able to specify precisely by using GDK_CURRENT_TIME. so i'd say that tap-and-hold expiration is one of the rarer cases, where one should always use GDK_CURRENT_TIME for menu popups. that in turn means there's no point in carrying across a time stamp (which would be outdated or misleading anyway) in the tap-and-hold API. it might make sense to add this consideration to the docs though. Federico --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk on directfb problem
Right now the gdk backend is pretty much hard coded to use a ARGB surface also the directfb Cairo backend does not work well unless the surface is RGB/ARGB. If I wanto to use the RGB16_565 I must add support in the cairo-directfb-surface? For overall performance the current setup is the best one reason its not been changed. What the solution for an embedded device that use the RGB16_565 format? Regards Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Damon Chaplin wrote: On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Agreed. 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). Well, I think we both agree that there needs to be an API somewhere for storing the metadata in memory. I'm looking forward to your prototype. It would be great if the API were integrated with GClosure; that way language bindings could leverage existing marshaling code to support invoking methods introduced by the language. 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?) gtk-doc documents signals/properties on interfaces already. Ah good! I had the impression it didn't ATM :) Thanks, Rob Taylor ___ 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/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Damon Chaplin wrote: On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Agreed. 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). Well, I think we both agree that there needs to be an API somewhere for storing the metadata in memory. I'm looking forward to your prototype. It would be great if the API were integrated with GClosure; that way language bindings could leverage existing marshaling code to support invoking methods introduced by the language. I was planning on using ffi, so we can lose all the marshalling code. How does that sound to you? Relatedly, I'd like to see pygobject's g_cclosure_marshal_generic_ffi in glib proper. 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?) gtk-doc documents signals/properties on interfaces already. Ah good! I had the impression it didn't ATM :) 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
Hi Alexander On Wed, 2007-05-02 at 14:58 +0200, Alexander Larsson wrote: On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote: 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? I'm not really convinced it is a good idea. Seems a bit fragile and bound to case trouble in various edge cases. Aliasing filenames is always problematic, so is using filenames in a non-canonical way that not all apps support. One thing to consider is that apps that remember URIs of files on portable media will be mislead if we continue to use /media/usbdisk-n convention. For example, I might have a file /Document on one UMS device, open it in AbiWord, close it all down and swap out the disk for another, which also has the file /Document. These would both have exactly the same URI. I think we do have mechanism in place to identify the physical device some file belongs to, but the whole idea of a URI (not a URI-Reference[1]) is that it is Universal. Therefore, I strongly believe there should be some distinction between the two files' URIs, either by changing the naming policy on the mount point to /media/some-volume-uuid or by simply devising a new addressing scheme, URI or otherwise. Personally I'm of the opinion that cramming everything into the POSIX model doesn't work, as it's not generic enough for DAV/VFAT/FTP/SMB/etc to work without lots of dodgy policy with regard to permissions, file ownership and naming. Either something massive could go into the kernel or GVFS could deal with this all in userspace, but either way this is a massive shock to the system and I don't expect this to ever happen, even though it would make things nicer. Consider being able to access files in a tar-bzipped FAT filesystem image that is accessed over DAV with a single address. (The addressing scheme here is made up on the spot. XRI might be a better scheme but I don't know that much about it.) * dav://myserver/mystuff.bz2 addresses the bzip image on the DAV share * bzip2:(dav://myserver/stuff.bz2) addresses the uncompressed file * tar:(bzip2:(dav://myserver/mystuff.bz2)) addresses tar contents * tar:(bzip2:(dav://myserver/mystuff.bz2))/myVFAT addresses a file with name myVFAT inside the tar archive * vfat(tar:(bzip2:(dav://myserver/mystuff.bz2))/myVFAT)/some/path/to/document addresses a file inside the file system Imagine the possibilities! [1] http://gbiv.com/protocols/uri/rfc/rfc3986.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a globe-trotting amnesiac cowboy whom everyone believes is mad. She's a radical green-skinned queen of the dead looking for love in all the wrong places. They fight crime! ___ gnome-vfs-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list -- Alex Jones http://alex.weej.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Separating menus with m_refUIManager-add_ui_from_string(ui_info)
Hi, I'm relying on the UIManager to construct my menu bar, and I'd like to 1. insert separators between menus 2. push the help menu off to the far right of the bar I tried using the separator/ tag in the ui_info string, but the separator ends up as a couple of dots (it looks like it's trying to be a horizontal line instead of vertical.. I have no idea how to push the help menu... It was possible in Qt, so I imagine it can be done in Gtk too Thanks for your help, Jonathan -- Morpheus linux, c'est une question de VI ou de MORE ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
I was going over this old posting and wanted to add some commentary. In a perfect world, which we should try to achieve, of course, any such passed uris would be canonical and resolvable within scope of both machines. That is, full host names should be passed and both boxes should be able to resolve them properly. Now I recognize that this is a pie in the sky. But it is a good ideal to hope for, and within any single network, and on an Internet where everybody properly implements IPv6, probably ideal. Just make sure that converting a GFile into a uri string considers this. On Thu, 2007-02-15 at 18:57 +0100, Alexander Larsson wrote: On Thu, 2007-02-15 at 17:52 +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 17:45 +0100, Alexander Larsson wrote: While a laudable idea I'm not sure this is practical, at least not as the main approach. If I drag a directory from nautilus to some other apps, do you really want to transfer the full recursive copy of all files in the directory via X messages? Its not gonna be fast... Well, if the 2 apps don't sit on the same computer, what else could you want ? Of course, as an optimization if the 2 apps are local to each other, they should just use the current behavior. Actually, its more than a performance issue. What you really want is the file reference (i.e. filename), not the file contents. The app recieving the filename can do all sorts of things with it, not just read it. e.g. it could stat it, it could statfs() it to see what filesystem type it is on, it could traverse the filesystem up or down, or it could open the file and later save back to the same filename. All of these operations would have to be supported, and you need to be able to save the file reference persistantly, for say recent-files. All in all, that seems hard to do via X. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scrappy umbrella-wielding werewolf looking for a cure to the poison coursing through his veins. She's a vivacious communist Hell's Angel who don't take no shit from nobody. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
VFS integration with kernel mounts
I've been reading back in the discussion this February, about GVFS and Alex's design and such. Read the postings about legacy VFS integration and creating a Fuse mount point into GVFS at ~/.mount or similar. I find that really interesting. What about the reverse? Are we going to use file:/// to access NFS directories and in-kernel CIFS mounts? Or is an abstraction going to be provided around these where appropriate? Or are we simply going to not touch on the problem? 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` Or are we simply going to consider it `file:///media/usbdisk-1/` and stuff like we do now? I really like the abstraction idea. It would basically be a GVFS mountable that just did whatever pmount work was necessary to get the device mounted, the proxy to the kernel VFS. Then what about arbitrary FUSE file systems? Is it an acceptable solution to write a fuse GVFS backend which auto-mounts? How should the translation from GVFS URI to POSIX path be handled? A `posix-path` property on a GFile? It should mount in ~/.mount if it was a pure-GVFS file system, or return the real underlying kernel path if it's just wrapped? Just pondering. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk on directfb problem
On 5/2/07, Michael Trimarchi [EMAIL PROTECTED] wrote: Right now the gdk backend is pretty much hard coded to use a ARGB surface also the directfb Cairo backend does not work well unless the surface is RGB/ARGB. If I wanto to use the RGB16_565 I must add support in the cairo-directfb-surface? For performance its a matter of ensuring that all the common cairo ops can be converted to directfb ops for a particular surface type the exact type is not important. If you look at the cairo binding you will see that a lot of this code is already in. Just its broken. For overall performance the current setup is the best one reason its not been changed. What the solution for an embedded device that use the RGB16_565 format? Turn on the acceleration defines in the cairo back end fix any bugs that effect your usage send patches to the directfb list. If your lucky you won't hit cases that have artifacts. You should grab the git heads of both cairo and directfb for this or at least the latest releases. You have a pretty good chance of it working if you don't try to do complex cairo ops on a directfb-cairo surface. The directfb team is aware of this issue and Dennis is looking into the issues of hardware acceleration primitives needed to support cairo. The reason work stopped is that the current directfb ops don't map well to cairo to make it really work directfb primitives need to be extended to support cairo Xrender has many of the same issues. Further down the food chain the actual hardware acceleration support for 2D operations is just now supporting advanced 2D rendering so even with a optimized implementation only the most recent chipsets will work. I your case I'd be surprised if you get a lot of performance gains unless you have a good directfb driver. If you chipset has support for acceleration in Xrender you can use that as a guide. Since you said your doing embedded work getting good performance from cairo is tough and embedded even harder Nokia has funded optimizing cairo/xrender for the ARM and it still has a long way to go. The easy way out. If you have a 3D chipset cairo/glitz/opengl/directfb will probably give you the best performance this would be directfb on top of glitz to drive gdk. I've not looked at the way directfb/opengl interact. If not directfb/opengl does not use the 3D hardware for dfb then dfb on glitz is easy if you use the cairo glitz driver as a guide. Sorry for the long email but your stepping into a area that is full of land mines good luck. What you want is not trivial. Regards Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Michael Lawrence wrote: On 5/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Damon Chaplin wrote: On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Agreed. 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). Well, I think we both agree that there needs to be an API somewhere for storing the metadata in memory. I'm looking forward to your prototype. It would be great if the API were integrated with GClosure; that way language bindings could leverage existing marshaling code to support invoking methods introduced by the language. I was planning on using ffi, so we can lose all the marshalling code. How does that sound to you? I guess using libffi closures would work, but GClosure is definitely better documented. Would libffi be bundled with GLib given that there's no current release? Relatedly, I'd like to see pygobject's g_cclosure_marshal_generic_ffi in glib proper. 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?) gtk-doc documents signals/properties on interfaces already. Ah good! I had the impression it didn't ATM :) Thanks, Rob Taylor ___ 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/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Michael Lawrence wrote: On 5/2/07, Rob Taylor [EMAIL PROTECTED] wrote: Damon Chaplin wrote: On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: 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. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Agreed. 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). Well, I think we both agree that there needs to be an API somewhere for storing the metadata in memory. I'm looking forward to your prototype. It would be great if the API were integrated with GClosure; that way language bindings could leverage existing marshaling code to support invoking methods introduced by the language. I was planning on using ffi, so we can lose all the marshalling code. How does that sound to you? I guess using libffi closures would work, but GClosure is definitely better documented. Would libffi be bundled with GLib given that there's no current release? I've been using the libffi that's part of gcc. At least on debian/ubuntu this is installable as a separate package. As python 2.5 ctypes depend on libffi, I'm not expecting it to be a huge issue platform-wise. I don't expect the interface for bindings maintainers will require any knowledge of ffi. Anyhow, enough talk, I need to actually finish the work before discussing any more :) Relatedly, I'd like to see pygobject's g_cclosure_marshal_generic_ffi in glib proper. 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?) gtk-doc documents signals/properties on interfaces already. Ah good! I had the impression it didn't ATM :) Thanks, Rob Taylor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.10.12 released
GTK+ 2.10.12 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.10/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/ gtk+-2.10.12.tar.bz2 md5sum: cf969c62134c662ff07e64613ed6c11f gtk+-2.20.12.tar.gzmd5sum: 58787b04190fbf99012460ff79019a46 This is a bug fix release in the 2.10 series. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.10.11 to 2.10.12 * Fixed bugs: 379414 file chooser warnings when changing path in the entry 418585 GtkFileChooserDefault sizing code is not DPI independent 419568 Crash in search if start with special letter 435062 build dies with icon cache validation 379399 Segfault to call gtk_print_operation_run twice. 387889 cups backend has problems when there are too many printers 418531 invalid read to gtkicontheme.c gtk_icon_theme_lookup_icon... 423916 crash in color scheme code 424042 Segmentation fault while quickly pressing Alt+arrows 415260 Protect against negative indices when setting values in G... 419171 XGetVisualInfo() may not set nxvisuals 128852 Gdk cursors don't look good on win32 344657 Ctrl-H doesn't toggle Show Hidden Files setting 345345 PrintOperation::paginate is not emitted for class handler 347567 GtkPrintOperation::end-print is not emitted if it's cance... 369112 gtk_ui_manager_add_ui should accept unnamed separator 392015 Selected menu item invisible on Windows Vista 399253 MS-Windows Theme Bottom Tab placement rendering glitches 399425 gtk_input_dialog_fill_axes() adds child to gtkscrolledwin... 403251 [patch] little memory leak in GtkPrintJob 403267 [patch] memory leak in GtkPageSetupUnixDialog 403470 MS-Windows Theme tab placement other than on top leaks a ... 404506 Windows system fonts that have multi-byte font names cann... 405089 Incorrect window placement for GtkEventBox private window 405515 Minor leak in gtkfilesystemmodel.c 405539 gdk_pixbuf_save() for PNG saver can return FALSE without ... 415681 gdk_window_clear_area includes an extra line and column o... 418219 GtkRecentChooser should apply filter before sorting and c... 418403 Scroll to printer after selecting it from settings 421985 _gtk_print_operation_platform_backend_launch_preview 421990 gtk_print_job_get_surface 421993 gtk_print_operation_init 423064 Conditional jump or move depends on uninitialised value(s... 423722 Fix printing header in gtk-demo 424168 gtk_print_operation_run on async preview 425655 Don't install gtk+-unix-print-2.0.pc on non-UNIX platforms 425786 GDK segfaults if XineramaQueryScreens fails 428665 Lpr Backend gets stuck in infinite loop during gtk_enumer... 429902 GtkPrintOperation leaks cairo contextes 431997 First delay of GdkPixbufAnimationIter is wrong 433242 Inconsistent scroll arrow position calculations 433972 Placing gtk.Expander inside a gtk.TextView() changes gtk 434261 _gtk_toolbar_elide_underscores incorrectly handles some s... 383354 ctrl-L should make 'Location' entry disappear 418673 gtk_recent_manager_add_item 429732 gtk_accel_group_finalize accesses invalid memory 435028 WM_CLIENT_LEADER is wrong on the leader_window 431067 Background of the header window is not updated 338843 add recent files support inside the ui manager 148535 add drop shadow to menus, tooltips, etc. under Windows XP * Updated translations: Belarusian Latin ([EMAIL PROTECTED]) Dzonka (dz) Greek (el) Spanish (es) Basque (eu) Italian (it) Galego (gl) Dutch (nl) Turkish (tr) A list of all bugs fixed in this release can be found here:
Re: VFS integration with kernel mounts
On Wed, 2007-05-02 at 14:58 +0200, Alexander Larsson wrote: On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote: 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? I'm not really convinced it is a good idea. Seems a bit fragile and bound to case trouble in various edge cases. Aliasing filenames is always problematic, so is using filenames in a non-canonical way that not all apps support. But isn't the deal, with taking FUSE into account, that apps need to deal with at least two references to a file _anyway_? I mean, one that is the GVFS URL e.g. 1. smb:///server-hook/path/to/file and one that can be used with POSIX e.g. 2. /home/davidz/.mounts/smb-server-hook-32132/path/to/file that is just a FUSE mount maintained by the GVFS daemon? In other words, I'm saying you _already_ need things like this for GVFS specific file system drivers... meaning you need to translate from 1. to 2. at least (and possibly back). So what's the big deal of having GVFS recognize media-1234:///path/to/file/on/usbstick and just make libgvfs look up /media/raptor (or whatever) and use POSIX IO from there to actually read /media/raptor/path/to/file/on/usbstick. The whole point here is that GVFS aware apps, like gedit, Totem, Nautilus, F-Spot, Rhythmbox or whatever, can store media-1234:///path/to/file/on/usbstick in e.g. the recent file list, desktop file, media database etc. and actually, for free, have libgvfs (via the GVFS daemon) prompt the user to insert the media with the file in question if it's not available? (For example, that's a huge boon for me since I keep all my photos on an external USB harddisk and it's not fun to start F-Spot without the disk mounted. It's also not fun when mounting the disk elsewhere.) Or maybe I'm missing something? Feel free to tell me to read docs and/or the code if my question is stupid and the answer already lies there. Thanks! David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.13.1 released
GLib 2.13.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.13/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.13/ glib-2.13.1.tar.bz2 md5sum: 9317b839a998d99b53ce6ba2a6cdd8b3 glib-2.13.1.tar.gz md5sum: 656b7b1d1fda7bed4f5392f446ff76ef This is the second development release leading up to GLib 2.14. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.12. If you have problems, you'll need to reinstall GLib 2.12. * GLib 2.14 will be source and binary compatible with the GLib 2.12 series; however, the new API additions in GLib 2.13.1 are not yet finalized, so there may be incompatibilities between this release and the final 2.14 release. * Bugs should be reported to http://bugzilla.gnome.org. About GLib == 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.13.0 to GLib 2.13.1 === * GRegex: - Portability fixes - Split into immutable GRegex and GMatchInfo - Add g_regex_get_max_backref() and g_regex_get_capture_count() to obtain information about the compiled regex * GKeyFile: - Fix roundtrip problems - Add g_key_file_load_from_dirs() * Unicode support: - Fix corner cases in case conversion routines * GOption: - Add a function to get the formatted help string * GHash: - Add new functions g_hash_table_get_keys() and g_hash_table_get_values() to retrieve the keys and values in list form * Updated transations: Simplified Chinese (zh_CN) Arabic (ar) Thanks to all the people who have contributed to this release: Hans Breuer Marco Barisione Paolo Borelli Chris Wilson Paul Jarc Emmanuele Bassi Jochen Baier Tor Lillqvist William Jon McCann Michael Natterer Dom Lachowicz Ryan Lortie Tim Janik Matthias Clasen May 3, 2007 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how to install the gtkmozembed development library
hi, in order to get gtkmozembed widget available you can install either firefox-dev or mozilla-dev packages (directly from synaptic on debians). In theory, these are going to install all dev stuff needed for embedding mozilla. Mozilla has been pushing also XULRunner use ahaed. xulrunner-dev package (from MOZILLA_1_8_BRANCH) is the recommended way to go, so. Mozilla trunk's gtkmozembed library has currently passed by HUGE changes , and seems to be a bit instable for development although things are getting better step by step. greetings. On 4/26/07, Dennis Francis [EMAIL PROTECTED] wrote: Can anyone please tell me how can I install gtkmozembed development library, so that I can use the browser widget in my code. -- --Antonio Gomes ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ cross compiling with scratchbox
what does $ dpkg -l | grep libpng return ? maybe missing dev packages of it ? On 4/30/07, Lesly A M [EMAIL PROTECTED] wrote: Hi all, I am new to GTK,.. I am trying to cross compile GTK for my ARM Board. I downloaded GTK+ Source GLib Source Pango Source and dependencies : atk, cairo, libpng,.. while trying to configure cairo, it checkes for the dependency of libpng. I already have configured and installed the libpng, but Its still showing thye error - checking for cairo's PNG backend... ./configure: line 24784: --exists: command not found ./configure: line 24784: --exists: command not found ./configure: line 24784: --exists: command not found configure: WARNING: Could not find libpng in the pkg-config search path checking whether cairo's PNG backend could be enabled... no configure: error: requested PNG backend could not be enabled [sbox-arm-linux: ~/cairo-1.2.6] - can anybody help me resolve this problem,.. TIA Lesly A M ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- --Antonio Gomes ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ cross compiling with scratchbox
--- Antonio Gomes [EMAIL PROTECTED] wrote: what does $ dpkg -l | grep libpng return ? maybe missing dev packages of it ? On 4/30/07, Lesly A M [EMAIL PROTECTED] wrote: Hi all, I am new to GTK,.. I am trying to cross compile GTK for my ARM Board. I downloaded GTK+ Source GLib Source Pango Source and dependencies : atk, cairo, libpng,.. while trying to configure cairo, it checkes for the dependency of libpng. I already have configured and installed the libpng, but Its still showing thye error - checking for cairo's PNG backend... ./configure: line 24784: --exists: command not found ./configure: line 24784: --exists: command not found ./configure: line 24784: configure: WARNING: Could not find libpng in the pkg-config search path checking whether cairo's PNG backend could be enabled... no configure: error: requested PNG backend could not be enabled [sbox-arm-linux: ~/cairo-1.2.6] - can anybody help me resolve this problem,.. TIA Lesly A M ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- --Antonio Gomes ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list I think that --exists: command not found indicates a too old version of /bin/sh - if I remember correctly, I resolved this by upgrading /bin/sh that was GNU 'bash' in my case. Regards, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk accessibility on Windows
Lainaus Steve Lee [EMAIL PROTECTED]: What is the status of accessibility on the Windows port of gtk? See http://bugzilla.gnome.org/show_bug.cgi?id=303304 Basically, only the trivially portable plumbing (atk, gail) has been ported, but the real interface to MSAA (or whatever else) nobody has worked on. --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GTK+ 2.10.12 released
GTK+ 2.10.12 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.10/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/ gtk+-2.10.12.tar.bz2 md5sum: cf969c62134c662ff07e64613ed6c11f gtk+-2.20.12.tar.gzmd5sum: 58787b04190fbf99012460ff79019a46 This is a bug fix release in the 2.10 series. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.8 is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Overview of Changes from GTK+ 2.10.11 to 2.10.12 * Fixed bugs: 379414 file chooser warnings when changing path in the entry 418585 GtkFileChooserDefault sizing code is not DPI independent 419568 Crash in search if start with special letter 435062 build dies with icon cache validation 379399 Segfault to call gtk_print_operation_run twice. 387889 cups backend has problems when there are too many printers 418531 invalid read to gtkicontheme.c gtk_icon_theme_lookup_icon... 423916 crash in color scheme code 424042 Segmentation fault while quickly pressing Alt+arrows 415260 Protect against negative indices when setting values in G... 419171 XGetVisualInfo() may not set nxvisuals 128852 Gdk cursors don't look good on win32 344657 Ctrl-H doesn't toggle Show Hidden Files setting 345345 PrintOperation::paginate is not emitted for class handler 347567 GtkPrintOperation::end-print is not emitted if it's cance... 369112 gtk_ui_manager_add_ui should accept unnamed separator 392015 Selected menu item invisible on Windows Vista 399253 MS-Windows Theme Bottom Tab placement rendering glitches 399425 gtk_input_dialog_fill_axes() adds child to gtkscrolledwin... 403251 [patch] little memory leak in GtkPrintJob 403267 [patch] memory leak in GtkPageSetupUnixDialog 403470 MS-Windows Theme tab placement other than on top leaks a ... 404506 Windows system fonts that have multi-byte font names cann... 405089 Incorrect window placement for GtkEventBox private window 405515 Minor leak in gtkfilesystemmodel.c 405539 gdk_pixbuf_save() for PNG saver can return FALSE without ... 415681 gdk_window_clear_area includes an extra line and column o... 418219 GtkRecentChooser should apply filter before sorting and c... 418403 Scroll to printer after selecting it from settings 421985 _gtk_print_operation_platform_backend_launch_preview 421990 gtk_print_job_get_surface 421993 gtk_print_operation_init 423064 Conditional jump or move depends on uninitialised value(s... 423722 Fix printing header in gtk-demo 424168 gtk_print_operation_run on async preview 425655 Don't install gtk+-unix-print-2.0.pc on non-UNIX platforms 425786 GDK segfaults if XineramaQueryScreens fails 428665 Lpr Backend gets stuck in infinite loop during gtk_enumer... 429902 GtkPrintOperation leaks cairo contextes 431997 First delay of GdkPixbufAnimationIter is wrong 433242 Inconsistent scroll arrow position calculations 433972 Placing gtk.Expander inside a gtk.TextView() changes gtk 434261 _gtk_toolbar_elide_underscores incorrectly handles some s... 383354 ctrl-L should make 'Location' entry disappear 418673 gtk_recent_manager_add_item 429732 gtk_accel_group_finalize accesses invalid memory 435028 WM_CLIENT_LEADER is wrong on the leader_window 431067 Background of the header window is not updated 338843 add recent files support inside the ui manager 148535 add drop shadow to menus, tooltips, etc. under Windows XP * Updated translations: Belarusian Latin ([EMAIL PROTECTED]) Dzonka (dz) Greek (el) Spanish (es) Basque (eu) Italian (it) Galego (gl) Dutch (nl) Turkish (tr) A list of all bugs fixed in this release can be found here:
Hello and win32 g_io_channel help needed
Hail! I am new.. so gday to everyone here. I am after some assistance with getting my event-driven serial port input working on Windows. The project is a portable serial tool for internal use within our company, I am writing it using libglademm since I love C++ and am a big Gnome/GTK fan (my laptop being Ubuntu Gnome based) On Linux I am using open and termios to handle the serial port setup, finally returning a GIOChannel for monitoring and so far.. so good. However I am now trying to get the evil version of it running and am not so happy. Here I am using CreateFile to open and configure my port, then use: m_PortDescriptor = _open_osfhandle((long)m_PortHandle, 0); channel = g_io_channel_unix_new(m_PortDescriptor); to get the channel. Later on I use g_io_add_watch to setup a monitor which seems to compile and run ok, however when I send data using g_io_channel_write_chars it seems to crash and I also don't seem to be receiving data (often resulting another application halt) I am not a GTK expert (this is my first project in it) and would really appreciate help since I want to promote using this sort of solution internally as much as possible. Kind regards, Burkey ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Hello and win32 g_io_channel help needed
Actually.. I have commented out the reading and my callback is called very quickly whenever I drag the window around with my mouse, so I really think there must be something wrong with the way I am getting a file descriptor or something like that? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Burke.Daniel Sent: Thursday, 3 May 2007 14:04 To: gtk-list@gnome.org Subject: Hello and win32 g_io_channel help needed Hail! I am new.. so gday to everyone here. I am after some assistance with getting my event-driven serial port input working on Windows. The project is a portable serial tool for internal use within our company, I am writing it using libglademm since I love C++ and am a big Gnome/GTK fan (my laptop being Ubuntu Gnome based) On Linux I am using open and termios to handle the serial port setup, finally returning a GIOChannel for monitoring and so far.. so good. However I am now trying to get the evil version of it running and am not so happy. Here I am using CreateFile to open and configure my port, then use: m_PortDescriptor = _open_osfhandle((long)m_PortHandle, 0); channel = g_io_channel_unix_new(m_PortDescriptor); to get the channel. Later on I use g_io_add_watch to setup a monitor which seems to compile and run ok, however when I send data using g_io_channel_write_chars it seems to crash and I also don't seem to be receiving data (often resulting another application halt) I am not a GTK expert (this is my first project in it) and would really appreciate help since I want to promote using this sort of solution internally as much as possible. Kind regards, Burkey ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GLib 2.13.1 released
GLib 2.13.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.13/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.13/ glib-2.13.1.tar.bz2 md5sum: 9317b839a998d99b53ce6ba2a6cdd8b3 glib-2.13.1.tar.gz md5sum: 656b7b1d1fda7bed4f5392f446ff76ef This is the second development release leading up to GLib 2.14. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.12. If you have problems, you'll need to reinstall GLib 2.12. * GLib 2.14 will be source and binary compatible with the GLib 2.12 series; however, the new API additions in GLib 2.13.1 are not yet finalized, so there may be incompatibilities between this release and the final 2.14 release. * Bugs should be reported to http://bugzilla.gnome.org. About GLib == 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.13.0 to GLib 2.13.1 === * GRegex: - Portability fixes - Split into immutable GRegex and GMatchInfo - Add g_regex_get_max_backref() and g_regex_get_capture_count() to obtain information about the compiled regex * GKeyFile: - Fix roundtrip problems - Add g_key_file_load_from_dirs() * Unicode support: - Fix corner cases in case conversion routines * GOption: - Add a function to get the formatted help string * GHash: - Add new functions g_hash_table_get_keys() and g_hash_table_get_values() to retrieve the keys and values in list form * Updated transations: Simplified Chinese (zh_CN) Arabic (ar) Thanks to all the people who have contributed to this release: Hans Breuer Marco Barisione Paolo Borelli Chris Wilson Paul Jarc Emmanuele Bassi Jochen Baier Tor Lillqvist William Jon McCann Michael Natterer Dom Lachowicz Ryan Lortie Tim Janik Matthias Clasen May 3, 2007 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
