Problems with 64bit build for Windows
Does anyone use a 64bit Windows build available from gtk.org ? I've installed a latest bundle of this release. Compile of my program works fine, but at the linking phase I get lots of unresolved external symbols related to intl.lib (the lib is correctly added to the list of libraries to link with, this works fine with 32 builds). Example: error LNK2019: unresolved external symbol libintl_fprintf referenced in function Next I've tried to link against the proxy-libintl but this does not work either. Note also that the link to the 64bit proxy-libintl is not correct, so I had to find it manually by going into the parent directory of the URL. Any help with this ? Regards, Miroslav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problems with 64bit build for Windows
Does anyone use a 64bit Windows build available from gtk.org ? Well, I don't use them on a day-to-day basis (my development environment is still a 32-bit XP, and I even cross-compile those 64-bit binaries from that). But I do run a 64-bit gtk-demo each time I have built new 64-bit binaries, so they aren't entirely untested. But I use the mingw (gcc and GNU binutils etc) toolchain, while you seem to use MSVC. There might indeed be problems with using the MSVC format import libraries. Using the 64-bit developer packages with MSVC hadn't been tested (before you now did it) at all... The mingw-w64 compiler is in a beta stage. mangles C global identifiers by prefixing an underscore, as is the convention on 32-bit. That is incorrect, such a convention is not used by the 64-bit MSVC, and this will be or has already been fixed in later releases of the mingw-w64. So, if you use MSVC, unfortunately you will have to wait until a 64-bit build that would have been built with a newer version of mingw-w64 is available. error LNK2019: unresolved external symbol libintl_fprintf referenced in function To be precise, the problem here is that the symbol exported is actually _libintl_fprintf. (And the same pattern holds for all other symbols, too, this is not restricted to just libintl.) Note also that the link to the 64bit proxy-libintl is not correct, so I had to find it manually by going into the parent directory of the URL. Ah, thanks, will have to fix this. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problems with 64bit build for Windows
To be precise, the problem here is that the symbol exported is actually _libintl_fprintf. (And the same pattern holds for all other symbols, too, this is not restricted to just libintl.) Overall problem does not seem to be big at all. The only library with a problem seems to be intl.lib. All other libs seem to link fine. Regards, Miroslav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Treeview Signals
All, I have a treeview with Text and Combo Renderers. The key-press event is connected to the treeview. Why does the key-press callback only get called when the focus cell is a text renderer? I would like it to be called when the focus cell is a combo render also. Thanks, dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GWeakNotify fired earlier than expected
Hi,
From reading the documentation, I am expecting a GWeakNotify to be
fired when the object is finalized (which I interpret as right before
it is freed). However, I am seeing it called during destroy while
references are still held. I am likely just misunderstanding
something, any explanations? Thanks...
$ ./weak
created widget, ref count 1
in container, ref count 2
Finalize, ref count 2
destroyed container 1
destroying last ref 1
$ cat weak.cc
#include stdio.h
#include gtk/gtk.h
static void OnFinalizeDebug(gpointer userdata, GObject* wasptr) {
printf(Finalize, ref count %d\n, wasptr-ref_count);
}
int main(int argc, char** argv) {
gtk_init(argc, argv);
GtkWidget* widget = gtk_label_new(abc);
g_object_ref_sink(widget);
g_object_weak_ref(G_OBJECT(widget), OnFinalizeDebug, widget);
printf(created widget, ref count %d\n, G_OBJECT(widget)-ref_count);
GtkWidget* box = gtk_vbox_new(FALSE, 0);
gtk_container_add(GTK_CONTAINER(box), widget);
printf(in container, ref count %d\n, G_OBJECT(widget)-ref_count);
gtk_widget_destroy(box);
printf(destroyed container %d\n, G_OBJECT(widget)-ref_count);
printf(destroying last ref %d\n, G_OBJECT(widget)-ref_count);
g_object_unref(widget);
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GWeakNotify fired earlier than expected
After reading the gobject code a bit more, it seems that weak
references are fired on dispose, not finalize:
static void
g_object_real_dispose (GObject *object)
{
g_signal_handlers_destroy (object);
g_datalist_id_set_data (object-qdata, quark_closure_array, NULL);
g_datalist_id_set_data (object-qdata, quark_weak_refs, NULL);
}
All of the documentation I could find states that it happens during
finalization, but it seems it should all say that it happens during
dispose. In my example this detail is actually very important.
Doesn't look like there is a way to catch dispose without shimming the
instance handler. Any ideas?
On Mon, Mar 16, 2009 at 5:16 PM, IdaRub ida...@gmail.com wrote:
Hi,
From reading the documentation, I am expecting a GWeakNotify to be
fired when the object is finalized (which I interpret as right before
it is freed). However, I am seeing it called during destroy while
references are still held. I am likely just misunderstanding
something, any explanations? Thanks...
$ ./weak
created widget, ref count 1
in container, ref count 2
Finalize, ref count 2
destroyed container 1
destroying last ref 1
$ cat weak.cc
#include stdio.h
#include gtk/gtk.h
static void OnFinalizeDebug(gpointer userdata, GObject* wasptr) {
printf(Finalize, ref count %d\n, wasptr-ref_count);
}
int main(int argc, char** argv) {
gtk_init(argc, argv);
GtkWidget* widget = gtk_label_new(abc);
g_object_ref_sink(widget);
g_object_weak_ref(G_OBJECT(widget), OnFinalizeDebug, widget);
printf(created widget, ref count %d\n, G_OBJECT(widget)-ref_count);
GtkWidget* box = gtk_vbox_new(FALSE, 0);
gtk_container_add(GTK_CONTAINER(box), widget);
printf(in container, ref count %d\n, G_OBJECT(widget)-ref_count);
gtk_widget_destroy(box);
printf(destroyed container %d\n, G_OBJECT(widget)-ref_count);
printf(destroying last ref %d\n, G_OBJECT(widget)-ref_count);
g_object_unref(widget);
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GWeakNotify fired earlier than expected
On Mon, Mar 16, 2009 at 5:51 PM, Havoc Pennington havoc.penning...@gmail.com wrote: Hi, On Mon, Mar 16, 2009 at 12:45 PM, IdaRub ida...@gmail.com wrote: After reading the gobject code a bit more, it seems that weak references are fired on dispose, not finalize: Right, that's correct. All of the documentation I could find states that it happens during finalization, but it seems it should all say that it happens during dispose. Probably true. dispose is typically done during finalize, but can happen sooner also. dispose can happen multiple times. In my example this detail is actually very important. Doesn't look like there is a way to catch dispose without shimming the instance handler. Any ideas? You mean there's no way to catch finalize? Finalize deliberately can't be intercepted, because it raises a lot of thorny issues about reentrancy; what if the object is used or its refcount increased during finalization? It would be nice if you could intercept it, the author being responsible for understanding what finalize means, and not doing anything inappropriate. I was attempting to write some ownership debugging code, basically something like leak and use-after-free detection for a few specific object. We'll catch this other ways though, so I suppose I will drop this idea. Thanks for your great reply. So things are split into two phases, dispose() which you can get notifications about (and which can happen multiple times); and finalize which actually frees the object. Havoc ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
HOWTO: Center window on screen.
Hi list, I've seen this question asked several times and even asked it myself, so as I finally made it happen, I thought I'd share my success with others in need. Simply putting: gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); at any creative point in your code seems to place windows at random positions on screen. What works for me is putting: gtk_window_set_type_hint(GTK_WINDOW(window), GDK_WINDOW_TYPE_HINT_DIALOG); gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); right before the final call to gtk_widget_show_all(window);. br - N :o) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE : RE : GTK+ 2.16.0 released
Ok, no problem, Thank you -Message d'origine- De : tlillqv...@gmail.com [mailto:tlillqv...@gmail.com] De la part de Tor Lillqvist Envoyé : lundi 16 mars 2009 00:34 À : dupuit cyril Cc : gtk-app-devel-list@gnome.org Objet : Re: RE : GTK+ 2.16.0 released Just a little question, when this last release can be available at the following page http://www.gtk.org/download-windows.html. In a day or two. Most likely during next week anyway. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Background color problem
Hello everybody, I'm using libclutter-gtk (with GtkClutterEmbed widget), where I want to display some graphics. If somebody doesn't know it, I'll describe it a bit. It is derived from GtkWidget. Then it uses it's own canvas. The canvas is white, and it doesn't have some kind of transparency. So, as I thought, I decided to fill it's background with color, got from it's GtkStyle. After some experiments I realized, that widgets (main window, container and GtkClutterEmbed) don't have needed color: quod_main_window_create_widgets(self); // here I create all widgets GtkStyle* default_style = gtk_widget_get_style (GTK_WIDGET(self)); GdkColor* bg = default_style-bg[GTK_STATE_NORMAL]; g_debug(%x %x %x %x, bg-red, bg-green, bg-blue, bg-pixel); gtk_widget_show_all((GtkWidget*) self); ** (./dist/Debug/GNU-Linux-x86/gnome-quod:2349): DEBUG: dcdc dada d5d5 0 if I change the code in such way: quod_main_window_create_widgets(self); // here I create all widgets gtk_widget_show_all((GtkWidget*) self); GtkStyle* default_style = gtk_widget_get_style (GTK_WIDGET(self)); GdkColor* bg = default_style-bg[GTK_STATE_NORMAL]; g_debug(%x %x %x %x, bg-red, bg-green, bg-blue, bg-pixel); ** (./dist/Debug/GNU-Linux-x86/gnome-quod:3088): DEBUG: b0b0 b8b8 f1f1 b0b8f1 Can you help me with this? I don't know how to change the color of my widget, because I've created as a separate class, derived from GtkClutterEmbed. And when I use the next construction in static GObject* quod_board_widget_constructor(GType type, guint n_construct_properties, GObjectConstructParam *construct_properties) GdkColor* bg = default_style-bg[GTK_STATE_NORMAL]; // got in the same way g_debug(%x %x %x %x, bg-red, bg-green, bg-blue, bg-pixel); // again: dcdc dada d5d5 0 and not #b0b8f1 ... Now, I'm thinking how can I get the correct (needed) color in my widget constructor. Or, should I connect the signal expose-event to my widget, where I will recheck widget's color and use it as background. What should I use, when I want to redraw my widgets when user dynamically changes GTK theme? Thank you in advance, Vlad Volodin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Background color problem
Vlad Volodin wrote: The canvas is white, and it doesn't have some kind of transparency. So, as I thought, I decided to fill it's background with color, got from it's GtkStyle. After some experiments I realized, that widgets (main window, container and GtkClutterEmbed) don't have needed color: You really just can't use this method at all. Some widgets won't have a color as a background; they'll have a pixmap. You won't be able to paint it using this method. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Background color problem
Sorry, Brian, but as I said before, I also can't get the correct GtkWindow background color before it is shown. why? (thank you for your reply) 2009/3/16 Brian J. Tarricone bj...@cornell.edu: Vlad Volodin wrote: The canvas is white, and it doesn't have some kind of transparency. So, as I thought, I decided to fill it's background with color, got from it's GtkStyle. After some experiments I realized, that widgets (main window, container and GtkClutterEmbed) don't have needed color: You really just can't use this method at all. Some widgets won't have a color as a background; they'll have a pixmap. You won't be able to paint it using this method. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Background color problem
Rather than showing the window, call realize(). That does everything that show() does EXCEPT make the window visible. Then you should be able to get the background color. X doesn't send the communication to the server until there is idle time OR you force it (by calling realize()). On Tue, 2009-03-17 at 00:11 +0300, Vlad Volodin wrote: Sorry, Brian, but as I said before, I also can't get the correct GtkWindow background color before it is shown. why? (thank you for your reply) 2009/3/16 Brian J. Tarricone bj...@cornell.edu: Vlad Volodin wrote: The canvas is white, and it doesn't have some kind of transparency. So, as I thought, I decided to fill it's background with color, got from it's GtkStyle. After some experiments I realized, that widgets (main window, container and GtkClutterEmbed) don't have needed color: You really just can't use this method at all. Some widgets won't have a color as a background; they'll have a pixmap. You won't be able to paint it using this method. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Background color problem
No guys, that doesn't help.
Well my code is the next one:
static GObject* quod_board_widget_constructor(GType type, guint
n_construct_properties, GObjectConstructParam *construct_properties)
{
GObject *obj;
QuodBoardWidgetClass *klass;
GObjectClass *parent_class;
QuodBoardWidget *self;
g_debug(quod_board_widget_constructor);
self = QUOD_BOARD_WIDGET(obj);
{
GError* err = NULL;
gtk_widget_realize(GTK_WIDGET(self));
GtkStyle* default_style = gtk_widget_get_style (GTK_WIDGET(self));
GdkColor* bg = default_style-bg[GTK_STATE_NORMAL];
ClutterColor stage_color = { bg-red / 0xFF, bg-green /
0xFF, bg-blue / 0xFF, 0xF0 };
ClutterActor*stage = gtk_clutter_embed_get_stage
(GTK_CLUTTER_EMBED (self));
g_debug(quod_board_widget_constructor: %x %x %x %x, bg-red,
bg-green, bg-blue, bg-pixel);
clutter_stage_set_color (CLUTTER_STAGE (stage), stage_color);
}
return obj;
}
static GObject* quod_main_window_constructor(GType type, guint
n_construct_properties, GObjectConstructParam *construct_properties)
{
GObject *obj;
QuodMainWindowClass *klass;
GObjectClass *parent_class;
QuodMainWindow *self;
g_debug(quod_main_window_constructor);
klass = QUOD_MAIN_WINDOW_CLASS(g_type_class_peek(QUOD_TYPE_MAIN_WINDOW));
parent_class = G_OBJECT_CLASS(g_type_class_peek_parent(klass));
obj = parent_class-constructor(type, n_construct_properties,
construct_properties);
self = QUOD_MAIN_WINDOW(obj);
{
GError* err = NULL;
gtk_window_set_title((GtkWindow*) self, Gnome Quod);
gtk_window_set_default_size((GtkWindow*) self,
MAIN_WINDOW_DEFAULT_WIDTH, MAIN_WINDOW_DEFAULT_HEIGHT);
g_signal_connect((GtkObject*) self, destroy, (GCallback)
_gtk_main_quit_gtk_object_destroy, NULL);
gtk_window_set_icon_from_file((GtkWindow*) self, GNOME_ICONDIR
/quod.png, err);
// Create all used widgets and attach possible signals
quod_main_window_create_widgets(self);
GtkStyle* default_style = gtk_widget_get_style (GTK_WIDGET(self));
GdkColor* bg = default_style-bg[GTK_STATE_NORMAL];
g_debug(quod_main_window_constructor (before show):%x %x %x
%x, bg-red, bg-green, bg-blue, bg-pixel);
gtk_widget_show_all((GtkWidget*) self);
default_style = gtk_widget_get_style (GTK_WIDGET(self));
bg = default_style-bg[GTK_STATE_NORMAL];
g_debug(quod_main_window_constructor (after show):%x %x %x
%x, bg-red, bg-green, bg-blue, bg-pixel);
}
return obj;
}
** (./gnome-quod:16210): DEBUG: quod_main_window_construct
** (./gnome-quod:16210): DEBUG: quod_main_window_class_init
** (./gnome-quod:16210): DEBUG: quod_main_window_constructor
** (./gnome-quod:16210): DEBUG: quod_main_window_init
** (./gnome-quod:16210): DEBUG: quod_main_window_construct
** (./gnome-quod:16210): DEBUG: quod_main_window_construct
** (./gnome-quod:16210): DEBUG: quod_board_widget_new
** (./gnome-quod:16210): DEBUG: quod_main_window_construct
** (./gnome-quod:16210): DEBUG: quod_board_widget_class_init
** (./gnome-quod:16210): DEBUG: quod_board_widget_constructor
** (./gnome-quod:16210): DEBUG: quod_board_widget_init
(./gnome-quod:16210): Gtk-CRITICAL **: gtk_widget_realize: assertion
`GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed
(without realize, this error doesn't occur)
** (./gnome-quod:16210): DEBUG: quod_board_widget_constructor: dcdc dada d5d5 0
** (./gnome-quod:16210): DEBUG: quod_main_window_constructor (before
show):dcdc dada d5d5 0
** (./gnome-quod:16210): DEBUG: quod_main_window_constructor (after
show):b0b0 b8b8 f1f1 b0b8f1
** (./gnome-quod:16210): DEBUG: quod_main_window_finalize (and other
destructions, when I press the close button)
http://img10.imageshack.us/img10/5275/72303372.png
here you can see the gray box, it is colored from ClutterColor stage_color.
I wish, you can help me with the next question: When is GtkStyle
(compare before show and after show) applied to my windows/ widgets
etc. I can't get correct (blue, as in screen) colors, instead of them
I got gray: #dcdad5. I don't have such colors in my themas. Are they
default. (they are equal to gtk_wiget_get_default_style)
Thank you all again :)
2009/3/17 Chuck Crisler charles.cris...@comcast.net:
Rather than showing the window, call realize(). That does everything
that show() does EXCEPT make the window visible. Then you should be able
to get the background color. X doesn't send the communication to the
server until there is idle time OR you force it (by calling realize()).
On Tue, 2009-03-17 at 00:11 +0300, Vlad Volodin wrote:
Sorry, Brian,
but as I said before, I also can't get the correct GtkWindow
background color before it is shown. why?
(thank you for your reply)
2009/3/16 Brian J. Tarricone bj...@cornell.edu:
Vlad Volodin wrote:
The canvas is white, and it doesn't have some kind of transparency.
So, as I thought, I
Pango 1.24.0 released
Pango 1.24.0 is now available from: http://download.gnome.org/sources/pango/1.24/ d209f41079833cd2ef2c5e580ab9c5ee pango-1.24.0.tar.bz2 eb2394d143012432b73b8633ed632726 pango-1.24.0.tar.gz This is a stable release providing new functionality as compared to Pango-1.22, while maintaining source and binary compatibility. However, the PangoFc backend API has changed slightly. Projects subclassing PangoFc are advised to review the changed API. The major change since 1.22 is an overhaul of the internal caching of the PangoFc fontmap implementation. The new code is much faster and more memory efficient. This, combined with other optimizations available in this release, drastically reduce Pango's overhead on Linux systems. By popular request, pango-view now can save to PS, EPS, PDF, and SVG, and the bug with pango-view -q requiring an X connection is also fixed. These make pango-view a much more usable tool. It now even ships with a man page. See the NEWS file for an extensive list of improvements. 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.24 depends on version 2.17.3 or newer of the GLib library and version 1.7.6 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.23.0 and 1.24.0 = - pango-view improvements: * pango-view -q now works without a X server. * Ability to save to PS, EPS, PDF, and SVG files. Filetype is detected from output file extension. * New options --foreground, --background, and --annotate. * Now installs a manual page, thanks to help2man. - PangoFc API changes: * PangoFcFont now has a fontmap property that subclasses can use at construction time to setup the font-fontmap link. * New backend-public API: pango_fc_font_map_find_decoder() - Misc optimizations - Build fixes - Misc bug fixes - Bugs fixed in this release: Bug 547963 – man page for pango-view Bug 502804 – pango-view or pangocairo-view option to annotate Bug 502801 – per-backend pango-view options Bug 502805 – pango-view option for foreground/background color Red Hat Bug 490331 - Crash of galeon in libpango Bug 523166 – pango-view opens display even when invoked with -q Bug 567160 – Share cmap cache between PangoFcFont's of the same face Red Hat Bug 487593 - crash changing language in gdm Bug 572662 – Remove deprecated GTK+ symbols Bug 572529 – Poor -I ordering can break build Overview of changes between 1.22.4 and 1.23.0 = - Change the PangoFc font loading API to allow for lazy loading of fonts. - Add private PangoFcFontset that loads fallback fonts as needed. - Call FcFontMatch() and only if fallback fonts are needed call FcFontSort(). - Optimize HarfBuzz number of malloc calls - Don't malloc megs of unused memory in HarfBuzz - Print-out, and parse, numeric styles correctly. Things like DejaVu Sans weight=100 parse as font description now. - New public API: Add two new public macros: PANGO_ATTRIBUTE_INDEX_FROM_TEXT_BEGINNING PANGO_ATTRIBUTE_INDEX_TO_TEXT_END Add new public enum
Re: Background color problem
On Mon, 2009-03-16 at 23:28 +0300, Vlad Volodin wrote:
first of all, you really want to use the clutter list.
I'm using libclutter-gtk (with GtkClutterEmbed widget), where I want
to display some graphics. If somebody doesn't know it, I'll describe
it a bit. It is derived from GtkWidget. Then it uses it's own canvas.
The canvas is white, and it doesn't have some kind of transparency.
So, as I thought, I decided to fill it's background with color, got
from it's GtkStyle. After some experiments I realized, that widgets
(main window, container and GtkClutterEmbed) don't have needed color:
Containers in GTK+ do not usually have a background: they are assumed to
be transparent transparent. GtkWindow does have a background color,
though, since it'll have to provide the background for most widgets.
to set the color of the Stage embedded inside GtkClutterEmbed you can
get a specific color out of the GtkWindow style; you cannot do this at
any time you like: you'll have to connect to the style-set signal of the
GtkWindow that contains the GtkClutterEmbed-- at which point you have a
guarantee that a GtkStyle has been applied to the widget.
also, you have to remember that GdkColor and ClutterColor are not
compatible structures: you have to convert between the two.
GdkColor gdk_color = { 0, };
ClutterColor clutter_color = { 0, };
gdk_color = widget-style-bg[GTK_STATE_NORMAL];
clutter_color.red = CLAMP (((gdk_color.red / 65535.0) * 255), 0, 255);
clutter_color.green = CLAMP (((gdk_color.green / 65535.0) * 255), 0, 255);
clutter_color.blue = CLAMP (((gdk_color.blue / 65535.0) * 255), 0, 255);
clutter_color.alpha = 255;
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with gtkbuilder mingw cross (not the signal problem)
I'm cross compiling a gtk app that uses gtk builder with mingw. My build system is Fedora 10. I create my mingw env from this: http://www.profv.de/mingw_cross_env/ This is not the same problem others have had with connecting callbacks, but it may be related. The app builds fine. When the application starts, gtk_builder_add_from_string() fails. I did some sleuthing, and discovered that g_module_symbol() fails to find the symbol gtk_adjustment_get_type. I'm guessing it fails for other symbols as well, GtkAdjustment just happens to be the first object in my builder file. nm shows that the symbol is in the binary. Note that I can successfully lookup my callback functions using g_module_symbol(). So it just has something to do with exporting those symbols gtkbuilder relies on for instantiating objects. Any ideas? example compile line: i386-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src -I.. -DPACKAGE_LOCALE_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share/locale\ -DPACKAGE_SRC_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/../gtk/src\ -DPACKAGE_DATA_DIR=\/home/jstebbins/Source/HandBrake.mingw/build/contrib/share\ -mms-bitfields -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/gtk-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/gtk-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/atk-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/cairo -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pango-1.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/glib-2.0 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/glib-2.0/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/pixman-1 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/freetype2 -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include -I/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/include/libpng12 -Wall -g -g3 -O3 -fno-common -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o /home/jstebbins/Source/HandBrake.mingw/build/../gtk/src/main.c example link line: i386-mingw32msvc-g++ -g -O2 -I/home/jstebbins/Source/HandBrake.mingw/build//libhb -Wl,--export-dynamic -g3 -O3 -o ghb.exe callbacks.o queuehandler.o audiohandler.o x264handler.o main.o settings.o resources.o presets.o preview.o icons.o icon_tools.o values.o appcast.o plist.o hb-backend.o renderer_button.o ghbcellrenderertext.o ghb-dvd.o marshalers.o -L/home/jstebbins/Source/HandBrake.mingw/build//libhb -L/home/jstebbins/Source/HandBrake.mingw/build//contrib/lib -lhb /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/liba52.a -lm /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmkv.a -lavformat -lavcodec -lavutil /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libdca.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libdvdread.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaac.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmp3lame.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libmpeg2.a -L/home/jstebbins/Source/HandBrake.mingw/build/contrib//lib /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbisenc.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libvorbis.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libsamplerate.a -lx264 -lxvidcore /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libmp4v2.a -lswscale /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libtheora.a /home/jstebbins/Source/HandBrake.mingw/build/contrib//lib/libogg.a /home/jstebbins/Source/HandBrake.mingw/build/contrib/lib/libfaad.a -lbz2 -lpthread -liberty -L/home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgtk-win32-2.0.a -lcomdlg32 -lwinspool -lcomctl32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk-win32-2.0.a -limm32 -lshell32 -luuid /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libatk-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libgdk_pixbuf-2.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libtiff.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libjasper.a -ljpeg /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpangocairo-1.0.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libcairo.a /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpng12.a -lmsimg32 /home/jstebbins/Source/mingw_cross_env-2.4/usr/i386-mingw32msvc/lib/libpixman-1.a
Re: Background color problem
Oh! Thank you very much.
The thing with style-set works. As you said, I decided to add this
handler to my mainwindow (parent) and apply it's color to Stage.
Sorry, I've asked this question, but I can't find any explanation:
GdkColor gdk_color = { 0, };
ClutterColor clutter_color = { 0, };
They are structures, why do you use commas before the last brackets?
I've found C99 standard, where the same rule is applied to enum type
too. What is the purpose of it? (I've tried 1,, 2,, and only the
first field is assigned. So, it doesn't look as it able to clear all
the structure).
Thank you and everybody, who has helped me, again
Best wishes,
Vlad Volodin
2009/3/17 Emmanuele Bassi eba...@gmail.com:
On Mon, 2009-03-16 at 23:28 +0300, Vlad Volodin wrote:
first of all, you really want to use the clutter list.
I'm using libclutter-gtk (with GtkClutterEmbed widget), where I want
to display some graphics. If somebody doesn't know it, I'll describe
it a bit. It is derived from GtkWidget. Then it uses it's own canvas.
The canvas is white, and it doesn't have some kind of transparency.
So, as I thought, I decided to fill it's background with color, got
from it's GtkStyle. After some experiments I realized, that widgets
(main window, container and GtkClutterEmbed) don't have needed color:
Containers in GTK+ do not usually have a background: they are assumed to
be transparent transparent. GtkWindow does have a background color,
though, since it'll have to provide the background for most widgets.
to set the color of the Stage embedded inside GtkClutterEmbed you can
get a specific color out of the GtkWindow style; you cannot do this at
any time you like: you'll have to connect to the style-set signal of the
GtkWindow that contains the GtkClutterEmbed-- at which point you have a
guarantee that a GtkStyle has been applied to the widget.
also, you have to remember that GdkColor and ClutterColor are not
compatible structures: you have to convert between the two.
GdkColor gdk_color = { 0, };
ClutterColor clutter_color = { 0, };
gdk_color = widget-style-bg[GTK_STATE_NORMAL];
clutter_color.red = CLAMP (((gdk_color.red / 65535.0) * 255), 0, 255);
clutter_color.green = CLAMP (((gdk_color.green / 65535.0) * 255), 0, 255);
clutter_color.blue = CLAMP (((gdk_color.blue / 65535.0) * 255), 0, 255);
clutter_color.alpha = 255;
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: fsync in glib/gio
On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote: The debate is far from over with this. gio should be made slower and do unnecessary syncronous I/O in order to fulfill the standards, yes. Sure, it should fsync on ext4-before-it-was-fixed systems - it sucks to loose data; though I'm still unconvinced this is a standards issue :-) But there are milllions of lines of code that does the rename as atomic replace and the chances that anywhere near a majority of those are fixed is extremely slim. Therefore everyone should be aware of the broken filesystems that don't give data-before-metadata-on-rename guarantees so that sane people can stay away from them. Out of interest, what distributions are shipping with ext4 configured in this helpful loose your data mode ? can we not simply inject the go slower patch into these ext4 distros [ since it won't affect their performance quite as badly as everywhere else ], as a temporary workaround; and then sit back and let the default glib behaviour be to work well on all sane systems ? :-) Regards, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Mon, 2009-03-16 at 10:23 +, Michael Meeks wrote: On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote: The debate is far from over with this. gio should be made slower and do unnecessary syncronous I/O in order to fulfill the standards, yes. Sure, it should fsync on ext4-before-it-was-fixed systems - it sucks to loose data; though I'm still unconvinced this is a standards issue :-) There is no requirements in any standard as to what happens on system crashes. But there are milllions of lines of code that does the rename as atomic replace and the chances that anywhere near a majority of those are fixed is extremely slim. Therefore everyone should be aware of the broken filesystems that don't give data-before-metadata-on-rename guarantees so that sane people can stay away from them. Out of interest, what distributions are shipping with ext4 configured in this helpful loose your data mode ? can we not simply inject the go slower patch into these ext4 distros [ since it won't affect their performance quite as badly as everywhere else ], as a temporary workaround; and then sit back and let the default glib behaviour be to work well on all sane systems ? :-) It seems both ubuntu and F11 will backport the ext4 fixes. However, even with these fixed there is risk for data loss on e.g. xfs, and even ext3 if you configure it in data=writeback mode. There was also reports from nokia about it being unsafe on the flash file system they were using. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Am Montag, den 16.03.2009, 11:49 +0100 schrieb Alexander Larsson: On Mon, 2009-03-16 at 10:23 +, Michael Meeks wrote: On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote: But there are milllions of lines of code that does the rename as atomic replace and the chances that anywhere near a majority of those are fixed is extremely slim. Therefore everyone should be aware of the broken filesystems that don't give data-before-metadata-on-rename guarantees so that sane people can stay away from them. Out of interest, what distributions are shipping with ext4 configured in this helpful loose your data mode ? can we not simply inject the go slower patch into these ext4 distros [ since it won't affect their performance quite as badly as everywhere else ], as a temporary workaround; and then sit back and let the default glib behaviour be to work well on all sane systems ? :-) It seems both ubuntu and F11 will backport the ext4 fixes. However, even with these fixed there is risk for data loss on e.g. xfs, and even ext3 if you configure it in data=writeback mode. There was also reports from nokia about it being unsafe on the flash file system they were using. If flash file system is this one (they mention Nokia on the website - 2nd link): http://www.linux-mtd.infradead.org/faq/ubifs.html#L_powercut http://www.linux-mtd.infradead.org/doc/ubifs.html This might be either not noticed by the developers or not an issue with their file system. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Mon, 2009-03-16 at 11:55 +0100, Sven Herzberg wrote: Am Montag, den 16.03.2009, 11:49 +0100 schrieb Alexander Larsson: On Mon, 2009-03-16 at 10:23 +, Michael Meeks wrote: On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote: But there are milllions of lines of code that does the rename as atomic replace and the chances that anywhere near a majority of those are fixed is extremely slim. Therefore everyone should be aware of the broken filesystems that don't give data-before-metadata-on-rename guarantees so that sane people can stay away from them. Out of interest, what distributions are shipping with ext4 configured in this helpful loose your data mode ? can we not simply inject the go slower patch into these ext4 distros [ since it won't affect their performance quite as badly as everywhere else ], as a temporary workaround; and then sit back and let the default glib behaviour be to work well on all sane systems ? :-) It seems both ubuntu and F11 will backport the ext4 fixes. However, even with these fixed there is risk for data loss on e.g. xfs, and even ext3 if you configure it in data=writeback mode. There was also reports from nokia about it being unsafe on the flash file system they were using. If flash file system is this one (they mention Nokia on the website - 2nd link): http://www.linux-mtd.infradead.org/faq/ubifs.html#L_powercut http://www.linux-mtd.infradead.org/doc/ubifs.html This might be either not noticed by the developers or not an issue with their file system. Yes, this was it. See: http://bugzilla.gnome.org/show_bug.cgi?id=562976 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GWeakNotify fired earlier than expected
After reading the gobject code a bit more, it seems that weak
references are fired on dispose, not finalize:
static void
g_object_real_dispose (GObject *object)
{
g_signal_handlers_destroy (object);
g_datalist_id_set_data (object-qdata, quark_closure_array, NULL);
g_datalist_id_set_data (object-qdata, quark_weak_refs, NULL);
}
All of the documentation I could find states that it happens during
finalization, but it seems it should all say that it happens during
dispose. In my example this detail is actually very important.
Doesn't look like there is a way to catch dispose without shimming the
instance handler. Any ideas?
On Mon, Mar 16, 2009 at 5:16 PM, IdaRub ida...@gmail.com wrote:
Hi,
From reading the documentation, I am expecting a GWeakNotify to be
fired when the object is finalized (which I interpret as right before
it is freed). However, I am seeing it called during destroy while
references are still held. I am likely just misunderstanding
something, any explanations? Thanks...
$ ./weak
created widget, ref count 1
in container, ref count 2
Finalize, ref count 2
destroyed container 1
destroying last ref 1
$ cat weak.cc
#include stdio.h
#include gtk/gtk.h
static void OnFinalizeDebug(gpointer userdata, GObject* wasptr) {
printf(Finalize, ref count %d\n, wasptr-ref_count);
}
int main(int argc, char** argv) {
gtk_init(argc, argv);
GtkWidget* widget = gtk_label_new(abc);
g_object_ref_sink(widget);
g_object_weak_ref(G_OBJECT(widget), OnFinalizeDebug, widget);
printf(created widget, ref count %d\n, G_OBJECT(widget)-ref_count);
GtkWidget* box = gtk_vbox_new(FALSE, 0);
gtk_container_add(GTK_CONTAINER(box), widget);
printf(in container, ref count %d\n, G_OBJECT(widget)-ref_count);
gtk_widget_destroy(box);
printf(destroyed container %d\n, G_OBJECT(widget)-ref_count);
printf(destroying last ref %d\n, G_OBJECT(widget)-ref_count);
g_object_unref(widget);
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GWeakNotify fired earlier than expected
Hi, On Mon, Mar 16, 2009 at 12:45 PM, IdaRub ida...@gmail.com wrote: After reading the gobject code a bit more, it seems that weak references are fired on dispose, not finalize: Right, that's correct. All of the documentation I could find states that it happens during finalization, but it seems it should all say that it happens during dispose. Probably true. dispose is typically done during finalize, but can happen sooner also. dispose can happen multiple times. In my example this detail is actually very important. Doesn't look like there is a way to catch dispose without shimming the instance handler. Any ideas? You mean there's no way to catch finalize? Finalize deliberately can't be intercepted, because it raises a lot of thorny issues about reentrancy; what if the object is used or its refcount increased during finalization? So things are split into two phases, dispose() which you can get notifications about (and which can happen multiple times); and finalize which actually frees the object. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GWeakNotify fired earlier than expected
On Mon, Mar 16, 2009 at 5:51 PM, Havoc Pennington havoc.penning...@gmail.com wrote: Hi, On Mon, Mar 16, 2009 at 12:45 PM, IdaRub ida...@gmail.com wrote: After reading the gobject code a bit more, it seems that weak references are fired on dispose, not finalize: Right, that's correct. All of the documentation I could find states that it happens during finalization, but it seems it should all say that it happens during dispose. Probably true. dispose is typically done during finalize, but can happen sooner also. dispose can happen multiple times. In my example this detail is actually very important. Doesn't look like there is a way to catch dispose without shimming the instance handler. Any ideas? You mean there's no way to catch finalize? Finalize deliberately can't be intercepted, because it raises a lot of thorny issues about reentrancy; what if the object is used or its refcount increased during finalization? It would be nice if you could intercept it, the author being responsible for understanding what finalize means, and not doing anything inappropriate. I was attempting to write some ownership debugging code, basically something like leak and use-after-free detection for a few specific object. We'll catch this other ways though, so I suppose I will drop this idea. Thanks for your great reply. So things are split into two phases, dispose() which you can get notifications about (and which can happen multiple times); and finalize which actually frees the object. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-performance Priority Queue / Heap for glib
On Thu, Mar 12, 2009 at 01:56:05PM +0100, Maik Zumstrull wrote: Worked on fifth-or-so attempt, must have been a temporary server glitch. You likely have a (transparent) proxy with multiple IP addresses. Don't limit the login to your IP address when logging in. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using Pango for Batch Processing
On 02/17/2009 12:51 PM, Wouter Bolsterlee wrote: 2009-02-17 klockan 18:23 skrev Joshua Harvey: I'm interested in using Pango to set type in OpenType fonts to be saved as PNG images. I've done some googling and I can't find any examples on how to use the library or pango-view to do this without GTK. The idea is to use either pango-view or the Pango Ruby wrapper to convert text into PNGs on the fly from a linux server that's not running gtk, for use as titles in web pages. I've got pango-view installed, but when I run it I get: % pango-view -q --text hi there -o hi.png Hello Joshua, I wrote something exactly for this a while back, but never got around to publish it. I just uploaded it to Launchpad for you: Dude, just hack pango-view to do what you want. https://code.launchpad.net/~uws/+junk/render-text-to-image There's a README file telling you how to use it. Basically it's just his: $ render-text-to-image \ --font='Georgia' \ --size=48 \ --text-color='#eee' \ --background-color='#000' \ --text='Hello, world!' \ --output=hello.png It also supports transparency, margins, and some simple markup. pango-view from the just-released pango 1.24.0 does all that: $ pango-view \ --font 'Georgia 48px' \ --foreground '#eee' \ --background transparent \ --text 'Hello, world!' \ --output hello.png \ --no-display Cheers, behdad Good luck, and let me know if you have any comments! — Wouter ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Using Pango for Batch Processing
Here is yet another tool doing something like that: http://live.gnome.org/Vala/PangoCairoSample which I wrote to input some Hebrew into my non-Hebrew supporting media player. Regards, Dov 2009/3/17 Behdad Esfahbod beh...@behdad.org On 02/17/2009 12:51 PM, Wouter Bolsterlee wrote: 2009-02-17 klockan 18:23 skrev Joshua Harvey: I'm interested in using Pango to set type in OpenType fonts to be saved as PNG images. I've done some googling and I can't find any examples on how to use the library or pango-view to do this without GTK. The idea is to use either pango-view or the Pango Ruby wrapper to convert text into PNGs on the fly from a linux server that's not running gtk, for use as titles in web pages. I've got pango-view installed, but when I run it I get: % pango-view -q --text hi there -o hi.png Hello Joshua, I wrote something exactly for this a while back, but never got around to publish it. I just uploaded it to Launchpad for you: Dude, just hack pango-view to do what you want. https://code.launchpad.net/~uws/+junk/render-text-to-imagehttps://code.launchpad.net/%7Euws/+junk/render-text-to-image There's a README file telling you how to use it. Basically it's just his: $ render-text-to-image \ --font='Georgia' \ --size=48 \ --text-color='#eee' \ --background-color='#000' \ --text='Hello, world!' \ --output=hello.png It also supports transparency, margins, and some simple markup. pango-view from the just-released pango 1.24.0 does all that: $ pango-view \ --font 'Georgia 48px' \ --foreground '#eee' \ --background transparent \ --text 'Hello, world!' \ --output hello.png \ --no-display Cheers, behdad Good luck, and let me know if you have any comments! — Wouter ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Wrong Exif Id in io-jpeg.c?
Hi,
Per the Exif specification, and the comments within io-jpeg.c, the 6 byte Exif
Marker (APP1 marker) should be 0x45786966, or Exif\0\0.
But, in io-jpeg, they've defined:
#define EXIF_IDENT_STRING Exif\000\000
which in hex would be 0x457869660030 by my count.
In the code that follows, we see:
.
.
.
/* The Exif APP1 marker should contain a unique
identification string (Exif\0\0). Check for it. */
if (!memcmp (cmarker-data, EXIF_IDENT_STRING, 6)) {
exif_marker = cmarker;
}
.
.
.
So, the author of the comment alluded to the correct identification string, but
wasn't using it for the check.
Since this is still in the most recent code, I'm wondering if I'm missing
something, or if this is a bug.
thanks!
paul
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Wrong Exif Id in io-jpeg.c?
On Mon, 16 Mar 2009, Paul Stuart paul_stu...@seektech.com wrote : But, in io-jpeg, they've defined: #define EXIF_IDENT_STRING Exif\000\000 which in hex would be 0x457869660030 by my count. I'm not quite sure how you reckon that. Escaped numbers in C strings are evaluated as octal, so seeing three digits is quite normal. The compiler will regard \000 as a single zero byte. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Wrong Exif Id in io-jpeg.c?
Huh, didn't know that. Thanks! From: gtk-list-boun...@gnome.org [gtk-list-boun...@gnome.org] On Behalf Of Robert Pearce [...@bdt-home.demon.co.uk] Sent: Monday, March 16, 2009 2:29 PM To: gtk-list@gnome.org Subject: Re: Wrong Exif Id in io-jpeg.c? On Mon, 16 Mar 2009, Paul Stuart paul_stu...@seektech.com wrote : But, in io-jpeg, they've defined: #define EXIF_IDENT_STRING Exif\000\000 which in hex would be 0x457869660030 by my count. I'm not quite sure how you reckon that. Escaped numbers in C strings are evaluated as octal, so seeing three digits is quite normal. The compiler will regard \000 as a single zero byte. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Announce - First release of libchamplain's bindings
Hi, I finally released to CPAN the first release of libchamplain's bindings (Download here http://search.cpan.org/perldoc?Champlain). Libchamplain consists of a Clutter actor (a canvas) that supports numerous free map sources such as OpenStreetMap http://www.openstreetmap.org/, OpenArialMaphttp://www.openaerialmap.org/and Maps for free http://www.maps-for-free.com/. Even though I made an official release, I still have some troubles with the CPAN module and I seek some help. The C API defines the following function: ChamplainView* champlain_view_embed_get_view (ChamplainViewEmbed *embed); For a reason beyond my comprehension I can't binding this particular function. At first, the compilation of the C generated code issues this warning: xs/Gtk2ChamplainViewEmbed.c: In function 'XS_Gtk2__Champlain__ViewEmbed_get_view': xs/Gtk2ChamplainViewEmbed.c:56: warning: initialization makes pointer from integer without a cast And the unit tests fail with this error: undefined symbol: SvChamplainViewEmbed It looks like if the Gtk2/Glib helper methods don't pickup ChamplainViewEmbed as a valid GType but I don't know how to fix this. Another question, are the Perl bindings making a difference for functions that return gchar * instead of const gchar *? From my understading any function returning a gchar * should have the string freed by the invoker while a const gchar * should never be freed. Is the bindings code performing the free for me or should I do it? -- Emmanuel Rodriguez ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Announce - First release of libchamplain's bindings
Thanks for the help. I will try to fix the issues as soon as possible. On Mon, Mar 16, 2009 at 9:58 AM, Torsten Schoenfeld kaffeeti...@gmx.dewrote: Emmanuel Rodriguez wrote: I finally released to CPAN the first release of libchamplain's bindings (Download here http://search.cpan.org/perldoc?Champlain). Libchamplain consists of a Clutter actor (a canvas) that supports numerous free map sources such as OpenStreetMap http://www.openstreetmap.org/, OpenArialMaphttp://www.openaerialmap.org/and Maps for free http://www.maps-for-free.com/. A few other things that caught my eye: • gperl_croak_gerror ignores its first argument (for historical reasons), so the convention is to simply pass in NULL. I'm taking note. • You have no tests. libchamplain's API appears to be very well designed, so the wrappers are mostly trivial. But still, writing good bindings blindly, i.e. without tests, is error-prone. Don't worry I will add unit test coverage in the next days. I'm also missing a lot of documentation and some examples. I really wanted to make the code public as we where lagging behind python and C# :) Once more, thanks for the help. -- Emmanuel Rodriguez ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
RE: gktimageview on windows
This topic (and solution) was recently discussed on the camelbox mailing list. Jeffrey Hallock Data Processing Programmer WBA Market Research 2191 Defense Highway, Suite 401 Crofton, MD 21114 Phone: (607) 330-5300 x318 Fax: (607) 273-0295 [cid:image001.jpg@01C9A63C.8A708BD0] This email may contain information that is confidential or privileged. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify the sender and destroy any and all copies. Thank you. From: gtk-perl-list-boun...@gnome.org [mailto:gtk-perl-list-boun...@gnome.org] On Behalf Of Jamie Lahowetz Sent: Friday, March 13, 2009 4:30 PM To: gtk-perl-list@gnome.org Subject: gktimageview on windows How can I gt this on windows so that I can install Gtk2::Imageview? -- Jamie Ryan Lahowetz University of Nebraska - Lincoln Graduate Student - Geosciences 402.304.0766 jrl9...@huskers.unl.edumailto:jrl9...@huskers.unl.edu No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09 05:59:00 inline: image001.jpg___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: gktimageview on windows
If your talking about my post, it is still unsolved as far as I'm aware. 2009/3/16 Jeff Hallock jhall...@wbanda.com This topic (and solution) was recently discussed on the camelbox mailing list. *Jeffrey Hallock *Data Processing Programmer WBA Market Research 2191 Defense Highway, Suite 401 Crofton, MD 21114 Phone: (607) 330-5300 x318 Fax: (607) 273-0295 [image: WBA_Logo RGB] *This email may contain information that is confidential or privileged. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or any attachments is strictly prohibited. If you have received this message in error, please notify the sender and destroy any and all copies. Thank you.* -- *From:* gtk-perl-list-boun...@gnome.org [mailto: gtk-perl-list-boun...@gnome.org] *On Behalf Of *Jamie Lahowetz *Sent:* Friday, March 13, 2009 4:30 PM *To:* gtk-perl-list@gnome.org *Subject:* gktimageview on windows How can I gt this on windows so that I can install Gtk2::Imageview? -- Jamie Ryan Lahowetz University of Nebraska - Lincoln Graduate Student - Geosciences 402.304.0766 jrl9...@huskers.unl.edu No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09 05:59:00 ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list -- Jamie Ryan Lahowetz University of Nebraska - Lincoln Graduate Student - Geosciences 402.304.0766 jrl9...@huskers.unl.edu image001.jpg___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: gktimageview on windows
2009/3/13 Jamie Lahowetz jlahow...@gmail.com: How can I gt this on windows so that I can install Gtk2::Imageview? What is the sticking point - that you can't get the c library gtkimageview to compile under windows? Then you'd be better of asking the author of the c library, Björn Lindqvist bjourne ( at ) gmail.com If the c library works, but you can't get the Perl bindings going, please post the error message, but I can't promise to help, as I am not running windows. Regards Jeff ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Restoring a List View's position
Hi, 2009/3/17 Jeff Hallock jhall...@wbanda.com: Is there a reason not to actually just have different tree view widgets created? You could pack them all into a vbox - and then call show/hide on the appropriate widgets when changing views. This is how I approach this type of problem. The displaying and hiding of the widgets is seamless on my system. I had thought of that, but that doesn't scale too well if you've got a huge number of views. Plus I'd like the system to remember it's state between invocations (storing the selection set, display position etc etc to a file and then re-reading it on startup). I'm not really expecting a nice simple get_state and set_state function, but I was hoping it was possible to do that myself. MB ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Restoring a List View's position
Matthew Braid ptkp...@mdb.id.au writes: storing and restoring the tree view's current display position. I wonder if you're fighting its size_allocate, maybe it doesn't scroll properly until after the resize for a new model. (Which would be a serious misfeature, but TextView for instance does even worst stuff.) As a hack you might try scrolling (by cell or by pixels) in an idle handler lower than GTK_PRIORITY_RESIZE. I initially tried using $treeview-get_visible_range and $treeview-scroll_to_cell, but get_visible_range seems to be a little flakey on my system and often aborts with a message about some assertion failing (something != nil I think). Sounds like a bug. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Restoring a List View's position
On Mar 16, 2009, at 2:59 AM, Matthew Braid wrote:
I initially tried using $treeview-get_visible_range and
$treeview-scroll_to_cell, but get_visible_range seems to be a little
flakey on my system and often aborts with a message about some
assertion failing (something != nil I think). So after realising that
eval {} over a failed Gtk assertion just doesn't work (yay), I tried
directly manipulating the scrollbars instead.
Were you asking for the visible range after having removed the model?
On store, I do this:
$store{POS} = $list-get_vadjustment-get_value;
and on restore I:
$list-get_vadjustment-set_value($store{POS});
This doesn't error, but it also doesn't do anything - scrollbar
steadfastly stays where it is.
You may need to wait for the adjustment change to take effect. Try
setting the new scrollbar positions in an idle handler. This may
result in undesirable flicker, in which case, your next idea isn't
terribly inappropriate.
I starting looking into storing the coords of the currently visible
cells and using scroll_to_point, but now I'm dealing with screen
coordinates and that seems a bit low level for what should simply be
'scroll to this entry in the list'.
Well, if you want it to look to the user as though the view is just as
he left it, then simply scrolling a certain row onscreen may not be
sufficient. If i understand correctly, when you scroll to the list
item, it's somewhat random as to where it will be (depends on your
parameters). So, scroll to point isn't that bad of a compromise.
What is it that I'm missing?
You might try asking on gtk-app-devel-list, as this is a general gtk+
question, not restricted to perl.
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
