Re: GTK+ Windows dependancies
I would recommend *not* installing packages from other sources in your MinGW folder. I did not know. It is better to install them in the directory of Code:Blocks (my IDE)? No, that would also be mixing stuff from separate sources. I would install them in a totally separate folder. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: buildable_set_name
amol wrote: Hi, When we do gtk_buildable_set/get_name for any object created through GtkBuilder, GtkBuildable does g_object_set/get_data to return the corresponding name of object if its set/get_name are not overridden. But GtkWidget overrides set/get_name of buildable interface and does gtk_widget_set/get_name. I may create GtkWidget through GtkBuilder and after that i may set widget name accordingly (to use different styles in different cases). But when i do gtk_buildable_get_name it returns me new name which was set through widget_set_name and not through buildable_set_name. That is correct. There's only one name for the object, it can be set and accessed either by using the widget or the buildable accessors. No one except GtkAction and GtkActionGroup seems to be using buildable set/get_name. My doubt is - What is the intention for GtkWidget to override set/get functions of GtkBuildable interface. The intention of introduction the set/get_name is to be able to name the widget so you can access the ids used in the ui designer in runtime. I've used the names myself for ui testing frameworks (based upon gazpacho and libglade though), and I am sure there are other uses for them. Can we get rid of it w/o affecting any Gtk applications. It's a nice feature which are useful in some circumstances. I'd really like to keep it. Gtk+ don't have any idea about the custom Id's specified in ui file while object creation. What is achieved doing by gtk_widget_set_name with Id specified in ui file.(gtkrc and ui Creator must be always in sync for themes to be work correctly ) I am planning to get rid of overriding set/get_name of buildable in GtkWidget. Does it will have any adverse effect? I don't quite understand how this is an issue. Yes, objects created by a UI designer will be named. Yes, you will have to keep your gtkrc files in sync with these names. The problem you are having is that you have a theme depending on the name property of a widget when it shouldn't. Use the class name instead, why is that not sufficient? Johan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Does libX11 use shared memory between several clients?
On Jan 29, 2008 5:35 AM, Bin Chen [EMAIL PROTECTED] wrote: [...] I can't see any code to transfer modified display structure to the server, this API is invoked by a XIM server so obviously the register stuff need to be accessed by other process, is there any shared memory trick in libX11? Yes, but this is not one of those tricks I would think. When connecting to the X server, XOpenDisplay establishes a connection and returns a locally allocated Display structure to be used for all your api calls. All commands to the X server are sent and queued so to speak on the display. I dont know much about the guts of XIM but it looks like _XRegisterFilterByType doesnt need to tell the server anything... only needs to tell Xlib locally how to handle input when it comes from the X server. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ Windows dependancies
I looked the gimp install directory and I found this files : - bin/*.dll - etc/gtk-2.0/gdk-pixbuf.loaders - etc/gtk-2.0/gtk.immodules - etc/gtk-2.0/gtkrc - etc/pango/pango.aliases - etc/pango/pango.modules - lib/gtk-2.0/2.10.0/engines/* - lib/gtk-2.0/2.10.0/immodules/* - lib/gtk-2.0/2.10.0/loaders/* - lib/locale/* - share/themes/* The files are missing from the GTK+-2.12.6 binaries archive : - etc/gtk-2.0/gtkrc (optionnal) - lib/gtk-2.0/2.10.0/loaders/* (now - for the moment ? - include in dll) - lib/locale/* (move in share/) It's better ? -- Nicolas Joseph Responsable de la rubrique GTK+ de developpez.com http://nicolasj.developpez.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: What's wrong with the docs?
I feel the same way. I can't think of an example off of the top of my head, but I swear there have been things that the only way I figured them out was by reading the python documentation and sort of guessing at the C API. Yes I look at the reference docs on gtk.org and gnome.org. Date: Wed, 30 Jan 2008 17:27:33 -0200 From: John Coppens [EMAIL PROTECTED] Subject: What's wrong with the docs? To: gtk-app-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Hello all... There must be something terribly wrong somewhere, when I try to find documentation on operation with GTK+ or GDK elements, I always seem to get _much_ more documentation from the Python/Perl libraries than from the actual C interface. I'm sure others noticed the same trend. So, why is this? - Are the original (C/C++) docs really so scarse they don't appear at the top of of the list? or... - Is something in the google algorithms preferencial to anything but C? - Are those docs maybe declared unaccessible by the spider engines? (by robots.txt or so) - Or are those alternative languages just much more popular than C? Which makes this question pop up: Wouldn't it be interesting/practical to have _common_ documentation. Say, GtkWidget is used in Python like this, in C like this, etc.? I could even serve as an educational tool to compare languages. Just idle thoughts... John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ Windows dependancies
On Thu, 31 Jan 2008, Tor Lillqvist wrote: In particular, the loaders directory is now gone due to Tor's decision to build a monolithic gdkpixbuf library for GTK on Windows, with all the loaders pre-embedded. Personally, I wish he'd reconsider that. OK, you are the second person to oppose this change (if I recall correctly), so from the next build I will return to not including the loaders in the gdk-pixbuf DLL. Thank you. It's not a big deal, but I'm a thrifty Scot, and it pains me to think of people having to install jpeg and tiff libraries that'll just take up disk space and never get used. (Although that's small beer compared to be volume of useless cr*p installed on most Windows machines.) Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Alpha support in GTK-DFB
Hi All, We are working on an environment that has multiple Graphics and Video Layers were the Graphics layer is set with ARGB color format . We have got GTK-DFB running on this platform. We are trying to address a requirement where we have an graphics application and the video application running simultaneously . The video layer physically sits below the graphics layer. So we need to make the graphics application transparent(i.e alpha value to zero ) so that we can view the content being presented on the video plane. Looking at the GdkColor structure it does not take any parameters for computing the Alpha value. However we find that DFB has support for manipulating the alpha values. So we are stuck with this problem as we cannot set the Alpha values to the graphics layers in GTK. It would be of great help if you could throw some light on how GTK abstracts/handles the alpha values . Regards, Jerin The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Issue in DirectFB-GTK Port Event dispatch mechanism
Hi All,
We are currently involved in bringing up a multi-threaded graphics
abstraction layer on top of GTK-DFB. We are facing issues with the event
dispatch mechanism of GTK-DFB. On further analysis, we find that the
GTK-X11's event dispatch mechanism is a bit different from that of GTK-DFB.
The GTK-X11's event dispatch is thread safe i.e Please find below the
GTK-X11's event dispatch function code.
static gboolean
gdk_event_dispatch (GSource*source,
GSourceFunc callback,
gpointeruser_data)
{
GdkDisplay *display = ((GdkDisplaySource*)source)-display;
GdkEvent *event;
GDK_THREADS_ENTER ();--
_gdk_events_queue (display);
event = _gdk_event_unqueue (display);
if (event)
{
if (_gdk_event_func)
(*_gdk_event_func) (event, _gdk_event_data);
gdk_event_free (event);
}
GDK_THREADS_LEAVE ();---
return TRUE;
}
In comparison to this we find that GTK-DFB's event dispatch code is not
thread safe.
static void
dfb_events_dispatch (void)
{
GdkDisplay *display = gdk_display_get_default ();
GdkEvent *event;
THREAD PROTECTION MISSING--
while ((event = _gdk_event_unqueue (display)) != NULL)
{
if (_gdk_event_func)
(*_gdk_event_func) (event, _gdk_event_data);
gdk_event_free (event);
}
THREAD PROTECTION MISSING--
}
It would be of great help for us if someone could throw some light on the
queries below.
1. Was this implementation of GTK-DFB's event dispatching made not thread
safe? If so what is the reason behind it?
2. How is the application expected to be designed for the GTK-DFB
environment?
3. Is it advisable to port a multi-threaded graphics abstraction layer on
top of GTK-DFB?
Regards,
Jerin
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments contained in it.
Contact your Administrator for further information.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.15.3 released
Hi All,
Iam using glib api's (g_convert)to convert the UTF-8 to ISO-8859-1..
but it displayed error as Coversion from UTF-8 to ISO-8859-1 is not supported
For me its working fine in linux, but when i port my code in embedded..this
g_convert fails and displays error..
Is anybody knows how to solve this problem..
Regards
Pavan Reddy.
On Tue, 22 Jan 2008 Matthias Clasen wrote :
GLib 2.15.3 is now available for download at:
http://ftp.gnome.org/pub/GNOME/sources/glib/2.15/
glib-2.15.3.tar.bz2 md5sum: 83aa09c6126e3111c9f371c1396324e7
glib-2.15.3.tar.gz md5sum: c6e6310e1a8d2eb85e043cc9408486c6
This is the fourth development release leading up to GLib 2.16.
Notes:
* This is unstable development release. While it has had
a bit of testing, there are certainly plenty of bugs
remaining to be found. This release should not be used
in production.
* Installing this version will overwrite your existing
copy of GLib 2.14. If you have problems, you'll need
to reinstall GLib 2.14.
* GLib 2.16 will be source and binary compatible with
the GLib 2.14 series. The new API in GLib should be
stable at this point; we are still expecting to do
some minor API additions in GIO, so there may be
incompatibilities between this release and the final
2.16 release.
* Bugs should be reported to http://bugzilla.gnome.org.
About GLib
==
GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.
More information about GLib is available at:
http://www.gtk.org/
An installation guide for the GTK+ libraries, including GLib, can
be found at:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html
Overview of Changes from GLib 2.15.2 to GLib 2.15.3
===
* GChecksum:
- g_checksum_update can accept nul-terminated strings
- The MD5 implementation works correctly on buffers
that are longer than 64 bytes
* GIO:
- Don't include a copy of the inotify headers, rely on system headers
- g_file_find_enclosing_mount has an async variant now
- Reduntant seek API on file streams has been removed
* Bugs fixed:
508602 gmemory{in|out}putstream.c: unknown pointer size
508771 There is no g_file_test/exists() for GFile
508773 g_uri_escape_string() documentation unclear.
509465 AM_PATH_GLIB_2_0 doesn't support gio
509626 async functions: Document allowed NULL callback?
509990 GSeekable documentation unclear
510448 No inotify support on ARM or SH5
510855 g_checksum_update(): Take -1 for length.
* Updated translations:
Basque (eu)
Marathi (mr)
Swedish (sv)
Ukrainian (uk)
A list of all fixed bugs can be found here:
http://bugzilla.gnome.org/buglist.cgi?bug_id=508773,509465,510855,508602,509626,508771,510448,509990
Thanks to all contributors
Dan Winship
Alexander Larsson
Murray Cumming
Tim Janik
Kazuki IWAMOTO
January 21, 2008
Matthias Clasen
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Hi, Markku,
Thanks a lot for your help.
I did some further investigation on this issue. I have two questions on
this issue:
1. The object created by gtk_invisible_new() is not floating.
Here is a snippet from gtk+-2.12.5/tests/testselection.c
init_atoms();
selection_widget = gtk_invisible_new ();
* m = GTK_OBJECT_FLOATING(selection_widget); //***
dialog = gtk_dialog_new ();
gtk_widget_set_name (dialog, Test Input);
The black line (marked with **) is added by me.
When I run testselection, m is set to 0 instead of 1. Which means the
selection_widget is not floating.
right or I used a wrong macro?
2. How to release an object created by gtk_invisible_new()?
Look at following snippets:
void InitWidget() {
mWidget = gtk_invisible_new();
*gtk_object_ref(GTK_OBJECT(mWidget)); //***
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
mStyle = gtk_widget_get_style(mWidget);
}
nsLookAndFeel::~nsLookAndFeel()
{
// gtk_widget_destroy(mWidget);
gtk_widget_unref(mWidget);
}
If I comment out the black line (marked with **), the mWidget
reference count is 1 as expected,
but when unref it in nsLookAndFeel::~nsLookAndFeel, thunderbird will
crash.
It looks like that I can't us gtk_widget_unref() on the object returned
by gkt_invisible_new().
So my question is how to free an object returned by gtk_invisible_new()?
Thanks a lot
Brian
Markku Vire wrote:
Hi,
The reference that is returned by gtk_invisible_new is not owned by the
caller. If one tries to unref it, it's an immediate memory corruption.
When a toplevel widget is concerned, the things go like the following:
* New floating GtkWidget is created (not owned by anyone).
* GTK library takes ownership of the toplevel (calling
g_object_ref_sink). Floating reference is converted to normal one.
* Widget pointer is returned (refcount = 1, owner = gtk).
So, in the code you attached gtk_object_ref increases the reference
count to 2, gtk_object_sink does nothing (since it not floating any
more).
Later gtk_widget_unref decreases refcount back to 1, but there is still
one reference left (owned by gtk). Trying to remove it by g_object_unref
is a bug (as you noticed). The way to ask GTK to release the last
reference is to call gtk_widget_destroy.
If you are just interested about the GtkStyle object, you could try
using gtk_rc_get_style_by_paths for example?
Cheers,
-Markku-
On Fri, 2008-01-11 at 16:53 +0800, Brian Lu wrote:
Thanks a lot for your explanation. But look at following snippet from
firefox latest code base:
void InitWidget() {
mWidget = gtk_invisible_new();
gtk_object_ref(GTK_OBJECT(mWidget));
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
mStyle = gtk_widget_get_style(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.h#77
and
nsLookAndFeel::~nsLookAndFeel()
{
// gtk_widget_destroy(mWidget);
gtk_widget_unref(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.cpp#78
I find mWidget is leaked (detected by using libumem.so provided by solaris).
I don't understand why calling gtk_object_ref() to increase mWidget
reference count.
This causes mWidget's reference count to be 2 and gtk_widget_unref() in
deconstructor decreases it to 1.
Thanks
Brian
Markku Vire wrote:
Hi,
The caller doesn't own the returned reference in case of any gtk_*_new
functions, but the results are floating references (they are removed
once somebody calls gtk_object_sink). This is different from normal
GObjects. So, unreffing the returned value causes practically a double
free.
gtk_widget_destroy in turn runs dispose, ie. asks widget to drop
references to other widgets. Dropping external references usually causes
somebody else to drop the last reference to your widget, so it
efectively gets destroyed. In case of toplevels some global window list
is holding the reference.
Calling gtk_widget_destroy without taking ownership a a widget is
usually a bug that causes a memory leak, but this is not the case here,
since we are talking about a toplevel.
Cheers,
-Markku-
On Wed, 2008-01-09 at 17:39 +0800, Brian Lu wrote:
Hi, experts,
I found following codes will crash in gnome 2.21 environment:
...
GtkWidget *foo = gtk_invisible_new();
gtk_widget_unref(foo);
...
But it works well if gtk_widget_unref() is replaced with
gtk_widget_destroy().
Does that mean that we can't use gtk_widget_unref() on such object and
we can only
use gtk_widget_destroy() to release it?
Thanks
Brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: More patches
Hi, On Thu, 2008-01-31 at 06:06 +0100, Denis Oliver Kropp wrote: gdk-directfb-cleanups.patch Applied. gdk-directfb-copy-to-image.patch Applied. gtk-add-glib-libs-to-executables.patch This was a scary build issue. I installed glib, pango and gtk, but kept using my system's atk. When gtk-query-immodules-2.0 was built it failed to link as it missed a lot of new functions in the glib, e.g. glib_checksum_new(). I found out that it somehow tried to link against my system's glib, though using pkg-config the correct new glib was returned. Not sure if it's libstuhl or just the order on the linker command line, but adding $(GLIB_LIBS) explicitly did the trick. I did not apply this one as it affects other backends as well. Will leave it up to the GTK+ developers to decide if this is the right thing to do or not... Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: More patches
Sven Neumann wrote: Hi, On Thu, 2008-01-31 at 06:06 +0100, Denis Oliver Kropp wrote: gdk-directfb-cleanups.patch Applied. gdk-directfb-copy-to-image.patch Applied. gtk-add-glib-libs-to-executables.patch This was a scary build issue. I installed glib, pango and gtk, but kept using my system's atk. When gtk-query-immodules-2.0 was built it failed to link as it missed a lot of new functions in the glib, e.g. glib_checksum_new(). I found out that it somehow tried to link against my system's glib, though using pkg-config the correct new glib was returned. Not sure if it's libstuhl or just the order on the linker command line, but adding $(GLIB_LIBS) explicitly did the trick. I did not apply this one as it affects other backends as well. Will leave it up to the GTK+ developers to decide if this is the right thing to do or not... Ok, thanks! I think linking against GLIB_LIBS could only be a problem if the version found by pkg-config if older than the one used by atk, pango etc. For me it was the other way around which makes more sense. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: More patches
Yevgen Muntyan wrote: Denis Oliver Kropp wrote: Sven Neumann wrote: On Thu, 2008-01-31 at 06:06 +0100, Denis Oliver Kropp wrote: gtk-add-glib-libs-to-executables.patch This was a scary build issue. I installed glib, pango and gtk, but kept using my system's atk. When gtk-query-immodules-2.0 was built it failed to link as it missed a lot of new functions in the glib, e.g. glib_checksum_new(). I found out that it somehow tried to link against my system's glib, though using pkg-config the correct new glib was returned. Not sure if it's libstuhl or just the order on the linker command line, but adding $(GLIB_LIBS) explicitly did the trick. I did not apply this one as it affects other backends as well. Will leave it up to the GTK+ developers to decide if this is the right thing to do or not... Ok, thanks! I think linking against GLIB_LIBS could only be a problem if the version found by pkg-config if older than the one used by atk, pango etc. For me it was the other way around which makes more sense. 'rm system_prefix/lib/*.la' [1] and try again? This issue isn't directfb-specific. I'm wondering if an .la file ever did any good to me... not to mention the shell script that takes longer than gcc itself on many platforms. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Tue, 2007-12-04 at 08:31 +0200, Tor Lillqvist wrote: GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */ [...] GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */ [...] The sequences you list are exactly of the straightforward kind that in my opinion can and should be handled algorithmically. I.e. a dead accent followed by a letter can be mapped to the corresponding precomposed character without an explicit table. I have a patch in bug #321896 that implements such an algorithm (and which would handle your cases, too.) Basically it's waiting for a second opinion from the GTK+ maintainers. I made two small changes to the patch (now at #321896): 1. if diacritic marks belong to the same combining class, normalisation does not reorder them, so we need to try out all permutations then attempt to normalise again. 2. added a check if the compose sequence is overlong; otherwise one can type up too many dead keys, and overflow the buffer. I added a script at #321896 as well that parses UnicodeData.txt, checks and counts all characters that can be taken care of by the algorithmic function. They are about 1000 of them. Simos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
