should I delete the pointer by myself, or not?
hi, all
Glib::RefPtrGnome::Glade::Xml refXml;//-- this pointer
try {
refXml = Gnome::Glade::Xml::create(somefile);
}
catch (const Gnome::Glade::XmlError ex) {
// should i delete it ?
// how to delete it by myself?
g_print(ex.what().c_str());
return 1;
}
may i declare refXml like this:
auto_ptrGlib::RefPtrGnome::Glade::Xml refXml ?
- Wuan
Thanks all for replies
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About gtk_object_set_data()
hi,
chao yeaj wrote:
Hello everyone
I have a check button
and the check button may have an associated data,which is an
source id returned by g_timeout_add() function
I do this,because,the check button may be need a function
periodically changing its attributes
to manage the source id returned by g_timeout_add()
i use gtk_object_set_data() function to set the id to the
object's data filed
during the check button's life time, i may remove the data
using g_source_remove,and may create the data again using
g_timeout_add()
What I am not clear is that: when the check button is
destroying ,how gtk manage the data i set to the object?
When an object gets destroyed, its qdata list gets freed.
g_object_{s|g}et_data are convinience functions for
g_object_{s|g}et_qdata. Both work on the same data-list.
Stefan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: RADiola, a GTK RAD tool
Hi, I really like the idea. Looks great! The logical editor is a nice idea and it definitely outlines the ease with which the tool can be used. Can I get a sample version to try it? Atanas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
float params of a gobject
Hi, I'm trying to define a gobject class with a floating number property. In the init class procedure I define the property the following way: param_spec = g_param_spec_float (width /* name */, _(Icon Width) /* nick */, _(The width of the svg icon) /* blurb */, G_MINFLOAT /* minimum */, G_MAXFLOAT /* maximum */, 0.0 /* default_value */, (GParamFlags)(G_PARAM_READABLE | G_PARAM_WRITABLE)); g_object_class_install_property (g_object_class, PROP_WIDTH, param_spec); This compiles fine, but when running the test program it raises a glib exception: (test:5073): GLib-GObject-CRITICAL **: g_param_spec_float: assertion `default_value = minimum default_value = maximum' failed (test:5073): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed But default value 0.0 is equal G_MINFLOAT and lesser than G_MAXFLOAT, isn't it? Please I need a bit of help: What am I doing wrong? Or is it a glib bug? By the way the object is being created with gob, but I believe that the generated code is ok. Thanks in advance. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: float params of a gobject
Daniel Alonso wrote: [...] But default value 0.0 is equal G_MINFLOAT and lesser than G_MAXFLOAT, isn't it? Not sure here, but could it be something really dumb like... should you be using something more violent like: 0.0F or ((gfloat) 0 + 0.0) ? Just a guess... Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkClipboard and MS Windows port
Hello,
as I am trying to port a program written in C using Gtk+ on a Debian
GNU/Linux to MS Windows (using the MingGW32 compiler set) I have a
problem using GtkClipboard.
The program should simply do copy/paste stuff with simple text. While
I can happily use the X Window selection mechanisms (PRIMARY and
CLIPBOARD) on my GNU/Linux box, the copy/paste stuff does not work
with the MS Windows executable.
This is the error message that I get before even trying to use the
clipboard :
Gdk-WARNING ** gdk_selection-win32.c:1068
OpenClipboard failed : Handle de fenêtre non valide
which means that the window handle is not valid.
Now, if I go to the gdk_selection-win32.c file at line 1068 I find the
following (see arrow on the right-hand side margin below) :
void
gdk_win32_selection_add_targets (GdkWindow *owner,
GdkAtom selection,
gint n_targets,
GdkAtom *targets)
{
HWND hwnd;
guint formatid;
gint i;
GSList *convertable_formats, *format;
gboolean has_set_dib = FALSE, has_real_dib = FALSE;
#ifdef G_ENABLE_DEBUG
if (_gdk_debug_flags GDK_DEBUG_DND)
{
gchar *sel_name = gdk_atom_name (selection);
g_print (gdk_win32_selection_add_targets: %p: %s: ,
owner ? GDK_WINDOW_HWND (owner) : NULL,
sel_name);
g_free (sel_name);
for (i = 0; i n_targets; i++)
{
gchar *tgt_name = gdk_atom_name (targets[i]);
g_print (%s , tgt_name);
g_free (tgt_name);
}
g_print (\n);
}
#endif
if (selection != GDK_SELECTION_CLIPBOARD)
return;
if (owner != NULL)
{
if (GDK_WINDOW_DESTROYED (owner))
return;
hwnd = GDK_WINDOW_HWND (owner);
}
if (!API_CALL (OpenClipboard, (hwnd))) -- line 1068
return;
So it seems that the error message is produced upon execution of the
API_CALL (OpenClipboard, (hwnd))
call, as if the hwnd handle returned by GDK_WINDOW_HWND (owner) were
invalid.
Does anybody encounter this problem ? How could I fix it ?
Thank you for your ideas,
Cheers,
Filippo
--
Please, deactivate the HTML mail feature: use simple text mail for me.
Filippo Rusconi, PhD - CNRS researcher - key C78F687C @ pgp.mit.edu
Author of ``GNU polyxmass'' at http://www.polyxmass.org
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: float params of a gobject
But default value 0.0 is equal G_MINFLOAT and lesser than G_MAXFLOAT, isn't it? Read. http://developer.gnome.org/doc/API/2.0/glib/glib-Limits-of-Basic-Types.html#G-MINFLOAT:CAPS »Smallest positive value«, which means it is something like 0.1. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk installation help needed!!
My redhat enterprise 4 had gtk installed, works fine for me. However, I have a Fedora new machine now, which does not have gtk for developer installed. I downloaded gtk+-2.9.4.tar.gz and also gtk+-2.8.19.tar.gz I tried ./configure and it works fine. However, I could not do a make It conplains No targets specified and no makefile found... I checked the directory, there are Makefile.am Makefile.in, but, there is no Makefile nor makefile in 2.9.4 nor 2.8.19 I must missed something real simple or obvious. Please help!!! There must be a simple way to install... Thanks in advance ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why button is hidden behind drawing area(win32)
On Sun, Jul 09, 2006 at 01:10:26AM -0400, Freddie Unpenstein wrote: [...] What I don't understand, is why the widgets aren't just placed in the order they were created. Well, if it's not part of the documented interface, the implementors will do whatever seems convenient at the moment. In this case, I could well imagine adding new child widgets at the front of a linked list (which is simpler) and then rendering the list front-to-back. This would render the widgets newest-to-oldest, thus letting the older ones overpaint the newer. But the point is: you can't rely on anything if it's not in the official interface -- the implementors are free to (and will!) change those things. Regards -- tomás ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: float params of a gobject
Am Montag, den 10.07.2006, 12:45 -0300 schrieb Daniel Alonso: Hi, I'm trying to define a gobject class with a floating number property. In the init class procedure I define the property the following way: param_spec = g_param_spec_float (width /* name */, _(Icon Width) /* nick */, _(The width of the svg icon) /* blurb */, G_MINFLOAT /* minimum */, G_MAXFLOAT /* maximum */, 0.0 /* default_value */, (GParamFlags)(G_PARAM_READABLE | G_PARAM_WRITABLE)); g_object_class_install_property (g_object_class, PROP_WIDTH, param_spec); This compiles fine, but when running the test program it raises a glib exception: (test:5073): GLib-GObject-CRITICAL **: g_param_spec_float: assertion `default_value = minimum default_value = maximum' failed (test:5073): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed But default value 0.0 is equal G_MINFLOAT and lesser than G_MAXFLOAT, isn't it? From the API docs [1]: The minimum positive value which can be held in a gfloat. If you are interested in the smallest value which can be held in a gfloat, use -G_MAX_FLOAT. 0.0 is not considered positive in this case, I think it works like: G_MINFLOAT is the smalles floating number f that satisfies f 0. Since icons may only have a positive width, 1.0 might be a good default value. [1] http://developer.gnome.org/doc/API/2.0/glib/glib-Limits-of-Basic-Types.html#G-MINFLOAT:CAPS; -- Christian Neumair [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.13.3 released [unstable]
Pango-1.13.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 9441c965bbf50d637a3e8016c628ee7e pango-1.13.3.tar.bz2 6f968aa797c1770e86c6641a2baccfc5 pango-1.13.3.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12 * Bugs should be reported to http://bugzilla.gnome.org. About Pango === Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.1 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.2 and 1.13.3 == * Improved build system. Using gnome-autogen.sh now. (gnome-common needed for bootstrapping) * Improved documentation. Docs now include list of new API for each stable version of Pango. * New public API: - pango_glyph_string_get_width * Little performance improvement. * Misc fixes. * Bugs fixed in this release: Bug 330603 – pango_scan_int invokes undefined behaviour Bug 315599 – PangoAttribute remains in wrong context. Bug 163677 – pango_attr_list_splice: inconsistent docs Patch from Morten Welinder Bug 345070 – [ml_IN] not render for combination with ZWJ Patch from LingNing Zhang Bug 345274 – list of new symbols for each version is missing in docs Patch from Priit Laes Bug 346297 – autogen doesn't work with automake-1.6 Patch from Priit Laes Bug 135683 – Cache glyphstring extents Bug 344766 – Memory leak in get_ruleset() in modules/basic/basic-fc.c Bug 345600 – cvs build error in pango/opentype/Makefile Bug 345511 – -no-undefined problem with new libtool Behdad Esfahbod 10 July 2006 -- behdad http://behdad.org/ ___ 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.10 released
On Sun, 9 Jul 2006, Guillaume Cottenceau wrote: On 7/3/06, Matthias Clasen [EMAIL PROTECTED] wrote: GTK+ 2.10.0 is now available for download at: Notice: http://gtk.org/download/ still says The current stable version of GTK+ is 2.8. That's probably reasonable, since GTK+ 2.10 has a dependency on unstable pango. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Performance change from X in Fedora Core 4 to Fedora Core 5
[ Switching Cc: from gtk-list to gtk-devel-list ] On Mon, 2006-07-10 at 16:27 +0200, Clemens Eisserer wrote: Hi Owen, It's very likely that the speedup here is simply due to variations as to what gets put into video memory and what into system memory. I talked to nvidia driver developers about this issue and they told me that this is the case (I also saw a lot of time spent in malloc routines). This initially brought me to work in this a bit. They said that they'll include an option to disable pixmap-punting, however then a lot fo time will be spent inside the driver and the GPU for allocating the pixmap in VRAM. Its quite common that such surface-puntnig optimizations are in the drivers - I would not wonder if ATI would do the same in their propietary drivers. Thats why I would be really interrested about results on ATI chips (open and proprietary drivers) as well as onboard gpus. I think you misunderstood me; I'm not saying that time spent allocating pixmaps to video ram is a problem, I'm saying that the performance of Cairo will be very different to video ram as compared to system ram, and allocating many megabytes of persistent double-buffers, can easily change what gets in system ram and what in video ram. Now, maybe the nVidia drivers/hardware have problems with allocating pixmaps; my expectation and experience is that allocating a pixmap is much less expensive than the rest of an expose operation; but if the nvidia drivers do something heavyweight like flushing the GPU pipeline, who knows. (As a general philosophy: it's hard to optimize GTK+ for a black box like the proprietary nVidia drivers; I think GTK+ should do things that work well with the open source drivers, and let nVidia optimize for GTK+ if their drivers have problems with that.) But when keeping in mind that sexpose should happen in not more than 50-75ms I still think allocating and deallocating 12mb of pimaps (gftp) for a single expose is simply too expensive. I very much doubt that time for allocating pixmaps is proportional to the number of pixmaps in them. Also, many double-buffered toolkits do it the same way - Java Swing does not even release the pixmaps if windows are minimize. Not a convincing argument as to why GTK+ should do something. You have to keep in mind that many systems still don't have a lot of video memory, so if all windows in the system start keeping large back buffers, the effect may well be exhaustion of all available video memory. I would like to see a design which maybe would allow different approaches (maybe based on user descisions), so everybody would have the choice. While it's cool you are trying out different ways to do things, I think putting any code in GTK+ in advance of more careful performance investigation would be a mistake. Try some micro benchmarks: how long does allocating pixmaps take? Does that depend on size? Try your gtk-bench tests with no other windows open, then try them again after allocating 100MB of 100x100 pixmaps to run yourself out of video memory, etc. (Make sure to shut your browser before doing tests like this, Firefox is not shy about consuming video memory) Owen P.S. - using a single pixmap to do exposes for an entire set of subwindows of a toplevel window does have some advantages, like better redisplay, so it could be interesting to investigate, even if keeping persistent double buffers around is a bad idea. - in the composited architecture, there already *are* persistent double buffers for all toplevel windows, so investigating using those in some way could be interesting. What you have to avoid is the compositing manager doing tons of extra work in this case. signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Double-Buffering] Problems with spinner widget...
Hi there, Some days ago I wrote about problems with the spinner widget in my optimized build (still no answers :-/ ), and mentioned that FireFox's checkboxes seem to have the same problem. I now found out that the problem with firefox and checkboxes also persists with an unmodified gtk-2.6 + default theme. So basically only the spinner widget broke, and I don't have any clue why :-/ What does the spinner do magically when painting its text-field? lg Clemens ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: composite or render support in gtk
On Wed, 05 Jul 2006 17:13:20 -0300, Carlos Eduardo Rodrigues Diógenes wrote: There is any plan about wrapping composite or render in gtk? The X Render library provides a very low-level way of drawing things in X. A higher-level library that builds on Render, (or other systems), and actually designed to be used by application authors to draw things is the cairo graphics library. As of GTK+ 2.8, GTK+ provides easy access to draw with cairo via functions such as gdk_cairo_create. If there's something that Render allows that you're not able to do with cairo, then I would be interested in hearing about that. As for Composite, I'm not sure what kind of wrapping you are imagining would be appropriate for GTK+. -Carl pgpc4aWY6mZJM.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango-1.13.3 released [unstable]
Pango-1.13.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.11/ or http://download.gnome.org/sources/pango/1.13/ 9441c965bbf50d637a3e8016c628ee7e pango-1.13.3.tar.bz2 6f968aa797c1770e86c6641a2baccfc5 pango-1.13.3.tar.gz This is a development release leading up to Pango-1.14.0, which will be released just in time for GNOME-2.16. Notes: * This is unstable development release. While it has had fairly extensive testing, there are likely bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of Pango-1.12. If you have problems, you'll need to reinstall Pango-1.12 * Bugs should be reported to http://bugzilla.gnome.org. About Pango === Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most of the work on Pango so far has been done in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+-2.x. Pango is designed to be modular; the core Pango layout engine can be used with different font backends. There are three basic backends, with multiple options for rendering with each. - Client side fonts using the FreeType and fontconfig libraries. Rendering can be with with Cairo or Xft libraries, or directly to an in-memory buffer with no additional libraries. - Native fonts on Microsoft Windows. (Optionally using Uniscribe for complex-text handling). Rendering can be done via Cairo or directly using the native Win32 API. - Native fonts on MacOS X, rendering via Cairo. The integration of Pango with Cairo (http://cairographics.org) provides a complete solution with high quality text handling and graphics rendering. Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango 1.13.1 depends on version 2.10.0 or newer of the GLib library and version 1.1.2 or newer of the cairo library (if the cairo backend is desired); more information about GLib and cairo can be found at http://www.gtk.org/ and http://cairographics.org/ respectively. Overview of changes between 1.13.2 and 1.13.3 == * Improved build system. Using gnome-autogen.sh now. (gnome-common needed for bootstrapping) * Improved documentation. Docs now include list of new API for each stable version of Pango. * New public API: - pango_glyph_string_get_width * Little performance improvement. * Misc fixes. * Bugs fixed in this release: Bug 330603 – pango_scan_int invokes undefined behaviour Bug 315599 – PangoAttribute remains in wrong context. Bug 163677 – pango_attr_list_splice: inconsistent docs Patch from Morten Welinder Bug 345070 – [ml_IN] not render for combination with ZWJ Patch from LingNing Zhang Bug 345274 – list of new symbols for each version is missing in docs Patch from Priit Laes Bug 346297 – autogen doesn't work with automake-1.6 Patch from Priit Laes Bug 135683 – Cache glyphstring extents Bug 344766 – Memory leak in get_ruleset() in modules/basic/basic-fc.c Bug 345600 – cvs build error in pango/opentype/Makefile Bug 345511 – -no-undefined problem with new libtool Behdad Esfahbod 10 July 2006 -- behdad http://behdad.org/ signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
