Dmitry Konyshev wrote:
> Have you already tried to attach to the hung process with gdb? You
> should be able to see in which point the process hangs.
>
> Aren't there another threads that update the GUI? Do they all have gtk
> functions calls protected with the lock?
Heh, I sort of figured out th
Dmitry Konyshev wrote:
You can use gdb to set up a break point in your function and see how
execution flow gets to your function and in which thread's context.
Okay, I did this. You were totally right:
The callbacks are called within the context of the main thread. Still,
the program hangs whe
Dmitry Konyshev wrote:
gnome-vfs sources, file gnome-vfs-job.c, function job_notify. It adds
idle handler, that calls the callback, to the main loop. It doesn't call
the callback function by itself in its own thread.
That's good to know of course, thanks.
In other words, the crash occuring in
Dmitry Konyshev wrote:
gnome-vfs seems to send its notifications in context of the main thread.
I don't know. Does it? It almost seems so when looking at the Nautilus
source, but I haven't read anything about that in the documentation.
Afterall, its purpose is to allow for transfers running a
Dmitry Konyshev wrote:
When the lockup actually happens? You mustn't use the lock in the
dialog's event handlers, 'cause they get called in context of the main
thread with the lock already acquired.
No, it's happening in a gnome-vfs signal handler. No Gtk lock is
acquired there.
Nau is open
For a better understanding of my problem, please have a look at this
function, which is called from a thread running parallel to the thread
owning the Gtk lock:
(Please notice the comments!!)
/// Handles a file overwrite request encountered during a transfer.
int TransferDirector::handle_status
Tim Janik wrote:
you can use gtk functions from any thread, as long as you take care to
acquire the gtk lock around any gtk functions:
GDK_THREADS_ENTER ();
fire up dialog here.
GDK_THREADS_LEAVE ();
Yep, I could do that. However I was told that the cleaner approach is to
use a dispatch
Hi,
I want to display a message dialog from a thread B running parallel to
the Gtk main thread A (it's a thread invoked by the async transfer
methods from gnome-vfs). When running the dialog directly, the program
locks up, which is what I expected since Gtk is not thread safe.
So I downloade
Original Message
Subject:Re: Feature request: Number of matches in Gtk::EntryCompletion
Date: Sat, 23 Apr 2005 01:10:47 +
From: rob page <[EMAIL PROTECTED]>
Reply-To: rob page <[EMAIL PROTECTED]>
To: Matthias Kaeppler <[EMAIL PROTECTED]
Murray Cumming wrote:
On Mon, 2005-04-11 at 16:31 +0200, Matthias Kaeppler wrote:
Murray Cumming wrote:
On Mon, 2005-04-11 at 12:47 +0200, Matthias Kaeppler wrote:
Murray Cumming wrote:
You don't have to call foreach() on each row. But if you really want to
examine each selection wheneve
uting something
(probably calling a huge bunch of signal handlers).
--
Matthias Kaeppler
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Murray Cumming wrote:
On Mon, 2005-04-11 at 12:47 +0200, Matthias Kaeppler wrote:
Murray Cumming wrote:
You don't have to call foreach() on each row. But if you really want to
examine each selection whenever the selection changes, what's the
alternative?
Hopefully you more often want to
Murray Cumming wrote:
On Mon, 2005-04-11 at 12:47 +0200, Matthias Kaeppler wrote:
Murray Cumming wrote:
You don't have to call foreach() on each row. But if you really want to
examine each selection whenever the selection changes, what's the
alternative?
Hopefully you more often want to
. Then you wouldn't have to call
foreach() on them all.
That's correct, but how can I achieve this? It would be enough for me to
only know the first and last row which is among the selection. Maybe
even only the last.
--
Matthias Kaeppler
___
gtk-l
you to set your processing to be triggered after the
delay. source_remove is needed so that you can cancel an earlier
timeout_add when you get a second 'selection_changed' event.
Hope that helps.
John
Matthias Kaeppler wrote:
Andrew E. Makeev wrote:
> I think, it is not GTK+ neither GTKMM
.
Regards,
-andrew
Hm, I'm not sure what you mean, can you elaborate on that? Sorry for my
ignorance, I'm fairly new to the whole Gtk thing.
--
Matthias Kaeppler
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
.
Regards,
-andrew
Hm, I'm not sure what you mean, can you elaborate on that? Sorry for my
ignorance, I'm fairly new to the whole Gtk thing.
--
Matthias Kaeppler
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
17 matches
Mail list logo
