Re: Why doesn't DataInputStream implement Seekable ?
Hi, this topic was about one year ago. Is there any progress on a Seekable BufferedInputStream since then? Is it possible to simulate a seek by immediately calling g_buffered_input_stream_fill after g_seekable_seek on the underlying FileStream? Regards, Yu > n Mon, 2008-12-08 at 22:37 +0100, Martin Olsson wrote: > > Hi, > > > > I'm wondering if there was any particular design rationale behind GLib not > > implementing the Seekable interface on the class DataInputStream? > > > > If there is no particular reason, then I would like to file a feature > > request > > to get Seekable into DataInputStream or one of it's base classes. > > > > I'm parsing a big file and I would like to seek to one specific location, > > read some data and then seek to a second location and read some data from > > there as well. As a workaround I tried to seek on the underlying > > FileInputStream > > that I passed as a parameter to the DataInputStream constructor but this > > hack didn't work reliably. > > The reason that is not reliable is that GDataInputStream inherits from > GBufferedInputStream, and the buffer it has causes issues with the seek. > > However, i don't think there is an inherent problem with implementing > seek in GBufferedInputStream (if the underlying stream supports it). > Would be a nice addition. > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Vala] Wrapping Errors with g_prefix_error?
On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote: > On Thu, Aug 20, 2009 at 22:09:21 -0400, Yu Feng wrote: > > GError doesn't support error wrapping as Java does. Is GLib is purposely > > avoiding it? > > If not, it will become a useful feature as the number of libraries that > > uses GError grows, as the feature has already been proved useful in > > Java, (indicated in this article): > > > > http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html > > Actually, in my opinion that article nicely explains, why you do *not* need > to have the original error information there. > > article> The main reason one would use exception wrapping is to prevent the > article> code further up the call stack from having to know about every > article> possible exception in the system. > > Well, so the code further up the call stack is not going to look at the > inner exception anyway except to print it to the operator, right? But for > that, it's enough to embed the wrapped error's message into the wrapping > error message. The error code is not relevant. > I buy your point. In an language like Java, the error(Exception) carries more than a message and a code. It also includes a source code reference therefore it make sense to save the cause as an data member. Nevertheless in the GObject case, because the error only carries an code, and a message, there is no need to wrap the low level errors. g_prefix_error would be sufficient as an substitute of 'wrapping'. How can we invoke this function in vala though? > By the way, you should be suggesting things like this on the Gtk list, not > here. I thought it was a GObject feature which was highly relevant to Vala. Yu > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Wrapping Errors
Dear List,
GError doesn't support error wrapping as Java does. Is GLib is purposely
avoiding it?
If not, it will become a useful feature as the number of libraries that
uses GError grows, as the feature has already been proved useful in
Java, (indicated in this article):
http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html
GError will need an extra field for chaining up the causes. gerror.h
doesn't have any preserved bytes for an extra field. However, because
GError is always accessed by pointers and no GLib program is supposed to
statically allocate memory for GError, it should be safe to append an
field to the internal structure of GError while keeping the ABI
compatible.
Two new proposed functions:
GError * g_error_new_with_cause(GQuark domain, gint code, GError ** cause,
const char* format, );
Returns an new GError with `cause' as its cause. `*cause' is set to NULL.
void g_set_error_with_cause(GError ** error, GQuark domain, gint code, GError
** cause, const char * format, ...);
sets *error to an error caused by *cause if error is not NULL. if error is
NULL, free *cause.
g_error_free should be modified so that all the chained up errors are freed.
Example:
my_function(GError ** error) {
GError * tmp_error = NULL;
some_io_function(, &tmp_error);
if(tmp_error != NULL) {
g_set_error_with_cause(error, MY_ERROR, MY_ERROR_NUMBER1, &tmp_error,
"some random error caused by some_io_function");
return;
}
/** do something else **/
}
Regards,
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libyaml-glib: YAML and GObject
Dear list(s),
I have been playing around GLib and libyaml with vala for a couple of
months. While I don't see a clear future of the code, I would like to
post a link to my code in case it will be useful to others.
The library is written in VALA, but one can write applications and link
against it in the same way as against other traditional GLib libraries.
This library provides the geometry object builder for a simulation
program I was writing at IU. It includes two parts:
a) a native representation of YAML nodes in GLib data type.
GList <-> Sequence
GHashTable <-> Mapping
gchar * <-> Scalar
However, as the fundamental containers in GLib are type-unaware,
decorators(is it the correct name?) are added to store the
type-information, as well as extra document stream information.
GYAMLNodeSequence <-> Sequence
GYAMLNodeMapping <-> Mapping
GYAMLNodeScalar <-> Scalar
GYAMLNodeAnchor <-> Anchor
The corresponding data structures in libyaml are not used, as they do
not work nicely with vala.
this part is based on the yaml wrapper in gore (gore @ sourceforge)[2];
b) an object builder that builds GObject from YAML,
The builder scans the YAML tree created by GYAMLParser, and builds
GYAMLBuildable objects from the document tree. GYAMLBuildable is
designed in such a way that it is compatible with GtkBuildable unless
the API is XML/YAML specific; nevertheless so far the interface is not
interchangeable with GtkBuildable, because one of the changes needed in
vala 'doen't make sense'.[1]
A short installation guide is at
http://github.com/fengy-research/libyaml-glib
The code can be obtained via
git clone git://github.com/fengy-research/libyaml-glib.git
The draft documentation(compiled by valadoc) is temporarily available at
http://www.does-exist.info/yaml-glib/Documentation/libyaml-glib-1.0/index.htm
More techy details are discussed under GYAMLBuilder, GYAMLBuildable, and
GYAMLDocument.
The attachment is a program that converts the standard invoice example
into GObject objects. After the library is properly installed, compile
with
valac --pkg libyaml-glib-1.0 libyaml-glib-builder.vala -X -export-dynamic
Your feedback is welcomed.
Regards,
Yu
[1] http://bugzilla.gnome.org/show_bug.cgi?id=584400
[2]
http://gore.svn.sourceforge.net/viewvc/gore/trunk/server/yaml_helper.c
http://gore.svn.sourceforge.net/viewvc/gore/trunk/server/libyaml-wrapper.vala
using GLib.YAML;
public class Invoice: GLib.Object, Buildable {
public int invoice {get; set;}
public string date {get; set;}
public Contact bill_to {get; set;}
public Contact ship_to {get; set;}
public double tax {get; set;}
public double total {get; set;}
public string comments {get; set;}
private List products;
public void add_child(Builder builder, GLib.Object child, string? type) throws GLib.Error {
products.prepend((Product)child);
}
public Type get_child_type (Builder builder, string tag) {
if(tag == "product") {
return typeof(Product);
}
return Type.INVALID;
}
public string summary(StringBuilder? sb = null) {
StringBuilder sb_ref = null;
if(sb == null) {
sb_ref = new StringBuilder("");
sb = sb_ref;
}
sb.append_printf("%d\n", invoice);
sb.append_printf("%s\n", date);
sb.append_printf("%g\n", tax);
sb.append_printf("%g\n", total);
sb.append_printf("%s\n", comments);
foreach(var p in products) {
sb.append_printf("%s %d %s %g\n", p.sku, p.quantity, p.description, p.price);
}
sb.append_printf("%s %s \n %s %s %s %s\n",
bill_to.given,
bill_to.family,
bill_to.address.lines,
bill_to.address.city,
bill_to.address.state,
bill_to.address.postal);
sb.append_printf("%s %s \n %s %s %s %s\n",
ship_to.given,
ship_to.family,
ship_to.address.lines,
ship_to.address.city,
ship_to.address.state,
ship_to.address.postal);
return sb.str;
}
}
public class Product : GLib.Object, Buildable {
public string sku {get; set;}
public int quantity {get; set;}
public string description {get; set;}
public double price {get; set;}
}
public class Contact : GLib.Object, Buildable {
public string given {get; set;}
public string family {get; set;}
public Address address {get; set;}
}
public class Address : Object, Buildable {
public string lines {get; set;}
public string city {get; set;}
public string state {get; set;}
public string postal {get; set;}
}
const string buffer =
"""
# This is the YAML 1.1 example. The YAML 1.2 example fails.
--- !Invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city: Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity: 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity: 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments:
La
Re: global menubars in GTK+
On Mon, 2009-05-25 at 20:17 +0800, Davyd Madeley wrote: > On Mon, 2009-05-25 at 22:31 +1200, John Stowers wrote: > > > Did you take a look at gnome2-globalmenu [1], I use it daily > > and find it works exceptionally well, with no code changes to Gtk+ apps. > > I did. > > I think the idea of guessing the menubar that you wish to make the > global menu by walking the widget tree and pulling it out is hacky. > > It's going to break applications with non-standard menubar packings. > It's going to break on applications with multiple menubars. It suffers > from the same basic problems as the IGE-MacOSX stuff - in that it is > creating a proxy from GtkWidgets (which could break all kinds of > assumptions) rather than using GtkActions. > > I don't think it's a long term solution to the problem. Neither do I. Did you take a look at GtkUIBuilder? I think it is a very good starting for the solution you proposed. An alternative or an extension to GtkUIBuilder that builds a native menubar instead of a GTK Menu Bar would be it. > > OTOH, if GTK+ had API for this, a backend could be written to power the > gnome2-globalmenu applet from this API. However, the reason why GGM is using GtkWidgets in favor of GtkActions is that there are plenty of programs who don't build the menus with GtkActions at all. 'It's going to break applications that do not use this API.' Otherwise using GtkUIBuilder is much less effort than the current approach. - Yu > > > [1] http://code.google.com/p/gnome2-globalmenu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkPlug not chaining up to GtkWindow's keys_changed handler?
Hi Federico, On Wed, 2009-04-22 at 21:20 -0500, Federico Mena Quintero wrote: > On Sat, 2009-04-18 at 17:22 -0400, Yu Feng wrote: > > > In GTK 2.14.4, GtkPlug does not chain up to GtkWindow's keys_changed > > handler. (gtkplug.c:1043 and gtkwindow.c:7937) > > > > The effect is that the key hash in the 'gtk-window-key-hash' data member > > of the window is not updated whenever the mnemonic keys are changed, and > > any newly associated mnemonic keys are ignored. > > > > Are there any particular reasons for this behavior or it is an honest > > typo? > > It could be a typo/oversight/etc. This is not the first time that > GtkPlug has had a bug due to failing to "sync up" with GtkWindow. > > Do you have a little reproducible test case for this problem? > Sorry I don't have a 'little' test case. I discovered the problem when writing a panel applet with a MenuBar in it(Global Menu) The problem can be reproduced by modifying the mnemonic keys of the menu items. If it is needed I can come up with one but it may take some time. Yu > Federico > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkPlug not chaining up to GtkWindow's keys_changed handler?
Dear list, In GTK 2.14.4, GtkPlug does not chain up to GtkWindow's keys_changed handler. (gtkplug.c:1043 and gtkwindow.c:7937) The effect is that the key hash in the 'gtk-window-key-hash' data member of the window is not updated whenever the mnemonic keys are changed, and any newly associated mnemonic keys are ignored. Are there any particular reasons for this behavior or it is an honest typo? Regards, Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Apparent deficiency in GtkBuilder signal connections and grouped widgets
Check out the first(widget pointer) parameter in the event handler. gtk_widget_get_name(widget) will give you the name of the widget. Yu On Sun, 2009-04-05 at 10:07 -0600, Michael Torrie wrote: > I am writing to the devel list after first posting to the regular list > about using GtkBuilder and grouped widgets like a group of radio > buttons. The only post that really spoke to my problem mentioned that > there really isn't a way with GtkBuilder to deal nicely with groups of > widgets like radio buttons in a group way. There's no easy way to have > one callback for an event for the whole group of radio buttons. > > I can easy do this by connecting callbacks manually and supplying a > "user-data" parameter to specify an arbitrary id to differentiate the > radio buttons. If I use the user-data field with GtkBuilder it tries to > use that to look up a widget in the tree, which isn't what is wanted. > > This seems like an obvious deficiency in GtkBuilder. As GtkBuilder is > being pushed as a central component of Gtk, I ask if this deficiency > will be addressed in some manner in the API, or if it already is, how > should programmers developing in GTK connect the events from grouped > widgets in a sane way? > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkLabel: angle and ellipsize are incompatible?
Dear List,
I noticed this line in gtklabel.c:
gtk_label_ensure_layout:
...
if (angle != 0.0 && !label->wrap && !label->ellipsize && !
label->select_info)
{
/* We rotate the standard singleton PangoContext for the widget,
* depending on the fact that it's meant pretty much exclusively
* for our use.
*/
...
Why is ellipsize incompatible with angle? There at least won't be any
problems when the angle is 90, 180, 270, will there?
Regards,
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Regards, Yu On Mon, 2009-01-19 at 20:07 -0600, Federico Mena Quintero wrote: > Fedora has a (currently unapplied?) patch in its gtk2 package which > changes GtkEntry's invisible-char defualt from "*" to "•" (Unicode > 0x2022 BULLET). > > openSUSE has a patch that changes the invisible-char to "●" (Unicode > 0x25CF BLACK CIRCLE). > > I'm arguing for committing openSUSE's patch based on the following > unquestionable criteria: > > * The circle is bigger. This goes hand in hand with Christopher > Alexander's "Nature of Order" principles of Strong Centers, Good Shape, > and Contrast. > > * The circle is fatter. We should have a no-discrimination policy > against Unicode glyphs with an above-average body mass index, I mean, > the ink-to-area ratio. > > * The circle is BIGGER. Size does matter, you know. > > * I started the bikeshed. > > Really, it doesn't make sense to carry around patches like these :) OK > to commit? > > Federico > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?
On Sat, 2009-01-10 at 14:30 +0200, Andrew W. Nosenko wrote: > On Sat, Jan 10, 2009 at 2:06 PM, Brian J. Tarricone wrote: > > On Sat, 10 Jan 2009 13:42:31 +0200 Andrew W. Nosenko wrote: > > > >> First at all, could you provide any real-world example, where min/max > >> restriction on GParamSpec could be usefull? The reason is simple: > >> when validation fails, the application has no way to know about it > >> and, therefore, to do anything usefull. There just no interface for > >> such things, like "validation-fails-callback". As consequence, any > >> validation should be done at the application level, before bringing > >> GObject/GParamSpec/GValue/etc machinery into game. Hence, I hard to > >> imagine any usefull example of using restrcted GParamSpecs... > > > > Then you really just aren't imagining hard enough. If you look at the > > gdk/gtk sources, there are quite a few GObject properties that use > > GParamSpecDouble that restricts the min/max value a property can have. > > For example, think of a progress bar that uses a double to indicate > > the percent full: 0.0 is 0%, 1.0 is 100%. Any value outside that > > range is invalid. > > I know about that. But how it usefull? What you can to do with it? > Yes, for progressbar it resulted just for some different rendering > that has nothing but visual effect. You could to don't use restricted > paramespec but just silently CLAMP(), for example, without any harm. > Even if you do not do any validation, the result would be the same: > just a visual effects, possible ugly, but have nothing with the core > functionality. > > In contrast, I say about about core functionality (application's > results, not application's appearance). If you calculate distance > based on coordinates, for example, would you entrust validation of the > coords (latitude/longitude) to the something (GValue/GparamSpec in out > case) that silently alters value or brings it into undefined (in sense > implementation-defined and undocumented) state? > > Please understand, while GObject was born from GTK+, I would to see it > as on generic-purpose C-based object system, not as on GTK+-oriented > underlying library... And tasks that should be able to be solved > using GObjects are far more wider than just GUI and presentation... > May be it just my dreams that has nothing with Glib developer's > targets, but... Can I dream? :-) > My mail is off the topic. It is about applying Gobject in physic research: I am not sure if the GTK people intend to see a proliferation of GObject to happen at all. But GObject can definitely do more than GTK. I have been trying to incorporate several physics research packages with tools built on top of GLib, and also been writing a physics package with GObject; so far so good. In some sense, the dynamical type system in GObject is exactly what the physics people struggled and failed to build with C++/Java and their poor understanding of software. The huge overhead for creating Classes in GObject also tend to reduce the number of classes therefore leads to carefully thought, and clearer frameworks. Unfortunately, most physics people don't even know GObject at all; neither do I have sufficient influence to advertise GObject in the community. Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?
Logically this doesn't work, because G_MAXDOUBLE is smaller than Inf and NaN is not part of the ordered double numbers. Why can't one use -Inf and Inf to create GParamSpec? Yu On Sat, 2009-01-10 at 12:17 -0500, Andrew Paprocki wrote: > On Sat, Jan 10, 2009 at 7:06 AM, Brian J. Tarricone wrote: > > But I don't disagree that NaN or +/- inf should be allowed, assuming > > a restriction such as the above isn't in place for the particular > > instance of GParamSpecDouble. > > This brings up an interesting question.. if the GParamSpecDouble > minimum/maximum are -G_MAXDOUBLE/G_MAXDOUBLE, should NaN/Inf be > allowed, otherwise not? That would allow a patch to add the > functionality without adding new fields to the GParamSpecDouble > structure. What does everyone think? Explicit, modifying the > structure, or implicit based upon the existing values? > > -Andrew > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
screen-changed signal emitted before constructor is invoked?
Dear developers, I created an Widget and overrode the constructor of the GObject interface to initialize private members. Then I listened to screen-changed signal of the widget. in the signal handler a private member was accessed; The private member was not properly initialized when the first screen_changed signal is emitted. Later on I added debug messages in the constructor and screen-changed signal handler; it turns out that the handler was invoked *before* the constructor. However, the construction of the GObject is not yet finished before the constructor function is invoked (at least to my understanding); Should this behavior be a bug? This is a serious interference with VALA where there is no way to specify the instance _init functions. I am also ccing to vala-list to see if the vala gurus can advice with a clean workaround. Thanks, Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
Hi, If GtkRange were a gtk container perhaps using gtk_container_xxx with child_properties will be an alternative. GtkContainer also has bettern granularity - the programmers can modify/remove each marker individually. Unfortunately it isn't a Container. Regards, Yu On Tue, 2009-01-06 at 00:31 -0500, Matthias Clasen wrote: > Over the Christmas vacation, I spent a day adding marks to scales. The > motivation for this came from the new sound preferences capplet, which > uses a GtkHScale for balance control. Jon did a nice job of adding > Left/Right labels (see the screenshot), but what is really missing > here is an easy to hit midpoint. > > So I wrote a patch for GtkRange and GtkScale that allows to add > 'marks' to certain values. When dragging the scale over one of these > marked values, there is a little resistance that makes it easy to > select the exact value. The api also allows to > show a label or icon next to the mark. > http://bugzilla.gnome.org/attachment.cgi?id=125318&action=view shows > the > various possibilities. > > I'd like to get this functionality into 2.16, if nobody objects, but > I'm not entirely sure that I have managed to come up with the best > possible api for this yet: > > > +void gtk_scale_add_mark (GtkScale*scale, > +gdouble value, > +GtkPositionType position); > +void gtk_scale_add_mark_text (GtkScale*scale, > +gdouble value, > +GtkPositionType position, > +const gchar *markup); > +void gtk_scale_add_mark_icon (GtkScale*scale, > +gdouble value, > +GtkPositionType position, > +GIcon *icon); > +void gtk_scale_clear_marks(GtkScale *scale); > > > Feedback appreciated, Matthias > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
old_parent parameter in parent-set.
Hi devels,
I was receiving a g_critical at g_signal_emit complaining about
ref_count = 0;
I looked into this and located the problem in gtktoolbar.c
gtk_widget_set_parent() doesn't add a reference to the parent, therefore
the child doesn't hold any reference to the parent(perhaps this is to
break the circular reference). If for some reason the parent is already
disposed before gtk_widget_unparent is called; eg, in this snippet from
gtktoolbar.c
---
static void
gtk_toolbar_finalize (GObject *object)
{
GList *list;
GtkToolbar *toolbar = GTK_TOOLBAR (object);
GtkToolbarPrivate *priv = GTK_TOOLBAR_GET_PRIVATE (toolbar);
if (toolbar->tooltips)
g_object_unref (toolbar->tooltips);
if (priv->arrow_button)
gtk_widget_unparent (priv->arrow_button);
for (list = priv->content; list != NULL; list = list->next)
{
ToolbarContent *content = list->data;
toolbar_content_free (content);
}
g_list_free (priv->content);
g_list_free (toolbar->children);
--
the signal pre emission code will give that g_critical error message.
This is not likely to happen since normally there is no signal
handler/emission hooks connected to parent_set signal; and the
skip_emission trick in gsignal.c will totally skip the signal emission.
But theoretically this is a flaw; and if someone adds a emission hook it
starts to kick your ass.
A way to fix would be unparenting children in dispose, where the parent
is still not disposed. and perhaps also document in 'parent-set' signal
and 'gtk_widget_unparent' to tell other widget writers that they should
unparent the widget when the parent is still alive.
I did a grep on Gtk 2.14.4 code:
# grep -A 100 'gtk.*_finalize' *.c|grep unparent
gtkclist.c- /* Since we don't have a _remove method, unparent the children
gtkclist.c- * unparent) The destroy will happen when the refcount drops
gtkclist.c- gtk_widget_unparent (clist->column[i].button);
gtktable.c- gtk_widget_unparent (widget);
gtktexttagtable.c- /* We don't want to emit the remove signal here; so we just
unparent
gtktoolbar.c-gtk_widget_unparent (priv->arrow_button);
among them only gtktoolbar.c seems to be affected.
Regards,
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Sun, 2009-01-04 at 15:43 -0500, Matthias Clasen wrote: > On Sun, Jan 4, 2009 at 5:14 AM, Alexander Larsson wrote: > > > IMHO that is a Gtk+ bug. > > I agree. Yu, can you file a bug about this ? Yes. Filed as Bug 566578 Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: struggling with the non-recursive gdk_threads_enter
On Wed, 2008-12-31 at 15:11 +0200, Tor Lillqvist wrote: > > The code need to be protected so that its execution is not interrupted > > by GDK activities in other threads. How can I do this without a > > recursive gdk critical section? > > Don't use GTK+ from multiple threads. Makes the code a lot cleaner. > > --tml Thanks. My module doesn't use threads, but the program that loads this module can be multithreaded. I am wonderrng if ATK people also encounter this problem. Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
struggling with the non-recursive gdk_threads_enter
Dear Devels: I am having troubles because the GMutex used gdk_threads_enter/leave can be non-recursive. I have a piece of code (g_module_check_init) to either be called from an event dispatched by GDK(if the module is loaded via GtkSettings) or be called directly without entering the GDK critical section(if the module is loaded via GTK_MODULE). The code need to be protected so that its execution is not interrupted by GDK activities in other threads. How can I do this without a recursive gdk critical section? Regards, Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
reference count not freed in dispose?
Hi,
I was reading gtkcellrendererspin.c
and saw:
static void
gtk_cell_renderer_spin_finalize (GObject *object)
{
GtkCellRendererSpinPrivate *priv;
priv = GTK_CELL_RENDERER_SPIN_GET_PRIVATE (object);
if (priv && priv->adjustment)
g_object_unref (priv->adjustment);
G_OBJECT_CLASS (gtk_cell_renderer_spin_parent_class)->finalize (object);
}
Isn't it suggested that the reference counts should be freed in dispose
method in GObject's document?
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Memory leak in gtk_label_size_request?
Greetings. When I was valgrinding my program I saw this: ==6254== ==6254== 65,272 (19,456 direct, 45,816 indirect) bytes in 73 blocks are definitely lost in loss record 199 of 207 ==6254==at 0x4006C0C: realloc (vg_replace_malloc.c:429) ==6254==by 0x1AD131: FcPatternObjectInsertElt (fcpat.c:358) ==6254==by 0x1ADBA7: FcPatternObjectAddWithBinding (fcpat.c:515) ==6254==by 0x1AE1EB: FcPatternObjectAdd (fcpat.c:545) ==6254==by 0x1AA14D: FcFontRenderPrepare (fcmatch.c:444) ==6254==by 0x325832: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1098) ==6254==by 0x2B8829: pango_font_map_load_fontset (pango-fontmap.c:138) ==6254==by 0x2B643B: itemize_state_process_run (pango-context.c:1280) ==6254==by 0x2B691E: pango_itemize_with_base_dir (pango-context.c:1466) ==6254==by 0x2BF578: pango_layout_check_lines (pango-layout.c:3824) ==6254==by 0x2C0A7A: pango_layout_get_extents_internal (pango-layout.c:2443) ==6254==by 0x4FC053: gtk_label_size_request (gtklabel.c:2521) Does it mean there is a leak in gtklabel or Pango? gtk2-2.14.4-3.fc10.i386 Regards, Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: reference count not freed in dispose?
On Fri, 2008-12-12 at 14:13 +0200, markku.v...@iki.fi wrote:
> Hi,
>
> Since the unreffing is done in finalize, it will not happen more than once
> (finalize is called once, destroy can take place more often).
>
> If somebody else may be holding reference to your (internal) object, then
> making unref in destroy is important, since this allows breaking reference
> loops. When this is not the case (you have not published the internal object
> in any way), then it doesn't matter in practise.
To the renderer, the object is not internal. It is settable via
'adjustment' property.
If someone supply a GtkAdjustment with a reference to the redererer in
data fields, there will be a circular reference. In common practice it
is OK, but it is not always going to be OK.
Yu
>
> Cheers,
>
> -Markku-
>
> Quoting Philip Withnall :
>
> > Yes, and priv->adjustment should be set to NULL afterwards to stop it
> > getting unreffed more than once. Please file a bug.
> >
> > Philip
> >
> > On Fri, 2008-12-12 at 00:41 -0500, Yu Feng wrote:
> >> Hi,
> >>
> >> I was reading gtkcellrendererspin.c
> >> and saw:
> >>
> >> static void
> >> gtk_cell_renderer_spin_finalize (GObject *object)
> >> {
> >> GtkCellRendererSpinPrivate *priv;
> >>
> >> priv = GTK_CELL_RENDERER_SPIN_GET_PRIVATE (object);
> >>
> >> if (priv && priv->adjustment)
> >> g_object_unref (priv->adjustment);
> >>
> >> G_OBJECT_CLASS (gtk_cell_renderer_spin_parent_class)->finalize (object);
> >> }
> >>
> >> Isn't it suggested that the reference counts should be freed in dispose
> >> method in GObject's document?
> >>
> >> Yu
> >>
> >>
> >>
> >>
> >> ___
> >> gtk-devel-list mailing list
> >> gtk-devel-list@gnome.org
> >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
>
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
reference count not freed in dispose?
Hi,
I was reading gtkcellrendererspin.c
and saw:
static void
gtk_cell_renderer_spin_finalize (GObject *object)
{
GtkCellRendererSpinPrivate *priv;
priv = GTK_CELL_RENDERER_SPIN_GET_PRIVATE (object);
if (priv && priv->adjustment)
g_object_unref (priv->adjustment);
G_OBJECT_CLASS (gtk_cell_renderer_spin_parent_class)->finalize (object);
}
Isn't it suggested that the reference counts should be freed in dispose
method in GObject's document?
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Project: DOM in Vala.
New project address set up. The primary goal is to implement as much as possible of the DOM3 specification; The secondary goal is to push to the limits vala compiler and vala language by implementing a set of industry standards. A hidden goal is to establish a solid foundation for the next version of GNOME Global Menu; http://code.google.com/p/libgdom3/source/checkout I've already did some for DOM Core. But the entire project is definitely beyond one person's efforts. Let me know if you want to participate. Cheers, Yu On Thu, 2008-11-20 at 12:50 +0800, Barco You wrote: > what's the username and passwd? > > On Thu, Nov 20, 2008 at 12:45 PM, Yu Feng <[EMAIL PROTECTED]> > wrote: > On Thu, 2008-11-20 at 09:38 +0800, Barco You wrote: > > Hi, > > I'm interested! > > https://gnome2-globalmenu.googlecode.com/svn/branches/0.6-dom/dom > > I am still trying to getting things organized. > > > > > > > On Thu, Nov 20, 2008 at 12:40 AM, Yu Feng > <[EMAIL PROTECTED]> > > wrote: > > Hi, all. > > > > I am working on a DOM[1] implementation(with the aid > of > > libgee) in > > vala. > > > > If others are also interested in using/writing it, > we can > > start a new > > project by spawning the DOM code from my project and > make it > > complete. > > > > It might be a redundancy, since there are already > > implementations > > (GDOM2[2], no updates for 5 years?) out there. > > > > Just for the sake of coding fun. > > > > NOTE: XML Parsing is not intended. > > > > Regards, > > > > Yu > > > > [1] http://www.w3.org/TR/DOM-Level-2-Core/ > > [2] http://gdome2.cs.unibo.it/ > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > > > > -- > > --- > > Enjoy life! > > Barco You > > > > > > -- > --- > Enjoy life! > Barco You ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Anybody Interested on implementing a DOM in Vala?
Hi, all. I am working on a DOM[1] implementation(with the aid of libgee) in vala. If others are also interested in using/writing it, we can start a new project by spawning the DOM code from my project and make it complete. It might be a redundancy, since there are already implementations (GDOM2[2], no updates for 5 years?) out there. Just for the sake of coding fun. NOTE: XML Parsing is not intended. Regards, Yu [1] http://www.w3.org/TR/DOM-Level-2-Core/ [2] http://gdome2.cs.unibo.it/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: another memory leak
On Wed, 2008-10-29 at 22:08 -0400, Jacques Le Normand wrote:
> Hello list,
> thank you for helping me to solve my previous post, which found that I
> had a memory leak. The solution was to remove uim (universal input
> method).
Would you say more about the solution in the list? I am also interested
in it but don't know why there is a leak.
> I have a new memory leak problem. This one creates and removes 2000
> text entries every 100ms. I've had top showing 64 megs resident after
> 5 minutes (and no sign of stopping).
> If anyone could run the code to see if they get a memory leak (and
> post the result) it would be great!
> If anyone could shed some light on the problem, even better!
> cheers
> --Jacques
>
> (and now the code...)
>
> #include
> #include
> #include
>
>
> GtkWidget *entry;
> GtkWidget *vbox;
>
> guint test_function(gpointer data){
> GList *iter;
> GList *original_iter;
> iter = original_iter = gtk_container_get_children (GTK_CONTAINER
> (vbox));
> while(iter){
> GtkWidget *child;
> child = iter->data;
> iter = iter->next;
> gtk_container_remove(GTK_CONTAINER(vbox),child);
>
>
> }
> g_list_free(original_iter);
> int i;
> for( i = 0 ; i < 2000 ; i++){
> entry = gtk_entry_new ();
> gtk_box_pack_start (GTK_BOX (vbox), entry, TRUE, TRUE, 0);
> gtk_widget_show (entry);
> }
> return 1;
> }
>
> int main( int argc,
> char *argv[] )
> {
> int time_interval = 100;
> GtkWidget *window;
> gtk_init (&argc, &argv);
>
> /* create a new window */
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_widget_set_size_request (GTK_WIDGET (window), 200, 100);
> gtk_window_set_title (GTK_WINDOW (window), "GTK Entry");
> g_signal_connect (G_OBJECT (window), "destroy",
> G_CALLBACK (gtk_main_quit), NULL);
> g_signal_connect_swapped (G_OBJECT (window), "delete_event",
> G_CALLBACK (gtk_widget_destroy),
> G_OBJECT (window));
>
> vbox = gtk_vbox_new (FALSE, 0);
> gtk_container_add (GTK_CONTAINER (window), vbox);
> gtk_widget_show (vbox);
>
>
> g_timeout_add(time_interval,(GSourceFunc) test_function,0);
>
> gtk_widget_show (window);
>
> gtk_main();
>
> return 0;
> }
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theme patriation
On Tue, 2008-10-28 at 19:09 -0400, Allin Cottrell wrote: > On Tue, 28 Oct 2008, Xavier Bestel wrote: > > > Hi Allin, > > > > On Mon, 2008-10-27 at 20:34 -0400, Allin Cottrell wrote: > > > 1) I like to run an analog clock on my desktop... > > > > Did you try cairo-clock ? > > http://macslow.thepimp.net/?page_id=23 > > Disclaimer: I'm an old fart and a grouch. But I really, really > don't want to have to run compiz just to get an analog clock! I > want my CPU cycles to be available for computations I'm interested > in. What I can tell from my experience is that compiz uses less CPU cycles than metacity. Perhaps more GPU cycles are consumed but you don't use them for computations anyways. > > > > 2) If desktop software supports multiple virtual desktops -- and > > > of course it should -- it seems rudimentary that you should be > > > able to specify that a given app always starts on desktop N... > > > You should use Devil's Pie for that: > > http://burtonini.com/blog/computers/devilspie > > Looks interesting, though if devil's pie is third party, it looks > as if you need a fourth party app to provide a GUI for devil's > pie. Sawfish does all this, with GUI, in one WM. > > Allin Cottrell > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theme patriation
On Tue, 2008-10-28 at 08:03 +0200, Kalle Vahlman wrote: > 2008/10/27 John Stowers <[EMAIL PROTECTED]>: > > On Mon, 2008-10-27 at 11:44 +0100, Steve Frécinaux wrote: > >> Ross Burton wrote: > >> > >> > Adding _NET_WM_CONTEXT_TOOLBAR sounds like it should be fairly simple to > >> > do, especially with a GTK+ utility function to mark a toolbar as the > >> > "main" toolbar. > >> > >> The same can be done for menu-bar for os-x-likeness addicts. > > > > Have you checked out the latest > >> > >> By the way, this could be solved easily using a GtkAppWindow gobject > >> that would handle commonly-looking applications windows like the > >> libgnome equivalent (was it GnomeApplication ?) did. It looks damn > >> simple: a menubar, a toolbar, a content area and a statusbar, and the > >> implementation can be different on different os to comply easily with > >> those (for instance, the osx impl could just not display the main > >> menubar in the window, etc). > > > > There is already a working implementation for mac style menu on Gtk. > > Check out http://code.google.com/p/gnome2-globalmenu/ > > Since it's implemented as a D-Bus service, couldn't that be easily > used to create the "menu-in-titlebar" effect? > Just replace the applet > with support for it in metacity... Only if someone writes it. > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gobject-introspection and gtkmmproc (Re: [Vala] Auto mm(C++) binding for libraries written in Vala?)
Hi, there is a link at http://live.gnome.org/GObjectIntrospection/ saying that gtkmm 'can' use gobject-introspection. Is anyone working on this / when will it likely to be done? Yu On Tue, 2008-10-14 at 09:48 -0700, Michael Lawrence wrote: > > > On Tue, Oct 14, 2008 at 9:04 AM, Yu Feng <[EMAIL PROTECTED]> > wrote: > Hi all, > > Will it be useful to make VALA capable of producing mm(C++) > bindings for > the libraries? > > Do you mean generating C++ bindings to libraries implemented in Vala > (C)? I think there's a VAPI->GIR translator in the works. So perhaps a > C++ backend to GObject Introspection would be a good place to start. > But then the gtkmm guys are probably already thinking about this. > > > > Where should be a good point to start? > > Regard, > > Yu > > ___ > Vala-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/vala-list > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Emission hooks for parent-set signal.(cont.)
On Tue, 2008-10-07 at 22:21 +0200, Tim Janik wrote:
> On Mon, 6 Oct 2008, Yu Feng wrote:
>
> >
> > static void
> > gtk_window_destroy (GtkObject *object)
> > {
> > GtkWindow *window = GTK_WINDOW (object);
> >
> > toplevel_list = g_slist_remove (toplevel_list, window);
> >
> > if (window->transient_parent)
> >gtk_window_set_transient_for (window, NULL);
> >
> > /* frees the icons */
> > gtk_window_set_icon_list (window, NULL);
> >
> > if (window->has_user_ref_count)
> >{
> > window->has_user_ref_count = FALSE;
> > g_object_unref (window);
> >}
> >
> > if (window->group)
> >gtk_window_group_remove_window (window->group, window);
> >
> > gtk_window_free_key_hash (window);
> >
> > GTK_OBJECT_CLASS (gtk_window_parent_class)->destroy (object);
> > }
> >
> >
> > Maybe moving the ->destroy line to the beginning of this function can fix
> > the problem?
>
> Assuming you suggest moving ->destroy() to before
> the g_object_unref() call because you see ref_count
> assertions with your emission hook uses, the answer
> is: No.
> The only way this function can be validly called is
> via a signal emission of the GtkObject::destroy signal.
> And emitting a signal on an instance will ref the
> instance before and unref the instance after
> the emission.
So the ref_count assertions is not produced from here. But I am still
puzzled about how the assertion might comes out from other places. Do
you have any possible explanations?
Yu
>
> > Yu
>
> ---
> ciaoTJ
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Emission hooks for parent-set signal.(cont.)
static void
gtk_window_destroy (GtkObject *object)
{
GtkWindow *window = GTK_WINDOW (object);
toplevel_list = g_slist_remove (toplevel_list, window);
if (window->transient_parent)
gtk_window_set_transient_for (window, NULL);
/* frees the icons */
gtk_window_set_icon_list (window, NULL);
if (window->has_user_ref_count)
{
window->has_user_ref_count = FALSE;
g_object_unref (window);
}
if (window->group)
gtk_window_group_remove_window (window->group, window);
gtk_window_free_key_hash (window);
GTK_OBJECT_CLASS (gtk_window_parent_class)->destroy (object);
}
Maybe moving the ->destroy line to the beginning of this function can fix the
problem?
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Emission hooks for parent-set signal.
I went into troubles adding an emission hook for parent-set signal. By adding the hook, I receive a warning: GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed aborting... Program received signal SIGABRT, Aborted. 0x00110416 in __kernel_vsyscall () (gdb) bt #0 0x00110416 in __kernel_vsyscall () #1 0x00588660 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0058a028 in abort () at abort.c:88 #3 0x0044944c in g_logv () from /lib/libglib-2.0.so.0 #4 0x00449486 in g_log () from /lib/libglib-2.0.so.0 #5 0x004496eb in g_return_if_fail_warning () from /lib/libglib-2.0.so.0 #6 0x00b4d4db in g_object_ref () from /lib/libgobject-2.0.so.0 #7 0x00b4fa08 in ?? () from /lib/libgobject-2.0.so.0 #8 0x00b62a62 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #9 0x00b631b6 in g_signal_emit () from /lib/libgobject-2.0.so.0 #10 0x010d2bc6 in gtk_widget_unparent () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x0106bac0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x09d68088 in ?? () #13 0x09da4838 in ?? () #14 0xbf879b38 in ?? () #15 0x00419790 in g_atomic_int_exchange_and_add () from /lib/libglib-2.0.so.0 #16 0x00b4d343 in g_object_unref () from /lib/libgobject-2.0.so.0 #17 0x00f912d6 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x010d2dad in gtk_widget_destroy () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x00e55eb0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #20 0x09dad000 in ?? () #21 0x in ?? () (gdb) Looking at the GTK source(2.12.11). What happens seems to be (1) When I close a toplevel window, gtk_widget_destory is invoked. (2) in gtk_widget_destroy, the toplevel window unref()s itself, then unparent()s all of its children. The ref_count of the toplevel window becomes zero. (3) In gtk_widget_unparent, an parent-set signal is emitted, with the destroying toplevel window as a parameter. (4) g_signal_emit collects destroying toplevel and emit the hook. When the toplevel is collected, a ref() is invoked, and the program gives the warning. I am not sure if this is correct, but apparently there is no way to fix the problem unless I don't add a hook to parent-set. Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Announcement for the DBus backed Global Menu
Hi, I am sorry for the longlong delay after last time I talked about writing the applets and stuffs. A lot have happened. One is that I made a big decision to move entirely on top of DBus, and also turned to Vala for the core of libgnomenu. Other components can be written in any other languages. This version of Global Menu doesn't require patching GTK code anymore. However, two dynamic patches are applied when libgnomenugtk is loaded. It will be better if the patches are adopted by the GTK itself: (1) emitting an 'insert' signal when inserting a child to a MenuShell, (2) hiding the menu bar with a 'local' property: if == true, the local menu bar is not hidden, if == false, it is hidden. libgnomenu provides a remote XML(GMarkup) facility on top of DBus: via four classes: XML.Document, Gnomenu.DBusView, Gnomenu.Document, Gnomenu.RemoteDocument, libgnomenu-gtk introspects the GTK menu system to a live XML document which is in sync of the menu system, and exposes it via libgnomenu on DBus. libgnomenu-gtk is loaded as one of the GTK_MODULES, so that if it is not loaded, GTK should behave like before. varies tools can inspect the exposed menu system, one of which(the most feasible one) is Gnomenu.MenuBar that takes an string-fied xwindow id as a parameter, and provide a view of the menu system with a true GtkMenuBar. String-fying the xwindow is for avoiding potential problems with 64bit XLib. Gnomenu.MenuBar can be integrated into a gnome-panel applet, that finds the active window, and shows its menu content. Though GnomenuMenuBar is now a subclass of Gtk.MenuBar, I'll have to make it a subclass of Gtk.Box/Gtk.Container to support multi-menubars on one window. The code is at http(s)://gnome2-globalmenu.googlecode.com/svn/branches/0.6-devel Several screenshots: http://ubuntuforums.org/showpost.php?p=5843905&postcount=2081 http://ubuntuforums.org/showpost.php?p=5832469&postcount=2072 http://ubuntuforums.org/showpost.php?p=5839130&postcount=2076 And many thanks to gtkmac/syncmenu. Regards Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: embedding G-I into apps
Is it possible to make use of GTK_MODULES/ --gtk-modules ?
On Wed, 2008-09-10 at 13:59 +0200, Johan Dahlin wrote:
> Colin Walters wrote:
> > (Using this list for gobject-introspection development for now,
> > probably ignore if you're not jdahlin =))
> >
> > I was looking a bit today about applying our shiny new introspection
> > tool to Totem, with an eye to eliminating the manual binding
> > infrastructure, and more generally figure out how existing C
> > applications can use g-i (and something like Alex' GScript API) to
> > have a nicer way to embed Python or Spidermonkey.
>
> As far as I can see it there are two options:
> A) dlopen the executable (not portable)
> B) create a temporary shared library
> C) execute the scanner inside the application (as you suggested)
>
> Discarding A, as we want to be portable. I've always thought about using
> a temporary shared library to solve this particular problem, but the one you
> suggested appears to be better in many ways.
>
> > Now, the scanner requires, at build time, to load the app's code so we
> > can call the foo_get_type() functions and introspect
> > properties/signals etc. This is problematic because on some platforms
> > you can't just dlopen() an executable. Owen and I had a discussion
> > about this and it sounds like basically what we need to do is actually
> > invoke the scanner from inside the application. So here's how it
> > could work:
>
> get_type() functions obviously needs to be available to the whole application.
>
> > o Add a hidden --introspect option to application
> > o When given, dlopen("gobject-introspection-sanner.so")
> > o dlsym("g_introspection_scan")
> > o Pass our current argv to that function
> > o This function (in a separate shared library from
> > gobject-introspection.so), uses the cPython API to create an
> > interpreter and load /usr/bin/g-ir-scanner
> > o Locate the main() function inside the Python script g-ir-scanner,
> > and invoke it with the argv originally passed
> >
> > Kind of gross admittedly, but apps should only need a small patch for
> > this approach and it seems most likely to work on random platforms.
> > If someone knows a better/nicer way, let me know!
>
> I would rather do it the other way around, by creating C bindings
> for the scanner, so you could do:
>
> scanner = gi_scanner_new ()
> gi_scanner_set_namespace (scanner, "totem");
> gi_scanner_add_sources (scanner, "totem-menu.h", "totem-video-widget.h");
> etc.
>
> That would make it sufficient to just g_module_open(NULL);
>
> To do that we'd need two tools:
> 1) one to generate A GIR for a python interface
> 2) another to create C bindings for a python method.
>
> I have the beginning of a tool which does 2, which shouldn't be too hard to
> fix up to make it possible just to generate this small piece of clue.
>
> Johan
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 12:18 +0200, Mikkel Kamstrup Erlandsen wrote: > 2008/8/21 Yu Feng <[EMAIL PROTECTED]>: > > On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: > >> Hi, > >> > >> On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > >> > Is there any particular reason that GLib doesn't provide a ref-counted > >> > string and a ref-counted array type? Lacking them in GLib makes the VALA > >> > language a real pain. > >> > > >> > >> I think you would have to explain more why this is an issue for vala, > >> at least for me (maybe everyone else already knows) > > > > OK. > > > > Vala claims automatic memory management and a programming language on > > top of GLib. > > > > First, it is very difficult to manage a string without a reference > > count. The current vala implementation is to assume that strings are > > immutable, and to copy the strings almost everywhere where increasing > > the ref-count should be used. The copying mechanism produces workable > > code, but doesn't work in a efficient way. This is where it hurts. > > > > Secondly, vala doesn't introduce any additional dependency other than > > GLib, to implement it in VALA level, the only way is to embed it in the > > compiler. A compiler with embeded code to do a ref-counted string > > doesn't sound nice. This is why I think it should be done at GLib level. > > How about using a GStringChunk and apply some magic compile-time > logic? Although I am not quite sure how it should be done - you are > the wizards :-) > > It could maybe also make more sense to add some more API to > GStringChunk as it is quite limited as it stands. Perhaps not since GStringChunk is not thread-safe and can't be globally held. and adding one for each thread is insane. > > Cheers, > Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 12:18 +0200, Mikkel Kamstrup Erlandsen wrote: > 2008/8/21 Yu Feng <[EMAIL PROTECTED]>: > > On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: > >> Hi, > >> > >> On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > >> > Is there any particular reason that GLib doesn't provide a ref-counted > >> > string and a ref-counted array type? Lacking them in GLib makes the VALA > >> > language a real pain. > >> > > >> > >> I think you would have to explain more why this is an issue for vala, > >> at least for me (maybe everyone else already knows) > > > > OK. > > > > Vala claims automatic memory management and a programming language on > > top of GLib. > > > > First, it is very difficult to manage a string without a reference > > count. The current vala implementation is to assume that strings are > > immutable, and to copy the strings almost everywhere where increasing > > the ref-count should be used. The copying mechanism produces workable > > code, but doesn't work in a efficient way. This is where it hurts. > > > > Secondly, vala doesn't introduce any additional dependency other than > > GLib, to implement it in VALA level, the only way is to embed it in the > > compiler. A compiler with embeded code to do a ref-counted string > > doesn't sound nice. This is why I think it should be done at GLib level. > > How about using a GStringChunk and apply some magic compile-time > logic? Although I am not quite sure how it should be done - you are > the wizards :-) > > It could maybe also make more sense to add some more API to > GStringChunk as it is quite limited as it stands. > I will investigate into this. It seems at least a g_string_chunk_remove has to be added. Thanks Yu > Cheers, > Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 07:57 +0200, Ali Sabil wrote: > > > > First, it is very difficult to manage a string without a > reference > count. The current vala implementation is to assume that > strings are > immutable, and to copy the strings almost everywhere where > increasing > the ref-count should be used. The copying mechanism produces > workable > code, but doesn't work in a efficient way. This is where it > hurts. > I am not quite sure, to me you seem to mix up copy on write string and > shared buffers, copy on write strings are just an optimization, and > they don't need to be in GLib. Concerning shared buffers, string are > *not* used in vala for shared buffers, simply because a string in vala > is a utf-8 encoded *immutablle* byte sequences. a byte buffer is > represented using uchar[]. Right now vala supports is pretty young > concerning array supports, they are hard to manage in the first place > because of the C quirks (null terminated arrays, vs arrays with an > extra parameter to specify the length). > > To keep it simple, why don't you just write a ByteBuffer class > inheriting from GObject ? > I don't know see any reasons. > > Secondly, vala doesn't introduce any additional dependency > other than > GLib, to implement it in VALA level, the only way is to embed > it in the > compiler. A compiler with embeded code to do a ref-counted > string > doesn't sound nice. This is why I think it should be done at > GLib level. > > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: > Hi, > > On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > > Is there any particular reason that GLib doesn't provide a ref-counted > > string and a ref-counted array type? Lacking them in GLib makes the VALA > > language a real pain. > > > > I think you would have to explain more why this is an issue for vala, > at least for me (maybe everyone else already knows) OK. Vala claims automatic memory management and a programming language on top of GLib. First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. > > The first question is whether a solution goes in glib or in vala, > which kind of depends on what the specific problems are. > > Havoc Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Lacking of a ref-counted string.
Dear Devs, Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. Is it possible to introduce them in the next major ABI breaking? When will the breaking be? Regards, Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
native menu system and GTK(3.0)?
Dear people, I would like to ask if there is plan for OSX native menu integration in GTK 3.0? I have an idea but I don't know if people want to do the integration at all. First, there is the ige-mac-menu from ige-mac-integration package, but as the developer says there is no plan to integrate it into GTK since the package doesn't fit. Currently, to perfectly synchronize the OSX native menu with the GtkMenu from the outside is impossible; (http://developer.imendio.com/node/216#comment-2126) Second, I am writing a layer similar to OSX's native menu for GNOME. On the GTK integration side, since the sync-menu method is not so well, I am thinking of patching GtkMenuShell and GtkMenuItem, so that they call the native menu functions remotely[1] whenever some important properties[2] are changed. I want to listen to you if this method makes better sense than the first one? Does it seem to be something possible in GTK 3.0? Regards, Yu [1] remotely: since the native menu are in a different process, the call has to be a remote one. It is some kind of slow, less than but around 10ms for a call. [2] submenu, text/title of the internal GtkLabel, accel-*, visible, enabled; and gtk_menu_shell_insert method. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
On Thu, 2008-07-17 at 14:23 -0400, Havoc Pennington wrote: > Hi, > > On Thu, Jul 17, 2008 at 2:06 PM, Philip Van Hoof <[EMAIL PROTECTED]> wrote: > > You could make a GLib.Iterator that uses gobject-introspection, but I > > don't think you want to make gobject-introspection the one thing > > everybody who wants to expose collections in his API has to use and > > learn. > > I didn't mean that - I meant if you exposed collections you'd use > GList or whatever, and g-i would know that it was a "GList of Foo", > and g-i would generate an iterator around the list based on that. Then > users of the g-i API for language bindings would see only the > iterator. > > >> Any language binding not using g-i has nothing to stand on if they > >> whine about manual work - they need to a) port to / help with g-i and > >> then b) we'll talk. > > > > Disagree with this. GObject-introspection can be an aid for the many > > quirks and Cisms our platform introduces. Future APIs should not focus > > on just the C application developers. > > g-i is not for C afaik. It's supposed to replace all the > source-code-scanners and "defs" files and so forth different language > bindings are using. It should be extended until it completely replaces > those things. > > g-i allows dropping static stubs - all functions are invoked *through* > g-i, and return values are marshaled with it also. > > > It'll also be useful for other tasks that right now require scripts to > > parse C code, as gobject-introspection will ship with a bunch of very > > interesting tools for that (representing an existing API as an XML that > > will be suitable to throw at a XSL compiler). > > Ideally all scanning (and merging in lookaside info) will happen in > g-i, which will then have everything a binding needs in the binary > typelib. > > > If GLib library authors wont focus on higher programming languages, then > > I fear Gtk+ and its accompanying large set of excellent libraries will > > get more and more neglected. But that's just my personal feeling. > > We don't need to break C to support other languages. Most libs will > keep being written in C, and lots of existing useful code is in C, so > we should keep having good C support. > > I think the ideal situation for the desktop looks a lot like Firefox > or Emacs or World of Warcraft for that matter, with a C/C++ core and > the top layers (including most visible functionality) in an agile > language. Well OK, if starting 100% from scratch, it might be more > ideal to write everything to a single virtual machine - but we aren't > starting from scratch, we're starting with millions of lines of > existing useful C code. > > > I don't know why only C/GLib experts should be the ones writing language > > bindings (which is the case right now). It's quite hard to find people > > who are into the higher language and yet know really a lot about GLib > > too. Usually these people have no reason whatsoever to care about GLib > > and its isms anymore. > > g-i should be able to include any code that is generic across all bindings. > > >> * as Owen mentioned long ago when this was already discussed, we'd end > >> up duplicating bunches of APIs just to make them use iterators instead > >> of whatever they use now - this is both bloat and confusing. It would > >> not be realistic to ever deprecate walking GList etc. - the iterator > >> replacement is much less convenient, and there's way, way, way too > >> much code using GList already. You can't deprecate something that > >> touches this much code. > > > > I didn't mention deprecating this code ... > > The point is that if we don't deprecate GList, as I think we can't, > then we end up with duplication and bloat. (Two versions of all > existing APIs, at minimum.) What about keep using GList in the inside; and always use collection API when the functions are to be invoked by bindings? GList's api is really convenient and light for managing weak references. GHashTable has some ability to manage strong reference but it surely know little about the GType of the object it holds. anyway I think GList and GHashTable is enough in doing their job; but they are a nightmare when binding to other languages. I really hate those special code in vala in keeping track of the strong references. BTW: I think it is a good chance to discuss this since people are also deciding the GTK 3.0 APIs now. Yu > > Havoc > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
Hi Tim, On Thu, 2008-07-17 at 17:51 +0200, Philip Van Hoof wrote: > Hi there, > > I would like to propose this API to go into glib/gio: > > http://live.gnome.org/IteratorsAPI > > A working implementation of it can be found here (just replace Gee.List > with GLib.Seq, as that is the name that we have for it in mind): > > http://svn.gnome.org/viewvc/libgee/trunk/gee/ > > To see users of this API, take a look at for example the Vala project. > On the IteratorsAPI wiki page, at the bottom, there are also a lot of > examples of projects that are right now inventing their own collections. > > We are working on adding convenience functions for C to make things as > type safe as possible (the #1 problem with glib's current collection > types): > > gchar* g_iterator_get_as_string (GIterator *iter); > gdouble g_iterator_get_as_double (GIterator *iter); > It looks like a GValue. Can it be simplified by using GValue? > A normal use-case would be a GObject in a sequence, which would with the > caller-owns API 'g_iterator_get' mean that you need to unref what you > get. We are thinking about making it possible to pass a 'free-function' > to the owner of the items (the collection), and to allow annotating how > to free what you get from 'g_iterator_get' (as it's caller owns). > > Right now, with the usage of GHashTable, GPtrArray and GList, language > binding developers loose all meaningful type information. > > This means that they have to resort to using manually written glue code. > This is among the reasons that makes fully automated language binding > generation a nearly impossible task at this moment. I think the problem is that lacking of reference management, GList is not intended to be used in a language binding; whereas in the reality a lot of GTK APIs take and return GList, forcing the binding programmers to write glue code. > In my opinion it's one of the reasons why we never really achieved > topnotch compelling language bindings, even though that was the #1 > promise of Gtk+ back when it all started. > > It's of course debatable whether or not they topnotch. They are not for > me and having a collection API that actually does make sense outside of > the C world would in my opinion be one more step in the direct direction > of improving this situation. > > This of course doesn't "magically" fix existing Cism APIs. But take a > look at the wiki page mentioned above for example on how this can easily > be improved. > > > Thanks, and please don't troll about how great doubly linked lists are. > > It's not the point. > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
questions about g_object_unref.
Hi all, not sure if it is appropriate here, but I don't quite understand
the code in g_object_unref:
glib-2.16.1/gobject/gobject.c: line:1763
/* here we want to atomically do: if (ref_count>1) { ref_count--;
return; } */
retry_atomic_decrement1:
old_ref = g_atomic_int_get (&object->ref_count);
if (old_ref > 1)
{
if (!g_atomic_int_compare_and_exchange (&object->ref_count,
old_ref, old_ref - 1))
goto retry_atomic_decrement1;
How does the code achieve the goal stated in the comments? It seems to
me that the code will loop at retry_atomic_decrement1 untill old_ref ==
1?
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkImageMenuItem:: forall includes the internal GtkImage Widget?
> On Sat, 2008-05-24 at 15:51 +, BJörn Lindqvist wrote: > On Fri, May 23, 2008 at 11:24 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > > > Isn't the GtkImage in a GtkImageMenuItem an internal widget? > > No, GtkImageMenuItem is a GtkContainer and the image widget is set > explicitly as its child, so it is not internal. Can you show me an example the user set the image as the container's child? > gtk_container_forall > says ""internal" (implementation details of the container). "Internal" > children generally weren't added by the user of the container, but > were added by the container implementation itself." > If it is an external child then it should not be treated as a property. Also, GtkImageMenuItem has to be a bin because GtkMenuItem is a bin. I think this is a typical application of the 'Decoration' pattern. one has a widget and one wants something to decorate it without change the functionality and knowing any details of it. > I agree that it is a little strange that GtkImageMenuItem is a GtkBin, > logically it has two children. It is not only strange but also has practical confusions. How is GtkBuilder UI Definition solving the confusion between property and external child? > Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkImageMenuItem:: forall includes the internal GtkImage Widget?
Hi everyone,
Isn't the GtkImage in a GtkImageMenuItem an internal widget?
The following code assumes GtkImage is an external widget. But
GtkImageMenuItem is from a GtkBin, thus it should not have more than a
child.
--
static void
gtk_image_menu_item_forall (GtkContainer *container,
gbooleaninclude_internals,
GtkCallback callback,
gpointercallback_data)
{
GtkImageMenuItem *image_menu_item = GTK_IMAGE_MENU_ITEM (container);
(* GTK_CONTAINER_CLASS (gtk_image_menu_item_parent_class)->forall)
(container,
include_internals,
callback,
callback_data);
if (image_menu_item->image)
/*^---shall here be an 'include_internals &&' ?*/
(* callback) (image_menu_item->image, callback_data);
}
--
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to move, resize and redraw a window at the same time?
On Tue, 2008-05-20 at 12:00 +0800, Zhe Su wrote: > Thanks a lot. > > On Tue, May 20, 2008 at 11:52 AM, Havoc Pennington <[EMAIL PROTECTED]> > wrote: > Hi, > > 2008/5/19 Zhe Su <[EMAIL PROTECTED]>: > > So I'm wondering is there and method to move, resize and > redraw a window > > at the same time to avoid flick? > > > The underlying X window system doesn't support doing this, > though it > may in the future as compositing managers become the norm. > > The best you can do with X is to not clear the window when > it's > resized, but you can't atomically resize and repaint because > those > things are separate X server commands and the server does not > do > whole-screen double-buffering. > > > And I'm wondering why there is no > > gtk_window_move_resize() for gtk window. > > > Well, setting a window size and position manually on a mapped > window > is a pretty uncommon operation, so most likely nobody has > asked to do > it. It probably works fine to do > gdk_window_move_resize(window_widget->window) as a workaround. > If this function is ok, then I'll stick with it. Is there any side > effect? > It seems that Gtk doesn't recommend setting the window size or position of widgets in the code. I think violating the gtk recommendation will be the only side effect. > > > The docs on gtk_window_move(), gtk_window_set_default_size(), > etc. > (and the implementation source code of same) may be of > interest, if > you're digging into this area. > > Havoc > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
Hmm, What about embedding different PDF viewers into the widget, on different platform? Or else will it be a lot of redundant work? On Wed, 2008-04-16 at 12:46 -0500, Cody Russell wrote: > I was thinking that it would be nice if there was an integrated print > preview widget in GTK+, that would be available cross-platform and > wanted to check with people here before I commit much time to this. > Right now we're spawning another process to do this, and I think an > integrated widget would be much nicer. > > Thoughts? > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_strsplit variant which filters empty strings from the result
I think you can filter the strv by yourself, with a loop and if(result[i] == NULL) continue; On Thu, 2008-04-10 at 22:20 +0300, Alexander Semenov wrote: > Hi again. :) > > On Thu, 2008-04-10 at 15:13 -0400, Morten Welinder wrote: > > Do you have a case where it would actually make sense to use such > > as function? The file name case is an awful one: > > > > 1. It's unix-specific. On win32 you can see /foo/bar\baz\bof > > What do you mean unix special? There is no difference which separator to > use. On windows I'd like to remove unneeded empty strings too. > > > 2. It fails to distinguish "//foo" and "/foo" which, even on unix, are two > > different file names. > > Hmm, I'v just simply made 'cd' to '//home' (is this bash specific?). > > > It seems to me that such a function is a tad special for a general library > > like glib. > > > > Morten > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkclipboard.c
Thank you for the clearify! but I am still confused. On Mon, 2008-03-31 at 02:22 -0500, Yevgen Muntyan wrote: > Yu Feng wrote: > Note that there are no threads involved, main loops > are not threads (like, not threads at all). Yes. They shouldn't be threads at least for on some platforms, but will they act very similar as threads? > > > but what will happen if in a rared case, the spawned thread handles an > > event, and makes another function call to > > gtk_clipboard_wait_for_contents? > > > > What I can see is that > > (1) another new thread(thread 2) is spawned by thread 1, and stored in > > results->loop. > > (2) when the callback is invoked, either for the first calling or the > > second calling, thread 2 will be killed > > > > Actually the "thread" 1, not 2, but it doesn't matter. > If you stop signal emission for some weird reason at > that point, then the inner main loop will never terminate. > But in normal case both main loops will stop, and the > quoted code won't even know who were first; and > both callers will get the same clipboard data. > > > (3) when the callback is invoked again for the other calling, thread 2 > > will be killed again > > This one is what's wrong here. Every callback data > instance contains its own main loop, I got the idea. The inner main loop(thread 1) is stored in result->loop. However I discovered that finally result->loop is stored into a qdata in set_request_contents_info. Then the callback stops the inner main loop given in qdata. If there is a re-entrance(so we create a inner inner loop, was the thread2 ) from the inner main loop, will the qdata be corrupted? It will be overwritten by the new value and we lose the old 'result' data, do we? In other words, I am now worrying about the callback data instance instead of the main loop reference. > so every main > loop will be stopped once. What you're saying would > be possible if 'selection-received' signal was emitted > recursively on the same clipboard widget, but So the inner main loop is spawned from a signal handler, which may be in-recursive or recursive. The above consideration is about the recursive signal handlers. Let's consider if the signal can't be emitted recursively. Will the inner main loop be blocked or will it delay or ignore the signal? If the inner main loop get blocked, where as the outer main loop is waiting for the inner main loop to quit, we will end up with two blocked main loops and a frozen application. I hope this is not the case and I am wrong somewhere again. > gtk_clipboard_request_contents() takes care of that. > > Regards, > Yevgen > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtkclipboard.c
Hi, everyone,
I have a question about gtkclipboard.c, there might be a problem.
Look at these functions
-
GtkSelectionData *
gtk_clipboard_wait_for_contents (GtkClipboard *clipboard,
GdkAtom target)
{
WaitResults results;
g_return_val_if_fail (clipboard != NULL, NULL);
g_return_val_if_fail (target != GDK_NONE, NULL);
results.data = NULL;
results.loop = g_main_loop_new (NULL, TRUE);
gtk_clipboard_request_contents (clipboard, target,
clipboard_received_func,
&results);
if (g_main_loop_is_running (results.loop))
{
GDK_THREADS_LEAVE ();
g_main_loop_run (results.loop);
GDK_THREADS_ENTER ();
}
g_main_loop_unref (results.loop);
return results.data;
}
static void
clipboard_received_func (GtkClipboard *clipboard,
GtkSelectionData *selection_data,
gpointer data)
{
WaitResults *results = data;
if (selection_data->length >= 0)
results->data = gtk_selection_data_copy (selection_data);
g_main_loop_quit (results->loop);
}
---
In order to make a blocked operation, the main thread(thread 0) spawns a
new thread(saying, thread 1) to wait for the callback.
but what will happen if in a rared case, the spawned thread handles an
event, and makes another function call to
gtk_clipboard_wait_for_contents?
What I can see is that
(1) another new thread(thread 2) is spawned by thread 1, and stored in
results->loop.
(2) when the callback is invoked, either for the first calling or the
second calling, thread 2 will be killed
(3) when the callback is invoked again for the other calling, thread 2
will be killed again and, since it is already destroyed, gtk will panic,
also, since we loose the track of thread 1, thread 0 will never wake up
again, and all the events will be dispatched by thread 1.
Is this the case? Shall there be a fix?
Yu
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
about gtk-macosx/menubar
Hi, I wonder if any of you is taking care of gtk menu system on osx. I am doing a global menu for gtk/gnome on X11, and wondering if we can paste two projects together. http://gnome2-globalmenu.googlecode.com/ Yu On Sun, 2008-03-09 at 20:00 +, Alberto Ruiz wrote: > combobox overrides x/ythickness for the editable entry on list mode, > I've opened a bug (#521442) and proposed a patch attached. > > Is it okay to commit? > > You can see the consecuences on a releated bug in #461805 attached > images: > http://bugzilla.gnome.org/attachment.cgi?id=99629 (notice the lack of > shadow on the editable entry) > http://bugzilla.gnome.org/attachment.cgi?id=92702 (same on the > renderer) > > For some reason the bug is not exposed on most commons egines though. > -- > Un saludo, > Alberto Ruiz > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
