Hi everyone,
i am experiencing random problems here if i use g_main_loop_quit from a
different thread than where the GMainLoop runs.
my program looks like this:
1. in main: create a new context and a new loop
2. spawn a thread
3. call g_main_loop_run in the thread on the previously created loop
Hi all
Can anyone tell me what kind of widget is used in the left
side of the main window of Evolution mail client ?
I found some probable stuff in the GAL library (e-shortcut-bar)
but I would need that widget showing a treeview-like menu as
evolution does.
Waiting for some clue, many
Armin Bauer wrote:
Hi everyone,
i am experiencing random problems here if i use g_main_loop_quit from a
different thread than where the GMainLoop runs.
my program looks like this:
1. in main: create a new context and a new loop
2. spawn a thread
3. call g_main_loop_run in the thread on the
Tristan Van Berkom wrote:
My guess is that it just doent make sence to remove the mainloop
while the other thread is sleeping in poll(), sure the code will lock
its mutex and everything; but when the other thread wakes up;
how could it deal with a gone mainloop ?
Scratch that; doesnt make any
On Thu, Mar 09, 2006 at 01:23:38PM -0500, Carlos Savoretti wrote:
Hi all
Can anyone tell me what kind of widget is used in the left
side of the main window of Evolution mail client ?
The source code of Evolution is freely available, so anyone
can tell by looking there (but no, I did not look
Armin Bauer wrote:
Is this a known problem or am i doing something wrong?
Heh, I think I figured it out; I think that after calling
g_main_loop_quit();
if the thread is sleeping, you'll have to call g_main_context_wakeup() on
it for _run() to return; I wonder if that is a bug or should be
Tristan Van Berkom wrote:
Armin Bauer wrote:
Is this a known problem or am i doing something wrong?
Heh, I think I figured it out; I think that after calling
g_main_loop_quit();
if the thread is sleeping, you'll have to call g_main_context_wakeup() on
it for _run() to return; I
Hi,
I use glib on windows to allocate memory for a camera. Its DLL then
uses the memory and pass it to the kernel and fill it via DMA. I have
to be sure that windows doesn't move my buffer(s) later since the
kernel has built its allocation table using it.
With windows there are functions to
There is a TreeView widget whose TreeSelection's mode is SELECTION_MULTIPLE.
I'd like to change how a single mouse click (and any of the equivalent actions
from the keyboard and other input methods) on a row impacts the selection. The
rest of the selection UI should behave as usual: Ctrl+click