Calling gtk_notebook_get_menu_label_text () in a for loop
Hi, I'm in need of calling gtk_notebook_get_menu_label_text() in a for loop to know if an archive is already open in a page. Each menu label page does contain the archive name. Since from the doc I read the string is owned by the widget and must not be freed will I produce memory leaks if I call gtk_notebook_get_menu_label_text() repeatedly? -- Colossus Xarchiver, a Linux GTK+2 only archive manager - http://xarchiver.xfce.org Xscreencast, a DE independent desktop session recorder - http://xscreencast.berlios.de Cpsed, a Linux OpenGL 3D scene editor - http://cpsed.sourceforge.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Calling gtk_notebook_get_menu_label_text () in a for loop
On Mon, Dec 04, 2006 at 10:23:09AM +0100, Colossus wrote: I'm in need of calling gtk_notebook_get_menu_label_text() in a for loop to know if an archive is already open in a page. If you have to scan some widgets and parse their labels to find out whether an archive is already displayed somewhere, you should primarily rethink your data structures... Each menu label page does contain the archive name. ...not only because this is the presentational layer and it can change easily (e.g. you find something should be displayed differently), unlike the underlying fact what is displayed where. Since from the doc I read the string is owned by the widget and must not be freed will I produce memory leaks if I call gtk_notebook_get_menu_label_text() repeatedly? If it says the string is owned by the widget, it means it is not your business to free it or otherwise mess with it (and if you try, the compiled should warn you, because the return type is const gchar*). It is *owned* by the widget, and therefore the widget knows when and how to free it. Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to get the used style for a widget
Hi,
how can I get the style which is actually used to draw the widgets in
an application? More preciously, I need to get the foreground colour
(resp. the colours for the GtkStateType enum) for a widget.
I want to change the foreground colour of this widget(GtkLabel) to red
if a file inside my application has changed and reset the colour to the
default foreground colour if the file was saved.
I tried gtk_widget_get_default_style() and gtk_widget_get_style() but
the returned style doesn't seemed to be used to draw any widgets.
I tried it with the following ~/.gtkrc-2.0:
style my_style
{
fg[ACTIVE]= #008918
fg[NORMAL]= #008918
}
widget_class * style my_style
This works, so I get all green menu items, notebook tabs and so on.
Now, I need a way to get these values for fg[ACTIVE] and fg[NORMAL] in
GTK.
Any ideas?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.key
___
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 the used style for a widget
On Mon, 4 Dec 2006 15:13:56 +0100 Enrico Tröger [EMAIL PROTECTED] wrote: ET how can I get the style which is actually used to draw the widgets in ET an application? This shoud work correct: GtkStyle *rc_style = gtk_rc_get_style (your_widget); -- Best regards, Eugene mailto:[EMAIL PROTECTED] ICQ:127457886 xmpp://[EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to get the used style for a widget
On Mon, 4 Dec 2006 17:18:05 +0300, Eugene Zagidullin [EMAIL PROTECTED] wrote: On Mon, 4 Dec 2006 15:13:56 +0100 Enrico Tröger [EMAIL PROTECTED] wrote: ET how can I get the style which is actually used to draw the ET widgets in an application? This shoud work correct: GtkStyle *rc_style = gtk_rc_get_style (your_widget); It does. Thank you very much. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Adjusting GtkFileChooserDialog appearance
Hi, I am trying to scale down the width of the GtkFileChooser dialog to fit in 320x240 display geometry. One annoying thing is that the [+ Add][- Remove] buttons of the 'Places' left-side pane define its minimal width. There is no property to hide it all together (which I would like to do very much). Instead, I thought I can get a hold of the buttons themselves and, let's say, take the Labels out and leave icons only. Also, It would be totally nice to place 'Places' TreeView into a GtkScrolledWindow. But, of course, GtkFileChooser (or its parents) provides no properties to manipulate all of that. Perhaps, someone had faced same issues in the past and figured out how to make the adjustments. Thanks in advance for any ideas / code samples. -Vlad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Adjusting GtkFileChooserDialog appearance
You can go in and mess with the contents of the dialog. Somewhere I think I have a function that walks the tree of widgets within it printing out relevant information. Such a solution is completely and horribly non-portable between versions of GTK of course. (So yeah, it would be great if GtkFileChooser had a few functions for accessing various logical component widgets.) Reed Vladislav Grinchenko wrote: Hi, I am trying to scale down the width of the GtkFileChooser dialog to fit in 320x240 display geometry. One annoying thing is that the [+ Add][- Remove] buttons of the 'Places' left-side pane define its minimal width. There is no property to hide it all together (which I would like to do very much). Instead, I thought I can get a hold of the buttons themselves and, let's say, take the Labels out and leave icons only. Also, It would be totally nice to place 'Places' TreeView into a GtkScrolledWindow. But, of course, GtkFileChooser (or its parents) provides no properties to manipulate all of that. Perhaps, someone had faced same issues in the past and figured out how to make the adjustments. Thanks in advance for any ideas / code samples. -Vlad ___ 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
Finding Version of GTK installed
Hi all, I'm working on a program that prereqs GTK, and I posted on this mailing list a while ago, however I've come across another issue. I can determine if GTK is installed on the computer, however I'm having trouble determining the version of GTK that is installed. When GTK is installed with the OS, then a gtk-config file is not created in /usr/lib or anyplace for that matter. I was wondering if anyone knew how to determine the version of GTK installed, or any file(s) that would contain this information. Thanks in advance (Embedded image moved to file: pic14160.gif)torolab David VandePol Software Developer WebSphere Application Server - Install IBM Canada Tel: (905) 413 - 2495 E-mail: [EMAIL PROTECTED]___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Finding Version of GTK installed
On 12/4/06, David Vandepol [EMAIL PROTECTED] wrote: mailing list a while ago, however I've come across another issue. I can determine if GTK is installed on the computer, however I'm having trouble determining the version of GTK that is installed. When GTK is installed There are a number of ways of doing this. You can use pkg-config to find the version of any package it knows about: [EMAIL PROTECTED]:~$ pkg-config gtk+-2.0 --modversion 2.8.20 That's the closest to the old gtk-config. In your running program you can test the version you compiled against and are linked against: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Feature-Test-Macros.html autotools can also check for versions for you with PKG_CHECK_MODULES. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Finding Version of GTK installed
On Mon, 4 Dec 2006 13:09:46 -0500 David Vandepol [EMAIL PROTECTED] wrote: a gtk-config file is not created in /usr/lib or anyplace for that matter. I was wondering if anyone knew how to determine the version of GTK installed, or any file(s) that would contain this information. gtk-config was for GTK+ version 1.x. From 2.0 on, the version can be interrogated by pkg-config --modversion gtk+(for version 1.2.x) pkg-config --modversion gtk+-2.0 (for version 2.x - the 2.0 is misleading) use --modversion, not --version (the latter will give you the version of pkg-config) John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkentry grab-focus
For those interested, here's a way to get the desired result. The
source of gtkentry.c shows that if the entry receives a click, it
resets the selection to the current position of the cursor. Hence the
following button-press-event callback works:
static gboolean event_cb(GtkWidget*w,GdkEvent*event,gpointer p)
{
if(!GTK_WIDGET_HAS_FOCUS(w)){
gtk_widget_grab_focus(w);
return TRUE;
}
return FALSE;
}
___
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 keep UTF-8 characters, but escape non-UTF-8 byte sequence to hex codes in ASCII
At 07:29 AM 12/1/2006, Peter Lund wrote: On Thu, 2006-11-30 at 15:46 -0800, Daniel Yek wrote: Well, with g_utf8_validate(), it is trivial to implement a function that escape non-UTF-8 bytes to Hex. However, I then found out that TreeView, or more likely Pango, would unescape the %xx sequence (undo my attempt to help it) and choke!??! What if you double the percent signs? Was it supposed to work? I tried, it didn't work. Thanks. -- Daniel Yek -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Pango-1.15.1 released [unstable]
Pango-1.15.1 is now available for download at: http://download.gnome.org/sources/pango/1.15/ or ftp://ftp.gtk.org/pub/pango/1.15 bb24f4fd3d303e84827f852b38a682f7 pango-1.15.1.tar.bz2 3d2bd774728c11728e15ba429c67e6d5 pango-1.15.1.tar.gz This is a development release leading up to Pango-1.16.0, which will be released just in time for GNOME-2.18. 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. If you have problems, you'll need to reinstall Pango-1.14.x * 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 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/. Bugs should be reported to http://bugzilla.gnome.org. Pango 1.15 depends on version 2.12.0 or newer of the GLib library and version 1.2.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.15.0 and 1.15.1 == * Add Thai langauage engine. (currently makes tests/testboundary fail.) * Add Lao and improved Thai sample text. * Improved Indic module. * Output correct path for hexboxes in pango_cairo_layout_path(). * Implement get_resolution method for the FT2 fontmap. Shouldn't make any difference whatsoever. Open a bug if it does. * Misc small fixes. * Optimizations: - Rework PangoLayout algorithms to avoid calling a recursive call to pango_layout_get_extents(). Avoids one pango_font_get_glyph_extents() call per glyph per layout rendering. We now make 2 such calls. - Don't cache run_logical_rect in PangoLayoutIter. Avoids one pango_font_get_glyph_extents() call per glyph per layout rendering. We are down to 1 now. - Cache line extents. This avoids the final pango_font_get_glyph_extents() call per glyph per layout rendering. Now we don't make any pango_font_get_glyph_extents() calls when rendering a layout (some conditions apply)! - Replace PANGO_IS_RENDERER with PANGO_IS_RENDERER_FAST for most internal uses, that is, just a NULL-check. - Use simple, fast, casts instead of PANGO_CAIRO_*() macros where the object cannot have reached us if it wasn't of the right type. * Bugs fixed in this release: Bug 135683 – Cache glyphstring extents Red Hat Bug 211964: [ta] Rendering issue with Tamil Patch from LingNing Zhang Red Hat Bug 213632: ZWJ (200d) and ZWNJ (200c) showing same output Patch from LingNing Zhang Bug 371388 – Add Thai langauage engine Patch from Theppitak Karoonboonyanan Bug 377975 – bug in _pango_glyph_item_iter_next_cluster Bug 369670 – Checked g_free calls Changes that also appeared between 1.14.7 and 1.14.8 = * Improved thread-safety. Pango is still NOT thread-safe, but this fixes lots of crashes using pangocairo from multiple threads. * Fix out-of-bounds array access. * Improved Indic shaper. * Improved Arabic language engine. * Choose shaper/font for unassigned Unicode codepoints. * Build fixes. * Bugs fixed in this release: Bug 35 – pango is not
