Re: Multi-threaded UI Freezes on GDK Call
On Tue, 18 Dec 2007 22:52:23 +0100 G Hasse [EMAIL PROTECTED] wrote: The wrong thing is trying to do threads! Why Why Why are all people doing this thread programing! I am convinced that with a propper design of your application, maybe in several processe, you don't need threads and your problem will go away... No, threads are not the problem. Not keeping ALL GUI-related things in ONE thread is the problem. I may have been missing the point, but it seems that this is the core of the OP's troubles. The problem with threads is that few beginners understand what they actually are. --D. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 20:37 -0500, Michael McCann wrote: Yes, I've already tried that, to no avail. My code basically only consists of: gdk_screen_get_default(): Get the default screen gdk_screen_get_root_window(): Get the root window gdk_pixbuf_get_from_drawable(): Get a pixbuf from the entire screen gdk_pixbuf_save_to_bufferv(): Save the pixbuf to a buffer. taking a screenshot of the root window takes a considerable amount of time, depending on the size of the screen and the amount of windows on it. gnome-screenshot forks in the background to avoid blocking the UI; since GDK cannot be called from multiple threads, forking is the only option you have. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Button Callbacks
Vroni wrote: Hi guys, I have this really dumb problem, but I can´t get my head around it. My program should do the following: - When a button is pressed, a specific playlist[m3u]-file should be opened in the media player. Sure, the first part is to add a callback for the buttons, but how do I open the file (and with it the media player. It should do the same as a double click on the file would)? Is it even possible to do do it this way? In a terminal, you'd do: $ xdg-open /path/to/playlist.m3u In your callback you'd probably want to use system() or g_spawn_async(), see the man pages and http://www.gtk.org/api/2.6/glib/glib-Spawning-Processes.html tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: App blueprint, advice please!
Patrick wrote: Lets say a customer had a detector and a pump to pump a sample through it. We could write a Bash script that works something like this: -icon launches Bash script -sends variable 2 to pump command to pump 2 ml per minute -pump command sends signal to serial port or GPIB bus, etc -bash sends variable 230 to set the detector to wavelength 230 nm -bash autozeros detector -launches plot command -after that launches data process command -then launches database storage command - emails whoever, turns your coffee maker on or whateveretc..etc Seems to me that the lingua franca of this kind of scientific instrument control and data collection is LabView. Most institutions already have site license for this software. LabView is ideal for several reasons: - Works with most GPIB cards, indeed most interface cards come with labview drivers - Easy graphical environment. Lets you chain things together (in a similar manner to bash, actually), but it's all within the program, rather than kludging together non-integrated programs. Plus it's all in-process. No external spawning things needed, which is expensive. - Royalty free code. You can sell you vi programs or give them away, or whatever. They aren't compiled, but can be obfuscated, or not. So you could sell labview code that people could modify. On the other hand, there's no reason why you couldn't use GTK and, say, Python to do similar things provided that you have drivers for the GPIB boards, and have a well-defined interface that you can use to easily build modules that you can string together. Certainly I don't believe C is the appropriate language to do any gluing. I would recommend python. Data collection modules that need to be close to the hardware can be done in C, but the rest could easily be done in python. If you defined a protocol for modules to communicate with each other, then you can very easily string modules together, hooking data out buses on one module (object) with the data in on another module. The GTK signals and slots mechanism would make this quite easy to do, all in-process. Michael It's a terrible over simplification but hopefully illustrates the idea. I only have a few hundred dollars to put towards this now but hopefully by the later half of 2008 it will be a few thousand. Please feedback with any thoughts you might have on this whole process. Thanks-Patrick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Michael Torrie Assistant CSR, System Administrator Chemistry and Biochemistry Department Brigham Young University Provo, UT 84602 +1.801.422.5771 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problems to compile gtk with jhbuild + imendio patchs
Hi guys, Sorry if is the wrong place to post this, but im having problems in compile Gtk with Quartz support through imendio patchs using jhbuild, All packages compiles very well, but when i try compile gtk i have this error: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../modules/other -I../../../gdk -I../../../gdk -I../../../gtk -I../../../gtk -DGTK_VERSION=\ 2.15.0\ -I/opt/gtk/include -D_REENTRANT -I/opt/gtk/include/glib-2.0-I/opt/gtk/lib/glib- 2.0/include -I/opt/gtk/include/pango-1.0 -I/opt/gtk/include/cairo -I/opt/gtk/include/libpng12 -I/opt/gtk/include/atk-1.0 -DG_ENABLE_DEBUG -DG_ERRORCHECK_MUTEXES -DG_DISABLE_DEPRECATED -O -gstabs+3 -std=gnu89 -Wall -MT libgail_la-gailwindow.lo -MD -MP -MF .deps/libgail_la-gailwindow.Tpo -c gailwindow.c -fno-common -DPIC -o .libs/libgail_la-gailwindow.o gailwindow.c: In function 'gail_window_get_name': gailwindow.c:349: warning: passing argument 1 of 'gtk_container_get_children' from incompatible pointer type gailwindow.c:1093:2: error: #error Port to this GDK backend make[5]: *** [libgail_la-gailwindow.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I try find something in google but no success. If i remove the #if GDK_WINDOWING_WIN32 things, compiles but then when i try link others librarys ldconfig throws a error. Any idea whats wrong ? Cheers -- A fé remove montanhas, mas eu prefiro a dinamite ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 00:58 -0500, David Zeuthen wrote: Hi, Here's a new set of patches http://people.freedesktop.org/~david/gio-4.patch http://people.freedesktop.org/~david/gvfs-4.patch http://people.freedesktop.org/~david/nautilus-4.patch There's a description in ChangeLog and comments below I commited this with some small changes: Renamed fuse_name to stable_name Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor. OK, I've fixed this. Was simply a typo where the value was used instead of the key in g_hash_table_remove(). Sweet. I don't see an obvious easy solution. It requires some work. The ideal thing to match with is an GMountSpec (which is basically the set of key-value pairs that define a gvfs mount). For a GDaemonMount this is availible in the GMountInfo object. Thats a gvfs-specific object though, so we can't make that availible in the base GVolume apis. What if we add some new vtable calls in GVolumeMonitor like find_volume_for_new_mount() and find_mount_for_new_volume() which we have GUnionVolumeMonitor call on the installed backends when new, unowned volume/mounts are added. I think I've come up with a pretty nice solution; see the new function g_volume_monitor_adopt_orphan_volume() in the gio patch. I'm thinking this can also be used for the favorite servers like we have today in gnome-vfs; e.g. we just implement a volume monitor that creates GVolume objects that matches a list in gconf. Then when the mount is actually created the volume monitor adopts the DaemonMount in it's adopt_orphan_mount() function. So, can there never be a situation where the GMount gets created before the corresponding GVolume object is? And in that case, how does the GVolume locate the mount? Other thoughts / questions about the API - Busy mounts. Right now the cdda:// backend refuses to unmount if there are open files on it. I think that's probably the right thing to do for any backend. Probably means we need to add flags to the unmount() calls; the flags used in Linux, e.g. - force unmount - lazy unmount comes to mind. While I can sort of see the usecases for these, aren't we sort of overcomplicating the API here? Is this really required? When and how would the user force unmount or lazy unmount something? (Or the reverse, if there is a case for one of these when should we not do it.) - Further, if a mount can't be unmounted because it's busy (and we can't avoid that since we support mounts backed by kernel drivers), we probably want something like lsof(8) that Nautilus and other stuff can use to put up a dialog showing what apps is blocking the unmount. How about a list_open_files() method on GMount() that returns an array of - process id (is that portable? maybe need an abstraction) - icon - name - etc. Would need backend support for this too. Now we're getting into really lowlevel bizarro things. I don't think we should really expose this in a generic API. Can't this just be reported in the error message for the G_IO_ERROR_BUSY error when unmounting. I.E. the error dialog would say Cannot unmount, because firefox (pid 35) is keeping files open on the volume, or Cannot unmount, because 13 applications are keeping open files on the volume.. Maybe in the last case we should at least give the name (and pid?) of one application so that you can make progress on unmount by killing that. - Mount options. Do we need this? At least for std file systems such as vfat and ntfs people still use it at least judging from bug reports. There's actually (very horrible) UI in gnome-mount for this crap http://people.freedesktop.org/~david/gm-prop/gm-prop2.png I don't know; maybe that's specific to each gvfs backend and the hal volume monitor. Ideally I want to ditch gnome-mount and just make the hal volume monitor call directly into HAL. I do believe we want some form of mount options. For instance, a very common request is to be able to specify the filename encoding of e.g. a ftp share. However, I don't think the right place for this is as API arguments for the mount call. Instead i think these are more like preferences for each mount point, that we can store somewhere and that gvfs automatically picks up each time you mount that particular share. I haven't sat down and worked out all the details about this though. - g_file_read() and g_file_read_async() probably needs to take a GFileReadFlags value. See my other mail about the cdda:// backend in this thread. pasted here: - have an operation on GInputFileStream to set/clear flags. Am unsure whether there should be a dedicated SKIP_SCRATCHED_AREA flag or whether it should overload a standard one. We should probably also default to !SKIP_SCRATCHED_AREA. Now, common sense dictates that it's probably not alright to add such public API to gio with the cdda:// backend
Re: g_format_file_size_for_display()
The practical use of such a function is to give the user a general idea of the size. Hence a 2.4% (k), 4.9% (m), or 7.4% (g) difference will not change the picture. However, something people need the full story. Therefore, the friendly application using such a function should probably consider having a tooltip telling the full story. That would be a good time to show things like read-only too. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkFileChooser and GVFS backend
On Dec 19, 2007 4:00 AM, Alexander Larsson [EMAIL PROTECTED] wrote: Yes, both of these are part of the long-term plan. However, we need to have the GtkFileSystem module for the next gnome module, as that will have the new glib, but not a new Gtk+. Talking about that... we need a plan for how to handle the gvfs filechooser backend for 2.22. I think it will be best to put it in libgnomeui, next to (or replacing) the gnome-vfs backend thats already there. After 2.22 we can look at moving it over to gtk itself, or doing something better. Does that sound reasonable ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Draw on a GtkFixed Widget with Cario and place some widgets inside?
Hi out there :) i have few questions i have to write a new tool for my work its something like a node based node editor so the nodes must be connect via splines and as content the node must have a tree view for the properties. So my first thought was to use GtkFixed get the drawable and draw something with cario on it and then place some treeviews widgets inside so do guys think it is possible? Concrete: 1) Can i draw on a GtkFixed with cario 2) Can i control the draw order from treeviews that the will draw after cario on the widget. I mean can i handle this with the realize signal and propagate it manual to the childs? without perm flushing? -- View this message in context: http://www.nabble.com/Draw-on-a-GtkFixed-Widget-with-Cario-and-place-some-widgets-inside--tp14421717p14421717.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Draw on a GtkFixed Widget with Cario and place some widgets inside?
On Dec 19, 2007 6:36 PM, Wolfman [EMAIL PROTECTED] wrote: i have few questions i have to write a new tool for my work its something like a node based node editor so the nodes must be connect via splines and as content the node must have a tree view for the properties. So my first thought was to use GtkFixed get the drawable and draw something with cario on it and then place some treeviews widgets inside so do guys think it is possible? Have you looked at GooCanvas? http://sourceforge.net/projects/goocanvas It's a Cairo canvas widget. I believe you can embed GTK+ widgets inside it. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Draw on a GtkFixed Widget with Cario and place some widgets inside?
jcupitt wrote: Have you looked at GooCanvas? ... I took a quick looks nice i could give try but that doesnt answer my question :) Cause if the things i mentioned above are possible i could make something smaller and leaner. -- View this message in context: http://www.nabble.com/Draw-on-a-GtkFixed-Widget-with-Cario-and-place-some-widgets-inside--tp14421717p14424216.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
Hi again, Almost more questions than answers this time, sorry. Also no patch either since I wanted to hear your thoughts before doing the work. On Wed, 2007-12-19 at 11:43 +0100, Alexander Larsson wrote: I commited this with some small changes: Renamed fuse_name to stable_name Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor. Great, thanks! I'm thinking this can also be used for the favorite servers like we have today in gnome-vfs; e.g. we just implement a volume monitor that creates GVolume objects that matches a list in gconf. Then when the mount is actually created the volume monitor adopts the DaemonMount in it's adopt_orphan_mount() function. Btw, is this how we should implement it? Or did you have anything else in mind? I really miss my public_html @ p.fd.o link that comes up automatically - I use it a lot when doing screen shots to share. I think if we do the feature this way (a gvfs module that links in gconf) it can be written in a day or less. So, can there never be a situation where the GMount gets created before the corresponding GVolume object is? And in that case, how does the GVolume locate the mount? That's a good question; it's not supported in the API yet because that situation can never happen for the use I wrote it for (cdda:// backend). How about a another vtable entry in the GVolumeMonitor gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter, GMount *orphan); that each implementation can implement? Alternatively we can put this method on the GMount interface but that seems wrong since it's only something volume monitors would ever want to do. Other thoughts / questions about the API - Busy mounts. Right now the cdda:// backend refuses to unmount if there are open files on it. I think that's probably the right thing to do for any backend. Btw, what are you thoughts about this? I feel strongly this is the right thing to do .. otherwise you can lose data. I'd even go as far and say that the GVfsBackend base class should automatically return G_IO_ERROR_BUSY on unmount() when there are pending jobs. At least that would be the default unmount() operation unless you override it. Probably means we need to add flags to the unmount() calls; the flags used in Linux, e.g. - force unmount - lazy unmount comes to mind. While I can sort of see the usecases for these, aren't we sort of overcomplicating the API here? Is this really required? When and how would the user force unmount or lazy unmount something? (Or the reverse, if there is a case for one of these when should we not do it.) - Further, if a mount can't be unmounted because it's busy (and we can't avoid that since we support mounts backed by kernel drivers), we probably want something like lsof(8) that Nautilus and other stuff can use to put up a dialog showing what apps is blocking the unmount. How about a list_open_files() method on GMount() that returns an array of - process id (is that portable? maybe need an abstraction) - icon - name - etc. Would need backend support for this too. Now we're getting into really lowlevel bizarro things. I don't think we should really expose this in a generic API. Can't this just be reported in the error message for the G_IO_ERROR_BUSY error when unmounting. I.E. the error dialog would say Cannot unmount, because firefox (pid 35) is keeping files open on the volume, or Cannot unmount, because 13 applications are keeping open files on the volume.. Maybe in the last case we should at least give the name (and pid?) of one application so that you can make progress on unmount by killing that. Right, I definitely think we want the dialog to look something like this +---+ | Cannot unmount public_html @ p.fd.o, the following | | applications are still using it | | | | [icon] GEdit - Secret Stuff.txt[kill] | | [icon] GEdit - My Diary.txt[kill] | | [icon] Tomboy [kill] | | [icon] /bin/cat[kill] | | | | [Cancel] | +---+ (dunno what icon / wording to use for [kill] though. Maybe there could also be a [switch to] button that dismisses the dialog (or not?) and takes you to the application) Stuffing all these details into the GError doesn't seem at all reasonable. So I think a simple g_mount_list_open_files() function is what we need (need an async function too). Anyway, In fact, I think we want such a dialog in the next gtk+ release: GtkWidget *gtk_io_unmount_busy_dialog_new
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote: Another thought: we probably need a way to learn more about the GDrive, GVolume and GMount objects than just their names and icons. First, cf. the network applet use, we need to know if the mount is networked or not and if it is, what hostname is it using. Simple proposal Attached are some unfinished patches that illustrate this idea; notes - flags are replaced by textual strings (notice the resemblance to mime types?) - content sniffing happens in a thread when done async - no actual sniffing is done; should be trivial to add though - needs work in the drive classification bits. - There's some other stuff I wanted to propose regardless of this - get_id() on GDrive,Volume,Mount: needed to pass these around - model,vendor on GDrive; some apps (notably the cd burner ones) will need this for user selection when having multiple drives Anyway, with this patch it should be simple to abuse the .desktop file format and add something x-content/video to e.g. Totem's and mplayer's desktop files. Then we can easily add machinery to the Preferred Applications capplet for choosing the default video player and we can finally get rid of this ugly entry boxes http://people.freedesktop.org/~david/g-v-m-prefs.png Ditto for the other x-content/* formats. This is a problem we haven't been able to solve for three years... If you like this idea, here are the next steps I'm going to do - Finish the patch - Propose x-content/* and x-drive/* types as a fd.o spec on xdg-list - Make the directory sniffing code plug-in based (I expect we want to update this code rather frequently, it's a bit like shared-mime-info) Anyway, the whole idea may be crack (I don't think so though), but you can't accuse me of not thinking in a user document centric way with this :-) David Index: gunixmount.c === --- gunixmount.c (revision 6163) +++ gunixmount.c (working copy) @@ -178,6 +178,14 @@ } static char * +g_unix_mount_get_id (GMount *mount) +{ + GUnixMount *unix_mount = G_UNIX_MOUNT (mount); + + return g_strdup (unix_mount-mount_path); +} + +static char * g_unix_mount_get_name (GMount *mount) { GUnixMount *unix_mount = G_UNIX_MOUNT (mount); @@ -393,6 +401,7 @@ { iface-get_root = g_unix_mount_get_root; iface-get_name = g_unix_mount_get_name; + iface-get_id = g_unix_mount_get_id; iface-get_icon = g_unix_mount_get_icon; iface-get_uuid = g_unix_mount_get_uuid; iface-get_drive = g_unix_mount_get_drive; Index: gdrive.c === --- gdrive.c (revision 6163) +++ gdrive.c (working copy) @@ -146,13 +146,35 @@ } /** + * g_drive_get_id: + * @drive: a #GDrive. + * + * Get an opaque textual identifier that can be used to pass a + * reference to @drive between processes. + * + * Returns: a string containing @drive's id. The returned string + * should be freed when no longer needed. + **/ +char * +g_drive_get_id (GDrive *drive) +{ + GDriveIface *iface; + + g_return_val_if_fail (G_IS_DRIVE (drive), NULL); + + iface = G_DRIVE_GET_IFACE (drive); + + return (* iface-get_id) (drive); +} + +/** * g_drive_get_name: * @drive: a #GDrive. * * Gets the name of @drive. * - * Returns: a string containing @drive's name. The returned - * string should be freed when no longer needed. + * Returns: a string containing @drive's name. The returned string + * should be freed when no longer needed. **/ char * g_drive_get_name (GDrive *drive) @@ -167,6 +189,50 @@ } /** + * g_drive_get_vendor: + * @drive: a #GDrive. + * + * Gets the vendor of @drive. + * + * Returns: a string containing @drive's vendor or %NULL if no such + * name could be found. The returned string should be freed when no + * longer needed. + **/ +char * +g_drive_get_vendor (GDrive *drive) +{ + GDriveIface *iface; + + g_return_val_if_fail (G_IS_DRIVE (drive), NULL); + + iface = G_DRIVE_GET_IFACE (drive); + + return (* iface-get_vendor) (drive); +} + +/** + * g_drive_get_model: + * @drive: a #GDrive. + * + * Gets the model of @drive. + * + * Returns: a string containing @drive's model or %NULL if no such + * name could be found. The returned string should be freed when no + * longer needed. + **/ +char * +g_drive_get_model (GDrive *drive) +{ + GDriveIface *iface; + + g_return_val_if_fail (G_IS_DRIVE (drive), NULL); + + iface = G_DRIVE_GET_IFACE (drive); + + return (* iface-get_model) (drive); +} + +/** * g_drive_get_icon: * @drive: a #GDrive. * @@ -468,5 +534,65 @@ return (* iface-poll_for_media_finish) (drive, result, error); } +/** + * g_drive_get_classification: + * @drive: a #GDrive. + * + * A #GDrive is an abstraction of a storage device connected to the + * system. As many popular consumer electronic devices, such as + * phones, music and video players, GPS devices and so on appear to + * the operating