Re: Conversion functions.
I looked at the code and I as far as I also think that something should be printed to stdout. The only thing I could see in the code was that malloc wasn't used to allocate char *buf in the args to function getline(). Magnus On Fri, 7 Sep 2007 10:08:19 +0200 David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Fri, Sep 07, 2007 at 01:45:09AM +0200, Magnus Myrefors wrote: yeti I have tested your minimal testprogram with the whole test-file. Unfortunately the program doesn't print anything to stdout. It doesn't seem to be any data stored in the GSList or in the datastructure, Data *data. If there is any line that starts with a digit (after possible whitespace), it has to print either the data or an error. If it doesn't, then there is no line whose first non-whitespace character would satisfy g_ascii_isdigit(c) or it does not end up in the list. This means either - g_ascii_isdigit(c) does not evaluate to TRUE for digits on your system - g_slist_prepend() does not work - g_slist_reverse() does not work - the file looks different than you sent Which one is it? (I tried to print a field every time a new line was about to be read in the while-loop). Furthermore, I wonder if the test, if(end == start) failfield = Latitude;, can conclude that the string was converted correctly with g_ascii_strtod(). If g_ascii_strtod() converts only a fraction of the string, it will result in (end != start) and failfield won't be set which results in no output to stderr. end is the input to the next conversion, therefore failfield will be set in the next conversion (or trailing garbage message will be printed if it was the last). Unless the file contain one of the few possible cases of concatenated floating point numbers that can be parsed back -- these can be catched by checking whether *end is space or '\0'. But this does not matter at all. Either way you get *some* output, either data or errors (or both in the case of trailing garbage). You must get some output even if g_ascii_strtod() and strtol() return completely random values. So I just don't believe you. Period. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Custom cel renderer
Hi All, I am trying to write custom cell renderer which should be able to display GtkWidgets. But I am not able to get GdkWindow of widget to be displayed since it not displayed or added to any container(not realized yet). I am creating one widget say GtkButton and wanted it to be displayed on cellrenderer. What i am trying is to implement 'cell_class-render' and in it try to draw this widget on parent GdkWindow through gdk_draw_drawable() but i am not able to get GdkDrawable (GdkWindow) of widget(i.e of button) to draw it on destination GdkWindow. Is there any way to draw this widget on parent GdkWindow or is there any other way to display widgets with cellrenderer? Are there any guidelines to write custom cellrenderer which will display any GtkWidget? Thanks in advance. Regards, Amol ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
is there a memory leak problem with gtk_widget_queue_draw()?
Hi, I am using GLib's memory profiling to check memory usage of my program. I noticed that for each refresh in my screen with gtk_widget_queue_draw(), I am checking my allocated memory and each refresh increases the size of allocated memory. Do you know any memory leak problem in gtk_widget_queue_draw()? Regards, -- View this message in context: http://www.nabble.com/is-there-a-memory-leak-problem-with-gtk_widget_queue_draw%28%29--tf4392383.html#a12523308 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: is there a memory leak problem with gtk_widget_queue_draw()?
On 9/6/07, okty [EMAIL PROTECTED] wrote: Hi, I am using GLib's memory profiling to check memory usage of my program. I noticed that for each refresh in my screen with gtk_widget_queue_draw(), I am checking my allocated memory and each refresh increases the size of allocated memory. Do you know any memory leak problem in gtk_widget_queue_draw()? The page http://live.gnome.org/Valgrind has some info on providing flags to glib, making it use less efficient (but memcheck-friendly) memory allocation code. Also, try writing a bare-bones program that does nothing except call gtk_widget_queue_draw code periodically, and see if you can replicate the problem. -Jim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: is there a memory leak problem with gtk_widget_queue_draw()?
On 9/6/07, okty [EMAIL PROTECTED] wrote: Hi, I am using GLib's memory profiling to check memory usage of my program. I noticed that for each refresh in my screen with gtk_widget_queue_draw(), I am checking my allocated memory and each refresh increases the size of allocated memory. Do you know any memory leak problem in gtk_widget_queue_draw()? I've never used Glib's memory profiling, but sometimes other programs like Valgrind (you could use this as well) report false positives in memory leaks. It has something to do with the way the memory is allocated (GAllocator is specially confusing for profilers) Does the profiler report the problem is inside gtk_widget_queue_draw code? Cheers Regards, -- View this message in context: http://www.nabble.com/is-there-a-memory-leak-problem-with-gtk_widget_queue_draw%28%29--tf4392383.html#a12523308 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Conversion functions.
On Fri, 7 Sep 2007 16:16:35 +0200 Magnus Myrefors [EMAIL PROTECTED] wrote: By the way I have found out that I used a way of reading lines from the input-file which can cause some problem. I read in a book that fgets(string, sizeof(string), input) should read one line up to sizeof(string) -1 or to the first newline- character. But when I tested I found out that that wasn't the case. That can explain the false data. Magnus I looked at the code and I as far as I also think that something should be printed to stdout. The only thing I could see in the code was that malloc wasn't used to allocate char *buf in the args to function getline(). Magnus On Fri, 7 Sep 2007 10:08:19 +0200 David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Fri, Sep 07, 2007 at 01:45:09AM +0200, Magnus Myrefors wrote: yeti I have tested your minimal testprogram with the whole test-file. Unfortunately the program doesn't print anything to stdout. It doesn't seem to be any data stored in the GSList or in the datastructure, Data *data. If there is any line that starts with a digit (after possible whitespace), it has to print either the data or an error. If it doesn't, then there is no line whose first non-whitespace character would satisfy g_ascii_isdigit(c) or it does not end up in the list. This means either - g_ascii_isdigit(c) does not evaluate to TRUE for digits on your system - g_slist_prepend() does not work - g_slist_reverse() does not work - the file looks different than you sent Which one is it? (I tried to print a field every time a new line was about to be read in the while-loop). Furthermore, I wonder if the test, if(end == start) failfield = Latitude;, can conclude that the string was converted correctly with g_ascii_strtod(). If g_ascii_strtod() converts only a fraction of the string, it will result in (end != start) and failfield won't be set which results in no output to stderr. end is the input to the next conversion, therefore failfield will be set in the next conversion (or trailing garbage message will be printed if it was the last). Unless the file contain one of the few possible cases of concatenated floating point numbers that can be parsed back -- these can be catched by checking whether *end is space or '\0'. But this does not matter at all. Either way you get *some* output, either data or errors (or both in the case of trailing garbage). You must get some output even if g_ascii_strtod() and strtol() return completely random values. So I just don't believe you. Period. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Scrolledwindow, layout and drawing area
Hi Federico, On 9/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: other widgets (like side panes, menu bar etc.); I need zooming and panning features, so I went for a scrolled window = layout = drawingarea. Why do you need the layout? You can just put a drawingarea inside a scrolledwindow. To zoom, just change the size of the drawing area and queue a repaint. To achieve zooming I handle the scroll event by scaling the original size pixbuf and copying it to an off screen pixbuf that is copied on the drawingarea in the expose_event handler. This will waste a lot of memory in the X server. I would keep the original image in your client program, then in the expose handler, just zoom up the bit of the image you need. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
could not use GTK+ with Evolution email..
Hi, I am trying to build the Evolution email client with directfb patches for cairo and gtk+. The build process fails with the following errors. -- /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_create_for_bitmap' /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_create' /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_set_size' collect2: ld returned 1 exit status make[3]: *** [test-calendar] Error 1 make[3]: Leaving directory `/root/build/src/evolution-2.8.3/widgets/misc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/build/src/evolution-2.8.3/widgets' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/build/src/evolution-2.8.3' make: *** [all] Error 2 Checking .. Error code is 2 -- I am using the gtk+ with directfb enabled and other supporting patches. One important thing is, the Evolution 2.8.3 is dependent on gtkhtml-3.12.3. I am not sure whether there is an equivalent ported version in GTK+ or my approach is not correct. Any idea what's going wrong.. Thanks in advance for any help.. Ramesh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Conversion functions.
On Fri, Sep 07, 2007 at 01:45:09AM +0200, Magnus Myrefors wrote: yeti I have tested your minimal testprogram with the whole test-file. Unfortunately the program doesn't print anything to stdout. It doesn't seem to be any data stored in the GSList or in the datastructure, Data *data. If there is any line that starts with a digit (after possible whitespace), it has to print either the data or an error. If it doesn't, then there is no line whose first non-whitespace character would satisfy g_ascii_isdigit(c) or it does not end up in the list. This means either - g_ascii_isdigit(c) does not evaluate to TRUE for digits on your system - g_slist_prepend() does not work - g_slist_reverse() does not work - the file looks different than you sent Which one is it? (I tried to print a field every time a new line was about to be read in the while-loop). Furthermore, I wonder if the test, if(end == start) failfield = Latitude;, can conclude that the string was converted correctly with g_ascii_strtod(). If g_ascii_strtod() converts only a fraction of the string, it will result in (end != start) and failfield won't be set which results in no output to stderr. end is the input to the next conversion, therefore failfield will be set in the next conversion (or trailing garbage message will be printed if it was the last). Unless the file contain one of the few possible cases of concatenated floating point numbers that can be parsed back -- these can be catched by checking whether *end is space or '\0'. But this does not matter at all. Either way you get *some* output, either data or errors (or both in the case of trailing garbage). You must get some output even if g_ascii_strtod() and strtol() return completely random values. So I just don't believe you. Period. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
