Re: How to scroll my gtk application window programmically
On Sat, 2007-11-10 at 20:48 -0600, ying lcs wrote: I would like to know how can I scroll my gtk application window programmically? I have tried this, but the scroll bar does not make and the content of the window did not get refresh? GtkWidget* topLevelWindow; GdkWindow* win = topLevelWindow-window; gdk_window_scroll (win, 1, 880); Is your top level window scrollable? My guess is that you actually have a scrollable widget (GtkTextView in a GtkScrolledWindow, or whatever) embedded somewhere in your top-level, and that's the thing you want to scroll. -Alan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A little compiler issue
On Fri, 2007-11-09 at 00:04 +0100, Rafał Mużyło wrote: It's not quite gtk related, but do any of you know how to fix a problem with G_LOCK/G_UNLOCK producing strict aliasing warnings with -O2 ? I'm looking for a real solution, not something to silence warnings, like -fno-strict-aliasing ? It seems that there was once a similar problem (bug 316221) but bugzilla seems to be either down or otherwise unaccessible, so I can't compare with my problem. I presume you're system is x86_64? I asked the same question in July: http://mail.gnome.org/archives/gtk-app-devel-list/2007-July/msg00038.html The executive summary for the thread is that it's an incorrect cast in GLib that only affects x86_64 with optimizations turned on. Likely you'll have to live with or disable the warnings until 64-bit systems become common enough that this bites someone with the wherewithall to track down the proper source of the problem in GLib. -Alan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: type-punning warnings with optimizations turned on?
On Fri, 2007-07-06 at 08:22 -0700, [EMAIL PROTECTED] wrote:
On Fri, 2007-07-06 at 08:00 -0700, Alan M. Evans wrote:
On Fri, 2007-07-06 at 09:27 +0200, Jonathan Winterflood wrote:
Wouldn't that be
typedef struct MyMutex MyMutex;
rather?
Or for short :
typedex struct _MyMutex {
GStaticMutex mutex;
} MyMutex;
Hi. Thanks for the input. But since this is C++, I'm not sure how that
makes a difference. Anyway, I tried it and the warnings remain.
That's right, your
struct MyMutex {
GStaticMutex mutex;
};
is correct in C++. You forgot to mention that you were using C++. It
makes a difference here.
Well, I did provide my compile line, which used g++ rather than gcc.
I'm not sure I've ever even seen the type-punning warnings in any of my
C code. Could be wrong about that, I guess.
You say accessing GStaticMutex thingies elsewhere in your program
doesn't elicit these warnings?
Check to see if all the other places where you use it are places where
the thing being used is actually a pointer to a GStaticMutex.
A quick grep tells me that it always a fully-qualified member, always
passed to _init(), _lock(), and _unlock() with . In short, they look
basically like this one.
Hmmm. Now that I'm recompiling everything by hand, I see that this
warning is everywhere I call g_static_mutex_lock() and
g_static_mutex_unlock(). I just did:
void test() {
static GStaticMutex mutex;
g_static_mutex_init(mutex);
g_static_mutex_lock(mutex);
g_static_mutex_unlock(mutex);
g_static_mutex_free(mutex);
}
And that produces warnings on the lock and unlock calls. Same with the
example from the online API docs, which basically differs only in the
way mutex is initialized.
I searched for GStaticMutex in /usr/include/glib2.0/*/*.h and found no
definition or declaration for it. Therefore you can't hold one in your
program: they are opaque objects. You must only hold pointers to them.
You can also initialize them statically via a macro. This is the text
of a comment in gthread.h (the only .h file in the glib2.0 header tree):
/* GStaticMutexes can be statically initialized with the value
* G_STATIC_MUTEX_INIT, and then they can directly be used, that is
* much easier, than having to explicitly allocate the mutex before
* use
*/
The API docs state explicitly that GStaticMutex is *not* opaque. In
fact, G_STATIC_MUTEX_INIT would be worthless if we could only hold a
pointer to GStaticMutex. And g_static_mutex_init() requires a pointer to
an already existing GStaticMutex. There's no g_static_mutex_new() like
there is a g_mutex_new().
Anyway, if GStaticMutex were opaque then the g_new() call in my code
wouldn't compile, I think.
Thanks for weighing in. It's beginning to look like I might just need to
live with the worthless warning...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
type-punning warnings with optimizations turned on?
I have the following snippit:
#include glib.h
struct MyMutex {
GStaticMutex mutex;
};
MyMutex * MyMutex_new() {
MyMutex *result = g_new(MyMutex,1);
g_static_mutex_init(result-mutex);
return result;
}
void MyMutex_free(MyMutex *mutex) {
g_static_mutex_free(mutex-mutex);
g_free(mutex);
}
void MyMutex_lock(MyMutex *mutex) {
g_static_mutex_lock(mutex-mutex);
}
void MyMutex_unlock(MyMutex *mutex) {
g_static_mutex_unlock(mutex-mutex);
}
When compiled without optimizations, I get no warnings:
g++ -O0 -Wall -c `pkg-config --cflags glib-2.0` test.cpp
But with optimizations on (actually, at or above -O2), I get warnings
about type-punning on the calls to g_static_mutex_lock/unlock:
g++ -O2 -Wall -c `pkg-config --cflags glib-2.0` test.cpp
test.cpp: In function ‘void MyMutex_lock(MyMutex*)’:
test.cpp:19: warning: type-punning to incomplete type might break
strict-aliasing rules
test.cpp: In function ‘void MyMutex_unlock(MyMutex*)’:
test.cpp:23: warning: type-punning to incomplete type might break
strict-aliasing rules
Did I do something wrong syntactically? Or is the source of this error
in GLib or perhaps gcc? I use GStaticMutex all over my code; this is the
only place producing a warning.
For information, the development system is FC6.x86_64 with GLib 2.12.9,
gcc 4.1.2.
Thanks for any suggestions.
-Alan (big fan of warning-free builds)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Newbie Question: How i can use glib-2.0 in my c-programm ?
On Tue, 2007-06-26 at 23:27 +0200, Kai Szymanski wrote: Sorry, german text. It say's: test.c:6: Error: »gstring« not declared This is because C is case sensitive. Try GString instead of gstring. ___ 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 and WIN32
On Sat, 2007-06-23 at 12:35 +0300, Tor Lillqvist wrote: Alan M. Evans writes: I created the minimal sample program, and it works! The working example is virtually copy/pasted out of the non-working code. That's so typical;) Could your problem then simply be caused by some dynamic memory management bug or similar in the full program that corrupts some data structures, maybe even GLib's own? Well, I can't rule anything out yet, but I doubt it. It's just that I do embedded programming for a living; odd failure modes are familiar territory. But this one has me scratching my head. g_spawn_async_with_pipes(); WaitForSingleObject(); BTW, why do you use g_spawn_async_with_pipes() if you then immediately wait for the process to finish? Wouldn't g_spawn_sync() be simpler? A sensible suggestion. In fact I probably would have arrived at that eventually. This was the first iteration, and I was using the async version somewhere else and just copied that block for this purpose. I'll try that now in hopes of getting the code rolling and off to the guy waiting for this functionality. Still, I think I'm going to produce a minimal program/DLL project and post a link when I get a chance. Hopefully you or someone else will be able to simply see where I went wrong and I can go sheepishly back to my hole. Thanks so much for your help, Tor! ___ 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 and WIN32
On Fri, 2007-06-22 at 18:54 +0300, Tor Lillqvist wrote:
Alan M. Evans writes:
This is being compiled with VC6, and does depend (indirectly) on
msvcrt.dll.
OK, good.
Are you saying that my method should work in this circumstance?
In principle, yes. In practice, if it doesn't, file a bug report at
bugzilla.gnome.org and include a complete but minimal sample program
source code as an attachment.
I created the minimal sample program, and it works! The working example
is virtually copy/pasted out of the non-working code.
So, the working example looks like this:
int main() {
g_spawn_async_with_pipes();
WaitForSingleObject();
_read();
_close();
}
And the non-working one looks like:
DLL:
__declspec( dllexport ) int func() {
g_spawn_async_with_pipes();
WaitForSingleObject();
_read();
_close();
}
Program:
#include DLL.h
int main() {
myfunc();
}
The interesting part of func() in the non-working version looks exactly
like the corresponding part of main in the working version. I've
compared them side-by-side. (They should look the same -- one was
copy/pasted from the other.) Does this scenario provide any hint about
whats going wrong?
This is very frustrating. Stuff like this makes me want to give up on
this programming stuff and go do something easy, like particle physics.
___
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 and WIN32
On Fri, 2007-06-22 at 11:37 +0300, Tor Lillqvist wrote: Alan M. Evans writes: The process being called simply prints a short message and returns. I see the message if I execute the program from a command prompt under Windows. The linux version works, In the Windows version, _read() always returns -1, errno=EBADF. Does your code use the same C runtime library as GLib does, msvcrt.dll, which is part of the operating system? If not, the file handles returned have no meaning in your code. File handles are basically indexes into a table in the C library. Microsoft in their infinite wisdom provides so many C runtimes libraries, and their newer tools for some reason don't allow building code against msvcrt.dll... If you want to use msvcrt.dll, you should either use the older, but for plain C still perfectly usable, Visual C 6.0. Or use gcc, i.e. mingw. This is being compiled with VC6, and does depend (indirectly) on msvcrt.dll. Are you saying that my method should work in this circumstance? ___ 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 and WIN32
Hello!
I'm having trouble reading the stdout pipe from
g_spawn_async_with_pipes() when compiled for WIN32. The docs on
developer.gnome.org mention some differences in Windows behavior but
nothing mentions what I'm supposed to read the pipe with. I've googled
endlessly and so far failed to produce the magic combination of search
terms to solve my problem.
So far (greatly trimmed for simplicity):
gint out;
if
(g_spawn_async_with_pipes(0,argv,0,G_SPAWN_DO_NOT_REAP_CHILD,0,0,pid,0,out,0,error))
{
#ifdef WIN32
WaitForSingleObject(pid,INFINITE);
len = _read(out,buf,10);
_close(out);
#else
waitpid(pid,result,0);
len = read(out,buf,10);
close(out);
#endif
}
The process being called simply prints a short message and returns. I
see the message if I execute the program from a command prompt under
Windows. The linux version works, In the Windows version, _read() always
returns -1, errno=EBADF.
I tried ReadFile(), which required casting out to a HANDLE, but that
call never returns. I must be doing something terribly wrong, since I
hardly believe that it doesn't work at all.
So I guess my real question is, under WIN32, how do I read the stdout
pipe returned from g_spawn_async_with_pipes()?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Command Window with MSVC++ GTK apps
On Tue, 2006-10-03 at 16:19, Christopher Backhouse wrote: Lots of my code has this at the top of it #pragma comment(linker, /subsystem:\windows\ /entry:\mainCRTStartup\) //Kill console window I got it off the internet somewhere. I assume the unrecognised pragma will be ignored by every other compiler out there so it should be portable (if a little ugly) Is it possible to just add the string in this command somewhere into the link options? That's it! The voodoo was in the name of the entry point. As I said, I had tried main but that didn't work. The actual desired entry point was mainCRTStartup. So adding /subsystem:windows /entry:mainCRTStartup to the linker options alters a former console app to execute without the console window. Same effect as running editbin /subsystem:windows on the console executable as described by Tor a few messages ago. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Command Window with MSVC++ GTK apps
On Tue, 2006-10-03 at 09:12, Tor Lillqvist wrote: add /subsystem:windows to the linking options. (If using gcc, it would be -mwindows.) Or run editbin /subsystem:windows on the .exe file any time after linking. I find that doing the former doesn't actually work. In that case it fails to link with WinMain, which of course doesn't exist. And I can't just change the entry point to main since that causes a GPF at runtime, probably because the prototypes for main and WinMain don't match. Running editbin after compiling does have the desired effect. Any idea how to change the link settings that will produce a working executable? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Command Window with MSVC++ GTK apps
On Tue, 2006-10-03 at 14:52, Reed Hedges wrote: Are you using cygwin or mingw? Nope. Just took my prog developed on my Linux workstation and created a VC++ project by adding the source files and specifying the Win32 glib/gtk+ libs and DLLs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
where is xmlparse.dll?
Trying to compile a simple gtk app for the first time under Windows using stuff linked from TML's webpage. I've managed to produce my app, complete with little boxes where the fonts should be rendered. In an attempt to put something a little more intuitive on the screen, I've come to the point of trying to run pango-querymodules.exe, but it's complaining about needing xmlparse.dll. Where do I get this? Or am I on completely the wrong track and should be doing something else to properly render fonts in my program? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: where is xmlparse.dll?
Found it. I had missed the expat requirement mentioned on Tor's page. Sorry to bother the list about it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Sockets in GTK+?
On Mon, 2006-08-21 at 06:18, Chris Sparks wrote: I went looking fo rGNet and what is odd is that it says this: It is written in C, object-oriented, and built upon GLib. C isn't object-oriented.. Object-oriented is a philosophy, not an attribute of a language. C++ supports objects within the language, C does not. But this does not mean that one cannot apply object-oriented principles when programming with C. Similarly, one could write a strictly non-object-oriented program in C++. Doing objects in C just requires some methodic discipline. Or think of it this way: All languages eventually get translated machine code. Is machine code object oriented? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: selected text is PRIMARY?
On Fri, 2006-04-14 at 11:14, Xavier Bestel wrote: Le vendredi 14 avril 2006 à 19:28 +0200, Jernej Simončič a écrit : On Fri, 14 Apr 2006 19:14:17 +0200, Xavier Bestel wrote: - One selection per application ? - One selection per window ? - One selection per widget ? I'd go for one selection per widget - I'm always annoyed in X when I select something, and my previous selection is erased (even though I do often use the middle-button pasting). Nice. And now when you press Ctrl-C, what happens ? Well, being merely a user, I would expect it to copy the selected object in the currently focussed widget. Is there something difficult or non-obvious about that? As for the pasting operation, I would expect that Ctrl-V would paste the object that was last copied or cut using Ctrl-C or Ctrl-X, regardless of PRIMARY selection. Further, middle-mouse pasting should occur with the last object selected with the mouse, regardless of Ctrl-C/Ctrl-X. I don't even think that PRIMARY selection requires a special visual cue to distinguish it from other selections. My argument here is that pasting from PRIMARY *always* occurs immediatly (or very soon after) selecting. It's inconceivable to me that someone would select with the mouse then leave their task for a long time and then return and paste with the middle button. I find this system to be very simple and flexible. Users who want to use PRIMARY-style pasting can do so. Users who want to use the Ctrl-C/Ctrl-V method can do so. User that have need of both are free to use them both. I fall into that last group. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Character Table
On Thu, 2006-03-02 at 14:24, dwolfe wrote:
for(n=32; n1000; n++)
{
static gchar buf[8];
g_sprintf(buf, %c, n);
printf(string:%s, buf);
gchar *end;
if(g_utf8_validate (buf, -1, end))
Check man 7 utf8 and perhaps you will understand why you are mostly
failing to produce valid UTF-8 characters this way.
Wrong list, by the way; try gtk-app-devel-list instead.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dealing with utf8 filenames
On Tue, 2006-02-21 at 16:25, Tor Lillqvist wrote: Also, I don't think the string returned from g_utf8_casefold() is guaranteed to be the same length as the original, so my calculation for string length is incorrect. Umm, no? You look at the casefolded string and calculate the length of the part up to the '.' of that? Yes, that's what I'm doing. No, I don't think it's correct. I am finding the extension in the case folded string and using that byte offset to select the string length from the original string. It could only be correct if the case folded string is guaranteed to be the same length in bytes as the original string. For ASCII, that's pretty likely. I'm not so sure about other types of characters. Perhaps I'm wrong about that. Is there a guaranteed correct way to do that? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: dealing with utf8 filenames
On Wed, 2006-02-22 at 07:59, Christian Neumair wrote: Am Mittwoch, den 22.02.2006, 07:09 -0800 schrieb Alan M. Evans: On Tue, 2006-02-21 at 16:25, Tor Lillqvist wrote: Also, I don't think the string returned from g_utf8_casefold() is guaranteed to be the same length as the original, so my calculation for string length is incorrect. Umm, no? You look at the casefolded string and calculate the length of the part up to the '.' of that? Yes, that's what I'm doing. No, I don't think it's correct. You can perfectly do pointer arithmetic with UTF-8 encoded strings. I don't have a problem with pointer arithmetic. My problem is that I'm doing arithmetic on one string (the case-folded version) and applying that math to another string (the original version). This can only be correct if the two strings are the same length in bytes. I don't believe that's a sure thing with UTF-8. For the sake of readability, I'd rather use the following code: char **str; /* str[0]: basename str[1]: extension */ str = g_strsplit (filename, ., 2); g_strfreev(str) Surely that won't work if there is more than one dot in the name! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: dealing with utf8 filenames
On Wed, 2006-02-22 at 10:47, Christian Neumair wrote: For the sake of readability, I'd rather use the following code: char **str; /* str[0]: basename str[1]: extension */ str = g_strsplit (filename, ., 2); g_strfreev(str) Surely that won't work if there is more than one dot in the name! Why? :) Because the file myprog-1.2.3.tar.gz will be split into: basename=myprog-1 and extension=2.3.tar.gz, which is incorrect for a file name and incorrect for an extension. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkSelectionMode
On Tue, 2006-02-21 at 12:16, Wallace Owen wrote: On Tue, 2006-02-21 at 12:03 -0800, Alan M. Evans wrote: Is there a way to allow the user to select *any* number of elements from a treeview, including zero? GTK_SELECTION_MULTIPLE almost does, but if there's a way to unselect the last selected element, I can't figure out what it is. I hold the control key then click on the selected one that I want to deselect. Does that not work for you? Sure enough it does. I'm certain I tried that earlier. I guess it just takes me asking a stupid question in a public forum to make it actually work. Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
dealing with utf8 filenames
Suppose I have a filename returned from g_dir_read_name(). It's UTF-8,
at least on Win32. I would like to determine if it has a particular
extension (case insensitive) and display it without the extension.
I can't believe that this manipulation is that uncommon, but the only
solutions I've been able to devise are very convoluted and not
technically correct. Here's what I have so far:
const gchar *name;
gchar *dotxci = g_utf8_casefold(.xci,-1);
while ((name=g_dir_read_name(dir))) {
gchar *utfname = g_utf8_casefold(name,-1);
gchar *extension = g_utf8_strrchr(utfname,-1,'.');
if (extension !strcmp(extension,dotxci)) {
GString *dname = g_string_new_len(name,extension-utfname);
/* dname-str here contains displayable filename */
g_string_free(dname,TRUE);
}
g_free(utfname);
}
g_free(dotxci);
This seems like an awful lot to go through just to get a filename
without an extension. In particular, I'm unhappy with the amount of
frivolous dynamic allocation. Also, I don't think the string returned
from g_utf8_casefold() is guaranteed to be the same length as the
original, so my calculation for string length is incorrect.
Is there some simple or obvious solution I'm missing?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Some scientific widgets that I have done.
On Mon, 2006-02-20 at 12:06, Alexandre wrote: Hi, I've written this mail to show some widgets for gtk that I have done. This widgets are for technical / scientific uses. It's the first version (0.1), there may be bugs, but I want to correct them, and in the future, release it as a library (like qwt). Here is the link to the page: http://tesla.eletrica.ufpr.br/~apb04/en/widgets.html My reaction to your widgets is mixed. The first bugs you may wish to address are the broken links on your web page, which I guess must work on your machine, but most likely not on any other machine. To be fair, I found the files, but only by guessing at the location and hand editing the URLs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK and threads
On Mon, 2006-02-06 at 11:22, Michael Torrie wrote:
I have attached a sample file that uses threads in the way you described
in your last post.
I generally like to make code examples compile without warning. Did you
even try to compile this?
#include stdio.h
#include stdlib.h
#include gtk/gtk.h
#include glib.h
#include pthread.h
#include unistd.h /* sleep() - on Unix, anyway */
gint thread_count=0;
gint dead_threads;
GSList *threads;
struct thread_info_data {
GtkTextBuffer *buffer;
gint id;
pthread_t tid;
gint terminate;
};
void thread (void *data) {
void * thread(void *data) {
struct thread_info_data *info;
GtkTextIter iter;
GString *message;
info=(struct thread_info_data *)data;
message=g_string_new();
while(info-terminate == 0 ) {
sleep(1);
g_string_printf(message,Thread %d here.\n,info-id);
g_print(%s,message-str);
gdk_threads_enter();
gtk_text_buffer_get_end_iter(info-buffer,iter);
gtk_text_buffer_insert(info-buffer,iter,message-str,-1);
gdk_threads_leave();
}
g_print(Thread %d stopping.\n,info-id);
gdk_threads_enter(); //borrowing a lock from gtk to lock our variable
dead_threads++;
gdk_threads_leave(); //we could and should use a counting semaphore
g_string_free(message,NULL);
g_string_free(message,FALSE); /* Hope NULL means FALSE here */
return 0;
}
void stop_thread(gpointer data, gpointer user_data) {
struct thread_info_data *thread;
thread=data;
thread-terminate=1;
g_print(Asked thread %d to stop.\n,thread-id);
//here we ought to make sure the thread really has died
//pthread_join(thread-tid,NULL);
}
void on_destroy(GtkWidget *widget, gpointer data) {
g_slist_foreach(threads,stop_thread,NULL);
while(dead_threads thread_count) {
while(gtk_events_pending()) {
gtk_main_iteration();
}
sleep(0);
}
gtk_main_quit();
}
void on_button_clicked(GtkWidget *widget, gpointer data) {
GtkTextBuffer *buffer;
GtkTextIter iter;
struct thread_info_data *thread_info;
buffer=GTK_TEXT_BUFFER(data);
thread_info=g_malloc(sizeof(struct thread_info_data));
thread_info-buffer=buffer;
thread_info-id=thread_count++;
thread_info-terminate=0;
threads=g_slist_append(threads,thread_info);
pthread_create((thread_info-tid),NULL,thread,thread_info);
gtk_text_buffer_get_end_iter(buffer,iter);
gtk_text_buffer_insert(buffer,iter,Button clicked!\n,-1);
g_print(Button clicked.\n);
}
int main(int argc, char *argv[]) {
GtkWidget *window;
GtkWidget *button;
GtkWidget *vbox;
GtkWidget *viewarea;
GtkWidget *view;
GtkWidget *buffer;
GtkTextBuffer *buffer; /* GtkTextBuffer doesn't inherit from GtkWidget!
*/
threads=NULL;
g_thread_init (NULL);
gdk_threads_init ();
gtk_init(argc, argv);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_signal_connect(GTK_OBJECT(window),destroy,
GTK_SIGNAL_FUNC(on_destroy),NULL);
gtk_container_set_border_width(GTK_CONTAINER(window),10);
vbox=gtk_vbox_new(FALSE,5);
gtk_container_add(GTK_CONTAINER(window),vbox);
gtk_widget_show(vbox);
viewarea=gtk_scrolled_window_new(NULL,NULL);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(viewarea),
GTK_POLICY_AUTOMATIC,
GTK_POLICY_AUTOMATIC);
gtk_box_pack_start(GTK_BOX(vbox),viewarea,TRUE,TRUE,2);
gtk_widget_show(viewarea);
view=gtk_text_view_new();
buffer=gtk_text_view_get_buffer(GTK_TEXT_VIEW(view));
gtk_text_buffer_set_text(buffer,The threads will write here.\n,-1);
gtk_container_add(GTK_CONTAINER(viewarea),view);
gtk_widget_show(view);
button=gtk_button_new_with_label(Click me);
gtk_signal_connect(GTK_OBJECT(button),clicked,
GTK_SIGNAL_FUNC(on_button_clicked),buffer);
gtk_box_pack_end(GTK_BOX(vbox),button,FALSE,FALSE,3);
gtk_widget_show(button);
gtk_widget_show(window);
gdk_threads_enter ();
gtk_main();
gdk_threads_leave ();
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: Depending on C99 (Re: GtkBindingSignal changes)
On Thu, 2006-01-05 at 08:26, Roger Leigh wrote: anyone could download the latest MS compiler from the MS website, so I don't think there's any good reason to restrict yourselves to this compiler's capabilities. Only if having Visual Studio along with your compiler isn't a good reason. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and glib
On Tue, 2006-01-03 at 05:31, Ricardo Biloti wrote: There is a simple gslist test program which yields a non clean report when valgrind is employed. The problem seems to be in glib. Below I quote the program and the valgrind output: [...] ==6578== 20 bytes in 1 blocks are still reachable in loss record 1 of 2 ==6578==at 0x1B906F75: calloc (vg_replace_malloc.c:175) ==6578==by 0x1B94C96E: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B94E27C: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x804852E: art_alloc_raycode (sample.c:23) ==6578==by 0x80485CA: main (sample.c:76) ==6578== ==6578== ==6578== 1106 bytes in 3 blocks are still reachable in loss record 2 of 2 ==6578==at 0x1B90659D: malloc (vg_replace_malloc.c:130) ==6578==by 0x1B94C8E6: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B95C8C8: g_strdup (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B94E286: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4) ==6578==by 0x804852E: art_alloc_raycode (sample.c:23) ==6578==by 0x80485CA: main (sample.c:76) [...] Could this be something dangerous? No. GAllocators keep private globals meant to be freed automatically by the OS at program exit. Suggest adding any reported leak that mentions g_allocator_new to your valgrind suppressions. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Why no g_string_append_vprintf() ?
On Tue, 2005-12-20 at 11:10, Paul LeoNerd Evans wrote: GLib defines a function to append data in a GString using a printf-like call, void g_string_append_printf(GString *str, const gchar *fmt, ...); Is there any reason why a va_list-version isn't provided as well for this? Without that, it is impossible to further wrap va-list or ...-style functions which would call this one. If there is no overriding reason why not, I'd like to start my patches with one that exports this. http://bugzilla.gnome.org/show_bug.cgi?id=164446 A patch was already submitted in January. Still UNCONFIRMED. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why no g_string_append_vprintf() ?
On Wed, 2005-12-21 at 14:58, Paul LeoNerd Evans wrote: Finally this would allow another function I added, because I noticed I keep doing: GString *str = g_string_new(NULL); g_string_append_printf(str, fmt, ...); return str; Instead, we just return g_string_new_printf(fmt, ...); I would welcome this addition. I do that *very* frequently. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote: typedef GList GStringList; Not entirely certain I like this. See below. GStringList* g_string_split(GString *str, gchar c); Seems to me this should return a gchar** a-la g_strsplit(). Whether or not this is more useful may depend on how you use it -- I use string arrays frequently, rarely use GLists of strings. But at least the naming would be more consistent. My opinion: GLib could use more support functions for string arrays. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Tue, 2005-12-20 at 15:18, Alan M. Evans wrote: On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote: typedef GList GStringList; Not entirely certain I like this. See below. GStringList* g_string_split(GString *str, gchar c); Seems to me this should return a gchar** a-la g_strsplit(). I take that back. I can always use g_strsplit() on the GString contents. On further consideration, I suppose that your GList contains GStrings, not gchar pointers. Still not certain that g_string_split() is the best name. And not certain that GList is the best container for the returned data. Do you really not mind 24 bytes of overhead for every returned token? (12 bytes for GList + 12 bytes for GString) My opinion: GLib could use more support functions for string arrays. I do not take this back. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem sending data to gtk_button on clicked event
On Wed, 2005-11-09 at 08:39, Evan Behar wrote:
I've been getting seg-faults when I try to work with data in my button
clicked callback functions, so as a test, I compiled and ran the
following program:
#include gtk/gtk.h
gchar m1[] = button 1;
gchar m2[] = button 2;
static void callback(GtkWidget* widget, GdkEvent *event, gpointer data) {
g_print (Hello again - %08X was pressed\n, data);
}
Your problem is that the marshaller for button clicked events only
passes two parameters. Try:
static void callback(GtkWidget *widget, gpointer data);
static gboolean delete_event( GtkWidget *widget, GdkEvent *event, gpointer
data) {
g_print (Check it - %08X was pressed\n, data);
gtk_main_quit();
return TRUE;
}
int main(int argc, char* argv[]) {
GtkWidget *window;
GtkWidget *button;
GtkWidget *box1;
printf(m1: %08X\n,m1);
printf(m2: %08X\n,m2);
printf((gpointer)m1: %08X\n,(gpointer)m1);
printf((gpointer)m2: %08X\n,(gpointer)m2);
gtk_init(argc,argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(window),delete_event,G_CALLBACK(delete_event),(gpointer)m1);
box1 = gtk_hbox_new(FALSE,0);
gtk_container_add(GTK_CONTAINER(window),box1);
button = gtk_button_new_with_label(Button 1);
g_signal_connect(G_OBJECT(button),clicked,G_CALLBACK(callback),(gpointer)m1);
gtk_box_pack_start(GTK_BOX(box1),button,TRUE,TRUE,0);
gtk_widget_show(button);
button = gtk_button_new_with_label(Button 2);
g_signal_connect(G_OBJECT(button),clicked,G_CALLBACK(callback),(gpointer)m2);
gtk_box_pack_start(GTK_BOX(box1),button,TRUE,TRUE,0);
gtk_widget_show(button);
gtk_widget_show(box1);
gtk_widget_show(window);
gtk_main();
return 0;
}
I ran this program, and clicked on Button 1, then Button 2, and then the
close button.
My program output was:
m1: 080491EC
m2: 080491F5
(gpointer)m1: 080491EC
(gpointer)m2: 080491F5
Hello again - 0002 was pressed
Hello again - 0002 was pressed
Check it - 080491EC was pressed
Naturally, if I use %s to try and output the data from the button callback
functions, it seg faults.
What am I doing wrong? Is there something else I need to do to be able to
send data on a clicked event?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Alan M. Evans [EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Programming style
On Sat, 2005-10-22 at 11:49, César Leonardo Blum Silveira wrote: Hello all, I have a few doubts about the way I code my GTK applications. One of them is: Is it ok to use many global variables for the widgets? For example, in a glade app where callbacks are of the form void callback(GtkWIdget *widget) I can only have access to the widget that received the signal, but what if I want to make it change a property of another widget? Should I use a global variable or should I try getting the toplevel widget and then decending to the neighbour widget I want to make changes on? Copy/Paste from one of my Glade programs (variable names changed to protect the innocent): xml = glade_xml_new (MY_GLADE_FILE, window1,NULL); glade_xml_signal_autoconnect(xml); /* Glade2 does not allow passing user_data to signal handlers. * Callbacks requiring user_data need to be set up manually. */ widget = glade_xml_get_widget(xml,btMyButton); g_signal_connect(widget,clicked, (GCallback)on_MyButton_clicked,my_data); Where my_data is a struct containing the data (including pointers to other widgets) that I want to pass to the button. This means that I did *not* define this signal in Glade. All the signals that did not require user_data were defined in Glade and setup by the autoconnect function. Now my callback looks like: void on_MyButton_clicked(GtkButton *button, gpointer user_data); Inside the callback, user_data is my_data. Of course, this same method can apply to any type of widget, not just buttons. Or you could just use globals, which are actually OK to use more often than many pedantic programmers will admit. If you know that there will only be one instance of a particular item existing at any moment then a global is often the simplest solution. Problems often arise when program complexity increases, however. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multithreading and GTK widgets
On Sun, 2005-10-16 at 15:59, Michael Matthews wrote: Hi! I am converting my program to use multiple threads: the primary thread for the GTK stuff, and the worker threads for all the time-consuming work that will be performed in the background. The GUI thread takes input from the user and copies it to a global, shared, synchronized data pool which the worker threads monitor. The workers, in turn, invoke GTK functions to write the results to some list/tree views. The problem I have run into is that the list/tree views are not updating properly. They only show a portion of the data which has been written to their models. If I minimize the app window and then restore it, the missing data appears. What am I doing wrong, and what should I do to resolve it? Are you wrapping all your setters in calls to gdk_threads_enter/leave? For example: gdk_threads_enter(); GtkTreeIter iter; gtk_list_store_append(model,iter); gtk_list_store_set(model,iter,MY_COLUMN,my_data,-1); gdk_threads_leave(); I would have the GUI thread update the list/tree models, but the GUI thread spends most of its time sitting in gtk_main. You will, of course, need to be sure you've done the right thing in your main thread as well: gdk_threads_init(); gdk_threads_enter(); gtk_main(); gdk_threads_leave(); -AME ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_strsplit
On Wed, 2005-10-05 at 09:10, Alan M. Evans wrote: /* throw away GLib array bookkeeping - keep only array data */ sarray = (gchar**)parray-pdata; g_ptr_array_free(parray,FALSE); Come to think of it, g_ptr_array_free returns the pdata pointer. sarray = g_ptr_array_free(parray,FALSE); is better, as it is not only marginally more effecient, but also less chummy with the GPtrArray implementation. -- Alan M. Evans [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: trouble subclassing GtkScrolledWindow
*sigh* On Wed, 2005-06-08 at 11:30, Alan M. Evans wrote: Hiya! See: http://mail.gnome.org/archives/gtk-app-devel-list/2003-June/msg00146.html and http://mail.gnome.org/archives/gtk-app-devel-list/2004-March/msg00279.html There's really not much more to say inasmuch as my problem is precisely what they describe. But nobody responded on the list to either of these messages. In short, I subclass GtkScrolledWindow and in my init function pack in a GtkTextView. All pretty boilerplate at this point. When I create an instance of this class, the following error appears three times: (test_etcterminal:7321): Gtk-CRITICAL **: file gtkrange.c: line 440 (gtk_range_get_adjustment): assertion `GTK_IS_RANGE (range)' failed And everything seems to work, although I haven't tried much aside from putting some text in the buffer to see if the scrollbars work (they do). But having my application report CRITICAL errors is, well, troublesome. If someone really wants to try, the sources that demonstrate this are at: http://alanevans.org/etcterminal/ -Alan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Alan M. Evans [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
trouble subclassing GtkScrolledWindow
Hiya! See: http://mail.gnome.org/archives/gtk-app-devel-list/2003-June/msg00146.html and http://mail.gnome.org/archives/gtk-app-devel-list/2004-March/msg00279.html There's really not much more to say inasmuch as my problem is precisely what they describe. But nobody responded on the list to either of these messages. In short, I subclass GtkScrolledWindow and in my init function pack in a GtkTextView. All pretty boilerplate at this point. When I create an instance of this class, the following error appears three times: (test_etcterminal:7321): Gtk-CRITICAL **: file gtkrange.c: line 440 (gtk_range_get_adjustment): assertion `GTK_IS_RANGE (range)' failed And everything seems to work, although I haven't tried much aside from putting some text in the buffer to see if the scrollbars work (they do). But having my application report CRITICAL errors is, well, troublesome. If someone really wants to try, the sources that demonstrate this are at: http://alanevans.org/etcterminal/ -Alan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
On Wed, 2005-06-01 at 12:25, Tristan Van Berkom wrote: Alan M. Evans wrote: If I make a class that internally uses threads and mutexes, how do I protect myself against another class (not necessarily mine) created in another thread (not necessarily under my control) also calling g_thread_init() because it is also internally using gthread? That sounds conceptualy broken, if I instantiate a GObject that is a GtkWidget, the GtkWidgetClass initializer will not call gtk_init() for me, so why should an object using the thread system have to call g_thread_init () ? The comparison lacks parity, in my opinion. It seems unlikely to me that a class which uses GtkWidget would be used in a non-GTK+ program. (Class in the C++ sense, not the GObject sense.) On the other hand, It seems completely feasable that a class that uses GLib types and threads might be used in an application which has no knowledge of GLib. In fact, that's exactly what I'm doing. In other words, a shared object that uses GLib might not expose GLib, but how would a shared object that uses GTK+ not expose that? Maybe it would be appropriate for the class initializer to do: if (!g_thread_supported ()) g_critical (You must initialize the thread subsystem to use MyObjectClass); Perfectly appropriate in an environment where GLib is assumed to be part of the development chain. Not so when the application developers (think Win32) have never heard of GLib. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_thread_init question
On Wed, 2005-06-01 at 14:28, Tristan Van Berkom wrote:
Alan M. Evans wrote:
(Class in the C++ sense, not the GObject sense.)
I am tempted to argue that class in the c++ sence *is* the same
as a class in the GObject sence; but that is a little off-topic :)
I knew you would be, and so would I. What I meant by that is, that a C++
API exporting a simple class makes no demands about the application
knowing GLib. One which exports a GObject or descendant implies that the
application know GLib.
The race condition is present only if you make it possible that
you call g_thread_init () from two seperate threads, to be blunt;
its your responsability to make sure that doesn't happen.
I know that it's my responsibility. That is why I asked the question in
the first place.
So lets say that you are writing an application that uses
GStreamer, GTK+ your shared object, in your main () you
will call each of the following:
void main () {
gtk_init (); // -- calls g_threads_init ()
gst_init (); // -- calls g_threads_init ()
my_customlib_init (); // your shared object library init point
// that will also call g_threads_init ()
}
I thought of this, but it seemed ... inelegant. Suppose I create a
drop-in replacement for the Win32 CAsyncSocket class. (Not what I'm
doing, by the way.) Now CAsyncSocket does not require calling some init
procedure, but MyClass does. Not really a drop-in replacement, is it?
I didn't come here to pick a fight. Honest. But it seems to me that this
whole thing would be a non-issue if g_threads_init() would respond to a
second call by returning instead of aborting. Imagine:
void g_threads_init(GThreadFunctions *vtable) {
static GStaticMutex only_once = G_STATIC_MUTEX_INIT;
if (g_static_mutex_trylock(only_once)) {
g_threads_real_init(vtable);
}
}
and no more aborting! I'm probably oversimplifying something there, but
it seems to me that the proper place to assure something is exclusive is
at the point of exclusivity (inside GLib) not independently by every
user of the exclusive procedure.
Sorry, now I'm ranting. I'll go away; just came here hoping there was
another choice...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
