Gtk+ 3 Quartz
Is anyone on this list using the quartz back end for 3.x? I'm experimenting with osx for the first time years, and I forgot what a nightmare that platform is. Anyway, trying to stay constructive, what exactly are you using? As in os version number - regular jhbuild? mac ports? other? The X11 back end for 3.x works fine (via mac ports). Yes I know I can't mix mac ports etc. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Formatting dates according to the region
On Mon, Apr 16, 2012 at 12:13 PM, Michael Cronenworth m...@cchtml.com wrote: Look at the documentation for g_date_time_format(). You will find the other format specifiers that you want. %a, %A, %b, %B, and %c look helpful for you. Thanks for your suggestion, but the trouble I have with those is I would still need to make assumptions about the order each part comes in, and the way they're presented, in a full date. I guess what I'm looking for is a repository of complete date formats that have already been localized, which is what g_date_time_format(%x) feels like but only with a particularly prickly format. Dylan If you are on a reasonably up to date GNU libc based system (ie Linux), then at least usually %c of strftime() works. (man strftime). The runtime logic is based around the environment variables (TZ), so testing is required to make sure you are getting the results you want in gnome or any other desktop environment. The portability of this is limited though. On windows the libc time routines are not only severely broken (anything to do with historical time for instance) in all versions, but broken in different ways. To a limited extent, some measure of locale configurability can be achieved with the winapi. I haven't made it to exploring this topic on osx and others. --- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GSource object lifetime
trying to stop a memory leak (2.24.1 x86_64)... I'm repetitively calling g_idle_source_new(), g_source_set_callback(), g_source_attach() to get an idle callback to run in a separate thread. The callback in question always exits with FALSE. The docs for GSourceFunc() state: ... Returns : it should return FALSE if the source should be removed. ... Does removed mean frees up the idle source, or just undoes the g_source_attach()? Should I be trying to reuse the idle source? I was destroying and recreating a time out source, but finally gave that up and just let it tick all the time. That stopped a leak in another program so that's why I was wondering... -- www.thomasstover.com FLYNN LIVES! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GSource object lifetime
On Tue, 3 May 2011 22:06:02 +0200, Tadej Borovšak tadeb...@gmail.com wrote: Hi. I'm repetitively calling g_idle_source_new(), g_source_set_callback(), g_source_attach() to get an idle callback to run in a separate thread. The callback in question always exits with FALSE. Do you call g_source_unref() after attaching it? Cheers, Tadej. That did help (I think I still have an unrelated leak). I think a few things could be made more clear in the docs (I'm not 100% sure I'm correct either): -A newly created source (from g_idle_source_new() ) has a reference count of 1 not 0. -g_source_attach() increases the reference count by 1 -returning FALSE in a source callback function detaches the source from the source's attached main context, and decreases the reference count by 1 -Once a source has been detached by source callback function returning FALSE, it can not be reattached g_source_attach(). An assertion error is thrown. You can however, decrease the source's reference count down to 0 so it will free itself, then create a fresh source. -- www.thomasstover.com FLYNN LIVES! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GSource object lifetime
On Tue, 3 May 2011 22:50:38 +0200, Tadej Borovšak tadeb...@gmail.com wrote: All that being said, maybe you could cook up a patch for API docs with this info? I'm sure people would find it useful. Is there a starting place to read how to go about doing that? -- www.thomasstover.com FLYNN LIVES! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_atomic_int_compare_and_exchange
I was just looking at gatomic.c to see if g_atomic_int_compare_and_exchange() would work on an integer inside memory obtained by mmap(MAP_SHARED) safely between processes. With my limited understanding it looks like it probably would except for the cases when it has to fall back to g_mutex_()* ops on g_atomic_mutex. I started to look at gthread.c to see if the mutex implementations themselves might be based on inter-process capable mutex technologies, but I'm not following along so well in there. So my questions are: -were any of the atomic functions intended for process shared memory or just thread shared memory? -even if that is not the case, would the non-mutex based implementations work in that fashion? -is there a way to test for what implementation is being used? (if it maters) -- www.thomasstover.com NO CARRIER ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk+3 xcb asynchronous X11
The talk of gtk 3 coming down the line reminded me a an old question I once had. I remember reading a paper analyzing X11 performance problems that concluded drawing operations were slowed because the synchronous nature of xlib required steps to wait for round trip traffic completion notifications before moving on to the next step. Then later on when the xcb library came out one of the cited reasons for its existence was that it provided a way use the X11 protocol asynchronously. Whether or not any of this is true, I have no idea. However, there is a xcb cairo backend, which always made me curious. Other than multi touch and clutter I haven't really been paying attention. Is xcb something entering the picture in gtk 3? -- www.thomasstover.com NO CARRIER ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
win32 win64 Gtk+ apt repo?
We are moving to the deb packaged win32 win64 mingw cross compilers that are available in the ubuntu 10.4 apt repositories, instead of home-built ones. This btw is awesome! With almost all of our windows development now completely ubuntu hosted, the notion of using .deb packaged win32/64 development and run time library files is pretty obvious. It certainly feels like more and more people are thinking this same way. Does anyone know of any apt repositories out there that already do this for things like Gtk+ before we start making our own. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 1-Bit Bitmap
...Any library that you can think of that offers bit by bit access without me needing to write a separate function to shift the bits out one by one from a 32-Bit int? Kind of like a bitarray? Are you using something other than C? -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_main_context_push_thread_default() g_io_*()
On Mon, 29 Mar 2010 20:26:03 -0400, A. Walton awal...@gnome.org wrote:
On Mon, Mar 29, 2010 at 6:58 PM, Thomas Stover
tho...@wsinnovations.com
wrote:
In the documentation for g_main_context_push_thread_default(), the
following sentence appears:
This will cause certain asynchronous operations (such as most
gio-based
I/O) which are started in this thread to run under context and deliver
their results to its main loop, rather than running under the global
default context in the main thread.
This makes me think my experiment program below would work, yet on
ubuntu
9.10 at least, it does not. Perhaps g_io_channel_unix_new() is not in
the
most group referred to above? Or maybe I'm doing this wrong. Thanks
for
any input.
GIO refers to the GIO library
(http://library.gnome.org/devel/gio/stable/), not to the g_io_* family
of functions. Probably worth filing a bug to make this clearer in the
documentation.
-A. Walton
Thanks for clearing that up.
In case anyone searching through list archives has this same issue, this
is how to delegate g_io_channel_* tasks to arbitrary threads /
GMainContexts. I had to look in giochannel.c.
-use g_io_create_watch() instead of _add_watch()
-then manually use g_source_attach() g_source_set_callback()
-the callback must be typecast to GSourceFunc
-apparently the GMainContext used by g_source_attach() will add a
reference to the GSource, so call g_source_unref() on the GSource after the
attach().
modified example below:
===
#include glib.h
#include unistd.h
#include sys/syscall.h
GMainContext *thread1_context, *thread2_context;
GMainLoop *main_loop1, *main_loop2;
gboolean idle_callback(gpointer data)
{
g_print(idle_callback() %d\n, (pid_t) syscall (SYS_gettid));
return FALSE;
}
gboolean input_callback(GIOChannel *source,
GIOCondition condition,
gpointer data)
{
GSource *idle_source;
gchar buffer[16];
gsize bytes_read;
g_print(input_callback() %d\n, (pid_t) syscall (SYS_gettid));
if(g_io_channel_read_chars(source, buffer, 1, bytes_read, NULL) !=
G_IO_STATUS_NORMAL)
return FALSE;
g_print( bytes_read = %d\n, (int) bytes_read);
idle_source = g_idle_source_new();
g_source_set_callback(idle_source, idle_callback, NULL, NULL);
g_source_attach(idle_source, thread1_context);
g_source_unref(idle_source);
return TRUE;
}
gpointer thread2_entry(gpointer data)
{
GIOChannel *channel;
GSource *source;
g_print(thread2_entry() %d\n, (pid_t) syscall (SYS_gettid));
main_loop2 = g_main_loop_new(thread2_context, FALSE);
channel = g_io_channel_unix_new(0);
source = g_io_create_watch(channel, G_IO_IN);
g_source_set_callback(source, (GSourceFunc) input_callback, NULL, NULL);
g_source_attach(source, thread2_context);
g_source_unref(source);
g_main_loop_run(main_loop2);
}
int main(int argc, char **argv)
{
g_thread_init(NULL);
thread1_context = g_main_context_default();
thread2_context = g_main_context_new();
main_loop1 = g_main_loop_new(thread1_context, FALSE);
g_thread_create(thread2_entry, NULL, FALSE, NULL);
g_main_loop_run(main_loop1);
return 0;
}
===
--
www.thomasstover.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_io_channel_write_*() GMainLoop logic
I'm looking for some tips on understanding how to make socket writes work in a main loop. In my past non-glib socket programs, I have had to do some write logic similar to: 1) attempt to write n bytes 2) if all n bytes were written, great 3) if some or all bytes were non written, that must mean OS buffers are full, so establish an event loop callback for when writes are again try-able 4) inside that callback repeat step 1 So in the world of glib, in step 3 I could do a g_io_create_watch(channel, G_IO_OUT), but what do I do when the write finally finishes? In other words, how do I stop the io watch for G_IO_OUT until its needed again? How bad would it be to just call g_io_create_watch(), g_source_attach(), and g_source_set_callback() every time a write didn't complete - plus g_source_destroy() when it finally finishes? Is that idea? Thanks. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_main_context_push_thread_default() g_ io_*()
In the documentation for g_main_context_push_thread_default(), the
following sentence appears:
This will cause certain asynchronous operations (such as most gio-based
I/O) which are started in this thread to run under context and deliver
their results to its main loop, rather than running under the global
default context in the main thread.
This makes me think my experiment program below would work, yet on ubuntu
9.10 at least, it does not. Perhaps g_io_channel_unix_new() is not in the
most group referred to above? Or maybe I'm doing this wrong. Thanks for
any input.
#include glib.h
#include unistd.h
#include sys/syscall.h
GMainContext *thread1_context, *thread2_context;
GMainLoop *main_loop1, *main_loop2;
gboolean idle_callback(gpointer data)
{
g_print(idle_callback() %d\n, (pid_t) syscall (SYS_gettid));
return FALSE;
}
gboolean input_callback(GIOChannel *source,
GIOCondition condition,
gpointer data)
{
GSource *idle_source;
unsigned char buffer[16];
g_print(input_callback() %d\n, (pid_t) syscall (SYS_gettid));
if(read(0, buffer, 16) 1)
return FALSE;
idle_source = g_idle_source_new();
g_source_set_callback(idle_source, idle_callback, NULL, NULL);
g_source_attach(idle_source, thread1_context);
return TRUE;
}
gpointer thread2_entry(gpointer data)
{
GIOChannel *channel;
g_print(thread2_entry() %d\n, (pid_t) syscall (SYS_gettid));
main_loop2 = g_main_loop_new(thread2_context, FALSE);
g_main_context_push_thread_default(thread2_context);
channel = g_io_channel_unix_new(0);
g_io_add_watch(channel, G_IO_IN, input_callback, NULL);
g_main_loop_run(main_loop2);
}
int main(int argc, char **argv)
{
g_thread_init(NULL);
thread1_context = g_main_context_default();
thread2_context = g_main_context_new();
main_loop1 = g_main_loop_new(thread1_context, FALSE);
g_thread_create(thread2_entry, NULL, FALSE, NULL);
g_main_loop_run(main_loop1);
return 0;
}
Here is an example session:
$ ./a.out
thread2_entry() 24928
f
input_callback() 24927
idle_callback() 24927
e
input_callback() 24927
idle_callback() 24927
k
input_callback() 24927
idle_callback() 24927
^C
What I was expecting is for input_callback() to run in thread 24928
instead of 24927.
--
www.thomasstover.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib *nix signals
From: Brian J. Tarricone bj...@cornell.edu To: gtk-app-devel-list@gnome.org Subject: Re: glib *nix signals Message-ID: 4b6dcb57.6080...@cornell.edu Content-Type: text/plain; charset=ISO-8859-1 I usually create a pipe (see pipe(2)), wrap the read side in a GIOChannel, and watch it via g_io_add_watch(). Then I write to that pipe in my signal handler. When the main loop wakes up again, it'll run the IO watch's callback function. See: http://git.xfce.org/xfce/libxfce4util/tree/libxfce4util/xfce-posix-signal-handler.c for some example code. It's simple and doesn't require the use of threads. -brian That's conceptually what I have done in the past (my life before glib). From what I can tell there are three ways. 1) GIOChannel and signalfd(2) on linux 2.6.27 2) the pipe(2) technique (probably only justifiable if no threads are in the picture) 3) dedicated signal listening thread which when signaled, grabs a lock on a worker thread's g_main_context, sets up an idle event, and let's worker thread's idle callback deal with it In the end, I'll probably make some abstraction that does one #1 if signalfd() is available, #3 if g_threads are engaged, and #2 otherwise. I'll have to go look at what to do in cygwin to... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
glib *nix signals
I'm looking for some notes / advise on catching SIGTERM in a glib main loop based program. Mainly on linux, but other kernels would be nice. This article: http://www.linuxjournal.com/article/2121 for instance, recommends masking all signals all the time and creating a dedicated thread siting around in a call to sigwait(). Translating that into glib threads might work. Any thoughts? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: main loop asynchronous queues
Chris Vine wrote:
In your code you didn't create a GMainContext object for each of your
threads, which is the key point. Each thread in which you want a main
loop should call g_main_context_new() which will create a GMainContext
object for the calling thread, then use that to create a GMainLoop
object, then call g_main_loop_run() on it to run it.
I was getting GMainContexts and GMainLoops confused. Thanks for you
input, I've learned several things.
The end goal I'm working for is to improve some programs I have that
send and receive messages over udp that require slow RSA operations
for each one. I want to move the RSA and related processing to another
thread, so that a worker thread listens for socket input, does some
openssl work, then gives a message to the main thread without blocking
on sockets or polling mutexes. At the same time the main thread can send
a message to a worker thread to be processed before sent instead of
slowing down the main thread. The adding of an idle_source to another
thread's main loop technique being discussed will certainly do the trick
nicely. The more I learn, glib just keeps getting better.
For anyone in the future searching around for more info on this topic,
here is a variation of the gtk hello world program I was doing some
experiments with. My main question at this point to anyone who might
know is, should the idle source get dereferenced / freed somehow? My
other question is g_source_attach() working on another thread's
GMainContext with atomic operations, will it possibly have to block for
access, or I'm I not doing this in a thread safe way?
/* build with gcc source.c `pkg-config --cflags --libs gtk+2.0 gthread-2.0`
One thread opens a window with a button, and another prints to the
console every 2 seconds. Each has a separate main context and main loop.
When the button in the first thread is pushed, the other thread's event
loop data structures are manipulated to schedule the running of
idle_callback() when possible in the other thread. */
#include glib.h
#include gtk/gtk.h
GMainContext *thread1_context, *thread2_context;
gboolean timeout_callback(gpointer data)
{
g_print(timeout_callback()\n);
return TRUE;
}
gboolean idle_callback(gpointer data)
{
g_print(idle_callback()\n);
return FALSE;
}
gpointer thread2_entry(gpointer data)
{
GMainLoop *main_loop;
GSource *seconds_timeout_source;
main_loop = g_main_loop_new(thread2_context, FALSE);
seconds_timeout_source = g_timeout_source_new_seconds(2);
g_source_set_callback(seconds_timeout_source, timeout_callback, NULL,
NULL);
g_source_attach(seconds_timeout_source, thread2_context);
g_main_loop_run(main_loop);
}
void button_click(GtkWidget *widget, gpointer data)
{
GSource *idle_source;
idle_source = g_idle_source_new();
g_source_set_callback(idle_source, idle_callback, NULL, NULL);
g_source_attach(idle_source, thread2_context);
}
gboolean delete_event(GtkWidget *widget, GdkEvent *event, gpointer data)
{
return FALSE;
}
void destroy(GtkWidget *widget, gpointer data)
{
gtk_main_quit();
}
int main(int argc, char **argv)
{
GtkWidget *window;
GtkWidget *button;
gtk_init(argc, argv);
g_thread_init(NULL);
thread1_context = g_main_context_default();
thread2_context = g_main_context_new();
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(window), delete_event,
G_CALLBACK(delete_event), NULL);
g_signal_connect(G_OBJECT(window), destroy,
G_CALLBACK(destroy), NULL);
gtk_container_set_border_width(GTK_CONTAINER(window), 10);
button = gtk_button_new_with_label(Test);
g_signal_connect(G_OBJECT(button), clicked,
G_CALLBACK(button_click), NULL);
gtk_container_add(GTK_CONTAINER(window), button);
gtk_widget_show_all(window);
g_thread_create(thread2_entry, NULL, FALSE, NULL);
gtk_main();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: main loop asynchronous queues
Chris Vine wrote:
In the case of callbacks to execute in the default program loop/context
(the main main loop) a worker thread can use g_idle_add()/
g_idle_add_full(). To execute a callback in other threads' main loops
you will have to do it in long-hand, making a GSource object with
g_idle_source_new(), and attach it to the GMainContext for the thread
in question (it is relatively trivial).
Wow that might open up some doors, but I've got to understand this
first. I'm fuzzy on several things. Here is some stabbing in the dark:
GMainLoop *thread1_mainloop, *thread2_mainloop;
GThread *thread2;
GSource *thread2_idle_source;
gboolean thread2_idle_function(gpointer data)
{
...
}
gpointer thread2_entry(gpointer data)
{
thread2_mainloop = g_main_loop_new(NULL, FALSE);
thread2_idle_source = g_idle_source_new();
g_idle_add(thread2_idle_function, NULL);
g_main_loop_run(thread2_mainloop);
return NULL;
}
some_callback_in_thread1()
{
tell_thread2_idle_function_to_run_somehow();
}
main()
{
g_thread_init();
thread2 = g_thread_create(thread2_entry, NULL, FALSE, NULL);
thread1_mainloop = g_main_loop_new(NULL, FALSE);
establish_some_callback_in_thread1_to_be_called_at_some_point();
g_main_loop_run(thread1_mainloop);
}
So now what?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
main loop asynchronous queues
Does glib allow for things like a two threaded program with inter-thread communication via async queues while each thread has a separate main loop waiting for both external stimulus and new queue messages to arrive? In other words, a) can a main loop be made to run a callback when a queue message arrives without polling (possibly futex based on linux), and b) can two threads each have a main loop? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel Touzeryemmanuel.touz...@free.fr wrote: Hi, [...] You know what I'm thinking... I think that this is from times where people used to build GUIs in the code... When they were writing all the container embedding and all, in C, building their dialogs. At that time that convention surely helped, you were constantly adding widgets to containers and so on. Today this is done in gtkbuilder and so what we have left is code not doing so much embedding in code (though obviously it happens) but Yes I would say its a historical thing, and I certainly hope that using GtkBuilder can be the standard in the end (I guess we still have lots of ground to cover). Only over my dead body ;-) Carlos Cheers, -Tristan Indeed. Not building interfaces manually may save time now and then, but it hinders your understanding of what is happening. For instance when you want to dynamically make interface changes at run time your left with simple hide show tricks. I can remember more than once when I wanted to tweak someone else's UI so as to do something like add a button that breaks out some widgets into a new window or adds some more widget filled h/vboxes in the mix, only to start looking at the code and see no code. Simple things become intrusive. Using helper tools is fine and wonderful, just don't strive for oversimplifying everyone else's world. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: Im not exactly sure what your trying to say, my understanding is that in the modern world you create widget subclasses when you need composite/dynamic widgets, all widgets are generally layed out in some kind of form, or multiple forms. Thats my understanding of the bleeding edge of the GUI, I think the OSX tools (Xcode/Interface Builder) are a little bit ahead of us on this front ... but not by much, considering that what we can potentially pull off is not restricted to Obj-C or any particular platform. Ofcourse I dont always read the headlines, so I would love to hear what other people think is the bleeding edge to strive for in the world of GUI development, really. Cheers, -Tristan Well that's pretty much how I see it, but creating new derived widgets is not always the same thing as dynamic interface manipulation. The issue that grabbed my attention more was the notion of always using GtkBuilder. I'm just saying I love the ability create and manipulate an entire interface in code the old fashion way. Being old and crusty (I'm 29), I take pleasure in questioning fashionable, main stream, sacred cow, gratuitously overused, technology. Near the top of that list is anything to do with XML. I miss the more agitated-old-timer-at-the-bar C code or die attitude that once was synonymous with the way I perceived FOSS. So while some articulate clearly of bleeding edge, I'll keep mumbling about often forgotten romantic concepts of yesteryear like fun. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: On Thu, Sep 10, 2009 at 3:24 PM, Thomas Stover tho...@wsinnovations.com wrote: [...] Well that's pretty much how I see it, but creating new derived widgets is not always the same thing as dynamic interface manipulation. The issue that grabbed my attention more was the notion of always using GtkBuilder. I'm just saying I love the ability create and manipulate an entire interface in code the old fashion way. Being old and crusty (I'm 29), I take pleasure in questioning fashionable, main stream, sacred cow, gratuitously overused, technology. Near the top of that list is anything to do with XML. I miss the more agitated-old-timer-at-the-bar C code or die attitude that once was synonymous with the way I perceived FOSS. So while some articulate clearly of bleeding edge, I'll keep mumbling about often forgotten romantic concepts of yesteryear like fun. Gah, I turned 30 this year !!! haha My opinion here is that things change, the code we wrote in the last 10 years can be here to stay, like we dont have to go and write it again. Instead the tasks that used to take time can now be considered script monkey tasks, and the rest of us C code or die hackers can move on to more interesting things that give more leverage to the young and upcoming script monkeys which may one day mature into real hackers ;-) This is my sales pitch to get hackers to help me actually write Glade in C, which I bet is still alot more fun than writing up interfaces using Glade or straight C, ... any takers ;-P Cheers, -Tristan ok, I'll drink to that. PyGtk works somewhat towards the same end in my boat. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Emmanuel Touzery wrote: It startles me that it doesn't seem to bother people much that all the widget variables are declared as GtkWidget*. Well, if you want you can use variables of type GtkWidgetOfTypeX * and type cast on the call of constructor. You have to type cast back to GtkWidget * allot, but I've done that sometimes. At least then more of your mistakes are caught by the compiler instead of g_assert(). Most API functions work in terms of widgets, while only when you need to do widget type specific operations do the derived types come into play. In other object oriented languages perhapses the constructors would return a derived class instance pointer and let the language work out when a base class is compatible or not. Here though, once you have an entire system based around typecasting, you just have to accept the trade offs of no-nonsense vs learning curve we are fortunate enough to have. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: custom tree model, iters, and memory management
Kristian Rietveld wrote: Hi, On Sun, Jul 26, 2009 at 8:22 PM, Thomas Stovertho...@wsinnovations.com wrote: While working on a custom tree model (thanks to Tim-Philipp Müller for the tutorial), I needed more pointers in my iter structure than the user_data, user_data2, and user_data3. So I defined a new structure and stored that in user_data. For the model's _get_iter(), _iter_children(), _iter_parent(), iter_nth_child() methods, if the output iter's user_data is NULL, a new one of these extra pointers structures gets allocated. At the moment, all of these allocations get also referenced in a GSList in the custom model, and freed when the model is finalized. While this does work ok, it feels strange. Any thoughts? Some light analysis shows the treeview doesn't use that many iters, so maybe this is fine? Feels strange indeed :) One of the problems is that you do not really know when an iterator is no longer used. This also depends on whether your model hands out persistent or non-persistent iterators. Persistent iterators stay valid for ever, non-persistent stay valid until the model changes its stamp, which is whenever the internal data structure of the model changes in such a way that the iterator for the same node will be different. For the persistent case, you need to keep all these extra allocated structures around until finalization, if you really allocate a new structure for every iterator handed out, the memory usage here is not bounded. I would suggest you to have a look at how GtkTreeModelSort and GtkTreeModelFilter handle this. A valid iterator only exists for a row in your model. You can group all the data you need for each row in a structure and group these structures in a list or tree form representing the layout of your model. Each row now has a structure with all required data and is accessible by a pointer. Instead of allocating a new structure for each iterator, put the pointer to the (already allocated) structure in the model's internal data structure in the iterator's user_data pointer. No need to allocate a new structure each time and the other model methods of your model can use the pointer in the iterator's user_data to access the internal data structure. Hope this helps and clear things up a bit. regards, -kris. Thanks for the input. Ideally iters would have an optional callback to free private data, but I think understand the thinking behind the design more now. It seems the custom model approach would be best if, as you describe, you can just point iters to real data nodes directly. In may case I think it is going to be worth going back to the source data store that I'm providing an optional gtk tree model wrapper for, and redoing it slightly so that every leaf depth uses the same base C structure, enabling me to do that. People like to say that low level Gtk+ is a rough edge, and while it is in deed something one has to learn to love, there is just no substitute for the power and flexibility it offers. This being an excellent example. Thanks again Gtk world. On the same topic, I'm trying to think of the best way to deal with the performance of deriving iterators from paths in a case like mine. Essentially I have linked lists that right now have to be traversed through to the the Nth position to resolve a path of N for a given depth. I could store another table somewhere with indexes mapped to pointers, but this table itself would have to be dynamically resized and completely rebuilt every time the data changed, virtually defeating the point of the linked list. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
custom tree model, iters, and memory management
While working on a custom tree model (thanks to Tim-Philipp Müller for the tutorial), I needed more pointers in my iter structure than the user_data, user_data2, and user_data3. So I defined a new structure and stored that in user_data. For the model's _get_iter(), _iter_children(), _iter_parent(), iter_nth_child() methods, if the output iter's user_data is NULL, a new one of these extra pointers structures gets allocated. At the moment, all of these allocations get also referenced in a GSList in the custom model, and freed when the model is finalized. While this does work ok, it feels strange. Any thoughts? Some light analysis shows the treeview doesn't use that many iters, so maybe this is fine? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn_async_with_pipes() ssh based IPC
So as much as I wish there were real (open source) ssh client and server C libraries for the ssh infrastructure, the general approach seems to to be child process with redirected IO on the client (with ssh on *nix and plink.exe on windows). On the server side connecting to a long running server program would require a helper program launched by the ssh server that then connects up via unix socket or something (why on earth wasn't unix socket forwarding part of the original idea?). I bet someone out there has tried this. Did it work? Anything odd to consider? Any alternative ideas? Any way to even imagine a secure server side on windows (win named pipes perhapses?). Is all this in anyway better than a maybe a custom tls/ssl server or something? I know this is slightly off topic, but I know everybody has had to ask themselves this same question. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes() ssh based IPC
Michael Cronenworth wrote: Thomas Stover on 07/09/2009 02:37 PM wrote: Is all this in anyway better than a maybe a custom tls/ssl server or something? I know this is slightly off topic, but I know everybody has had to ask themselves this same question. It's simple to write a GnuTLS server/client setup. Why don't you want to do that? I've done an openssl one before, and I'll look at gnutls, but the problems with that route as I see it are mainly: -you have to authenticate connections somehow- portably, and securely. Where as with ssh the OS just provides you with UIDs. I'm not a fan of the completely separate user database just for the one program architecture either. -(related to authentication) key management - ssh does all that already (ssh-agent, etc) (although the gnome-keyring library works for *nix) -more options for an admin to deal with -as legacy as ssh is, it does so much so well. It just feels like leveraging that would be a good idea. Also I might be thinking of the wrong project, but I have some vague memory of GnuTLS taking the downloads on their site down in protest after 911 (unless you donated money) or something quacky like that. (I'm pretty sure I shouldn't have said that, but whatever). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn_async_with_pipes() ssh based IPC
Michael Cronenworth wrote: You could have a TLS session without x509 auth and just use PAM or LDAP for user auth. Something like that is not provided by a single function call though. In a perfect world a password, another private key, or what ever wouldn't ever enter the picture. ssh-agent / pageant.exe work so darn well once you get up and running. It's already sad enough that there is no way to merge this world with https client authentication, somehow. SVN is one example of something that let's you keep things simple administratively by optionally using the ssh security model. I hate to say it, but the windows named pipes over SMB is another good model (the implementation however...). Passwords all over the place = evil. Each application asking you to decrypt a private key / cert on its own = annoying. Again gnome-keyring-daemon is on the right track, but I need something for the windows side. It sounds like you just want to be extremely lazy. That's the kind of support I need on a 24 hour a day basis. Suck it up and write your own implementation using the standard library tools available. It will be portable -- my GnuTLS apps run on Linux and Windows. This is with a glib event loop right? -- www.thomasstover.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+ 2.16.4 released
From: Gabriele Greco gabriele.gr...@darts.it Subject: Re: GTK+ 2.16.4 released To: gtk-app-devel-list@gnome.org On Thu, Jul 2, 2009 at 12:58 AM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.16.4 is now available for download at: About 2.16 releases: There is some official (like Tor Win32 bundles) or unofficial OSX framework released or we have to build from sources? Building an OSX universal binary framework compatible with 10.4+ is not exactly easy like configure/make :) I have some notes from August '08 when I built gtk for osx with the x11 back end. Let me know if you are interested. Most of the steps should be about the same. It was sort of funny in the sense that I have still never even used osx in gui mode. A friend set me up a shell account on his osx box on our lan, and from there via ssh and no root access, I made it all the way to screen shots for a presentation. I was very impressed that developers had taken the time to make all those pieces even work. My *nix experience comes from the gnu/linux world, and so for me at least, osx was a very strange animal. It would likely be easier to build for native osx gui (carbon?) than x11, since there was all sorts of --please-dont-do=that type switches I had to use. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: portable applications
Date: Wed, 24 Jun 2009 08:41:50 -0400 From: John Zavgren j...@zavgren.com Subject: portable applications To: gtk-app-devel-list@gnome.org Message-ID: 8bea388a0906240541p1bc747c7x174a9b35828b5...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Greetings: I wrote a Glade-3/GTK2/G++ application on a ubuntu machine, and the application works great. In fact it works so well that my colleagues want to use it. Ujnfortunately, they are not using ubuntu (and neither was I until I started developing my GUI. I chose ubuntu because it seemed to support GUI development.) I tried running my app on a Red Hat machine and the app failed because of an unresolved external reference,,, missing shared object file. No big deal. I attempted to statically link my app with the assistance of strace, the doctrinaire approach with embedded systems. That opened pandoras box! The number of references to shared object files was astounding. My intuition tells me that there must be a better way to build an application that will run on more than one Linux machine. Is there a simple way to statically link the esoteric aspects of my GUI Another approach you could take is to figure out how to make a .deb and .rpm files that list the packages for the libraries your app needs as dependencies. Not exactly the same thing you are talking about, but very much related. I wish I could speak from experience, but this is still on my mental to-do list. It is a sign of progress when someone uses portable to mean support for more than one linux distro. I would not recommend statically linking gtk. Most of the trick here is 1) portable build system (I endorse SCons), and 2) configuring / installing the required pieces on a build box for a supported target. Actually, if you get that far, the .deb / .rpm is not required, but a nice finishing touch. Binary portability is somewhat of a hot-button issue for many people now. It's not really a strong point for Linux. Sure it would be nice, but it's better to not require/expect its availability. For instance, there will always be different CPU architectures. Or if you are like many in my boat, you also still have windows builds. -- www.thomasstover.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 gis
Date: Thu, 11 Jun 2009 15:36:31 +0200 From: Andrea Zagli aza...@inwind.it Subject: gtk gis To: gtk-app gtk-app-devel-list@gnome.org Message-ID: 20090611153631.146644e2qf6bk...@saetta.homelinux.org Content-Type: text/plain; charset=UTF-8; DelSp=Yes; format=flowed do you know some widget that can display maps (from shp or postgis) and also allows very simple editing? on google i found only (old) widgets without editing thanks in advance I have helped a client make their own library. It uses cairo for all the output (not just for gtk). Cairo really is the magic that makes all the vectors and alpha blending so darn awesome. Some libraries that are excellent you can look into for building blocks are: -proj4 (cartographic projection) (everything uses this behind the scenes, but no one mentions it) -shapelib (most gis data is in or can be in shape files) -netcdf (things like weather radar overlays) -imagemagick (work with other non-png image formats for just cairo outside of gtk) -libcurl w/ glib bindings or libsoup for http data some other sources of data: -yahoo maps is kinda hackable and is ok for internal use (google maps wants you to only use it for externally reachable sites) -www.gisdatadepot.com more usa specific: -weather.gov -usgs.gov for academia (and through other pay sites): -http://www.unidata.ucar.edu/software/ldm/ (live scientific data of several kinds) All this is 2D, but it suites our needs very well. There is of course the http://grass.osgeo.org/ project which has many links and information for this area. I'm still looking for a simple open source library for some basic astronomical features like where the sunlight is, etc. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Man, I'm almost there. First, just ignore everything having to do with
win32 services. I was misreading the msdn service example. The
WaitFor*() is really done on an event. So here is a stripped down demo
of the progress so far. It does what I want, but then crashes before
ending the event loop gracefully, which means something needs to be
different. I'm sure it has something to do with the size arg to
g_source_new() call, since GSource is simply:
typedef struct {
} GSource;
Clearly I have no idea what I even want to pass to it.
=== glib_win32_event_test.c =
#include glib.h
#include windows.h
HANDLE windows_event = NULL;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
int global_int = 0;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
g_print(1) my_source_check()\n);
if(global_int)
{
g_print(1) bam!\n);
return TRUE;
}
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
global_int = 1;
SetEvent(windows_event);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GMainLoop *main_loop;
GSource *g_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
if((windows_event = CreateEvent(NULL, TRUE, FALSE, NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
main_loop = g_main_loop_new(NULL, FALSE);
g_timeout_add(1000, timeout_callback, NULL);
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = windows_event;
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source = g_source_new(g_source_funcs, sizeof(GSource));
g_source_attach(g_source, NULL);
g_source_add_poll(g_source, g_poll_fd);
if(CreateThread(NULL, 0, thread_entry, NULL, 0, NULL) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
cmd.exe session output:
1) I'm thread #3444
1) my_source_prepare()
2) I'm thread #5064
1) my_source_check()
1) still here...
1) my_source_prepare()
1) my_source_check()
1) still here...
1) my_source_prepare()
1) my_source_check()
1) still here...
1) my_source_prepare()
2) stuff is going to happen now..
2) I'm done
1) my_source_check()
1) bam!
1) still here...
[crash and burn]
=
Thoughts?
Tor Lillqvist wrote:
It's best to experiment, as I said I don't recall the details by
heart... and too busy to actually check now.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Well if any lone googlers ever find this, and want to know what
happened. I did fix it with this, but I still think the right way is to
some how create a new structure that is inherits the GSourceFuncs and
adds a place to store the event handle and the protected data (in this
case global_int). If there was an example of how to create a source, or
some doc on a source life cycle, that would be helpful. I did look at
the source, but was quickly lost. I'm guessing the main loop
architecture involves multiple sources, fds, and realization
callbacks all being able to exist without extras. So for instance 1
fd could trigger 5 sources, which each result in glib calling a variable
number of callbacks. If only there was more time to spend on these
things
#include glib.h
#include windows.h
HANDLE windows_event = NULL;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
int global_int = 0;
GMainLoop *main_loop;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
g_print(1) my_source_check()\n);
if(global_int)
{
g_print(1) bam!\n);
// g_source_remove_poll(source, g_poll_fd);
return TRUE;
}
return FALSE;
}
gboolean my_source_dispatch(GSource *source, GSourceFunc callback,
gpointer user_data)
{
g_print(1) my_source_dispatch()\n);
if(callback == NULL)
return FALSE;
return callback(user_data);
}
gboolean my_source_callback(gpointer data)
{
g_print(1) my_source_callback()\n);
g_main_loop_quit(main_loop);
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
global_int = 1;
SetEvent(windows_event);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GSource *g_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
if((windows_event = CreateEvent(NULL, TRUE, FALSE, NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
main_loop = g_main_loop_new(NULL, FALSE);
g_timeout_add(1000, timeout_callback, NULL);
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = windows_event;
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source_funcs.dispatch = my_source_dispatch;
g_source = g_source_new(g_source_funcs, sizeof(GSource));
g_source_attach(g_source, NULL);
g_source_add_poll(g_source, g_poll_fd);
g_source_set_callback(g_source, my_source_callback, NULL, NULL);
if(CreateThread(NULL, 0, thread_entry, NULL, 0, NULL) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
Thomas Stover wrote:
Man, I'm almost there. First, just ignore everything having to do with
win32 services. I was misreading the msdn service example. The
WaitFor*() is really done on an event. So here is a stripped down
demo of the progress so far. It does what I want, but then crashes
before ending the event loop gracefully, which means something needs
to be different. I'm sure it has something to do with the size arg to
g_source_new() call, since GSource is simply:
typedef struct {
} GSource;
Clearly I have no idea what I even want to pass to it.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Chris Vine wrote:
I may be missing your point (I would have to read through the
back-posts to make sense of it), but if you want to create your own
source object to hold its own protected/private data, it is just this:
struct MySource {
GSource source;
/* my data, such as a gpointer but it could be anything and as much member data as you want */
gpointer data;
};
It is created with:
MySource *my_source = (MySource*) g_source_new(source_funcs, sizeof(MySource));
/* initialise data */
my_source-data = my_object;
For more information see this, in particular the section Creating new
sources types:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
An idle object may already do much of what you want. With windows, I think
it uses a window event object under the hood.
Chris
Dude! Yes! Your example above needs to be in that section you reference,
which I missed even though I've been looking at that page all day. Now
if I could just figure out how to make the g_main_loop_quit() work with
out first calling g_main_loop_new(). Which would make sense to me except
g_main_loop_quit() is apparently the only function that needs the
g_main_loop_new() call. Even g_main_loop_run() will work with a NULL.
The relationship between main loops, main contexts, defaults, and
manually created ones is ambiguous at best. Anyway thanks Tor and Chris.
Some notes for anyone else who is just figuring out several things like
myself:
-a real new source would have a constructor that would do the
allocation and setup
-it would also have its own functions for setting up callbacks to source
specific events
-I think g_source_remove_poll() would be called in related destructor,
so I suppose the GPollFD structure needs to be stored in MySource as well
-I guess the destructor would be the closer_callback of the
GSourceFuncs parameter
-the GSourceFuncs and GPollFD variables are just copied by glib when
they given as parameters, so they don't need to dynamic (or
global/static like my last examples)
=== updated conversational source (yes! no globals) ===
#include glib.h
#include windows.h
typedef struct {
GSource source;
HANDLE windows_event_handle;
int integer;
} MySource;
gboolean my_source_prepare(GSource *source, gint *timeout_)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_prepare()\n);
*timeout_ = -1;
return FALSE;
}
gboolean my_source_check(GSource *source)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_check()\n);
if(my_source-integer)
{
g_print(1) bam!\n);
return TRUE;
}
return FALSE;
}
gboolean my_source_dispatch(GSource *source, GSourceFunc callback,
gpointer user_data)
{
MySource *my_source = (MySource *) source;
g_print(1) my_source_dispatch()\n);
if(callback == NULL)
return FALSE;
return callback(user_data);
}
gboolean my_source_callback(gpointer data)
{
GMainLoop *main_loop = (GMainLoop *) data;
g_print(1) my_source_callback()\n);
g_main_loop_quit(main_loop);
return FALSE;
}
gboolean timeout_callback(gpointer opaq)
{
g_print(1) still here...\n);
return TRUE;
}
DWORD WINAPI thread_entry(LPVOID lpParameter)
{
MySource *my_source = (MySource *) lpParameter;
g_print(2) I'm thread #%d\n, GetCurrentThreadId());
Sleep(4000);
g_print(2) stuff is going to happen now..\n);
my_source-integer = 1;
SetEvent(my_source-windows_event_handle);
g_print(2) I'm done\n);
return 0;
}
int main(int argc, char **argv)
{
DWORD error_code;
gchar *error_string;
GPollFD g_poll_fd;
GSourceFuncs g_source_funcs;
GMainLoop *main_loop;
MySource *my_source;
g_print(1) I'm thread #%d\n, GetCurrentThreadId());
memset(g_source_funcs, 0, sizeof(GSourceFuncs));
g_source_funcs.prepare = my_source_prepare;
g_source_funcs.check = my_source_check;
g_source_funcs.dispatch = my_source_dispatch;
my_source = g_source_new(g_source_funcs, sizeof(MySource));
g_source_attach(my_source, NULL);
main_loop = g_main_loop_new(NULL, FALSE);
g_source_set_callback(my_source, my_source_callback, main_loop, NULL);
if((my_source-windows_event_handle = CreateEvent(NULL, TRUE, FALSE,
NULL)) == NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateEvent() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
my_source-integer = 0;
g_poll_fd.events = 0;
g_poll_fd.revents = G_IO_IN;
g_poll_fd.fd = my_source-windows_event_handle;
g_source_add_poll(my_source, g_poll_fd);
g_timeout_add(1000, timeout_callback, NULL);
if(CreateThread(NULL, 0, thread_entry, (LPVOID) my_source, 0, NULL) ==
NULL)
{
error_code = GetLastError();
error_string = g_win32_error_message(error_code);
g_print(1) CreateThread() failed, \%s\\n, error_string);
g_free(error_string);
return 1;
}
g_main_loop_run(main_loop);
return 0;
}
===
--
www.thomasstover.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
g_io_channel_win32_new_messages() WaitForSingleObject()
Anyone know if you can use a win32 message io channel on arbitrary handles or just gdi windows or whatever the intended use of that is? I openly admit a don't get windows at all, so this maybe just really out there. Specifically, if I had handle returned from RegisterServiceCtrlHandler() (which as best as I can imagine in my linux centric reality is some sort alertable mutex like a futex) there are msdn examples showing WaitForSingleObject() used as an alternative to global variable polling. I'm just wondering if there is a path to glib event loop integration other than a timer and with an if statement inside. For those of you who never have to look at windows just use the above to make yourselves feel better today. For those of you that make all this stuff work on windows, I am truly grateful. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_io_channel_win32_new_messages() WaitForSingleObject()
Tor Lillqvist wrote:
I have never used that service control API, no idea what it is used for even...
oh, just the needlessly complex, 75 step, windows' equivalent to daemon()
But if MSDN says that the returned SERVICE_STATUS_HANDLE actually is a
normal HANDLE and a waitable one even, that can be passed to
WaitForSingleObject() and friends, then it should work to use it as
the fd in a GPollFD.
typedef struct {
#if defined (G_OS_WIN32) GLIB_SIZEOF_VOID_P == 8
gint64 fd;
#else
gint fd;
#endif
gushortevents;
gushortrevents
} GPollFD;
ok so on windows fd here is a pointer to a handle, not the rutime lib's
lookup table's integer index...
any ideas what the revents mask should be?
Unfortunately I don't actually know or understand the glib main loop
API very well by heart, so I can't say off-hand what you then should
do with such a GPollFD. Pass it to g_source_add_poll(), but for what
GSource? You might need to implement your own GSource type with
relevant callbacks to take care of that handle firing, and then pass
such a GSource object to g_source_attach()? Sorry...
--tml
typedef struct {
gboolean (*prepare) (GSource*source,
gint *timeout_);
gboolean (*check)(GSource*source);
gboolean (*dispatch) (GSource*source,
GSourceFunc callback,
gpointeruser_data);
void (*finalize) (GSource*source); /* Can be NULL */
/* For use by g_source_set_closure */
GSourceFunc closure_callback;
GSourceDummyMarshal closure_marshal; /* Really is of type GClosureMarshal */
} GSourceFuncs;
Very interesting. So presumably on windows poll() is really something
like WaitForMultiple*()? Which would mean what - a prepare that always
returns FALSE w/ *timeout_ = 0, and a check that does what it what
otherwise do if WaitForSingleObject() returned hot?
I'm going to try somethings...
---
ww.thomasstover.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
Please, please, please don't switch to UTF-16. To me gtk is about getting to use technologies that are solid, real, fun, and effective. Principally, that means C and *nix. UTF-8 is the greatest thing for one reason that kills all the others: solid compatibility with both of the above. I think gtk on 'doz is the coolest thing, and an extra file name conversion here and there is totally acceptable and then some. Siting the way other software does things just shows why gtk delivers so much. As an application developer, sticking with utf-8 all day long and not worrying about it is just awesome. Yes I do have to worry about it sometimes, like when I use .fred pinvoke() wrappers, some 'doz python issues, etc., but just use the appropriate conversion function and move on. ... I wonder if g_print() will deliver extended characters to the win32 console the right way ... I also wonder if you read text from a cgi form variable how you would even know what encoding it's in... ...cutting extended character text in windows and pasting it into gtk and having everything automatically work is fantastic btw... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
qt vs gtk
With the recent news that Nokia will be releasing QT under LGPL, I'm seeing allot of knee-jerk anti-GTK comments out there. I know I'm preaching to the choir on this list, but for the sake of moral I thought I would post my 2 cents on the matter. -I can't think of single QT application I even use. (although I admit I don't look for them) -Without getting into a C vs C++ debate, being able to use GTK straight from C really is the whole universe right there. Try returning GUI objects from dynamically loadable modules without C. In general, C libraries mix together far better than C++ ones. I use GTK together with all kinds of stuff. I'm younger and learned C++ in school. I had to unlearn the damage. The guys I know that still believe C++ always have this mental model that every library needs to be wrapped in some sort of all-encompassing toolkit, or you can't use it. -QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch. -HUGE: glib and gtk are separate. glib can be used on it's own. so one mental model to work with for gui and non-gui events. -When you start getting into it, there is just no contest. I love GTK. I have no doubt that if I started to read about qt, that I would constantly be saying, oh you can't do that, and you mean you have to that. Long live GTK! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
glib preprocessor strangeness
Ok so in the setup I've got, this works: $PKG_CONFIG_PATH=/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib/pkgconfig/ /opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/bin/arm-unknown-linux-gnu-gcc `pkg-config --cflags glib-2.0` glibtest.c `pkg-config --libs glib-2.0` Which it is suppose to. Yet while trying to debug a scons issue, I find my way to this quagmire. Examining the pkg-config output yields: $ PKG_CONFIG_PATH=/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib/pkgconfig/ pkg-config --cflags glib-2.0 outputs: -I/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/include/glib-2.0 -I/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib/glib-2.0/include and $ PKG_CONFIG_PATH=/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib/pkgconfig/ pkg-config --libs glib-2.0 outputs: -L/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib -lglib-2.0 OK that all makes sense, and is expected. Now here is the punchline - this fails: $/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/bin/arm-unknown-linux-gnu-gcc -Wall -I/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/include/glib-2.0 -I/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib/glib-2.0/include glibtest.c -L/opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/lib -lglib-2.0 with this error: /opt/crosscompilers/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/include/glib-2.0/glib/gtypes.h:34:24: error: glibconfig.h: No such file or directory I can't find a glibconfig.h anywhere. Not even in the glib build tree. I've tried other programs that repeat this same behavior. I've got nothing. Help much appreciated. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Running on Windows?
There is a certain ironic sadness to this truism. Date: Fri, 19 Dec 2008 04:55:07 -0800 (PST) From: lwhmellow lwhmel...@126.com ... Can be imaged my teacher must be mad if I ask him to install the runtime environment before clicking on my application. ... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib main loop without gtk
First thanks to Alexander Semenov, and Emmanuele Bassi for your
responses. It took some poking around, but I think get it now. Here is a
concept demo for any future searches that find this thread. I'm not sure
how to get out of the infinite loop though, since _iteration() returns
both TRUE and FALSE on normal execution. I can see how the approach glib
is using for events would allow for all sorts of stuff like mixing main
loops with other libraries and delegating events to helper threads. Good
stuff.
#include glib-2.0/glib.h
gboolean timeout_callback(gpointer opaq)
{
g_print(got here\n);
}
int main(int argc, char **argv)
{
g_timeout_add(3000, timeout_callback, NULL);
while(1)
{
g_main_context_iteration(NULL, TRUE);
}
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
glib main loop without gtk
So if one wants to use g_io_channels with out gtk (console / server app), what exactly is the idea? Does glib need an initialization function called first? I see the g_main_loop_new() and friends functions, and that part make sense. The thing is g_io_add_watch_full() type functions don't have a main loop parameter. In other words were does this default main loop come from? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to draw a primitive with one color and fill it with, another? (Sergey Parhomenko)
I would suggest you look at doing your drawing with cairo if possible.
Once I discovered that, I gave up on calling all those gdk functions.
Read the documents on their site at, http://www.cairographics.org . It
looks like most gtk drawing is going this way. I'm also fuzzy on what
the role of the pixmap is in your example. Are you trying to draw to a
widget, or to a pixmap?
Here is an untested example off of the top of my head to do what you
want to a widget (drawing area widget that is)...
void draw(GtkWidget* widget)
{
int width = widget-allocation.width;
int height = widget-allocation.height;
cairo_t *cr gdk_cairo_create(widget-window);
int x = width / 2;
int y = height / 2;
int r = 30;
/* clearing to white: (rgb values in cairo are floating points instead of
bytes) */
cairo_set_source_rgb(cr, 1.0, 1.0, 1.0);
cairo_rectangle(, 0, 0, width, height);
cairo_fill(cr);
cairo_set_source_rgb(cr, 0.0, 1.0, 0.0);
cairo_arc(cr, x, y, r, 0.0, 0.0);
cairo_fill(cr);
cairo_set_source_rgb(cr, 1.0, 0.0, 0.0);
cairo_stroke(cr);
cairo_destroy(cr);
}
Date: Mon, 14 Apr 2008 07:05:20 -0700 (PDT)
From: Sergey Parhomenko [EMAIL PROTECTED]
Subject: How to draw a primitive with one color and fill it with
another?
To: gtk-app-devel-list@gnome.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
Hello everyone.
I want to draw a red circle filled within with a green
color on my pixmap. I've set foreground and background
colors and passed TRUE as the filled parameter to
gdk_draw_arc(). But the circle is filled with the same
color as it is drawn, that is with the foreground
color - red.
How can I draw a red circle filled with green? The
relevant part of my code is below.
/* ... */
static GdkPixmap *pixmap = NULL;
void draw(GtkWidget* widget)
{
int width = widget-allocation.width;
int height = widget-allocation.height;
GdkGC *gc;
GdkColor colors[2];
int x = width / 2;
int y = height / 2;
int r = 30;
if (pixmap)
g_object_unref (pixmap);
pixmap = gdk_pixmap_new (widget-window,
width,
height,
-1);
gc = gdk_gc_new((GdkDrawable *)pixmap);
/* clearing to white: */
gdk_draw_rectangle (pixmap,
widget-style-white_gc,
TRUE,
0, 0,
width,
height);
gdk_color_parse(#ff, colors[0]);
gdk_color_parse(#00ff00, colors[1]);
/* By the way, can I get red and green GdkColor
faster, without these gdk_color_parse()? Are some
constants for this available? */
gdk_gc_set_rgb_fg_color(gc, colors[0]);
gdk_gc_set_rgb_bg_color(gc, colors[1]);
gdk_draw_arc(pixmap, gc, TRUE, x - r / 2, y - r / 2,
r, r, 0, 64 * 360);
}
/* ... */
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: What's wrong with the docs?
I feel the same way. I can't think of an example off of the top of my head, but I swear there have been things that the only way I figured them out was by reading the python documentation and sort of guessing at the C API. Yes I look at the reference docs on gtk.org and gnome.org. Date: Wed, 30 Jan 2008 17:27:33 -0200 From: John Coppens [EMAIL PROTECTED] Subject: What's wrong with the docs? To: gtk-app-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Hello all... There must be something terribly wrong somewhere, when I try to find documentation on operation with GTK+ or GDK elements, I always seem to get _much_ more documentation from the Python/Perl libraries than from the actual C interface. I'm sure others noticed the same trend. So, why is this? - Are the original (C/C++) docs really so scarse they don't appear at the top of of the list? or... - Is something in the google algorithms preferencial to anything but C? - Are those docs maybe declared unaccessible by the spider engines? (by robots.txt or so) - Or are those alternative languages just much more popular than C? Which makes this question pop up: Wouldn't it be interesting/practical to have _common_ documentation. Say, GtkWidget is used in Python like this, in C like this, etc.? I could even serve as an educational tool to compare languages. Just idle thoughts... John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
printing, cairo, cups
I've been trying to get myself up to speed with state of printing support in Gtk, and I'm down to just a few conceptual questions. It looks like the general idea is to setup a callback to render with cairo one page at a time using a GtkPrintContext. From this I would speculate that on win32, a cairo GDI surface is used with the GDI device being a windows printer. On the *nix side GtkPrintContext might be using cairo post script surface, but more likely an image (memory buffer) surface is used. If the GtkPrintContext is setup correctly, then the device dependent details width, height, and dpi get used to build such a cairo memory buffer surface. I'm also betting Gtk is pulling all this from CUPS. In that case, there is then the issue of cairo's lack of support for color space beyond RGBA, as in printing, arises. Although that is a completely separate topic, and definitely something I can live with for now if all else works out. My main question is this. Somewhere the cairo RGBA color space must be mapped into a printer's device dependent color space such as CMYK. Is this mapping done inside Gtk using info resolved from cups, or is this done inside cups with filters? Any help with my understanding would be appreciated. Most of this I'm just wildly guessing about since I haven't found it documented. I really would like to spare me the time of learning CUPS, which is why I want to understand how much, and what, work Gtk is doing for me. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Don't understand valgrind output
Date: Sun, 14 Oct 2007 10:24:14 -0400 (EDT) From: Allin Cottrell [EMAIL PROTECTED] Subject: Re: Don't understand valgrind output To: Michael Lamothe [EMAIL PROTECTED] Cc: gtk-app-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 13 Oct 2007, Michael Lamothe wrote: I have been struggling with application freezes in my application for about 2 months and I was hoping that I could get some help. I've been cleaning the application up with errors reported by valgrind but can't seem to work out what this means. Can anyone shed some light on this? Should I just ignore this memory error? ==13801== Syscall param write(buf) points to uninitialised byte(s) ==13801==at 0x40007F2: (within /lib/ld-2.5.so) ==13801==by 0x4B6D64E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) I don't think this has anything to do with your application as such. Valgrind is complaining about apparently uninitialized data in regard to XOpenDisplay. Allin Cottrell Yes this happens to me also. It is almost certainly not your application. Valgrind normally finds all sorts of errors that are effectively not really errors for one reason or another. Example: the C library not 100% free()ing something before exit. There is some sort of internal valgrind database that is used to suppress this stuff. This internal suppression does not always work due to subtleties like valgrind build time / application run time gcc/libc mismatches. For instance, on the latest 64bit ubuntu, there are dozens of such errors that I am not suppose to see, and so I just know that certain libc based errors can be ignored. Every time I valgrind a gtk app, I get all sorts of things like you are seeing with xlib and gtk libs. Whether or not these are real problems or ignorable, I don't know. They don't seem to cause any runtime issues though. I'm getting the impression that not many gtk people use valgrind, since perhapses these errors also could be added to the suppression database. Btw: if your application truly is freezing and not crashing with a core dump, then you most likely are caught in an infinite loop, or have some blocking IO that is being incorrectly handled. Just look at the cpu usage of the app next time it freezes. That will be a dead give away about the loop. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
