Re: frequently updated pixbuf images disapear after a while
On Sun, 27 Aug 2006, rupert wrote:
> gboolean crypto_mapper_check(gchar *data)
> {
> gchar *mapper_chk_cmd;
> gboolean result_mapper=FALSE;
>
> mapper_chk_cmd = g_strdup_printf("/dev/mapper/%s", data);
>
> FILE *fp = fopen(mapper_chk_cmd, "r");
> g_free(mapper_chk_cmd);
>
> if(fp)
>result_mapper = TRUE;
> else
> result_mapper = FALSE;
>
if (fp)
fclose(fp)
> //fclose(fp);/* this one crashes the the app when enabled*/
> return result_mapper;
> }
alternatives (not compile tested):
gboolean crypt_mapper_check(gchar *data)
{
gchar *s;
FILE *fp;
s = g_strdup_printf("/dev/mapper/%s", data);
fp = fopen(s, "r");
g_free(s);
if (fp) {
fclose(fp);
return TRUE;
} else
return FALSE;
}
gboolean crypt_mapper_check(gchar *data)
{
gchar *s;
FILE *fp;
s = g_strdup_printf("/dev/mapper/%s", data);
fp = fopen(s, "r");
g_free(s);
if (fp)
fclose(fp);
return fp != NULL;
}
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: frequently updated pixbuf images disapear after a while
On Sun, 27 Aug 2006, rupert wrote: > the g_sprintf returns the number of characters, so i should use it like the > normal sprintf, > gchar *mapper_chk_cmd; > g_sprintf(mapper_chk_cmd, "/dev/mapper/%s", data); > > but it doesnt seem to help, the segfault is there, too Sorry, I meant g_strdup_printf(). > when i init it with gchar mount_chk_cmd[128]; i can use it like > with sprintf, but i cant free the memory for these gchars. > > I got the warning with the g_sprintf, but i think it was because it returned > int > > i removed the fclose and pclose, but the app also crashed after a while with > the same > symptoms. > The file descriptor thing has nothing to do with the segfaults. They were a separate problem. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: frequently updated pixbuf images disapear after a while
On Sun, 27 Aug 2006, rupert wrote: > mh, i noticed that, but when i the fclose in the line before return TRUE i get a segfault. You are papering over another fault. Find that and fix it instead. It might be that sprintf() creates a string that is too big for the buffer you allocated. Such things can be quite unhealthy, which is why one should use g_sprintf() instead. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: frequently updated pixbuf images disapear after a while
On Sun, 27 Aug 2006, rupert wrote:
> i changed it to this
>
> gchar mapper_chk_cmd;
> mapper_chk_cmd = g_sprintf(MAPPER_PATH, data);
>
> but now i get a warning about a wrong pointer assignment(translated into
> english)
> in the fopen call.
You ought to get a warning about the mapper_chk_cmd = g_sprintf(...)
assignment, too.
If you don't, then you should turn on more warnings (you need BOTH -W AND
-Wall because gcc programmers are weird).
The reason is of course that mapper_chk_cmd needs to be a gchar * and not
a gchar.
>
>>
>>>FILE *fp = fopen(mapper_chk_cmd, "r");
>>>
>>>if(fp) {
>>>return TRUE;
>>>} else {
>>>return FALSE;
>>>}
>>>fclose(fp);
>>
>> file descriptor leak.
>
>
> ?? what do you mean with that, how can i fix that?
Open files have a small cost associated with them. You should free those
resources by closing files, particularly when you can't possibly use them
again.
In this case I can tell for sure that you are not going to need the files
because you open them inside a function and the file pointer value
can't escape (at least as the function currently stands).
>
>>return TRUE;
>>> }
>>>
>>> gboolean crypto_mount_check(gchar *data)
>>> {
>>>gchar mount_chk_cmd[128];
>>>gchar buf[512];
>>>
>>>sprintf(mount_chk_cmd, MOUNT_PATH, data);
>>
>> mount_chk_cmd = g_sprintf(MOUNT_PATH, data);
>
>
> same aS above
Ditto ;)
>
>>
>>>FILE *pp = popen(mount_chk_cmd, "r");
>>>
>>>if(pp) {
>>>size_t got = fread(buf, 1, sizeof(buf), pp);
>>>pclose(pp);
>>>if(got != 0) {
>>
>> check also errno.
>>
>>>return TRUE;
>>>} else {
>>>return FALSE;
>>>}
>>>}
>>>
>>>return TRUE;
>>
>> why TRUE?
>
>
> without I get a warning that a non-void function flew ends(translated.)
Yeah, but I mean, why do you want it to return TRUE and not FALSE?
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: frequently updated pixbuf images disapear after a while
On Sun, 27 Aug 2006, rupert wrote:
> {
>gchar mapper_chk_cmd[128];
>
>sprintf(mapper_chk_cmd, MAPPER_PATH, data);
mapper_chk_cmd = g_sprintf(MAPPER_PATH, data);
(if MAPPER_PATH is a format string with zero or one %s in it.)
>
>FILE *fp = fopen(mapper_chk_cmd, "r");
>
>if(fp) {
>return TRUE;
>} else {
>return FALSE;
>}
>fclose(fp);
file descriptor leak.
>return TRUE;
> }
>
> gboolean crypto_mount_check(gchar *data)
> {
>gchar mount_chk_cmd[128];
>gchar buf[512];
>
>sprintf(mount_chk_cmd, MOUNT_PATH, data);
mount_chk_cmd = g_sprintf(MOUNT_PATH, data);
>
>FILE *pp = popen(mount_chk_cmd, "r");
>
>if(pp) {
>size_t got = fread(buf, 1, sizeof(buf), pp);
>pclose(pp);
>if(got != 0) {
check also errno.
>return TRUE;
>} else {
>return FALSE;
>}
>}
>
>return TRUE;
why TRUE?
> }
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key-value file parser, howto get all groups and create loop from them
On Mon, 14 Aug 2006, rupert wrote:
> void crypto_mount_set_pixbuf(struct treedata *treedata){
>
> gchar *mountpoint;
> GtkTreeIter iter;
> gtk_tree_model_get_iter_first(treedata->store,&iter);
>
A couple of stylistic points:
1) put the opening brace as the first thing on the next line
2) add an empty line between the variable declarations and the first line
of code (the gtk_tree_model_get_iter_first() call).
3) put a space after the ',' that separetes the arguments to
gtk_tree_moedl_get_iter_first().
In Java the normal thing seems to be to put the brace on the first
line, the way you did (except that they would add a space between
')' and '{').
Different languages have different idioms.
Almost *all* C programmers would agree with 1, 2, and 3 above.
> do
> {
Most C programmers would put these on the same line as 'do {' (note the
space).
> gtk_tree_model_get(treedata->store, &iter, MOUNTPOINT_COLUMN,
> &mountpoint, -1);
> g_print("MOUNTPOINT_COLUMN: %s\n", mountpoint);
>
> if(crypto_mount_check(mountpoint))
> {
Likewise.
> g_print("%s FOUND\n", mountpoint);
> treedata->pixbuf_mount =
> gdk_pixbuf_new_from_file("pics/mount.png", NULL);
> gtk_list_store_set(treedata->store, &iter, MOUNT_COLUMN,
> treedata->pixbuf_mount, -1);
> g_object_unref(treedata->pixbuf_mount);
>
> }
> else
> {
Most C programmers would put these three on the same line: '} else {'.
> g_print("%s NOT FOUND\n", mountpoint);
> treedata->pixbuf_mount =
> gdk_pixbuf_new_from_file("pics/unmount.png", NULL);
> gtk_list_store_set(treedata->store, &iter, MOUNT_COLUMN,
> treedata->pixbuf_mount, -1);
> g_object_unref(treedata->pixbuf_mount);
>
> }
>
> }while(gtk_tree_model_iter_next(treedata->store, &iter));
Almost all C programmers would have a space between '{' and 'while'.
Most would also have a space between 'while' and '(', as 'while' is a
keyword, not a function call (the same goes for 'if', 'for', 'switch').
> gtk_tree_model_get_iter_first(treedata->store,&iter);
No need to do the final gtk_tree_model_get_iter_first(). I mean, iter is
a local variable and you are done with it and besides it gets destroyed
anyway as soon as the function returns...
> }
>
>
> I have to give me a timeframe of a day or two before asking question,(this
> gets a note on the monitor.)...
;)
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key-value file parser, howto get all groups and create loop from them
On Mon, 14 Aug 2006, rupert wrote: > thx for the hel, with adding the tip lanve gave its working somehow now, > but i had to do some changes: > > gtk_tree_model_get_iter_first(treedata->store,&treedata->iter); > i have this line now before make_list and also in the function that updates > the > pixbuf. The next improvement you should try is to remove the iter field from the struct, remove the gtk_tree_model_get_iter_first() call before the call to make_list() and put a gtk_tree_model_get_iter_first() call into your callback function (probably as the first line of code after the declarations of the local variables). Iterators are usually just used as a special kind of loop variables -- you don't make loop variables global just so you can use the same loop variable in another loop inside a completely unrelated function. Or so that you can initialize a local loop variable to whatever value was left in the global loop variable from the last executed loop somewhere else. Just get rid of it. > Now i have to extract one field from every single line, so that i update the > pixbuf in > each line. use gtk_tree_model_iter_next() inside your loop. You can use it instead of normal loop variable: just call it until it returns FALSE. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key-value file parser, howto get all groups and create loop from them
On Mon, 14 Aug 2006, Lance Dillon wrote: > The problem is your code doesn't seem to initialize iter in any way. > Before you call make_list, you should probably do something like this: No, no. make_list() by itself is fine. It sets its local iter in every iteration through the call to gtk_list_store_append(). The problem is that the global treedata.iter doesn't get set by the call to make_list(). If it /had/ been a call-by-reference parameter, then it would have been set to point to the last item in the model (which is perhaps also not what Rupert wanted but at least /something/ would happen). > gtk_tree_model_get_iter_first(treedata.store,treedata.iter); > > This initializes iter to the beginning of the treemodel. > Then you can call make_list(). 1) Not necessary at all before calling make_list(). 2) might be nice anyway -- but after calling make_list or perhaps inside the callback function. But actually, the real question is: why keep a global iterator around in the first place? -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key-value file parser, howto get all groups and create loop from them
On Mon, 14 Aug 2006, rupert wrote:
> void make_list(GtkListStore *store, GtkTreeIter iter, gpointer
> pixbuf_mapper_yes, gpointer pixbuf_mapper_no, gpointer pixbuf_mount_yes,
> gpointer pixbuf_mount_no){
Notice the lack of * in front of the variable iter.
> make_list(treedata.store, treedata.iter, treedata.pixbuf_mapper_yes,
> treedata.pixbuf_mapper_no, treedata.pixbuf_mount_yes,
> treedata.pixbuf_mount_no);
and likewise the lack of & in front of treedata.iter.
> hope thats the part you are asking for
It was and it explains the symptoms perfectly :)
Now go and read up on parameter passing in C -- especially how C really
always uses call-by-value and how call-by-reference is only supported by
doing it "manually".
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key-value file parser, howto get all groups and create loop from them
On Mon, 14 Aug 2006, rupert wrote: Strangely the function seems to stop, because i only get 1 test on the bash: (cryptomaster:11056): Gtk-CRITICAL **: gtk_list_store_set: assertion `iter->stamp == list_store->stamp' failed And how, pray tell, do you get your iterator initialized? ;) The snippet you showed just copied the iterator in the struct into your local iterator -- but how do you get a sensible value into the iterator in the struct? -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: pthread_t through pthread_self?
On Sun, 13 Aug 2006, Luka Napotnik wrote: > I'm interested if the function pthread_self() returns a valid pthread_t > structure for threads, created with g_thread_new() so the pthread_t can > be used with pthread_kill() ? As long as you are working on top of POSIX, yes, it should. pthread_kill() does perhaps do not do what you want: http://docs.sun.com/app/docs/doc/816-5137/6mba5vpk4?a=view http://users.du.se/~hjo/realtime/manuals/posix-threads/uguide/users-95.htm "For example, sending a SIGKILL signal to a thread using pthread_kill() will terminate the entire process, not simply the target thread. SIGKILL is defined to terminate the entire process, regardless of the thread it is delivered to, or how it is sent." You probably want to use pthread_cancel(). http://www2.yo-linux.com/cgi-bin/man.cgi?section=all&topic=pthread_cancel -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: help me catch up on GTK gui tools
On Sun, 6 Aug 2006, Tristan Van Berkom wrote: >We are planning on releasing the first stable Glade 3 very soon > (along the lines of "this week"). :))) Looking forward to that! -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Animation problem
On Sun, 6 Aug 2006, Norbert Bauer wrote:
> Thank you very much!
> Like this it's now working and seems korrekt :-)
Isn't the real solution to actually call the main loop once in a while?
while (...) {
/* FALSE means do NOT block when there are no more events
(so we know it will return as quickly as it reasonably can)
*/
if (gtk_main_iteration_do(FALSE)) {
... gtk_main_quit() was called while inside gtk_main_iteration_do()
... so the user must have asked us to quit
}
... do whatever that is the reason for having to block the outer
... main loop in the first place
}
Once you have a main loop running, all event handling and timeouts work
normally so you should be able to use a standard animation in a standard
way.
-Peter
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: help me catch up on GTK gui tools
On Sun, 6 Aug 2006, Brett Stottlemyer wrote: > Thanks for the help. You're welcome. > My thought for starting with Solaris instead of a > Linux variant was that I have used Solaris (but not like this) and not > Linux. While it would certainly be easier to test in Linux, it would mean > I'd have to eventually fight the learning curves for both Linux and Solaris. It is probably easier to 'apt-get install devhelp' and learn how GTK+/Gnome works on Linux than to fight the entire battle on Solaris. But maybe that's just me ;) (btw. why on Earth do you have to use Solaris at all? Is it Company Policy that Cannot be Changed? ZFS and dtrace are cool but isn't that about it?) > Not that I'm getting the code compiled on Solaris, I may try out Linux. I > didn't want to spend the time to find something I like in one environment > then find out it is somehow incompatible with the environment I need. The > free VMWare Server sure gives me more options (No affiliation, a friend > pointed me in their direction about a month ago). > > So from a GUI building standpoint, I can use whatever works to get the > basics done and then modify/update in code for any custom widgets. Sounds > good to me. I really just want simple controls around a gtkglext window. While I'm at it: do NOT have glade generate code for you! It is a trick to trap you into having completely unmaintainable code and a GUI you no longer can modify with glade or anything else. Instead, ask for whatever named widget (including windows and dialogs) you need from the glade XML file with glade_xml_get_widget(). You can either connect signals to callback functions manually with g_signal_connect() or you can use a linker option (--export-dynamic) that puts non-static function names into the executable and then call glade_xml_signal_autoconnect(). You specify which functions you want connected with which signals inside glade. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 6 Aug 2006, Iago Rubio wrote: > The 'possibly lost' bites means - AFAIK - that exists pointers to the > interior of the analyzed block that may have pointed to the start of the > block and have been moved, among other possible causes, such as debug > padding - where a pointer to an object is returned as the start + > padding of the memory block as with pymalloc and python debug builds. GTK+/Gnome doesn't release everything on exit normally -- and that's a feature! Why waste time on piecemeal clean up of things the operating system is going to clean up anyway much faster? You even risk slow paging in from swap in order to do that useless clean up! (I think that used to be a real performance bug with Netscape/Mozilla.) There is an environment variable that can be set to a specific value to tell the libraries to clean up their stuff anyway so the leaks in an application can stand out. Can't remember what the variable is called or what value to set it to. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: help me catch up on GTK gui tools
On Sat, 5 Aug 2006, Brett Stottlemyer wrote: > So to get started and figure out what I want to use, I'm testing out tools > at home using Solaris 2.10 installed within VMWare Server on a PC (I never > could get MINGW/MSYS/GTK to work on the PC, plus that wasn't the end system Testing/playing around will undoubtedly be easier with a modern Linux distribution instead of Solaris ;) Personally, I use Ubuntu Dapper, others may use Fedora or Novell/SuSE. > anyway). I know the general advice is to install the binary packages, but I > don't have much sysadmin experience and this is on a fresh Solaris 10 > install (on my PC) - I figured if I couldn't compile the libraries I'd have > trouble with any tools using the libraries (this also goes back to the PC > trouble I had). So I've spent more than a few days getting gtk 2.10.1 and > all dependencies compiled. Which could have been a couple of 'apt-get install' commands or some pointing and clicking inside Synaptic with Ubuntu. I know that you need to get this thing running on Solaris at the end, but along the way you also need to try out various alternatives and that might (will!) be a heck of a lot easier on something more mainstream. Regarding getting things built from source: jhbuild might possibly be your friend. It can autodownload from tarballs and CVS (and subversion?) and compile the libraries for you. After it is done you can see what it ended up downloading, pack it up, and take it with you to work. > My not properly conceived notion was to then get > gtkglext/glade and the corresponding mm versions and start testing > development. Now that I have 2.10.1 compiled, there is no gtkmm 2.10 (2.6 > is the latest stable) and there is a choice with glade v2 (for gtk 2.8) and > the in-development glade v3. I also saw a hint that gtkbuilder (in > development?) is preferred over glade also. I have only used glade v2 (and v1). It is ugly and clunky but it gets the job done. > And I'm not sure which versions > are compatible with gtkglext. All of them. You can name your widgets in the GUI builder and inside your program you can get a pointer to any of the named widgets. If that widget is a container, you can easily put your own, manually created, widget into it, for example. Or you could call gdk_gl_window_new() on its GdkWindow (accessible in the window attribute of every GtkWidet -- except for those that don't have their own window where it is NULL) and then start drawing. In other words, it matters very little if glade/gtkbuilder has direct support for a widget or not. About your long list of options, I can't really tell which is best. All I can say is that I have programmed Gtk+/Gnome in C and Perl with very few problems. Maybe you should just get something running on some libraries that are relatively easy to install and see how that goes? -Peter PS: Sorry for the convoluted syntax :/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: AW: threads & gtk
On Sat, 5 Aug 2006, chabayo wrote: > ...fork() creates a copy (or less a copy if kernel has a workaround - i > dont now how that's handled) of memory? fork() does indeed create a copy. If you have a variable in the original process (= the parent), the child process will also have a variable -- with the same value. Those values are not kept synchronized, however, as the two processes don't share their memory. (ok, the kernel does optimize things a bit -- it doesn't change how it works and looks to a programmer, it only speeds things up a bit.) When you are using fork() then you are not using threads. At all. gdk_threads_enter()/gdk_threads_leave() are not relevant. At all. The child processes must not try to call X directly or indirectly (so no gdk_() calls). Only the parent process may do that. Perhaps the simplest way of making sure that gets done right is to use simple external programs (which you can then also test in isolation from the command line). In that case, you should really use g_spawn_async_with_pipes(), which also papers over differences between windows and Unix/Linux. Using fork() can work splendidly but you must know what you are doing. And then there's the threads way. That can also work splendidly but here you must also really know what you are doing. Some of the rules are the same as with processes: only the main thread should use X and GDK and GTK+ and Gnome (unless you REALLY know what you are doing!). So let the main thread handle the GUI and let the others be worker threads that communicate with the main thread to arrange for it to update the GUI or to be told to go off and do different stuff based on what the user does with the GUI. But if you are using threads, fork() make no sense and pipes make (almost) no sense, either. For communication between threads, have a look at GAsyncQueue. For making sure that only one thread touches shared data structures at a time, have a look at GMutex and g_atomic_int_get() and friends. After getting /something/ up and running with either threads or with g_spawn_async_with_pipes(), take a moment (read: a couple of days, more like it), to specify, in detail, on paper, precisely what needs to be communicated between the threads. Consider if the worker threads need to get the main thread to do something when they are done. Consider if they should grab one task at a time from the main thread and complete that or if they should abort whatever they are doing if the main thread has new work for them. Consider what should happen in the user interface if one or both of the worker threads is/are already working on something. Should the option to create more work for them be grayed out while they are busy? Is there anything the threads need to communicate between each other? How about preferences (that you might want to make changeable from the GUI) -- should you lock the entire preferences block while the worker threads are busy so their preferences don't suddenly change under them? (that could be a really nasty problem to find!) Oh, and see what Wikipedia has to teach about concurrent programming. In particular: reentrancy, data consistency, atomicity of updates/reads, critical sections, deadlocks, and race conditions. > As i mentioned a pipe _works_like_ a file handle all file handles get > dublicated except the 1,2 & 3 ?? - or just pipes? ( ok, just could test > but may miss something ) The parent process can actually choose which file handles get inherited. But never mind that -- you shouldn't need to know. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: threads & gtk
On Sat, 5 Aug 2006, chabayo wrote: > pid_t pid=fork (); > gdk_threads_enter (); threads and processes are not quite the same... (threads share address space, processes don't. Threads share file handles, processes don't (with a few exceptions).) I think you are looking for g_thread_create() and related functions. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
