Re: g_malloc overhead
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: > Colin Walters escribió: > > On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod wrote: > > > >> Lets just say that > >> UTF-16 is at best implementation details of Firefox. > >> > > > > Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET > > (i.e. all the most important platforms) are all UTF-16 it's likely to > > be with us for quite a while, so it's important to understand. > > > Yes i only wanted say that. For example i work in c# and i would like > create glib libraries and use it in .net, but the "char" in mono/.NET is > utf16 and therefore i have there the same overhead. > > The solution are 2: > > 1.- conversion using glib (): > http://library.gnome.org/devel/glib/2.19/glib-Unicode-Manipulation.html#gunichar2 > .-2. automatic NET conversion in the p/invoke side. > > The 2 solutions have the same overhead. > > > But yeah, there's no way POSIX/GNOME etc. could switch even if it made > > sense to do so (which it clearly doesn't). > > > Yes, i only talked about the overhead with utf8 outside of glib, only that. > Perhaps the only solution is add more suport to utf16 in glib with more > methods. > There's zero point in talking about a "solution" until you have profile data indicating that there is a problem. - Owen ___ 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.7 released
[ Removing gnome-announce-list and gnome-hackers from the Cc ] On Sat, 2007-01-06 at 04:44 -0800, Sergei Steshenko wrote: > My memory, of course, is not getting better as years go by, but it still > remembers some peculiar things. > > OK, on the official gtk site one can read: > > http://www.gtk.org/faq/#AEN703 : > > " > 5.28. Why does GTK+/GLib leak memory? > > It doesn't. > ... > ". The FAQ answer could be a little more expansive, but I think the sense is pretty obvious. People *Frequently* (F) mail gtk-app-devel-list and Ask the Question (AQ): "I wrote this program that creates a window then destroys it and the program's memory size doesn't go back to its original value" And the answer to that is: "GTK+ isn't leaking memory, you are seeing GLib or the C library caching allocated memory" It's a not a statement "there has never been and never will be any bugs in GTK+ that can cause a memory leak". Use common sense! > I read this in the times of, I think, gtk+-2.8.18, and it is still there. > > So are there or there are no memory leaks in gtk+-2.8.20 ? > > Did gtk+2.10.* introduce more or less memory leaks ? There may still be memory leaks (bugs) we haven't discovered in GTK+-2.8 and GTK+-2.10, so it's pretty hard to say. But for your purposes: GTK+-2.8 doesn't leak significant amounts of memory GTK+-2.10 doesn't leak significant amounts of memory Really. > If one reads on http://www.gtk.org about absence of memory leaks, should > he/she consider this to be cheap propaganda at best ? > > Or the above claim should be reformulated as: > > * for gtk+2.8.20 there are no known to developers occurences of memory leaks; GTK+-2.8 is no longer maintained, so many memory leaks that have been fixed in the GTK+-2.10 series will be present in GTK+-2.8.20. > * gtk+2.10.* is effectively a developmnet release, so expect memory leaks and > stay > away from it for production code. GTK+-2.10 is not a development release. > I am asking these particular questions because of the > > 387170 Fairly large leak in gtk+ > 360350 leak in gtk_radio_button_focus > 362439 gtkicontheme::pixbuf_supports_svg leaks GList > 364514 gtk leaks GDI objects on the win32 classic look and feel > 364868 GDI resource leak in GtkStatusIcon on win32 > 370395 leak in gtk_rc_parse_icon_source > 382314 gtkpagesetup leaks when setting new paper size > 389194 mem leaks in gtkpagesetupunixdialog > 348108 Refleaks in gtk-demo If you are interested, you can read all of these bug reports, you can look at the CVS history and you can determine if they were present in GTK+-2.8 or not. You can also determine the amount of memory that would be leaked in a typical program. But I don't understand the logic that takes you from "Some memory leaks were fixed between GTK+-2.10.6 and GTK+-2.10.7" to "GTK+-2.10.7 is likely to be very leaky and I should avoid it" > bugs mentioned in the original announcement of gtk+2.10.7. > > FWIW, 'konqueror' WEB browser doesn't appear to leak, while gtk+-based > Mozilla, Firfox, Seamonkey leak a lot, and I'm not sure whether it's > 'Gecko' or gtk+ issue. The memory usage of Gecko, whether leaks or just using lots of memory, has basically zero to do with GTK+. - Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why is pango_font_description_set_* functions leaking
On Tue, 2006-05-02 at 06:03 -0700, nerdy wrote: > Hello all, > > I found that the functions pango_font_description_set_family and > pango_font_description_set_size are leaking memory. I am using pango > version 1.4.0. > > fontdesc = pango_font_description_new(); > pango_font_description_set_family(fontdesc,"courier"); > pango_font_description_set_size(fontdesc,size*PANGO_SCALE); > pango_font_description_free (fontdesc); > > When i ran the program (pasted below) and saw the memory usage profile > from top command, i see that a the program allocates a lot of memory > continuously. When i commented out the statements that i suspect are > leaky, i dont see any contiuous memory allocation. Is this behaviour > typical of pango or am i missing something. Please clarify my doubt. You are continually drawing at bigger and Bigger and BIGGER font sizes... don't you expect this to allocate more and More and MORE memory? Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem displaying Japanese Text in GtkEntry/GtkTextView
On Mon, 2006-04-24 at 16:47 +0530, Gaurav Jain wrote: > Hello, > > I have written a small GTK program (attached below), which is supposed > to display some japanese text in a GtkEntry and GtkTextView. The text > is UTF8, and I have extracted the UTF8 values from an application that > contained some valid UTF8 japanese text. > > The problem is that when I run this program on Solaris or AIX (with > GTK 2.0.9) the japanese text is not shown correctly (it either shows > blank spaces or boxes). On Linux (with GTK 2.4) it shows the japanese > text correctly. > > Is there a way to get this working on Solaris or AIX too? Do I need > to install some fonts or set some environment variables? Is the > environment variable such as GTK_RC_FILES or GTK2_RC_FILES required to > be set here? Nobody is likely to be able to help you with GTK+-2.0.9 except your operating system vendor. It was released quite a long time ago, and probably was configured on those operating systems to use core X fonts, rather than the more modern font fonts that are supported with current versions of GTK+. The configuration of core X fonts was done with the config file: /etc/pango/pangox.aliases (may be some place else on your system, perhaps under /opt/gnome or something like that.) You need to make sure that the fonts referenced in that file are present on your system. Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.10.1 released
Pango-1.10.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ pango-1.10.1.tar.bz2 md5sum: 1ff4c96982f61ea6f390d09a4febdf18 pango-1.10.1.tar.gzmd5sum: 6b3b06b3263845706a2bfc769b83f7fc This is a stable release and is source and binary compatible with 1.10.1. Notable changes include significant performance improvements for the Cairo backend on Windows and a couple of important bug fixes. 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 two 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. 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-1.10 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 depends on version 2.6.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.10.0 and 1.10.1 = - Add various forms of caching to the Win32 backend, greatly improving performance [Tor Lillqvist] - Fix problem with colors leaking from a Pango item to subsequently drawn strings. [Choe Hwanjin] - Fix bug where error underlines would be drawn 1024 times too big in the Cairo backend. [Luis Villa] - Misc bug and build fixes [Jean Brefort, Matthias Clasen, Behdad Esfahbod, Kazuki Iwamoto] Owen Taylor 3 October 2005 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTKImage displays after long latency
On Wed, 2005-08-31 at 11:37 -0700, Barry Demchak wrote: > Hi, Owen -- > > No luck ... the thing reports 400x400 (pixels) ... > > ... and when I render it in Internet Explorer, the rendering is instant. > > Any other ideas?? Well, if something is really slow, running it under a debugger interrupting execution and seeing where you are can often provide insight. Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTKImage displays after long latency
On Tue, 2005-08-30 at 14:41 -0700, Barry Demchak wrote:
> Hi --
>
> This is my first GTK application, and I'm "simply" trying to display an SVG
> rendering in a window. I can do this OK, but it appears that there is a
> latency of ~2000ms between assigning the pixbuf into the GTKImage widget
> and actually seeing the result on the screen.
>
> FYI, the scribble example works fine on my system ... so I don't think
> there's something wrong with the system ... more likely a gap in my GTK
> knowledge.
>
> Here's what I'm doing:
>
>GdkPixbuf *pb = rsvg_pixbuf_from_file_at_size("circle.svg",-1,-1,NULL);
>gtk_image_set_from_pixbuf((GtkImage*) mapimage, pb);
>
> And before that, this is what I did:
>
>GtkWidget *mapimage = NULL;
>GdkPixbuf *pb = rsvg_pixbuf_from_file_at_size("circle.svg",-1,-1,NULL);
>mapimage = gtk_image_new_from_pixbuf(pb);
>
> I can see that scribble does things quite differently ...
>
> ... should I be trying to get librsvg to render into something besides a
> new pixbuf??
>
> (I'm quite sure that the librsvg call is finished, and the
> gtk_image_new_from_pixbuf has finished ... and *then* it takes 2 seconds to
> show up on the screen.)
Could librsvg be rendering your image at an enormous size?
You might want to gdk_pixbuf_get_width(), gdk_pixbuf_get_height()
Regards,
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_idle_add_full and main loop
On Wed, 2005-08-31 at 12:53 +0200, Paweł Różański wrote:
> Hi,
>
> I'm digging for an answer and I can't find it.
>
> I Have two threads, but they are native Windows threads (I use 2.6.8
> on winXP). One of them is standard GTK main loop, the other one is a
> callback from external library. So i made it like
>
>
> int func(data)
> {
> gtk_label_set_text(GTK_LABEL(lab), "something");
> gdk_window_process_all_updates();
> return false;
> }
>
> callback()
> {
> ..
> g_idle_add_full(G_PRIORITY_HIGH_IDLE, &func, NULL,NULL);
> ..
> }
>
>
> And It works... well sort off. func get called right away only if i
> constantly move mouse pointer over my gtk application (i suspect this
> triggers pending events). I want to have fired that func right away,
> since it's a "progress" (its called about once for second).
>
> Sorry if it's on mailing list but seraching "threads GUI" didn't bring
> me detailed answer. In faq there is a "g_idle_add_full" trick like
> this one but there is nothing about my problem with lazyness of that
> approach.
>
> I'm thinking of g_signal to main loop or something but well
> maybe there is an elegant solution.
Sounds like potentially a bug in the Win32 main loop code in GLib.
Adding an idle source should wake up the the thread that is waiting
for incoming events; there is a semaphore for this function.
Can you create a small standalone test case? (and preferably put
it in bugzilla)
Thanks,
Owen
P.S. - guess one question is - did you call g_thread_init()?
That is needed for correct operation of GLib from a threaded
program.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.10.0 released
Pango-1.10.0 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.8/ pango-1.10.0.tar.bz2 md5sum: c75489ec7f5fe77e31e4cbde71ad0c16 pango-1.10.0.tar.gzmd5sum: a44ab8dd4edc7346ac9433ee8599cc54 This is a stable release providing new functionality as compared to Pango-1.8, while maintaining source and binary compatibility. Notable improvements in Pango since version 1.8 include: * Integration with the cairo vector graphics library * Addition of a Khmer shaper (this also appeared in 1.8.2) * Update of data tables to Unicode 4.1 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 two 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. 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-1.10 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 depends on version 2.6.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Special thanks to: Amit Aronovitch [PangoLayoutIter fixes] Behdad Esfahbod [General assistance] Jens Herden, Javier Sola [Khmer] Harshula Jayasuriya [Sinhala] Tor Lillqvist [Win32 backend] Sukhjinder Sidhu [Gurumukhi] Manish Singh [Keeping stuff building] David Turner [FreeType compatibility] Thanks to all Pango-1.10 contributors, including: Sebastien Bacher, Brandon Bergren, Billy Biggs, Chris Blizzard, Paolo Borelli, Hans Breuer, Ross Burton, Damien Carbery, Gustavo J. A. M. Carneiro, Damon Chaplin, Matthias Clasen, Kees Cook, Behnam Esfahbod, Thomas Fitzsimmons, Kazuki IWAMOTO, Tim Janik, Alex Jones, Aivars Kalvans, Theppitak Karoonboonyanan, Stepan Kasal, Tommi Komulainen, Karel Kulhavy, Tor Lillqvist, Mikael Magnusson, Ben Maurer, Gora Mohanty, Vincent Noel, Keith Packard, Vittorio Palmisano, Roozbeh Pournader, William N. Ray, Changwoo Ryu, Adam Sampson, Gautam Sengupta, Manish Singh, Emil Soleyman-Zomalan, Morten Welinder Owen Taylor 15 August 2005 ___ 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.8.0 released
On Mon, 2005-08-15 at 20:59 +0100, Chris Vine wrote: > On Monday 15 August 2005 13:52, Owen Taylor wrote: > > On Sun, 2005-08-14 at 19:50 -0400, Allin Cottrell wrote: > > > > One further compatibility issue: the app that I have built and run > > > OK (without warnings) using gtk 2.6, now shouts repeatedly, when > > > built against 2.8: > > > > > > Gdk-CRITICAL **: gdk_drawable_get_colormap: assertion > > > `GDK_IS_DRAWABLE (drawable)' failed > > > > > > Gdk-WARNING **: gdk_window_set_back_pixmap(): pixmap must have a > > > colormap > > > > > > Any suggestions what's going on here? > > > > Uck. That will teach me to make last minute changes. > > > > Fixed in CVS with the following change. > > > > Thanks for pointing it out, > > Good to know this has been fixed, but I also notice that I get odd effects if > I try to use it with GNOME-2.10.2 (the gnome panel displays curious "black" > areas which are not correctly filled with the background colour). > > Will a recompile of GNOME deal with this or is it best to stick with GTK+-2.6 > and/or use GNOME-2.11 for the moment? Hard to say ... might actually be the exact same problem as the above. Nobody else has reported such issues, so that would be further evidence supporting the theory that it was the above problem. Regards, Owen ___ 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.8.0 released
On Sun, 2005-08-14 at 19:50 -0400, Allin Cottrell wrote:
> On Sat, 13 Aug 2005, Matthias Clasen wrote:
>
> > Release notes are available at:
> >
> > http://www.gtk.org/gtk-2.8.0-notes.html
>
> These notes speak of a "Pango 1.10". Has this been released
> anywhere?
No. Hopefully later today.
> It would be nice to have the new cairo/pixman dependency properly
> registered via pkgconfig. The Gtk dependencies directory contains
> cairo but not libpixman. Cairo builds and installs OK without
> pixman, but then the pango (1.9.1) build fails for lack of pixman
> (though this is not flagged by configure).
It's just an example, so you can 'make -k', 'make -k install'. There's
a fix in Pango CVS for the issue.
> One further compatibility issue: the app that I have built and run
> OK (without warnings) using gtk 2.6, now shouts repeatedly, when
> built against 2.8:
>
> Gdk-CRITICAL **: gdk_drawable_get_colormap: assertion
> `GDK_IS_DRAWABLE (drawable)' failed
>
> Gdk-WARNING **: gdk_window_set_back_pixmap(): pixmap must have a
> colormap
>
> Any suggestions what's going on here?
Uck. That will teach me to make last minute changes.
Fixed in CVS with the following change.
Thanks for pointing it out,
Owen
2005-08-15 Owen Taylor <[EMAIL PROTECTED]>
* gdk/linux-fb/gdkwindow-fb.c (gdk_window_set_back_pixmap):
* gdk/win32/gdkwindow-win32.c (gdk_window_set_back_pixmap):
* gdk/x11/gdkwindow-x11.c (gdk_window_set_back_pixmap):
Handle pixmap == NULL when checking for a colormap.
(Allin Cottrell).
--- gdk/x11/gdkwindow-x11.c 12 Aug 2005 13:13:54 - 1.247
+++ gdk/x11/gdkwindow-x11.c 15 Aug 2005 12:34:49 -
@@ -2913,7 +2913,7 @@ gdk_window_set_back_pixmap (GdkWindow *w
g_return_if_fail (pixmap == NULL || !parent_relative);
g_return_if_fail (pixmap == NULL || gdk_drawable_get_depth (window) ==
gdk_drawable_get_depth (pixmap));
- if (!gdk_drawable_get_colormap (pixmap))
+ if (pixmap && !gdk_drawable_get_colormap (pixmap))
{
g_warning ("gdk_window_set_back_pixmap(): pixmap must have a colormap");
return;
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Providing gtk_main() with asynchronous data
On Tue, 2005-08-02 at 06:36 -0600, Pat Mahoney wrote: > On Tue, Aug 02, 2005 at 07:47:32AM -0400, Owen Taylor wrote: > > On Sun, 2005-07-31 at 15:44 -0600, Pat Mahoney wrote: > > > (not subscribed; please CC replies) > > > > > > I'm trying to find a way to provide my mainloop with asynchronous data > > > from a thread. I have read this: > > > > > > http://mail.gnome.org/archives/gtk-app-devel-list/2004-July/msg00181.html > > > > > > which describes how to use a GAsyncQueue and GSource to watch the queue > > > for available data (and to have the thread wake up the mainloop when data > > > is available). A callback is run in the context of gtk_main when > > > data is available. It works perfectly except for one show-stopper > > > problem: > > > > Note that using a custom GSource here is perhaps overcomplicated. The > > simplest method is: > > > > g_idle_add (function_to_call_in_main_thread, data_to_pass_to_function); > > > > (Or use g_idle_add_full() if you want to prioritize the callback higher > > than the default idle priority.) > > Yes, that is simplest. In my case, the CPU usage jumps to 100% (though > the app is still responsive). My particular app is reading frames from > one or more webcams (select() doesn't work with video4linux devices, so > this must be done in a seperate thread or process). The camera_thread > is triggered by the mainloop to snap a picture which it pushes onto a > GAsyncQueue. > > My callback on_camera_frame_available() checks the queue and returns > immediately if there is no data. Similarly, the GSourceFuncs check the > queue. However, by using the GSource, the check is performed about 2-3 > times per frame (using printf() to watch that, so timing may be skewed), > while the g_idle_add() method runs my callback continually, and so the > GAsyncQueue is constantly being checked for data, sucking down the CPU. Your idle function presumably has the wrong return value. To quote: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-idle-add If the function returns FALSE it is automatically removed from the list of event sources and will not be called again. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Fonts
On Tue, 2005-08-02 at 00:16 +1000, Russell Shaw wrote: > Hi, > Does all text in gtk/pango get sent to the X server as ascii, or are bitmaps > sent too? If sent as ascii, is it 7-bit, 8-bit, or something longer? > Does gtk have any control over what renders the fonts at the X server? > Is XDrawString used? When rendering using Xft or (for in GTK+-2.7, Cairo), characters are rendered client side and sent to the server as images. Then a RenderCompositeGlyphs request is made to draw those images to the screen. It looks conceptually like: Using glyphset 1432413: draw glyph #3 at 40,10 draw glyph #4 at 50,10 [...] Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Providing gtk_main() with asynchronous data
On Sun, 2005-07-31 at 15:44 -0600, Pat Mahoney wrote: > (not subscribed; please CC replies) > > I'm trying to find a way to provide my mainloop with asynchronous data > from a thread. I have read this: > > http://mail.gnome.org/archives/gtk-app-devel-list/2004-July/msg00181.html > > which describes how to use a GAsyncQueue and GSource to watch the queue > for available data (and to have the thread wake up the mainloop when data > is available). A callback is run in the context of gtk_main when > data is available. It works perfectly except for one show-stopper > problem: Note that using a custom GSource here is perhaps overcomplicated. The simplest method is: g_idle_add (function_to_call_in_main_thread, data_to_pass_to_function); (Or use g_idle_add_full() if you want to prioritize the callback higher than the default idle priority.) Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkEntry widget in a MenuItem not getting button_press_event signals
On Fri, 2005-07-29 at 16:46 -0700, Wallace Owen wrote: > Am I doing something wrong? the online ref. man for GtkMenuItem says: > > "As it derives from GtkBin it can hold any valid child widget, altough > only a few are really useful." > > > .. so I put a GtkTable in it, then put a 2D array of GtkEntry widgets in > that, and then connected the GtkEventBoxes to the button_press_event. > > If I put the table into an hbox, the signal handler gets invoked and > all's hoopy. > > What might I be doing wrong? Am I abusing the MenuItem class somehow? Yes! You are trying to put an a table event boxes (or entries???) in a menu item? What would that mean? (Do you want a grid menu? That is supported in the GTK+-2.6 API) The note in the documentation is probably a bit confusing ... "not useful" here doesn't just mean "doesn't make sense" but also "won't fully work" ... interactive widgets in general won't work within a menu. Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.9.1 released [unstable]
Pango-1.9.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.7/ pango-1.9.1.tar.bz2 md5sum: 91f386893ff483e14dc4571e352150e4 pango-1.9.1.tar.gzmd5sum: f7750cb67b239ff6ef2144a94b4ea04e This is a development release leading up to Pango-1.10.0, which will be released together with GTK+-2.8. This release continues improving the support for cairo that was first introduced in 1.9.0; the Pango/cairo API is thought to be finalized at this point. Many bug fixes and improvements from the stable branch are also included. 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.8. If you have problems, you'll need to reinstall Pango-1.8.2 * 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 two 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. 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-1.9 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 depends on version 2.6.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.9.1 and 1.9.2 === * Support setting of font options and DPI on PangoContext for the Cairo backend. * Adapt to recent Cairo API changes * Win32 build improvements [Tor Lillqvist] * Misc bug fixes [Hans Breuer, Thomas Fitzsimmons, Kazuki IWAMOTO] Overview of stable-branch changes since 1.9.1 = * Add Khmer support [Jens Herden, Javier Sola] * Fix bugs and crashes in the operation of PangoLayoutIter [Amit Aronovitch] * Remove dependence of opentype code on FreeType internals [David Turner, Behdad Esfahbod] * Support for TrueType fonts on Win32 with characters outside the BMP [Tor] * Handle alpha in XftColors again. [Mikael Magnusson] * Fix Oriya character classification [Gora Mohanty, Gautam Sengupta] * PangoAttrIterator bug fixes [Morten Welinder] * Clean up copyright/licensing information [William N. Ray] * Misc bug and build fixes [Brandon Bergren, Chris Blizzard, Behdad, Harshula, Alex Jones, Karel Kulhavy, Ryan Lortie, Emil Soleyman-Zomalan, Morten] Owen Taylor 26 July 2005 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.8.2 released
Pango-1.8.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.6/ pango-1.8.2.tar.bz2 md5sum: f5b5da7a173f0566d8217ec112fde993 pango-1.8.2.tar.gzmd5sum: 90fe9836f0e00c4da5c7499d6e3b7fc8 This is a stable branch release; notable changes since 1.8.1 include support for Khmer and a fix for a crash with PangoLayoutIter that was affecting many GNOME users with right-to-left languages. 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 usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with three different font backends: - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.8.0 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, and a number of Indic and South-East Asian 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 depends on version 2.6.0 or better of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.8.1 and 1.8.2 === * Add Khmer support [Jens Herden, Javier Sola] * Fix bugs and crashes in the operation of PangoLayoutIter [Amit Aronovitch] * Increase sharing of data between different copies of Pango [Tommi Komulainen, Ross Burton] * Remove dependence of opentype code on FreeType internals [David Turner, Behdad Esfahbod] * Cache metrics for the Win32 backend [Tor Lillqvist] * Improve handling of RTL text when passing it to Uniscribe [Tor] * Support for TrueType fonts on Win32 with characters outside the BMP [Tor] * Handle alpha in XftColors again. [Mikael Magnusson] * Better handling of MacThai encoded fonts [Theppitak Karoonboonyanan] * Handle zero width chars properly in Hangul backend [Young-Ho Cha, Changwoo Ryu] * Fix Oriya character classification [Gora Mohanty, Gautam Sengupta] * PangoAttrIterator bug fixes [Morten Welinder] * Clean up copyright/licensing information [William N. Ray] * Misc bug and build fixes [Sebastien Bacher, Brandon Bergren, Chris Blizzard, Paolo Borelli, Behdad, Harshula, Alex Jones, Aivars Kalvans, Stepan Kasal, Karel Kulhavy, Ryan Lortie, Ben Maurer, Sukhjinder Sidhu, Manish Singh, Emil Soleyman-Zomalan, Morten] Owen Taylor 26 July 2005 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Window Visibility Signal
On Mon, 2005-07-25 at 14:45 -0600, Kevin DeKorte wrote: > On Monday 25 July 2005 02:11 pm, David Necas (Yeti) wrote: > > On Mon, Jul 25, 2005 at 01:57:02PM -0600, Kevin DeKorte wrote: > > > Nice tip, but unfortunately the expose event does not signal when the > > > object is covered up. Only when revealed. I even hooked "event" and > > > "event-after" and nothing was emitted when I covered up the window. Only > > > events were triggered when I moved the mouse into the window and out of > > > it and clicks. > > > > I'm not following this thread closely, so I'm sorry if > > I missed something, but have you tried "visibility-notify-event" > > signal? See attached example. > > > > Ah! sample code is good... had been trying the visibility-notify-event, but > it > didn't work then I saw the "add_events" call and I went ... "doh!" Added that > and it works almost how I want it, is there another event I should be looking > for as well? Switching desktops and minimizing does not seem to pop the > event, but this is pretty close. Covering up the window does work.. You probably need to catch ::unmap-event, ::map-event as well. (For toplevels, for subwindows it gets harder -- you'd need to track those events on the toplevel.) There are some other quirks of ::visibility-notify-event you have to be aware of - most importantly, you aren't guaranteed to get an expose when you become visible again, so if you suppress drawing when you aren't visible, you have to redraw everything when you become visible. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: strangeness of g_signal_connect
On Mon, 2005-07-25 at 12:50 +0530, Annamalai Gurusami wrote: > Colossus <[EMAIL PROTECTED]> writes: > > > In my app I have the following: > > > > g_signal_connect ((gpointer) AddFile_button, "clicked", > > G_CALLBACK (on_add_files_activate), > > "dummy"); > > I normally write the above call like this: > > g_signal_connect( G_OBJECT(AddFile_button), "clicked", > G_CALLBACK(on_add_files_activate), "dummy"); > > Are both correct? Which is the preferred way to do it? Unless you are programming in C++, either will work, since there is an automatic cast from any type to a void *, which is what the first argument of g_signal_connect() takes. In C++, you need the first. My preference is simply: g_signal_connect (AddFile_button, "clicked", G_CALLBACK (on_add_files_activate), "dummy"); The reason that g_signal_connect() takes a void * rather than a GObject * for the first parameter is that you could, in theory, have libgobject types not deriving from GObject that supports signals. In practice, I don't know of any uses of that. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: width of string rendered by pango font?
On Wed, 2005-07-13 at 00:40 -0400, Allin Cottrell wrote:
> On Mon, 11 Jul 2005, David Morse wrote:
>
> > How does one figure out the width of a certain string in a certain
> > pango font? (Other than abandoning pango fonts and reverting to
> > gdkfonts, of course. ; )
>
> It's a bit of a contortion.
>
> gint get_string_width (const gchar *str)
> {
> gint width;
> GtkWidget *w;
> PangoLayout *pl;
> PangoContext *pc;
>
> w = gtk_label_new(NULL);
> pc = gtk_widget_get_pango_context(w);
>
> pl = pango_layout_new(pc);
> pango_layout_set_text(pl, str, -1);
> pango_layout_get_pixel_size(pl, &width, NULL);
>
> gtk_widget_destroy(w);
> g_object_unref(G_OBJECT(pl));
>
> return width;
Well,
PangoLayout *gtk_widget_create_pango_layout (GtkWidget *widget,
const gchar *text);
Would simplify the above. And considering that asking about the
size of a string before you have a widget to draw it on is meaningless,
you wouldn't have the creation of the dummy label either.
(Finding the size of a string is documented in
http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html
BTW)
Regards,
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: whatever happened to the gtk_kennel?
On Mon, 2005-07-11 at 10:05 -0400, David Morse wrote: > Back in the day there were plans to incorporate "kennels" into gtk - > it was a method for sizing widgets without the contraints of the > widget heirarchy. I think they were first used in > "BEAST", but were planned for general consumption. I don't see them > in the docs now. GtkSizeGroup is basically the same thing, probably too normally named for you to find it ;-) Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [gdk;gdkpixbuf] Optimisation. Is it possible?
On Mon, 2005-07-11 at 09:58 +0200, [EMAIL PROTECTED] wrote:
> I'd like to create a lot of images from some values.
> Values is in some type of tree (background, what in right upper
> corner, what in ...).
> Is it possible to reuse GdkGC for enother GdkDrawable then in
> constructor?
>
> Something like:
>
> G_INLINE GdkGC *return_gc_background1(GdkDrawable *gd) {
> static GdkGC *gc = NULL;
> static GdkColor color;
> if(G_UNLIKLY(!gc)) { //It's used many times but once init.
> gc = gdk_gc_new(gd);
> gdk_color_parse("ff", &color); //1
> gdk_gc_set_foreground(gc, &color);
> }
> return gc; //What will be happend if enother GdkDrawable
> }
A GdkGC can be used with any drawable with the same depth and
GdkScreen as the one for which is was created.
However, drawing onto a drawable that interprets colors differently
is likely not useful, so you really need the two drawables to have
the same GdkColormap.
Regards,
Owen
P.S.:
G_INLINE isn't used like that.
There is no significant value to G_UNLIKELY in this type of code;
it reduces the readability of your code for a very tiny
performance improvement.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.9.0 released [unstable]
Pango-1.9.0 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.7/ pango-1.9.0.tar.bz2 md5sum: d4948020be961217f2c3b0c0470762d1 pango-1.9.0.tar.gzmd5sum: acd786b4995ab233e3f4345db787e6f1 This is a development release leading up to Pango-1.10.0, which will be released together with GTK+-2.8. The major change in this release is support for Cairo. 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.8. If you have problems, you'll need to reinstall Pango-1.8.1 * 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 two 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. 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-1.9 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 depends on version 2.6.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.8.x and 1.9.x === * Add Cairo support; PangoCairoFontmap is an interface with implementations for Fontconfig fonts and Win32 fonts * Extend PangoFcFontmap to allow more customization by subclasses * Handle NULL language better for pango_context_get_metrics() * misc optimization [Paolo Borelli, Behdad Esfahbod] * Misc bug and build fixes [Hans Breuer, Damien Carbery, Keith Packard, Manish Singh] * Doc fixes [Tim Janik] Overview of stable-branch changes since 1.8.1 = * Increase sharing of data between different copies of Pango [Tommi Komulainen, Ross Burton] * Cache metrics for the Win32 backend [Tor Lillqvist] * Improve handling of RTL text when passing it to Uniscribe [Tor] * Better handling of MacThai encoded fonts [Theppitak Karoonboonyanan] * Support for TrueType fonts with characters outside the BMP [Tor] * Handle zero width chars properly in Hangul backend [Young-Ho Cha, Changwoo Ryu] * Misc bug and build fixes [Sebastien Bacher, Paolo Borelli, Aivars Kalvans, Stepan Kasal, Ben Maurer, Sukhjinder Sidhu, Manish Singh, Morten Welinder] Owen Taylor 20 June 2005 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkListStore and Threads problems
On Fri, 2005-06-17 at 11:56 -0300, Lorena Salinas wrote:
> gdk_threads_leave(); /* release GTK thread lock */
> pthread_mutex_unlock(&mutex);
>
>
> while (valid) {
>
> gtk_tree_model_get (GTK_TREE_MODEL (model), &iter,
> TEST_COL_5,&status,
And it surprises you that this doesn't work?
All GDK and GTK+ calls must be made within the GDK lock.
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkListStore and Threads problems
On Tue, 2005-06-14 at 15:20 -0300, Lorena Salinas wrote: > Hi, > > This is what I do inside the worker_thread function > (create_and_start_worker_thread ()) every time I want to update the > model: > > > gdk_threads_enter(); /* get GTK thread lock */ > > gtk_list_store_set (GTK_LIST_STORE (host_model), &iter, > MYMODEL_COL_STATUS, STATUS_NORMAL, > -1); > > gdk_threads_leave(); /* release GTK thread lock */ > > I don't know if the problem is because the model is sorted by that > column. I set this using : gtk_tree_view_column_set_sort_column_id Which is fine. Presumably the problem is in the main thread. You are forgetting to get the lock in a timeout or something like that. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkListStore and Threads problems
On Tue, 2005-06-14 at 14:40 -0300, Lorena Salinas wrote:
> Hi,
>
> This is my app's main function:
>
> int main (int argc, char **argv)
>
> {
>
> /* init threads */
> g_thread_init(NULL);
>
> gdk_threads_init();
>
> /* init gtk */
> gtk_init (&argc, &argv);
>
> /* create the model and fill with data */
> create_and_fill_model();
>
> /* create the window with a tree_view and an icon_view */
> create_window_and_views_for_model();
>
> /* start the worker thread */
> create_and_start_worker_thread ();
>
> /* enter the GTK main loop */
> gdk_threads_enter();
>
> gtk_main();
>
> gdk_threads_leave();
>
> return 0;
>
> }
>
> I don't surround function calls in the main loop (eg: callbacks like row
> changed)
> because this will actually block the main thread.
I'd suggest reviewing
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
in detail. Somewhere, you modifying the tree view without the GTK+/GDK
lock.
Regards,
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkListStore and Threads problems
On Tue, 2005-06-14 at 09:59 -0300, Lorena Salinas wrote: > Hello, > > I'm having problems with threads and a gtkliststore model. > > My working thread updates a column value of a gtkliststore model using > gtk_list_store_set() (every call surrounded by gdk_threads_enter() and > gdk_threads_leave ()). That seems to be working right. And you are also surrounding all calls to GTK+ in the main thread by these calls? And you've called gdk_threads_init()? Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_main_context_prepare(): main loop already active in another thread
On Tue, 2005-06-14 at 13:03 +0200, Colossus wrote:
> Hi,
>
> I red the gtk_threads html page. I put the pair gdk_threads_enter() /
> gdk_threads_leave() inside a function outside the gtk_main loop as
> showed below:
>
> void signalhandler (int signum)
> {
> int status;
> waitpid ( -1, &status, WNOHANG );
> gdk_threads_enter();
The *only* thing you are allowed to do in a signal handler is call a
very limited set of C library functions. You certainly can't make
GTK+ calls from a signal handler.
You might want to use the "child watch" functionality of GLib.
Regards,
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why my program quit when I use g_thread?
On Thu, 2005-05-19 at 18:00 +0200, Daniel Pekelharing wrote: > Um, I don't know much about g_thread, but you code is flawed: > > if (!g_thread_supported()) > g_thread_init(); > > In other words if g_thread is not supported then init g_thread... > I think you want: > > if (g_thread_supported()) > g_thread_init(); > > Unless I got something all wrong here... g_thread_supported() basically tells you whether g_thread_init() has already been called. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_window_set_default_icon_list()
On Tue, 2005-05-17 at 00:14 -0400, Freddie Unpenstein wrote: > I've gone looking through the API, and I'll be stuffed if I can figure > something out... > > As I understand it, you're supposed to load the icons into GdkPixbuf's, store > them in a GSList, and > then feed that list to the gtk_window_set_default_icon_list() function. But > what then? > > Does the function keep the list you gave it, or does it make a copy and > expect you to clean it up. > How about the images; does it take an extra reference, and expect you to > release yours? > What if you give it a new list; what happens to the old list and the old > images? > What if I modify the list after giving it to the function? > > Appart from affecting all new windows vs. a specific window, are there any > other > differences (especially in terms of memory management) between this function > and gtk_window_set_icon_list()? > > > Stay tuned, for someone who has a clue to give you this, and other exciting > answers... > Same GTK time, same GTK channel...! ;) When the docs are insufficient, you can always take a look at the source: http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkwindow.c?view=markup Take advantage of this whole "open source" thing :-) Quoting the relevant portion: g_list_foreach (list, (GFunc) g_object_ref, NULL); g_list_foreach (default_icon_list, (GFunc) g_object_unref, NULL); g_list_free (default_icon_list); default_icon_list = g_list_copy (list); So, it copies the list and references the pixbufs in it. Given enough experience with the way that GTK+ works, this isn't particularly surprising, but the docs could certainly be more explicit. I assume you are going to submit a bug in bugzilla with suggestions for improving the documentation? Thanks, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to use the mouse wheel?
On Tue, 2005-05-17 at 19:42 +0200, Daniel Pekelharing wrote: > Hi, > > I'm trying to use the mouse wheel, I already have a mouse callback, > I think I just need to know what the GDK_*_MASK definition is for the > wheel, I have my widget set up for button press/release: > > gtk_widget_add_events(widget, GDK_BUTTON_PRESS_MASK | > GDK_BUTTON_RELEASE_MASK); That will work ... you'll get a GDK_SCROLL event. Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to get GtkWindow associed with XID?
On Sun, 2005-05-15 at 15:56 +0200, jacktm wrote: > Owen Taylor wrote: > >If you need to embed a GTK+ widget into a non-GTK+ > >application you'll need to implement the embedder side of > >the XEMBED protocol. > > > > http://www.freedesktop.org/Standards/xembed-spec > > > >Regards, > > Owen > > > > > But gdk_window_foreign_new wraps XID by GdkWindow. > What I need to do next is to wrap GdkWindow by GtkWindow. > Isn't it possible? It should be the same situation as > I have GdkWindow and I want to create GtkWidget as > child of GdkWindow. It should be possible, but it doesn't work > for me... GtkWindow doesn't *wrap* a GdkWindow, it *creates* a GdkWindow with specialized attributes. An arbitrary XWindow created by someone else won't have the right attributes. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to get GtkWindow associed with XID?
On Sun, 2005-05-15 at 13:16 +0200, jacktm wrote: > Hello. > > I need do get the GtkWidget associated with XID. I thought > I can do it using gdk_window_foreign_new, but it doesn't > work for me. I tried many things, after googling I found > something like that: > > GtkWidget *toplevel = gtk_window_new(GTK_WINDOW_TOPLEVEL); > GdkWindow *gdk_win = gdk_window_foreign_new(xwin); > gtk_widget_set_parent_window(toplevel, gdk_win); > gtk_widget_show(toplevel); > > But it creates new window and everything paints in that. > It looks like gtk_widget_set_parent_window doesn't work. > What am I doing wrong? Why doesn't it work for me? It's not clear what you are trying to do here. GtkWidgets create their own X windows you can't reuse an existing one. If you need to embed a GTK+ widget into a non-GTK+ application you'll need to implement the embedder side of the XEMBED protocol. http://www.freedesktop.org/Standards/xembed-spec Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: nested gdk_threads_enter() hangs: linux/gcc vs. win32/mingw?
On Sat, 2005-05-14 at 12:26 +0200, Felix Kater wrote: > Hi, > > I am using the same code on win32/mingw and linux/gcc, however, when I > execute the code on linux, the programm hangs at the second (nested) call of > gdk_threads_enter(), see below. > > Am I doing something illegal to use nested calls of gdk_threads_enter()? > If not, is there a flag to allow/disallow nested calls I miss on linux? The GDK mutex is not recursive, unless the operating system only has recursive mutexes. So, no, you can't do that. You'll need to restructure the code. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Missing pango_render_part_get_type in Win32 Pango?
On Thu, 2005-05-12 at 22:44 -0300, Daniel K. O. wrote:
> I'm wondering if the function pango_render_part_get_type() should be
> exported on Pango Win32 1.8.0.
>
> Right now I'm trying to compile GTKmm 2.6.2, and getting this error:
>
> ---
> Creating library file: .libs/libpangomm-1.4.dll.a
> .libs/renderer.o: In function
> `ZN4Glib5ValueIN5Pango10RenderPartEE10value_typeEv':
> c:/projects/gtkmm-2.6.2/pango/pangomm/renderer.cc:44: undefined
> reference to `pango_render_part_get_type'
> ---
>
> Then I just did a quick test:
>
> ---
> #include
> int main(void)
> {
> GType t = pango_render_part_get_type ();
> return 0;
> }
> ---
It's public. Put a bug in bugzilla about it.
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: is GBoxed the way to wrap things like GList, GHashMap, ... [resend]
On Fri, 2005-04-22 at 08:37 +0200, Stefan Kost wrote:
> hi,
>
> Several of my GObjects provide thgs like GList or GHashmap as readable
> properties. Unfortunately these properties are just gpointers.
> For the file-serialisation it would be nice to know whats behind the pointer.
> Is
> GBoxed the way to go? This modules has only vague docs, especially what it is
> for.
>
> For GList I assume I would do:
>
> #define MY_TYPE_BOXED_LIST my_boxed_list_get_type();
>
> GType my_boxed_list_get_type (void)
> {
>static GType type = 0;
>if (type == 0) {
> type = g_boxed_type_register_static("MyBoxedList",
> my_boxed_list_copy,my_boxed_list_free);
>}
>return type;
> }
>
> gpointer my_boxed_list_copy (GType boxed_type, gconstpointer src_boxed)
> {
>return g_list_copy (src_boxed);
> }
>
> gpointer my_boxed_list_free (GType boxed_type, gpointer boxed)
> {
>return g_list_free (boxed);
> }
>
> For the properties I would install a g_param_spec_boxed with the type =
> MY_TYPE_BOXED_LIST?
Yes, this will work. Of course, "GList" isn't a very useful object type,
you can't serialize a "list" - you need to know what it is a list of.
So, for many cases you might as well use G_TYPE_POINTER, unless you
actually want the copies for memory management reasons.
> Does that makes sense? Or can anyone point me to a more complete example?
There are many examples of boxed types in GTK+. But we generally avoid
properties and signal parameters of type GList because it doesn't work
for language bindings. You'd need parameterized types for that, which
we've never really wanted to add to GObject.
Regards,
Owen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_window_foreign_new returns NULL
On Fri, 2005-04-22 at 01:19 +0200, jacktm wrote: > // Open the display > Display *dpy = XOpenDisplay(NIL); > assert(dpy); > > // Get some colors > int blackColor = BlackPixel(dpy, DefaultScreen(dpy)); > int whiteColor = WhitePixel(dpy, DefaultScreen(dpy)); > > // Create the window > Window w = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, >200, 100, 0, blackColor, blackColor); > gdk_win = gdk_window_foreign_new((guint32)w); If you used the GTK+ display, rather than opening a new one, this code would work. But here, the problem is that the command to create 'w' is still queued up in the buffers for the 'dpy' display, and has not been sent to the server or processed. So, either use GDK_DISPLAY() rather than dpy, or call XSync (dpy, False); after calling XCreateSimpleWindow() Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: threads gdk/Xlib
On Mon, 2005-04-11 at 13:06 +0100, StÃphane Konstantaropoulos wrote: > Hello all, > > I am programming a testing app for a gtk widget that embeds Xine and I > am facing little problems with threads and XLib: the application crashes > all the time whith "Xlib: unexpected async reply" > > It got fixed only when I called the following functions in the following > sequence: > > XInitThreads (); > g_thread_init(NULL); > gdk_threads_init(); > gtk_init(&argc, &argv); > > There is no need to put gtk_main() between gdk_threads_enter() and > gdk_threads_leave(). If you use a debugging threads library, you'll then see warnings about "unlocking an unlocked mutex" or similar. If you call gdk_threads_init (), then all calls to GDK must be within the GDK lock. On the other hand, there is no reason to call gdk_threads_init() if you are using GDK from only one thread. > To sum up: there are calls to Xlib from other threads, created by Xine. Gdk > also calls Xlib but only from the > main thread (my app does not create any). Xine always calls XLockDisplay() > before doing any of these calls. > > Question then: > > - Does Gdk call XLockdisplay() at all? When necessary, yes. You only need to call XLockDisplay() if you are doing incredibly grotty low-level Xlib programming. GDK does some of that, it's conceivable that Xine does too, though I rather doubt it. > - Do you need to call XInitThreads() before gdk_threads_init() ? -> that's > the way it seems to work for me. No, I don't think so. You *do* need to call XInitThreads before making any other GDK/GTK+ calls (like gtk_init() since they might call Xlib functions) > - Why is this (ie the interaction between Xlib threads and Gdk threads) not > documented anywhere? Because there really is no interaction. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting native X Window from GtkWidget
On Mon, 2005-03-14 at 15:22 +0100, JÃrg Henne wrote: > } > > As you can see, I tried both suggested routes. However, both of them > lead to the same problem: > > Entering > Handle: 0x34000c1 > > (process:11392): GLib-GObject-CRITICAL **: gtype.c:1871: initialization > assertion failed, use g_type_init() prior to this function Are you sure you are using WxGTK as the widget system for your python script? .. this warning would imply to me that nothing has ever initialized GTK+ or the underlying object system. (If you were using pyGTK, there are a wrapper for eggtrayicon floatng around though it's not in the standard bindings.) Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: deadlock
On Thu, 2005-03-10 at 21:18 +0100, Dirk Huenniger wrote:
> Hello everybody,
> My name is Dirk, I'm writing a control programm for a 1m telescope in
> Germany. The current status of the device is periodically displayed in GTK
> using a thread. When the user clicks the quit butten a callback routine is
> started. At the same time my thread does a gtk_threads_enter(). But it
> cannot enter because the callback is running so it waits inside the
> gtk_threads_enter
> routine. My callback routine askes the thread to quit and waits for that
> to happen. But the thread cannot react because it is waiting inside
> gtk_threads_enter(). So everything is hanging now. I also
> tried to quit my thread in a routine added with gtk_quit_add, it did not
> help. But the following evil hack worked:
>
> /* my callback routine*/
> menu_exit (GtkMenuItem *menuitem,
> gpointer user_data)
> {
>gdk_threads_leave(); /* give back gdk "semaphore" ?*/
>thread_stop(); /* let thread take it and give it back*/
>gdk_threads_enter(); /* take it again*/
> }
There's nothing yucky about this at all. GTK+ is reentrant
at this point, so it's fine to release the lock temporarily. If you
called, say, gtk_dialog_run() at this point, the same thing would
happen.
Regards,
Owen
(The general question of when it's OK to release the GTK+ lock isn't
something I can give a really well defined answer to. If the other
thread isn't going to modify the widget hierarchy, then it's fine
to release it in almost any callback.
If the other thread *is* modifying the same widget hierarchy, then
it's fine to release it in callbacks like ::clicked, ::activate,
etc, but I wouldn't do it in ::-event callbacks, ::size-allocate,
::size-request, since those involve walking over the widget hierarchy.)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_window_process_updates() blocks?
Felix Kater wrote: Hi, gdk_window_process_update() freezes my application (gtk-2.4.13/win32) in case that it is performed on a gdk-window of a button which is created in a gtk-main-window which was never shown. In case that I show the window (and hide it) before gdk_window_process_update() there is no problem. Is that a normal behaviour? If so, how can I find out if a button is in a window which was never shown? Are you sure that the window isn't NULL? In any case,. this isn't normal behavior ... and is probably win32 specific. You should test with the current release before reporting a bug. Then if it still happens, please file a bug report with a short test case. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.8.1 released
Pango-1.8.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.6/ pango-1.8.1.tar.bz2 md5sum: 88aa6bf1876766db6864f3b93577887c pango-1.8.1.tar.gzmd5sum: 937a2de21f82b994e36d6705a3db5f31 This is a bug fix release containing numerous fixes as compared to 1.8.0. The most important fix is a workaround for a compatibility problem with GtkHTML that was causing problems with the display and printing of fonts in Evolution. There are also some critical bug fixes for Sinhala rendering. 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 usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with three different font backends: - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.8.0 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, and a number of Indic and South-East Asian 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 depends on version 2.6.0 or better of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of changes between 1.8.0 and 1.8.1 === * Fix several problems with conjuct formation in Sinhala [Harshula] * Fix problems that were causing fonts to be missized and not print in GtkHTML [Ross Burton] * Fix compilation with old fontconfig [Vincent Noel] and old FreeType [Andrew P. Lentvorski, Jr] * Work around problem with glyphs in monospace fonts being truncated by Xft [Billy Biggs] * Misc bug fixes [Damon Chaplin, Matthias Clasen, Kees Cook, Nick Lamb, Adam Sampson,Manish Singh, Morten Welinder] * Misc build fixes [Sebastien Bacher, Matthias Clasen, Tor Lillquist] * Doc improvements [Torsten Schoenfeld, Billy Biggs, Morten Welinder] Owen Taylor 4 March 2004 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: documentation of GtkBinding
On Wed, 2005-03-02 at 14:39 -0600, Boncek, John wrote: > Thanks, Owen. I'll definitely have to check out the book when it comes > out. The book isn't coming out ... after some years of working on it, it came apparent that the author group was better suited to writing GTK+ than writing about GTK+, and the project was abandoned. What we had is available as the gtk-book module in GNOME CVS, but it is pretty badly out of date in most areas and far from complete. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: documentation of GtkBinding
Boncek, John wrote: In the archive of this list for January 2001, I found a message posted by Owen Taylor that included this link for some documentation of the GtkBinding system, http://www.labs.redhat.com/otaylor/gtk/keyboard.ps but it's not there any more. Does anyone (Owen?) know where it is now, or where any other documentation of GtkBinding can be located? http://people.redhat.com/otaylor/gtk/keyboard.ps Will work. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: "ASSERTION: How'd we get a floated inline frame?"
Tom Copeland wrote: Hi folks - I'm getting a "ASSERTION: How'd we get a floated inline frame?" message from a small embedded Mozilla program... everything seems to work OK, but it makes me kind of nervous. The program does this, more or less: That's a Mozilla layout engine message ... nothing to do with GTK+. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A bug in Gtk+?
On Wed, 2005-02-23 at 14:31 +0500, Zeeshan Ali wrote: > Hello, > > On Wed, 23 Feb 2005 10:12:07 +0200, Olexiy Avramchenko > <[EMAIL PROTECTED]> wrote: > > When you create main loop with NULL as context parameter, main loop gets > > shared default context. Before you create your main loop, default > > context was populated with functions from gtk/gdk. > > > > The blocker is gdk_event_prepare (it just locks the global mutex), GLib > > code call it because the event source is not removed by gtk_main_quit. > > Thanks. Got it :) > > > You may: > > 1. Create separate context (this looks like the best solution). > > 2. Use gdk_threads_leave() before your g_main_loop_run() call. >I'll go for #1 i think. Note that if you want to integrate your own callbacks with GTK+ GUI callbacks in the same thread (like repaint events), you need to do 1... you can only have one running contex per thread. And in fact, what gtk_main() looks like is basically: gtk_threads_leave(); g_main_loop_run(); gtk_threads_enter(); So it's very much the "normal" way things work. Regards, Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
