Re: gtk errors !GTK_WIDGET_REALIZED (widget) failed
I'm doing it to get transparency for the window. The strange thing is is that the window is in fact shown (realized) using gtk_widget_show before I call the colormap stuff. I've managed to get this working using straight C but I'm now creating a gui using libglade. Any idea's what I need to do in libglade to get this working? Paul Pogonyshev wrote: 3saul wrote: when trying to: GdkColormap *colormap = gdk_screen_get_rgba_colormap(screen); gtk_widget_set_colormap(widget, colormap); This is literally as complicated as my program is. Create a window (using libglade), setup callbacks, apply colormap. What does this mean? Is there a web page somewhere with an explanation of such errors? The full error message is: Gtk-Critical **: gtk_widget_set_colormap: assertion '!GTK_WIDGET_REALIZED (widget)' failed It means what it says, that the widget is not realized. I.e. it is not shown on screen and you cannot set colormap until it is. Why do you need it anyway? AFAIK colormaps are handled by GTK+ itself just fine. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/gtk-errors-%22%21GTK_WIDGET_REALIZED-%28widget%29-failed-tf3460522.html#a9688570 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
Re: gtk errors !GTK_WIDGET_REALIZED (widget) failed
Looks like this is definitely a libglade issue. I found this: http://developer.gnome.org/doc/API/libglade/libglade-extending.html I can see how it would be trivial to use a custom widget for anything other than the main window itself. Any idea's how I'd achieve this? I want to specify the main window in glade as a custom widget (to see if this solves the issue in my original post). If you have any other idea's I'd love to hear them. Thanks Paul Pogonyshev wrote: 3saul wrote: when trying to: GdkColormap *colormap = gdk_screen_get_rgba_colormap(screen); gtk_widget_set_colormap(widget, colormap); This is literally as complicated as my program is. Create a window (using libglade), setup callbacks, apply colormap. What does this mean? Is there a web page somewhere with an explanation of such errors? The full error message is: Gtk-Critical **: gtk_widget_set_colormap: assertion '!GTK_WIDGET_REALIZED (widget)' failed It means what it says, that the widget is not realized. I.e. it is not shown on screen and you cannot set colormap until it is. Why do you need it anyway? AFAIK colormaps are handled by GTK+ itself just fine. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/gtk-errors-%22%21GTK_WIDGET_REALIZED-%28widget%29-failed-tf3460522.html#a9705376 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
Re: gtk errors !GTK_WIDGET_REALIZED (widget) failed
Hi, From the gtkmm documentation (just a wrapper for gtk): void Gtk::Widget::show ( ) Flags a widget to be displayed. ie. it doesn't acually show the widget, but tells gtk you'd like it to (wich it will do for you, a short time later) I'm guessing the widget hasn't had time to get realized before you do your colormap stuff Since your code should be called after realization, you could put it in the on_realize() handler [or rather, connect your code to the realize signal in C (as opposed to C++)] If you are calling this code a long time later (eg. on pressing a button) then I guess the problem's elsewere. Hoping to help, Jonathan On 3/27/07, 3saul [EMAIL PROTECTED] wrote: I'm doing it to get transparency for the window. The strange thing is is that the window is in fact shown (realized) using gtk_widget_show before I call the colormap stuff. I've managed to get this working using straight C but I'm now creating a gui using libglade. Any idea's what I need to do in libglade to get this working? Paul Pogonyshev wrote: 3saul wrote: when trying to: GdkColormap *colormap = gdk_screen_get_rgba_colormap(screen); gtk_widget_set_colormap(widget, colormap); This is literally as complicated as my program is. Create a window (using libglade), setup callbacks, apply colormap. What does this mean? Is there a web page somewhere with an explanation of such errors? The full error message is: Gtk-Critical **: gtk_widget_set_colormap: assertion '!GTK_WIDGET_REALIZED (widget)' failed It means what it says, that the widget is not realized. I.e. it is not shown on screen and you cannot set colormap until it is. Why do you need it anyway? AFAIK colormaps are handled by GTK+ itself just fine. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/gtk-errors-%22%21GTK_WIDGET_REALIZED-%28widget%29-failed-tf3460522.html#a9688570 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Fw: Thread-save posting of events
[ this repeats the note with better formatting; hopefully] Tobias, This response may be a little off topic. But as I have followed this thread I understand your are moving some application to linux from MS. Moreso, you are planning on using gtk to get that port done. Here is a little of my experience with gtk threaded program design. 1. Having gtk thread security features turned on is required if you plan to call gtk_ api's from more than one thread: Which you should NOT try to do. * If your app will be multi-threaded be sure to enable these protection feature as described. http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html * And use the glib set of api's for creating and managing threads, as described here: http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html 2. Spend some time devising a way to collect data values that need to be visually represented in gtk inside a container or memory structure that you can g_new0() allocate. * Then pass that pointer from the background thread to the foreground GTK main thread for display or updating ** maybe using GAsyncQueue to pass the pointers ** GAsyncQueue will also cause a thread to block; good for background threads waiting on work, BAD for the GTK main thread and its contructs. ** apis which act on the GAsyncQueue behave somewhat like the MS postMessage() api *** the sendMessage is synchronous and has no GTK/GLIB equivilent. One way to overcome this is to actually share a set of user.functions() and a common memory structure using glib's g_mutex apis. Be sure to call these shared(between threads) user.functions from a g_idle/g_timeout based functions in the gtk main thread when targeting the gui. *** If you don't call any gtk/gdk api's from another thread then you will not need to call gdk_threads_enter/exit() ** For gtk main thread to background thread interchanges look over the g_idle/g_timeout set of apis and potentially g_io_channel/watch apis; along with g_mutex 'es where needed. *** gapcmon.sourceforge.net, gfhcm.sourceforge.net contain working examples of tcp socket intensive gtk/C programs using these methods. ** If you look at how gtk suggest you setup for multi-threaded program, it describes wrapping the call to gtk_main() with ( gdk_threads_enter(); gtk_init(); gtk_window...;gtk_main();gtk_threads_exit() ). What is not so obvious is that this protects most button and g_signal callbacks. g_idle... g_timeout... g_thread... based functions are not protected by the gtk_main loop because they occur outside its control - so they must have gdk_threads_enter/exit wrappings just arround the gtk_... call only. *** You need to consider using gdk_threads_enter/exit in any g_idle/g_timeout/g_thread/g_io_ based routine *** if you follow me thus far, then you will never call a gtk/gdk routine from outside the gtk_main loop or thread; except for maybe g_io_watch based functions. 3. Socket based, and other OTHER PROCESS, communication wheter a pipe or a socket or orther mechanism may lend itself to g_io_channel and g_io_watch based apis. ** Look at a few example of how the glib feature set works; it ends up executing during the gtk_main loop thread/time be can be very useful in handling external process based communication. ** If you find that this (g_io_watch() ) method works for you, consider creating your own glib loop (g_main_loop_run()) in a background thread to get your io processing off the gtk_main timeslice 4. Finally, be careful how you implement or use classic unix signals: Danger, Danger Will Robinson.. I can not stress enough that you need to buy the book, readit, and workout some off-project tests before pounding out a ported application. You will find gtk/glib to have a rich set of widgets and programming constructs that make using it almost fun. I hope some of what I've said help your quest. James, (a.k.a Skoona) - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Tobias Rapp [EMAIL PROTECTED] Cc: gtk-app-devel-list@gnome.org Sent: Thursday, March 29, 2007 4:15:54 AM Subject: Re: Thread-save posting of events On 3/29/07, Tobias Rapp [EMAIL PROTECTED] wrote: Rick Jones wrote: I've only come across it while looking for other things, but perhaps the GAsyncQueues stuff would be useful for thread-to-thread comms? http://developer.gnome.org/doc/API/2.0/glib/glib-Asynchronous-Queues.html That looks exactly like the thing I'm searching for. I had a look at the API documentation before but don't know how I missed that one. Thanks! You probably still need watch routines executing the the various event loops (guessing). Yes, maybe I have to add an idle handler for the event loop with g_idle_add() (as proposed by John) and do a g_async_queue_try_pop() in there... Actually no, you can just
Re: gtk errors !GTK_WIDGET_REALIZED (widget) failed
Thanks for all the replies. Please find my anjuta project attached. It's very small and easy to see what I'm trying to achieve. You'll need anjuta 2.1.1 and glade 3. Thanks http://www.nabble.com/file/7543/src.tar.gz src.tar.gz Jonathan Winterflood wrote: Hi, From the gtkmm documentation (just a wrapper for gtk): void Gtk::Widget::show ( ) Flags a widget to be displayed. ie. it doesn't acually show the widget, but tells gtk you'd like it to (wich it will do for you, a short time later) I'm guessing the widget hasn't had time to get realized before you do your colormap stuff Since your code should be called after realization, you could put it in the on_realize() handler [or rather, connect your code to the realize signal in C (as opposed to C++)] If you are calling this code a long time later (eg. on pressing a button) then I guess the problem's elsewere. Hoping to help, Jonathan On 3/27/07, 3saul [EMAIL PROTECTED] wrote: I'm doing it to get transparency for the window. The strange thing is is that the window is in fact shown (realized) using gtk_widget_show before I call the colormap stuff. I've managed to get this working using straight C but I'm now creating a gui using libglade. Any idea's what I need to do in libglade to get this working? Paul Pogonyshev wrote: 3saul wrote: when trying to: GdkColormap *colormap = gdk_screen_get_rgba_colormap(screen); gtk_widget_set_colormap(widget, colormap); This is literally as complicated as my program is. Create a window (using libglade), setup callbacks, apply colormap. What does this mean? Is there a web page somewhere with an explanation of such errors? The full error message is: Gtk-Critical **: gtk_widget_set_colormap: assertion '!GTK_WIDGET_REALIZED (widget)' failed It means what it says, that the widget is not realized. I.e. it is not shown on screen and you cannot set colormap until it is. Why do you need it anyway? AFAIK colormaps are handled by GTK+ itself just fine. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/gtk-errors-%22%21GTK_WIDGET_REALIZED-%28widget%29-failed-tf3460522.html#a9688570 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/gtk-errors-%22%21GTK_WIDGET_REALIZED-%28widget%29-failed-tf3460522.html#a9741856 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
cross-compiling a GTK app, linux - darwin
Does anyone have expertise/recommendations to share, on the subject of compiling a GTK app on x86 Linux for the powerpc-apple-darwin target? I'm familiar with the linux - win32 cross. This is relatively easy since mingw makes the win32 API available in a single package, and Tor Lillqvist makes available the GTK dev material for win32, plus various dependencies, also nicely packaged. I'm wondering if tarring up all the GTK+ stuff from a fink installation on OS X, and dumping it into a suitable directory on Linux, is going to get me anywhere (having built a suitable binutils and cross-gcc first, of course). Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cross-compiling a GTK app, linux - darwin
On Thu, 2007-03-29 at 22:42 -0400, Allin Cottrell wrote: Does anyone have expertise/recommendations to share, on the subject of compiling a GTK app on x86 Linux for the powerpc-apple-darwin target? I'm familiar with the linux - win32 cross. This is relatively easy since mingw makes the win32 API available in a single package, and Tor Lillqvist makes available the GTK dev material for win32, plus various dependencies, also nicely packaged. I'm wondering if tarring up all the GTK+ stuff from a fink installation on OS X, and dumping it into a suitable directory on Linux, is going to get me anywhere (having built a suitable binutils and cross-gcc first, of course). First, see http://ranger.befunk.com/fink/darwin-cross/ . To build useful exes, though, you have to populate the cross environment with headers, libraries, and frameworks from the real OS X box. It's a bit tedious but doable. Here are some tips: - Place any .framework folders in the lib folder of the cross environment. - symlink any Include directories inside the frameworks to the include folder, but without the .framwork extension. In otherwords, symlink $CROSSROOT/lib/fooBar.framework/Headers to $CROSSROOT/include/fooBar - You'll have to go through each dylib and use the otool and install_name_tool command to find and fixup the linker paths to match your cross environment's directory structure. For example, many dylibs want to link against /usr/lib/libSystem.B.dylib. You'll have to use install_name_tool to change that to /path/to/cross/lib/libSystem.B.dylib. This does not affect your exes at all, unless you bundled a library with the exe, but then you'll want to use install_name_tool anyway to adjust the paths to be relative to the app bundle itself. For more information on this in general, see the following information that applies to more than just Qt: http://doc.trolltech.com/4.2/deployment-mac.html Right now I only have my OS X 10.3 PPC cross environment populated. I use it to, ahem, build Qt apps (app bundles and all) for OS X 10.3 or later from my Linux box. I have some scripts I used to do the fixups, which I may be able to e-mail to you. I cannot offer the cross environment for download anywhere because it contains actual apple libraries (the OS X runtime libraries and frameworks) that cannot be distributed. They'd have to come from your own licensed copy of OS X. I don't think it's currently possible to cross-compile GTK itself for Quartz (you can for X11, though), but once GTK is built, it's just a matter of transferring the headers, libraries, and frameworks to the linux environment. Michael Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Shipping multiple themes by default (Was: Sudden Tango changes in trunk)
Hi, Would it be difficult to ship multiple themes by default, for example legacy and tango (and perhaps qt and metal themes in the future?); the default theme could be selected at build time and the default default could be set to tango for win32 and win32 only. Distributors could easily decide which themes they do ship and it would be easy to switch the default default from legacy to tango with $next_major_release for all platforms -- while still making it available for legacy purposes. (In a way, this maps relatively close to how Java's Swing Look and Feel themes are handled.) Bye, -- Loïc Minier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: first Gtk Version over DirectFB
Kalle Vahlman ha scritto: 2007/3/28, Attilio Fiandrotti [EMAIL PROTECTED]: BTW, the directfb gnome bug page is also messy: a lot of bugs duplicates exist, many closed bugs are still indicated as open etc.. i can take care of that as i take care of bugs related to gtkdfb in debian: Awesome! do i need some special permission? indications about how to manage bugs in gnome? The Bugsquad wiki probably is a good place to start: http://live.gnome.org/Bugsquad and the bugsquad mailing list is a good place to ask specific questions about bug management (component-specific issues naturally belong to the individual lists): http://mail.gnome.org/mailman/listinfo/gnome-bugsquad Thanks, i'll inquiry the bugsqad guys about management of gtkdfb bugs. regards Attilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[WEB PATCH] towards making gtk website valid XHTML 1.0 Transitional
Hi, Here's an incomplete effort to help make the gtk.org website valid XHTML 1.0 Transitional, done with following the guidelines in http://www.w3.org/TR/xhtml1 and http://validator.w3.org/. I change several files which results in a 1200+ line diff. Please commit... Index: glib-1.2-NEWS.html === --- glib-1.2-NEWS.html (revision 572) +++ glib-1.2-NEWS.html (working copy) @@ -1,19 +1,16 @@ -html -head -titleGTK+ - GTK+ 1.2 Changes/title - +!--#include file=site_begin.html -- !--#include file=site_top.html-- -CENTER +center font face=lucida,helvetica size=+2 BGLib 1.2.x NEWS/B /font -/CENTER -BR +/center +br -PRE +pre !--#include file=HISTORIC/glib-NEWS-1.2.txt-- -/PRE +/pre /font !--#include file=site_bottom.html-- Index: gtk-2.10-notes.html === --- gtk-2.10-notes.html (revision 572) +++ gtk-2.10-notes.html (working copy) @@ -1,7 +1,4 @@ -html -head -titleGTK+ - GTK+-2.10 Release notes/title - +!--#include file=site_begin.html -- !--#include file=site_top.html -- preGTK+ 2.10 Specific Notes Index: section_end.html === --- section_end.html (revision 572) +++ section_end.html (working copy) @@ -1,4 +1,4 @@ -/B +/b nbsp; nbsp; /td/tr /table Index: gtk-2.10-announcement.html === --- gtk-2.10-announcement.html (revision 572) +++ gtk-2.10-announcement.html (working copy) @@ -1,7 +1,4 @@ -html -head -titleGTK+ - GTK+ 2.10 announcement/title - +!--#include file=site_begin.html -- !--#include file=site_top.html -- preGTK+ 2.10.0 is now available for download at: Index: box_begin.html === --- box_begin.html (revision 572) +++ box_begin.html (working copy) @@ -1,7 +1,7 @@ -table width=100% cellspacing=0 cellpadding=2 border=0 +table width=100% cellspacing=0 cellpadding=2 border=0 tr td bgcolor=#00 -table width=100% cellspacing=0 cellpadding=4 border=0 +table width=100% cellspacing=0 cellpadding=2 border=0 tr -td bgcolor=#EE nowrap -B +td bgcolor=#EE nowrap=nowrap +b Index: bindings.html === --- bindings.html (revision 572) +++ bindings.html (working copy) @@ -1,7 +1,4 @@ -html -head -titleGTK+ - Language Bindings/title - +!--#include file=site_begin.html -- !--#include file=site_top.html -- table border=0 cellpadding=0 cellspacing=0trtd valign=top Index: box_middle.html === --- box_middle.html (revision 572) +++ box_middle.html (working copy) @@ -1,4 +1,4 @@ -/B +/b /td /trtr -td bgcolor=#FF nowrap +td bgcolor=#FF nowrap=nowrap Index: announce.html === --- announce.html (revision 572) +++ announce.html (working copy) @@ -1,25 +1,22 @@ -html -head -titleGTK+ - 1.2 Announcement/title - +!--#include file=site_begin.html -- !--#include file=site_top.html-- !--#include file=section_begin.html-- GTK+ Version 1.2 Released !--#include file=section_end.html-- -P +p The GTK+ development team is pleased to announce the release of version 1.2 of the GIMP Toolkit. -/P -P +/p +p GTK+ is a multi-platform open source GUI Toolkit. Everything about GTK+ from the object-oriented design to the Free Software LGPL licensing allows you to code your project with the most freedom possible. You can develop open software, free software, or even commercial non-free software without having to spend a dime for licenses or royalties. -/P +/p p GTK+ is a set of libraries to create graphical user interfaces. It works on many Unix-like platforms, and a Windows version is in @@ -70,18 +67,18 @@ and GNOME projects. Don't get left out! /p p GTK+ is also being ported to Win32. For further information see: -A HREF=http://www.iki.fi/tml/gimp/win32/;http://www.iki.fi/tml/gimp/win32//A. +a href=http://www.iki.fi/tml/gimp/win32/;http://www.iki.fi/tml/gimp/win32//A. /p p GTK+ and GLib can be downloaded at -A HREF=ftp://ftp.gtk.org/pub/gtk/v1.2/;ftp://ftp.gtk.org/pub/gtk/v1.2//a. +a href=ftp://ftp.gtk.org/pub/gtk/v1.2/;ftp://ftp.gtk.org/pub/gtk/v1.2//a. /p p For further information please visit: ul -liGTK+ Home page: A HREF=http://www.gtk.org/;http://www.gtk.org//a +liGTK+ Home page: a href=http://www.gtk.org/;http://www.gtk.org//a liGIMP Home page: a href=http://www.gimp.org/;http://www.gimp.org//a -liGNOME Home page: A HREF=http://www.gnome.org/;http://www.gnome.org//a +liGNOME Home page: A href=http://www.gnome.org/;http://www.gnome.org//a /p !--#include file=site_bottom.html-- Index: gtk-2.0.0-notes.html === --- gtk-2.0.0-notes.html (revision 572) +++ gtk-2.0.0-notes.html (working copy) @@ -1,8 +1,4 @@ -
Re: GDesktopAppInfo
On Wed, 2007-03-28 at 15:51 +0200, Alexander Larsson wrote: On Tue, 2007-03-27 at 15:46 -0400, Dan Winship wrote: Alexander Larsson wrote: Do many apps really require creating launchers from arbitrary desktop files? What is the typical usecase of that? Well, the panel in multiple places (main menu, panel launchers, run dialog). The various panel add-ons/replacements (the Novell main menu and app launcher, Gimmie, deskbar, alacarte, etc). Nautilus, for creating launchers for dropped URLs/apps, and launching them later. Gnome-session for autostart. Beagle, for launching apps in search results. And then there's xfce-panel, Thunar, etc, etc. In the realm of the not-yet-deployed, my EggSMClient code uses the app's desktop file's Exec key to set the XSMP RestartCommand. That also led to a discussion of having a gtk_set_desktop_file() or gtk_application_set_desktop_file() method to call at startup, which would feed EggSMClient the data it needed, plus it could call g_set_application_name() and gtk_window_set_default_icon_name(), and possibly do other setup based on loadable modules, like initializing the bug-buddy signal handlers if the .desktop file includes X-GNOME-Bugzilla- keys, etc. Yeah, there is a clear need for this when implementing the Gnome desktop. But its sort of unix specific, so maybe it doesn't have to be in the very low levels of the stack. OTOH, its not really a large piece of code, especially given GKeyFile. non-GUI apps might need it also, like the new documentation indexer (Spoon - http://live.gnome.org/Yelp/Spoon). In fact, it would be great if this GDesktopAppInfo implemented a .desktop cache, which is much needed for gnome-main-menu and, probably, for spoon. Of course, it's still unix-specific, as you say, so why not have an implementation for that, on Windows, that reads the Start menu? Not sure if that would work -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDesktopAppInfo
On Thu, 2007-03-29 at 11:27 +0200, Rodrigo Moya wrote: On Wed, 2007-03-28 at 15:51 +0200, Alexander Larsson wrote: On Tue, 2007-03-27 at 15:46 -0400, Dan Winship wrote: Alexander Larsson wrote: Do many apps really require creating launchers from arbitrary desktop files? What is the typical usecase of that? Well, the panel in multiple places (main menu, panel launchers, run dialog). The various panel add-ons/replacements (the Novell main menu and app launcher, Gimmie, deskbar, alacarte, etc). Nautilus, for creating launchers for dropped URLs/apps, and launching them later. Gnome-session for autostart. Beagle, for launching apps in search results. And then there's xfce-panel, Thunar, etc, etc. In the realm of the not-yet-deployed, my EggSMClient code uses the app's desktop file's Exec key to set the XSMP RestartCommand. That also led to a discussion of having a gtk_set_desktop_file() or gtk_application_set_desktop_file() method to call at startup, which would feed EggSMClient the data it needed, plus it could call g_set_application_name() and gtk_window_set_default_icon_name(), and possibly do other setup based on loadable modules, like initializing the bug-buddy signal handlers if the .desktop file includes X-GNOME-Bugzilla- keys, etc. Yeah, there is a clear need for this when implementing the Gnome desktop. But its sort of unix specific, so maybe it doesn't have to be in the very low levels of the stack. OTOH, its not really a large piece of code, especially given GKeyFile. non-GUI apps might need it also, like the new documentation indexer (Spoon - http://live.gnome.org/Yelp/Spoon). In fact, it would be great if this GDesktopAppInfo implemented a .desktop cache, which is much needed for gnome-main-menu and, probably, for spoon. What is Spoon? The risk of adding a specialized thing like a desktop cache to a general library like glib is that it will by accident cause cache bloat in apps that don't require the cache, while at the same time not being aggressive enough on cacheing, and have the special apis needed for the case of the panel. Also, I just don't think every gnome application needs to link in the code that reads the panel menu. Of course, it's still unix-specific, as you say, so why not have an implementation for that, on Windows, that reads the Start menu? Not sure if that would work GAppInfo is already an abstraction and it has an windows implementation using the registry and the win32 shell apis. However, its an abstraction of file-app associations, not of the desktop menu. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a witless small-town romance novelist who dotes on his loving old ma. She's a beautiful Bolivian stripper with only herself to blame. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
Hi, On Mon, 2007-03-26 at 19:06 -0600, Federico Mena Quintero wrote: I was looking at the GtkTreeView code and it looks like there are other places that could get the array treatment. One place in particular was the sorting machinery... GtkListStore also uses a GList of information for the sort headers, and walks the list in g_list_store_compare_func (!). Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal, because their length is not constant. We would end up to alloc/dealloc/copy sequence when adding new items. They are also accessed according to sort_id (which can come from application program and are not neccesarily contiguous). This means that if we would have an ordered vector we could reach O(log n) search time. Yes, it's better than current O(n) one. However, why this step is needed at all for each comparisison!! It's certainly the case that there will be more sort function calls than changes to sort criteria. This would allow us to cache the pointer to active GtkTreeDataSortHeader directly, providing us constant time O(1) access. Or did I miss something? -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Idea for GSoC 2007 : Shortcuts improvement
On Sun, 2007-03-11 at 19:38 -0300, Lucas Mazzardo Veloso wrote: 2007/3/11, Steve Frécinaux [EMAIL PROTECTED]: What's harder is to play nice with the shorcuts that are already defined, like mnemonics and regular shortcuts (Shouldn't ctrl+n appear directly near the new icon from the toolbar ?). Really nice you have pointed it out. Yes, it should. In fact, already defined shortcuts should work without any (or with minimal) code modifications. So, when users holds CONTROL, all those already defined shortcuts have to pops-up. This must be the project primary goal. One problem you'll have to address there, then, is that keys like Ctrl are often used as modifiers for drag-and-drop. And you wouldn't want the shortcuts to pop up while you were dragging something-- not even in the brief moments between holding down Ctrl and starting to move the mouse. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Warning about reaped children
Hi,
I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes()
and ended up scratching my head about why my GChildWatch callback wasn't
firing. After some hot strace action and RTFM, I added that flag and
everything worked perfectly. Do we need a warning like the one in the
attached patch?
Federico
--- gmain.c~ 2007-01-22 11:12:44.0 -0600
+++ gmain.c 2007-03-29 15:38:01.0 -0600
@@ -3605,12 +3605,21 @@ check_for_child_exited (GSource *source)
if (child_watch_source-count count)
{
gint child_status;
+ GPid pid;
- if (waitpid (child_watch_source-pid, child_status, WNOHANG) 0)
+ pid = waitpid (child_watch_source-pid, child_status, WNOHANG);
+
+ if (pid 0)
{
child_watch_source-child_status = child_status;
child_watch_source-child_exited = TRUE;
}
+ else if (pid == -1 errno == ECHILD)
+ g_warning (waitpid() for process %d returned ECHILD. Did you launch the process
+ with g_spawn_async*() but forget to pass G_SPAWN_DO_NOT_REAP_CHILD?
+ The notification about child termination will not be emitted!,
+ child_watch_source-pid);
+
child_watch_source-count = count;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit : On 3/14/07, Tim Janik wrote: Hello Foundation Board. Hello GTK+ team. The Gtk+ project is in dire lack of new maintainers, mostly to review (...) Thanks for this report, and actually thanks for the first report you sent back in Christmas. On thaty time the board was in transition, but we already took your points and since then this has been one of the main points in our agenda. This is why GTK+ was one of the 2 main issues presented to the advisory board members this week, together with Documentation. There are lots of aspects to fix and improve in the GNOME project, but the board has decided to put these two on top of the agenda. A practical conclusion of the discussion this week was that we need a space for discussion where the GTK+ team, the board, the advisory board companies and probably any other key GTK+ contributor / stakeholder / user can share this discussion. An official channel where we can hold a discussion from these different perspectives in order to solve the main issues and push GTK+ to the bright horizon it deserves. This channel might be online+offline, something like a combination of a specific mailing list + meetings in relevant conferences + ... The GTK+ core team has the initiative proposing the space and the bootstrapping process of collaboration. Let's use this list to decide the new channel. I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote: Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit : On 3/14/07, Tim Janik wrote: Hello Foundation Board. Hello GTK+ team. The Gtk+ project is in dire lack of new maintainers, mostly to review (...) Thanks for this report, and actually thanks for the first report you sent back in Christmas. On thaty time the board was in transition, but we already took your points and since then this has been one of the main points in our agenda. This is why GTK+ was one of the 2 main issues presented to the advisory board members this week, together with Documentation. There are lots of aspects to fix and improve in the GNOME project, but the board has decided to put these two on top of the agenda. A practical conclusion of the discussion this week was that we need a space for discussion where the GTK+ team, the board, the advisory board companies and probably any other key GTK+ contributor / stakeholder / user can share this discussion. An official channel where we can hold a discussion from these different perspectives in order to solve the main issues and push GTK+ to the bright horizon it deserves. This channel might be online+offline, something like a combination of a specific mailing list + meetings in relevant conferences + ... The GTK+ core team has the initiative proposing the space and the bootstrapping process of collaboration. Let's use this list to decide the new channel. I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? If it's going to be a public discussion then it should be on gtk-devel-list. It would be silly to create a new mailing list just to discuss this one subject. If it's meant to be a private discussion then a CC list will probably do it, with the advisory and board lists in it. You might also want to arrange an extra conference call with the advisory board if that's more to their liking. But that will probably take 2 or 3 months to arrange. I'm disappointed that this has been turned into a discussion about discussing. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Supporting Gtk+ Maintenance
Hi Murray, Le jeudi 29 mars 2007, à 23:27, Murray Cumming a écrit : On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote: I'm wondering if gtk-devel-list is the place where the discussion about collaboration should be happening: I don't know if having a mix of technical discussions and collaboration discussions is good or not. Having a separate mailing list might help, but it might also be a stupid idea :-) What does the GTK+ team think? If it's going to be a public discussion then it should be on gtk-devel-list. It would be silly to create a new mailing list just to discuss this one subject. If it's meant to be a private discussion then a CC list will probably do it, with the advisory and board lists in it. My point is: this is up to the GTK+ team to decide. I personnally don't think there'll be anything private. You might also want to arrange an extra conference call with the advisory board if that's more to their liking. But that will probably take 2 or 3 months to arrange. This is definitely something we'll do if people feel it's necessary. I'm disappointed that this has been turned into a discussion about discussing. We're only trying to know how the GTK+ team wants to work. This is only a first step :-) Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Idea for GSoC 2007 : Shortcuts improvement
Hi 2007/3/29, Calum Benson [EMAIL PROTECTED]: One problem you'll have to address there, then, is that keys like Ctrl are often used as modifiers for drag-and-drop. And you wouldn't want the shortcuts to pop up while you were dragging something-- not even in the brief moments between holding down Ctrl and starting to move the mouse. You have a really good point here I haven't thought about before. I agree with you, the accelerators shouldn't be shown during a DnD event. The simplest solution might be to grab the pointer modifier mask and if it has an active GDK_BUTTON1_MASK we shouldn't pop up the shortcuts. If we have a pressed mouse button1, even if it's not necessarily a DnD, our user is probably doing something relevant and we must avoid distracting the user from the current task. I believe it is valid for all the mouse buttons as well. No doubt it is an important design decision we will need to take! Thanks for your feedback, Calum! Regards, Lucas -- This email recommends Free and Open Source Software (R) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
