Re: g_object_new shared memory
On Tue, 27 Oct 2009, Hieu Le Trung wrote: Hi, I've posted this through gtk-app-devel list but no good response. So that I'm doing cross post here. Please don't, this list is for discussing development of the glib and gtk+ libraries, not applications using it. I wonder if we can do it with g_object_new or not? The purpose is to have g_object_new to allocate memory on my own memory region. No, this is not possible. GObjects are allocated through g_slice which uses posix_memalign and falls back on g_malloc for very big chunks (greater than 1kb). See glib/glib/gmem.h for an API related to malloc hooks. Thanks, -Hieu Yours sincerely, Tim Janik --- http://lanedo.com/~timj/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On Fri, 17 Apr 2009, Cody Russell wrote:
This is rather old, but it never came up again after this so I'd like to
see what thoughts are about how to implement this in C. It was in 2.13
but removed before 2.14 because of disagreement, but I can't find any
public record of the disagreement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
There was a lengthy #gtk+ discussion about this that could be dug out of
the archives. But I'll better summarize the original API motivation here:
GtkAllocation gtk_widget_get_allocation (GtkWidget *widget);
Structures like GtkAllocation/GtkRequisition are very similar to (newer)
C standards constructs like struct Complex { double real, imag; }, i.e.
a fundamental compound, fully exposed to the user. Consequently they
shouldn't be sealed, but be directly used and manipulatable by the user.
An important part of what makes dealing with Gtk+ in C so cumbersome is
the variations and inconvenient definitions in our getter APIs. Many force
two lines instead of one-liners for accesing a simple value if compound
structures are involved.
This is unneccessarily so, as long as returned structs doesn't get too big,
passing by value is convenient, and acceptable performance wise (and
definitely portable C as well).
FWIW, returning a GtkAllocation is exactly as many bytes as returning
a double.
Here's an extreme case of getter inconvenience in Gdk/Gtk+:
voidgdk_window_set_user_data (GdkWindow *window,
gpointer user_data);
voidgdk_window_get_user_data (GdkWindow *window,
gpointer *data);
The choosen API might look most symmetric, but the getter is utterly
cumbersome to use, currently it forces us to:
gpointer helper_variable; // declare this lines away at start of code block
gdk_window_get_user_data (window, &helper_variable); // getter
foo = helper_variable; // use
Instead of what could have simply been:
foo = gdk_window_get_user_data (window); // getter, use, no helper
For a central API like Gtk+s which is very widely used, 1 or 2 additional
user code lines forced by our API choices can make a huge difference if
its needed in many places.
That is the case here, lots of code portions that currently do
widget->allocation.{member}
could either be changed to:
gtk_widget_get_allocation (widget).{member}
in the future, or to multiple lines of code, possibly spread out a
fair bit, because a helper variable needs to be declared.
And while returning a GtkAllocation* from gtk_widget_get_allocation()
would technically be feasible for the immediate current migration,
in the future we might want to hand out coordinates different from
the actual widget->allocation (e.g. handing out the allocation assigned
by a parent and not the possibly "adjusted" one stored in the child
like GtkSpinButton does it).
This has basically the same problem as const char*, either we hand out
a pointer to internals and in the absence of GC force ourselves into
keeping certain structure members around forever, or we hand out a
copy and force the caller into freeing (forcing 3 instead of 1 lines
of caller code).
To sum up our getter options:
a)
/* force adding lots of helper variables into user code */
void gtk_widget_get_allocation (GtkWidget *widget,
GtkAllocation *allocation);
b)
/* convenient access, no garbage collection problem */
GtkAllocation gtk_widget_get_allocation (GtkWidget *widget);
c)
/* tie ourselves into always keeping the handed out GtkAllocation
* allocated in the widget, which can be different from the
* actual widget->allocation.
*/
const GtkAllocation* gtk_widget_get_allocation (GtkWidget *widget);
d)
/* force caller to free returned allocation, most often forces
* an extra GtkAllocation *helper; variable.
*/
GtkAllocation* /*freeme*/ gtk_widget_get_allocation (GtkWidget *widget);
Here, (c) is the worst as it preserves part of our current API problem
we intended to fix with GSEAL(). Now, (a) is what's often used in Gtk+
currently, but forces user code into explicitely adding helper variables.
Together with non-C99 compliance, it forces *two* simultaneous code
changes many lines *apart*.
Currently (d) is what we do for strings, most often an additional
helper variable like in (a) is needed here as well, to allow access
and freeing, e.g.
GtkAllocation *a;
a = gtk_widget_get_allocation (widget);
foo = a->{member};
g_free (a);
So, given the technical problem of (c), and then the pain and error-
proneness inflicted on users by (a) and (d), I highly prefer (b).
At first sight, it might seem a bit inefficient over the other variants,
but upon closer inspection (sizeofs) and given resonable compiler
optimizations, it's not doing more structure copies than (a) or (d),
and doesn't come with hea
Gtk+ 3 Roadmap Draft
Hello Gtk+ Development Community. The need for a Gtk+ 3.0 roadmap has been discussed during several Gtk+ team IRC meetings, at conferences and on other opportunities. So a few months ago, we've set down to collect the input from so many people who have contributed feature requests, ideas, improvment suggestions and procedure suggestions to this. An initial draft was then sent to the core team for initial comments. Unfortunately for business and personal reasons, I've not had a chance to stay on the topic for quite a long while. But recently Cody Russell gave me some friendly kicks in the right direction and even threatened to wikify the roadmap draft to open it up for community participation. ;) I think that's exactly what needs to happen with this. This roadmap draft is in no way finalized, it's basically a conglomerate of the various inputs and feedback the core team has been getting so far. I'd like to particularly thank Stormy and Dave Neary for good discussions and suggestions on the post-draft process. Discussion of the roadmap, additions/changes/deletions and reclassifications of the contents are probably best done in several phases as outlined in the prelude. The source text is attached and for reference provided online next to an html version: http://testbit.eu/~timj/blogstuff/GtkRoadmap3Draft2.html http://testbit.eu/~timj/blogstuff/GtkRoadmap3Draft2.txt I sincerely hope this is helpful for everyone. ;) --- ciaoTJ = Gtk+ 3 Roadmap Draft2 = Prelude The suggested plan is to work on this and publicize it in multiple steps: - The Gtk+ core team produces an initial version (draft1). [TimJ collects feedback via email during the first core team email round and integrates draft2 for gtk-devel-list.] - The draft is reviewed, extended and completed to produce a real roadmap with the gtk-devel-list community. [Probably best done by letting people edit a live.gnome.org wiki page after announcing change intentions on the mailing list.] - An "official" Gtk+ project roadmap is put up on the web, announced in various channels and feedback is requested from other projects and companies of the GNOME/free software hemisphere for a period of 1-2 months. - Feedback and change requests are worked into the official roadmap after discussions on gtk-devel-list. - A team is formed that maintains a list of contributors and volunteers for particular tasks and keeps track of the roadmap progress. Feedback on the exact progress is of course welcomed as well. Introduction The Gtk+ team is forming a roadmap to structure the development process of the Gtk+-3.0 release and to open up the involved decision making progress. Since development on the project depends to a large extend on community contributions, we cannot provide deadlines, but will use priority based classifications instead. ~~(Stormy nicely describes the tension between time, features and contributors here: http://www.stormyscorner.com/2008/09/as-open-source.html)~~ Items are classified according to: * 1) Items we believe the core team will have completed by 3.0. * 2) Community contributions that are feasible to achieve for 3.0. * 3) Items that seem unlikely to be completed for 3.0 or are specifically planed for 3.x follow up releases. Features planned for 3.0 These features are meant to be completed and integrated with the release of Gtk+ 3.0. The core team will do its best to achieve completion, but contributions are also very welcome. * Full offscreen rendering, probably completed in 2.x. This is needed for animations and effects beyond the classic widget boundaries. * Remove all public structure fields so the API is defined only in terms of function entry points. * Introduce new widget creation means that fix currently problematic widget property defaults like widget visibility. ~~(A wiki page exists, which considers table property changes: http://live.gnome.org/action/edit/GTK+/PropertyDefaults)~~ * Eliminate the need for implementing realize/unrealize, map/unmap, style_set and more, depending on how much offscreen rendering allows for this. * Implement a new base class widget for scrollable widgets that could help to simplify the implementation of widgets like text-view, scrolled window, tree-view. ~~(The Beast project has something resembling this here: http://beast.gtk.org/rdocu-gxk/gxkscrollcanvas.h.html)~~ * Resolution independence, this allows free scaling of UIs, including fonts, pixmaps and spacing/padding. ~~(David Zeuthen already started to work on this: [[http://blog.fubar.dk/?p=102 Resolution Independent GTK+]]. In a corresponding email thread, David explains how the features could be split up according to 2.x and 3.x dependencies: http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00044.html)~~ * Anything from the current 2.16 list that didn't make it in time: - support for icons in entries
Fixing EMail Addresses in GLib/Gtk+ bugzilla components
Hey All. Christian Dywan just pointed out to me that bugzilla-subscribing to [EMAIL PROTECTED] is not good enough to receive all Gtk+ related bug report emails. A little investigation [1] shows that most components look like this: Component | Description | Default Assignee | QA Contact gdk | GTK+ drawing kit| [EMAIL PROTECTED] | [EMAIL PROTECTED] gtk | GTK+ widgets ...| [EMAIL PROTECTED] | [EMAIL PROTECTED] Some however have people assigned: input-methods | Input method support in GTK+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] Some a QA-Contact: GtkFileChooser | The widget for file selection | [EMAIL PROTECTED] | [EMAIL PROTECTED] And some have bogus addresses: GtkBuilder | Constructing interfaces from XML | [EMAIL PROTECTED] | [EMAIL PROTECTED] To allow reliable subscription to all GLib/Gtk+ bugs, I suggest that: a) We *always* use [EMAIL PROTECTED] as "QA Contact" for components. b) We use "Default Assignee" in cases where individuals will tackle the majority of bug reports for a particular component. c) We don't use *any* fake gnome.bugs addresses, i.e. just let "Default Assignee" default to [EMAIL PROTECTED] if none signed up. [1] http://bugzilla.gnome.org/editcomponents.cgi?product=gtk%2B --- ciaoTJ ___ 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 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.
Yu
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)
On Fri, 26 Sep 2008, Peter Clifton wrote: On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote: As i said above, there is no need at all for micro speed optimization in these code paths. And using GTK_IS_HBOX() adds a type registration dependency, which prevents things like moving GtkHBox/GtkVBox into a different lib like libgtk3compat. Forget the micro-optimization on the string lookups. My real point was this: If you're leaving all the behavioual defaults for the old widgets in Gtk 3.0, then going to pains to detect "compat" replacement widgets with the old class names to change behaviour, then you might as well have just left the compat widgets in the library. For real cleanup, the widgets would have to be removed (including any special-casing of behavioural defaults). If that means the base-class of any compat widgets needs to support changing the defaults during inheritance, that looks to me like how it should be done. Right, but per-instance fields still aren't neccessary for this kind of special casing. Adding a single method needs_compat_defaults() that HBox/VBox would override to return TRUE is good enough to figure the specialized class bahviour (and allows moving HBox/VBox out of Gtk+ still). g_type_is_named() would just have been a lazy shorthand for this ;) Peter Clifton --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)
On Fri, 26 Sep 2008, Peter Clifton wrote:
On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
- Change additional defaults as needed, e.g.:
gtk_box_init (GtkBox *self)
{
gboolean compat_type =
g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
g_type_is_named (G_OBJECT_TYPE (box), "GtkVBox");
if (!compat_type)
gtk_widget_show (self); // GtkBox defaults to ::visible=TRUE
}
Why not store the defaults as class struct memebers. GtkBox can
initialise the class members to the new defaults, then the shallow
compat subclasses can override them.
Because it adds complexity and memory overhead without any neccessity.
This avoids the string compare for each operation where multiple
defaults exist. (I assume from the is necessary with the type lookup).
There is no need to avoid a string lookup here, widget packing is hardly
time critical (i.e. it totally pales compared to e.g. the time spent on
realizing, size requesting or size allocating widgets).
It also avoids leaving any trace of the names GtkHBox / GtkVBox in GTK.
It seems kindof silly remove the TINY API for using these old classes,
but have to retain lots of:
if (detect_old_class_names) {
foo;
else
bar;
Since the legacy is still there! Plus the code would presumably run much
faster if you could just do GTK_IS_HBOX() rather than look up the name
by string.
As i said above, there is no need at all for micro speed optimization
in these code paths. And using GTK_IS_HBOX() adds a type registration
dependency, which prevents things like moving GtkHBox/GtkVBox into a
different lib like libgtk3compat.
Peter Clifton
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Moving to GtkBox (Re: Minutes of the GTK+ Team Meeting - 2008-09-23)
On Thu, 25 Sep 2008, Mike Kestner wrote:
The types would essentially be
boilerplate, so it's not like they are going to be a maintenance issue.
If the motivation for removing the types is that, "things aren't as
beautiful as they could be" then that argument doesn't really outweigh
the pain of porting existing code. Especially when the cost of
supporting existing code is so low.
There doesn't really need to be any pain involved for the application
developers at all here. We've previously talked about libgtk3compat
(or libgtk3graveyard) and this looks like another good example for
having it. I.e. the box changes can look as follows:
- Make GtkBox a constructable widget (effectively introducing a new
user level widget as Mitch described)
- Add orientation switching to GtkBox:
gtk_box_set_orientation (GtkBox*, GtkOrientation);
This effectively moves all hbox_size_request, vbox_size_request,
hbox_size_allocate and vbox_size_allocate logic into gtkbox.c
- Make GtkHBox and GtkVBox very shallow compatibility types derived
from GtkBox. This involves one G_DEFINE_TYPE() macro and implementing
gtk_hbox_new and gtk_vbox_new as simple wrappers around g_object_new.
(They'd effectively call gtk_box_set_orientation() in their _init
functions.)
- Change the packing defaults for gtk_box_pack_start_defaults and friends
unless old compat types are detected, i.e.:
void
gtk_box_pack_start_defaults (GtkBox *box, GtkWidget *child)
{
gboolean compat_type =
g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
g_type_is_named (G_OBJECT_TYPE (box), "GtkVBox");
gboolean expand = compat_type ? TRUE : FALSE;
gboolean fill = compat_type ? TRUE : FALSE;
gtk_box_pack_start (box, child, expand, fill, 0);
}
I've used a new helper function g_type_is_named() here, since adding
that might be helpful in a couple other compat cases as well. It roughly
amounts to g_type_is_a (type, g_type_from_name (type_name)); and doesn't
require the checked for type to actually be registered.
- Change additional defaults as needed, e.g.:
gtk_box_init (GtkBox *self)
{
gboolean compat_type =
g_type_is_named (G_OBJECT_TYPE (box), "GtkHBox") ||
g_type_is_named (G_OBJECT_TYPE (box), "GtkVBox");
if (!compat_type)
gtk_widget_show (self); // GtkBox defaults to ::visible=TRUE
}
- The shallow compat types GtkHBox and GtkVBox could be moved into a
libgtk3compat that allows fine grained "undeprecation", e.g.:
#define GTK_DISABLE_DEPRECATED 1 // allow code cleanups
#define GTK_COMPAT_HBOX1 // still need GtkHBox though
So as long as GTK_COMPAT_{H|V}BOX are defined, *no* existing
application code will need changing.
- Locking the orientation for GtkHBox and GtkVBox widgets could be added
in addition, but I don't think it's strictly neccessary. After all,
GtkHBox and GtkVBox will continue as mere wrappers to help people in
their porting efforts and IMHO should be kept as simple as possible.
The officially supported box interface will be GtkBox anyway.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_assert() semantics is changed without announce
On Fri, 26 Sep 2008, Andrew Cowie wrote: On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen wrote: The important part of the assert semantics are: if the assertion fails, the program aborts. If you are using assertions in a way that make it important where or how the message is reported In the Java bindings we trap the log messages that are raised by assertions and propagate a (quite fatal) Java Exception instead. That quite nicely terminates the program, but in a way that a) gives the developer some idea of where things are wrong, and b) doesn't crash the VM in the process. Crashing VMs are rather frowned upon. The fact that assert uses the existing log facility is lovely. Please revert back to this! Thanks for the feedback and use case descriptions everyone, I can definitely see the point why people want to see g_assert() using g_log() be restored. Similar reasons do apply in the testing framework case though, e.g. assertion messages from test programs should be sent on to the gtester framework executavle for logging and should usually not pollute stderr. I'll investigate if we either: - Restore g_assert()s old logging behaviour unless g_test_init() has been called; or - Restore g_assert()s old logging behaviour unconditionally and just capture + redirect everything from g_log() to gtester after g_test_init() has been called. I hope that should fix everyone's issues. AfC Sydney --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: string return result conventions
On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote: ok - can i ask people a favour? could you kindly review e.g this: http://lkcl.net/webkit/DerivedSources/GdomAttr.cpp just looking at it myself, i think where i use fromUTF8 i have a memory leak, ... but after looking at it again i don't think i have.. there, but key question: in the use of g_value_set_string() - that "takes over" the memory passed in to it, right? ... i should be using g_value_take_string(), shouldn't i? g_value_set_string() duplicates your string internally. g_value_take_string() takes over ownership of your string and frees it with g_free(). That is, you might only pass in strings that have been allocated with g_malloc/g_new/g_strdup/g_*, because only those require a matching g_free() call. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: string return result conventions
On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote:
ok - in this situation, fortunately we have control over that. the
property getter is entirely auto-generated. the code review of the
new webkit glib/gobject bindings brought to light the webkit
convention of not imposing any "memory freeing" of e.g. strings on
users of the library. use of refcounting is done on c++ objects, for
example.
the strings in webkit are unicode (libicu). _at the moment_ i'm
alloc-sprintf'ing strings - all of them - into utf-8 return results.
it was recommended to me that i create a string pool system, to keep a
record of strings created, and, at convenient times, destroy them all
(reminds me of apache pools and samba talloc). exactly when is
"convenient" is yet to be determined, which is the bit i'm not too
keen on :)
We've done a simialr thing in beast (beast.gtk.org), where we pile up
strings in a garbage collector pool and free them, once the topmost
main loop level is reached. This works fairly well in practice, it
however does have the following downsides:
- Strings can't be kept used across main loop invocation:
foo = get_string();
gtk_main();
foo; // <- has been freed now
- Loops might build up extremely large temporary memory requirements:
for (i = 0; i < 100; i++)
gc_pool_add_string ("123456789");
Be aware that this loop needs 10MB. A more sophisticated GC pool
can be able to at least deal with:
for (i = 0; i < 100; i++)
{ foo = get_string(); gc_pool_free_early (foo); }
However that can still cause temporary bloat, if get_string() adds a
string to the GC pool internally without early freeing.
- Recursive main loops block the GC pool:
gtk_main();
dispatch_handler1(); // adds strings to GC pool that need freeing
gtk_main(); // recursive main loop blocks *any* GC pool freeing
So basically, there is no *convenient* time for string freeing in
C. Someone could always keep a pointer to a returned member around
somewhere. Because the event loop processing model most often recurses
down into handlers and comparatively quickly winds up the stack again,
the main loop coupled GC pool freeing tends to moderately work in
practice, but as shown above, it does come with severe potential
worst cases. Particularly the for() add_to_pool (pointer); case
is easily triggered implicitely.
clearly, the best overall thing would be to actually return the
unicode strings themselves rather than convert them (needlessly?) to
utf-8.
Strings handed out by the Gtk+ API and also strings passed in to Gtk+
API are/must be in UFT-8 format already, so there's no need for conversion
here.
if that's not possible to do, what would you recommend, in this situation?
many thanks,
l.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: string return result conventions
On Sun, 14 Sep 2008, Luke Kenneth Casson Leighton wrote: folks, hi, i'm looking for advice on memory return result conventions - who is responsible for maintaining andd/or freeing memory, in particular strings, as return results from pproperrty getting for example. the webkit-glib bindings are going extremely well, pywebkitgtk has them in use, however, the conventions for webkit are that the library maintains responsibility for any string management, such that users of the library do not have to worry about malloc or free. therefore it's important for me to find out what glib / gobject memory conventions are, for strings. Strings querried through the property interfacem e.g.: gchar *string = NULL; g_object_get (label, "label", &string, NULL); is always duplicated and needs to be a freed by the caller, because the returned string might have been dynmically constructed in the objects proeprty getter (i.e. not correspond to memroy actually allocted for object member storage). much appreciated your advice. l. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When to call g_thread_init(), again...
On Fri, 15 Aug 2008, Christian Dywan wrote: I think both is rather open for missunderstandings actually, before and after the improvement of the g_thread_init documentation. g_mem_set_vtable clearly asserts that it must be called *before anything else* and so does g_thread_init. There is no ambiguity with regard to when g_thread_init should be called as I see it. At best it's paradox that one is supposed to call two functions before each other, ie. before any Glib function. There's no *practical* ambiguity. If you really want to change the memory allocators, g_mem_set_vtable() needs to be called before *any* other glib function (because all glib functions can potentially allocate memory), including g_thread_init(). g_thread_init() really *should* be called before all other glib functions (except g_mem_set_vtable() which sets up the allocator vtable that's needed by everything in glib, including g_thread_init), but in practice we've been trying to make late g_thread_init() calls work nevertheless (Owen's decision AFAIK, because not doing so will potentially break a bunch of libraries on Unix/windows). About not calling g_thread_init() and using glib from different threads, or even using glib from threads that have been created by non-glib functions (like pthread_create), I'd say this is generally a _very_ bad idea. I'm not entirely sure wether it'll break GLib currently, but it may very well break badly in the future, if we ever want to make use of fast thread local storage: http://people.redhat.com/drepper/tls.pdf ciao, Christian --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: my ongoing fantasy of garbage collected C programming
On Tue, 5 Aug 2008, Britton Kerin wrote: I've tried several times now to get Hans-Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/gc/) working with gtk, but so far no luck. I found all the stuff about how to build glib to be GC friendly and set env vars and such, and then I rebuild almost all of the lib stack on top of it (except atk and the X libs themselves). I still end up with strange failures and seg faults that go away if I just remove -lgc from the link flags. I don't free anything by hand so its got to be something the GC is doing. I'm hoping that the presence of the gc-friendly build support in glib means that somebody knows how to make this work. I would really love to know how to do it. I won't go into the different gc builds and such that I've tried unless someone is interested. AFAIK, no one has tried to make boehm GC really work with glib & gtk+ programs so far. The "gc friendly" mode that glib has in general just zeros-out certain memory portions before calling free(), so GC-alike leak detectors like e.g. valgrind can do a more accurate job. Depending on how clever your GC implementation is, I'd actually expect quite some real world problems with it trying to "collect" glib memory. E.g. GLib only stores pointers into the _middle_ of fundamental GType nodes (not the node start) and with GSlice provides its own allocator that cannot be replaced with GC collection (the memory pages allocated by gslice.c:allocator_memalign are also not pointed to directly, a pointer to an admin structure at the page tail is kept instead). Thanks, Britton --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: va_list *
On Mon, 28 Jul 2008, Ryan Lortie wrote: ISO C99 (footnote 215, §7.15) says that this program is valid and should print out 1, 2, 3... Note that GLib can currently *not* rely on C99 features. That's a pity, but "no" is the oucome of our last discussion on this topic: http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00057.html "" Collects a variable argument value from a va_list. We have to implement the varargs collection as a macro, because on some systems va_list variables cannot be passed by reference. "" AFAIR, this was at least the case on systems that implemented va_list with an array type. Can anyone please weigh in on whether or not these "some systems" have gotten their act together yet? Is it still necessary to go out of our way like this in glib? I think it's best to simply switch to C99 at *some* point (e.g. next year? 2009 - C99 will be ten years old by then). At that point we *know* we can rely on features like va_list pointers. Before that, people are not forced to upgrade compilers, so there'll always be an ancient setup/system that breaks for new feature uses. Thanks in advance. Cheers --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Let gtk-doc grok GSEAL
Hi Stefan, as mentioned during the last IRC meeting: http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20080722.txt It'd be nice if gtk-doc understood the GSEAL macros. I guess the handling would be best, if: - GSEAL(field); is treated like /**/ field; - optionally, gtk-doc could ignore GSEAL(), so we can still generate docs for older gtk versions where some unsealed fields are treated as public read-only API. Could you please look into supporting this? --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GUADEC 2008 GTK+ Meeting Minutes
Hey All. Kris took meetings during the GTK+ developers meeting at this years GUADEC. It took some time to transform them into a proper writeup, and Kris had to leave for a vacation flight before he could finish them off. So here are the minutes from Kris with a few finishing touchups from me. Please keep in mind that these minutes are from our meeting 2 weeks ago, and thus don't reflect on recent community discussions and new tweaks to the 3.0 plans. For an update on our latest plans, please have a look at the summary of yesterdays IRC meeting: http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00187.html GTK+ Meeting, 8 July 2008, GUADEC 2008 -- Final agenda: 1. Opening 2. 2.14 release overview 3. Planning GTK+ 2.16 - Features - Schedule 4. 3.0 - Current status - Schedule 5. Technical discussions - 3.0 policy - Sealing GtkRcStyle - Offscreen rendering event processing - New GDK backend that renders into image buffers 6. Closing Notes: 1. The meeting was opened at 12:10. 2. Last year we have promised to get GTK+ 2.14 out of the door around GUADEC 2008. We are closely approaching this date and we seem to be mostly feature complete. The testing framework bits have landed in GTK+, as well has the first part of the offscreen rendering work. Furthermore, a lot of small API improvements, bug fixes and clean ups have been done. The remainder of the offscreen rendering work deals with event processing and is hard to get right (more on this later in the meeting). If we wait for this to land we will most definitely not make the GUADEC 2008 release date. Therefore the current plan amongst the core developers is to delay the second part of the offscreen rendering work to the next release and get GTK+ 2.14 released in its current shape. After asking whether people have more pending features that could make it into 2.14, nobody has something ready that could go in at this point. Mitch still wants to get new adjustment API (accessors for it) in 2.14 if possible. During the next IRC meeting the team would like to propose to API freeze the next development release and release the stable 2.14 after a few weeks of stabilization. 3. It was mentioned that Behdad has requested us to consider renaming to "GTK+ toolkit" and change the license to GPL3. The renaming to "GTK+ toolkit" issue has already been handled in bug #540529 and will not be done. Changing the license to GPL3 (in GTK+'s case LGPL3) is a long process and is not planned to be carried out immediately. In any case we do not want to block a possible GTK+ 3.0 on a license change. A recent discussion on the mailing list left the impression that some implications in mixing LGPL3 code with LGPL2 code still have to be figured out. Apart from offscreen rendering part 2, the following items are on the agenda for GTK+ 2.16: * Mathias Hasselmann's extended layout work. Plans are to start API review soon. * Mathias Hasselmann's tool palette. The tool palette is a "tool box" as found in for example the Glade UI builder and GIMP. It will undergo some more real world testing as it will be tried to replace Glade's toolbox with the tool palette. After that remaining kinks in the API will be ironed out and a proposal send to the mailing list for discussion. * Libsexy integration. This is something that has been on the list for a couple of years now. Libsexy certainly contains some nice features and there are no objections if these get merged at some point. The problem is that so far nobody has stepped up to actually cherry pick features from libsexy and get them in such a form so that inclusion in GTK+ can be considered. Lately Cody Russell has been working on getting an "icon entry" going for GTK+. If his work continues we hope to get a few libsexy improvements in GTK+ 2.16. * Simpler API to create a simple ListView, a wrapper around GtkTreeView to make simple list creation without MVC split easy. Kris has been discussing such an API with Johan Dahlin and Emmanuele Bassi as they are familiar with the Python and Perl variants of simple lists APIs respectively. The Python and Perl APIs seem nice and similar, we want to attempt to come up with something similar for C. Further ideas that were raised: * Add a new signal to GtkTreeModel that inserts a given number of rows in one go. Kris argues that this is only part of a bigger problem: we want to have a proper batch/transaction API in GtkTreeModel. We shouldn't just add this single signal for now, but sit down and properly design this transaction based API and try to get it right for most use cases. * How to do extend the print dialog? Tim advises to file patches implementing these extensions in bugzilla. * What is happening on the "GLib foundation library" front? This foundation library is supposed to become a general desktop support abstr
Re: libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)
On Thu, 17 Jul 2008, Sven Herzberg wrote: Hi, Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik: On Thu, 17 Jul 2008, Martin Meyer wrote: 2) Is it entirely possible from a gtk perspective to have all that code detached from gtk-core and placed in a different library? Are there any deprecated things that this would *not* work for? Maybe we can detach as many as possible and leave the rest in place for now. Complete deprecated widgets should be fairly easy to separarte, single deprecated functions that some components may have can be hard to impossible to move when the implementation requires access to internals. But this could be worked around with a strange compile setup, right? With something like this: ~/sources/gtk+ ~/sources/gtk-deprecated and gcc -I$(top_srcdir)/../gtk+/gtk to access potential gtkwidgetpriv.h, right? Would mean "recompile with every source change to gtk+" but if some (many?) people depend on this, I think they can easily distribute the burden of maintaining a parallel version. There is no point in having libgtk3deprecated access gtk+ internals and not go through public interfaces only. If we did that, we'd simply preserve the maintenance burden on Gtk+ internal definitions. We really want to get rid of a bunch of stuff, be free to refactor structures and internal methods to implement new things cleanly. If libgtk3deprecated kept acessing and relying on internals it'd either constantly break or hinder us on doing reorganisations. Also, this'd tie release cycles and maintenance resources of libgtk3deprecated closely to Gtk+ again. The main point in seperating deprecated code is to load off the core team though, so application developers or distributors that still have an interest in deprecated components can take over its maintenance as long as that's necessary. A closing word on the library name, since this'd be an ABI break, such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should probably advertise that it ships deprecated Gtk+ stuff. So the best name is probably libgtk3deprecated for this (there could possibly be a libgtk4deprecated as well at some point). Well, so GTK+ 4.0 could be accompanied by these two: libgtk3deprecated-4.0.so libgtk4deprecated-3.0.so Right? I'd guess that if deprecated 2.x components that landed in libgtk3deprecated are still required when a libgtk4deprecated is released, they could possibly need some porting and simply be included as real parts of libgtk4deprecated. This is highly speculative though and can be considered when we have the Gtk+-4.0 discussion. We're not quite there yet ;) Regards, Sven --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)
On Thu, 17 Jul 2008, Martin Meyer wrote: Several people have mentioned the "move the deprecated stuff into a separate library" idea. Can we get some concrete answers on: 1) Would this satisfy the various apps still using the deprecated code? i.e. is it OK to depend on this different library in the future in addition to gtk-3? Are there any arguments against this, aside from the effort/time involved? It'd certainly reduce the pain for application developers that still use deprecated widgets such as CTree or ItemFactory. 2) Is it entirely possible from a gtk perspective to have all that code detached from gtk-core and placed in a different library? Are there any deprecated things that this would *not* work for? Maybe we can detach as many as possible and leave the rest in place for now. Complete deprecated widgets should be fairly easy to separarte, single deprecated functions that some components may have can be hard to impossible to move when the implementation requires access to internals. 3) How long / how much effort would it be do to this? Is it something that has to be done by experienced GTK hackers or can it be handled as a side project? I think any moderately experienced developer could tackle this (e.g. someone who has implemented his own widget at some point). A closing word on the library name, since this'd be an ABI break, such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should probably advertise that it ships deprecated Gtk+ stuff. So the best name is probably libgtk3deprecated for this (there could possibly be a libgtk4deprecated as well at some point). Martin --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96
On Tue, 15 Jul 2008, Alessandro Vesely wrote: This discussion reminds me that smc_notify_tree() does not actually check which thread does a chunk belong to. Could that result in misbehavior? No, chunks may be freely passed back and forth betwen threads without problems. Except for a few blocks that fit into 2*magazine_size, all allocations are shared between all threads anyway. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GProxy, Dynamic Method Invocation
On Tue, 1 Jul 2008, Mikkel Kamstrup Erlandsen wrote: Over the past few weeks I have been pondering a way to add dynamic method invocation and introspection to GObjects. I am meaning to implement this myself (unless someone else really want to do it), if the reception is luke-warm or better :-) You can find the draft here: http://live.gnome.org/MikkelKamstrup/GProxyIdea you might want to follow the links to GPlugin there, but that page is still a bit messy... What I would like to discuss is: * Is this utter insanity? In your emails and on the wiki pages you say (combined): - your implementation shouldn't use code generation; - you don't want to use libffi to call C methods. How then, do you actually want to implement dynamic method invocations, given that all you can hope to get from GModule is an opaque function pointer once a method is found? Cheers, Mikkel --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib unit testing docs (Re: proposal about glib)
On Wed, 25 Jun 2008, [EMAIL PROTECTED] wrote: hi 2）I use glib's Testing, but documentation is missing. There was no guide for how to set up your own project to use the glib testing framework or higher level overview of setup/teardown, available asserts, running, parameters, etc. Quick Guide: http://blogs.gnome.org/timj/2008/06/24/23062008-writing-unit-tests-with-glib/ Mini HOWTO: http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00181.html Reference documentation: http://library.gnome.org/devel/glib/stable/glib-Testing.html The initial proposal provides a high level overview of the main driving design aspects: http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg0.html For more general introductions to unit testing, the email recommends: [1] "xUnit Test Patterns: Refactoring Test Code" by Gerard Meszaros. book:http://www.amazon.com/dp/0131495054 wbesite: http://xunitpatterns.com/ (the website is really good as it described many patterns introduced in the book) [2] "Simple Smalltalk Testing: With Patterns" by Kent Beck. link: http://www.xprogramming.com/testfram.htm [3] "JUnit Test Infected: Programmers Love Writing Tests" by Eric Gamma and Kent Beck link: http://junit.sourceforge.net/doc/testinfected/testing.htm (Excellent introduction to automated unit testing) thanks --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-doc installation broken
Hi Stefan. gtk-doc continues to produce problems when compiling the gtk.modules module from jhbuild, this time it's during installaiton: *** Installing gtk-doc *** [5/14] make install Making install in help make[1]: Entering directory `/usr/src/gtk+head/gtk-doc/help' Making install in manual make[2]: Entering directory `/usr/src/gtk+head/gtk-doc/help/manual' make[3]: Entering directory `/usr/src/gtk+head/gtk-doc/help/manual' make[3]: Nothing to be done for `install-exec-am'. /bin/bash /usr/src/gtk+head/gtk-doc/install-sh -d /usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C /localhome/tjlocal/bin/install-check -m 644 C/fdl-appendix.xml /usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C/fdl-appendix.xml /localhome/tjlocal/bin/install-check -m 644 C/gtk-doc-manual.xml /usr/src/gtk+head/installation/share/gnome/help/gtk-doc-manual/C/gtk-doc-manual.xml /bin/bash /usr/src/gtk+head/gtk-doc/install-sh -d /usr/src/gtk+head/installation/share/omf/gtk-doc-manual /localhome/tjlocal/bin/install-check -m 644 gtk-doc-manual-C.omf /usr/src/gtk+head/installation/share/omf/gtk-doc-manual/gtk-doc-manual-C.omf scrollkeeper-update -p /var/lib/scrollkeeper -o /usr/src/gtk+head/installation/share/omf/gtk-doc-manual /var/lib/scrollkeeper/scrollkeeper_docs: Permission denied make[3]: *** [install-doc-omf] Error 1 make[3]: Leaving directory `/usr/src/gtk+head/gtk-doc/help/manual' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/usr/src/gtk+head/gtk-doc/help/manual' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/gtk+head/gtk-doc/help' make: *** [install-recursive] Error 1 *** error during stage install of gtk-doc: ## Error running make install *** [5/14] The jhbuild runs as user tjlocal on this system and installs into a user writable prefix. /var/lib/scrollkeeper/scrollkeeper_docs couldn't possibly be user-writable in that setup. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSEAL branch merge
On Fri, 20 Jun 2008, Hans Breuer wrote: Am 20.06.2008 14:44, Tim Janik schrieb: Hey All. As discussed during previous IRC meetings: http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00194.html The GSEAL branch has been merged into upstream today. With the patch attached (and some minor things already commited) it does compile again with msvc. The code where I'm not 100% sure is from the GSEAL branch and gives: gtkmenu.c gtkmenu.c(825) : error C4047: 'function' : 'int ' differs in levels of indirection from 'struct _GtkWidget *' gtkmenu.c(825) : warning C4024: 'g_value_set_boolean' : different types for formal and actual parameter 2 Ok to commit? Yes, thanks, please commit. Thanks, Hans --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSEAL branch merge
On Fri, 20 Jun 2008, Christian Persch wrote: Hi; what's the purpose of sealing the "GtkFooPrivate *priv" members of GtkFoo structs? Those are opaque pointers that code outside of gtk cannot access anyway. And in gtk+ itself using obj->priv is just a pointer deref while using G_TYPE_INSTANCE_GET_PRIVATE which you replaced it with is more costly than that. Inside Gtk+ it doesn't make a difference, and code that copied structure definitions from gtk's .c files to access ->priv pointer internals anyways can now be automatically spotted with -DGSEAL_ENABLE. Christian --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GSEAL branch merge
Hey All. As discussed during previous IRC meetings: http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00194.html The GSEAL branch has been merged into upstream today. At public request, I'm attaching the resulting diff from git to this email. A similar diff can be retrieved from upstream now with: svn diff -r20477:20634 --- ciaoTJ gseal-r20477-r20634.diff.bz2 Description: gseal-r20477-r20634.diff.bz2 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Offscreen pixmap redirection available
Hey All.
The Offscreen redirection rendering bits have been committed to upstream SVN
some while ago:
Bug 318807 – Offscreen windows and window redirection
Note that the offscreen event processing is not in SVN yet and planned to be
worked on after GUADEC. I'd actually like to discuss some of the event
processing logic bits with other core developers during GUADEC, probably best
during our Gtk+ development BOPF on Tuesday:
http://guadec.expectnation.com/guadec08/public/schedule/grid?date=2008-07-08
Until then, I'd like to ask everyone with an interest in the offscreen
rendering business (canvas authors, etc.) to scrutinize the current offscreen
rendering implementation and API, ideally by testing gtk_widget_get_snapshot()
for your particular uses. Anything that can be spotted now can be *fixed* now,
i.e. before the next stable Gtk+ realease, so please look into early testing
if at all possible.
/**
* gtk_widget_get_snapshot:
* @widget:a #GtkWidget
* @clip_rect: a #GdkRectangle or %NULL
*
* Create a #GdkPixmap of the contents of the widget and its children.
*
* Works even if the widget is obscured. The depth and visual of the
* resulting pixmap is dependent on the widget being snapshot and likely
* differs from those of a target widget displaying the pixmap.
* The function gdk_pixbuf_get_from_drawable() can be used to convert
* the pixmap to a visual independant representation.
*
* The snapshot area used by this function is the @widget's allocation plus
* any extra space occupied by additional windows belonging to this widget
* (such as the arrows of a spin button).
* Thus, the resulting snapshot pixmap is possibly larger than the allocation.
*
* If @clip_rect is non-%NULL, the resulting pixmap is shrunken to
* match the specified clip_rect. The (x,y) coordinates of @clip_rect are
* interpreted widget relative. If width or height of @clip_rect are 0 or
* negative, the width or height of the resulting pixmap will be shrunken
* by the respective amount.
* For instance a @clip_rect { +5, +5, -10, -10 } will
* chop off 5 pixels at each side of the snapshot pixmap.
* If non-%NULL, @clip_rect will contain the exact widget-relative snapshot
* coordinates upon return. A @clip_rect of { -1, -1, 0, 0 }
* can be used to preserve the auto-grown snapshot area and use @clip_rect
* as a pure output parameter.
*
* The returned pixmap can be %NULL, if the resulting @clip_area was empty.
*
* Return value: #GdkPixmap snapshot of the widget
*
* Since: 2.14
**/
GdkPixmap* gtk_widget_get_snapshot (GtkWidget*widget,
GdkRectangle *clip_rect);
---
ciaoTJ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:
> On Tue, 3 Jun 2008 13:34:13 +0200
> Kristian Rietveld <[EMAIL PROTECTED]> wrote:
>
>> 4. We will completely lose all means to simply access fields by just
>> dereferencing the structure. Instead, we will start to use GObject
>> properties to access this data much more often. Using g_object_[sg]et()
>> can become a little tedious. Therefore we should introduce a couple of
>> convenience accessors for GObject properties such as g_object_get_int(),
>> *double(), *string(), etc.
>
> Because of the dynamic nature of the GObject property system, this
> would also bring a substantial performance overhead,
No, it won't. Simply because the vast majority of widget field accesses
are not time critical. E.g. reading out GTK_LABEL (widget)->text is something
that rarely happens more than once or twice per X event being processed.
So it really doesn't matter whether you use a field access here, a
simple getter function, a dynamic property accessor or a signal emission
to figure the value.
We have only a few cases, where performant field accees is desired, e.g.:
GtkWidget *toplevel = widget;
while (toplevel->parent)
toplevel = toplevel->parent;
For such cases, where additional overhead could actually show up in the
profiles, we are providing helper functions, see gtk_widget_get_toplevel().
> Note that I don't propose to abandon the dynamic access functionality,
> which is certainly useful and desirable in a number of specific
> situations. I simply point out that the performance penalty of dynamic
> access is unjustified for static use.
Note that most often you can use very simple and fast getter functions
instead of the dynamic proeprty interface:
G_CONST_RETURN gchar *
gtk_label_get_text (GtkLabel *label)
{
g_return_val_if_fail (GTK_IS_LABEL (label), NULL);
return label->text;
}
Other than that, I'd have to see reproducable performance profiles for
things claimed to be "unjustifyably" slow, to consider changes/fixes.
> --
> Jean-Yves Lefort <[EMAIL PROTECTED]>
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
On Tue, 3 Jun 2008, Vincent Geddes wrote: > Hi, > > Any chance of using C99 for GTK+ 3.0? its a pretty good improvement > over ANSI C in many respects. > > Various resources: > 1. http://www.ibm.com/developerworks/library/l-c99.html > 2. http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00057.html After the discussion we had in 2006, I'd rather not have this get into the way of Gtk+-3.0. I'm mentally preparing to have this discussion again in 7+ months though, because by then C99 is a decade old standard ;) That could mean it's 3.1 material though. > Vincent --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
On Tue, 3 Jun 2008, Alberto Mardegan wrote: > ext Kristian Rietveld wrote: >> 10. Remove all structure fields from the public API. There are two ways >> this can be done: >> a) Move object structures to private headers. >> b) Move object structures to the local C file, the rest of GTK+ will then >> also have to use accessors. > > If you go for (a), will the private headers be installed in the target > system? No, definitely not. "private headers" here means "internal", in that they'll be accessible only from within the Gtk+ source tree during the gdk and gtk library builds. > I've often felt that subclassing a GTK+ widget to modify its > functionality is usually harder than creating a new widget from scratch > (copying from the GTK+ code), as accessing the parent private members is > impossible, and many members that could be useful for a derived class > are in the private struct. > > I like the Python way of doing it (by mangling the members name you want > to protect, so the client must really know what he's doing when > accessing it); I would find it useful if private GTK+ were private but > somehow accessible (at least from derived classes). This would essentially make the fields part of our (semi-)public API, and that in turn means we need to preserve their behaviour compatibly. This is something we cannot provide and which gets us into much trouble currently when we try to fix bugs or optimize/improve the current code base. However, if instead the public API is defined only in terms of function entry points (object properties and signals are essentially provided via functions as well): - We can add compatibility code to those functions to emulate old behaviour on top of a changed code base. - We can establish a clear migration procedure for any particular feature by adding new functions and deprecating old ones. - We can provide compile time and runtime warnings for deprecated functions to aid developers in migration. > Ciao, > Alberto --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: questions about g_object_unref.
On Sun, 1 Jun 2008, Yu Feng wrote:
> 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?
no, it loops until object->ref_count == old_ref-1, which implements
the functionality outlined in the comment. you possibly want to read
up on g_atomic_int_compare_and_exchange() and maybe CAS (compare-and-swap)
algorithms in general.
> Yu
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Offscreen rendering & Redirection
On Sun, 13 Apr 2008, Rémi COHEN-SCALI wrote: Hi Bug #318807 is a patch for implementing offscreen rendering and events redirection. I'am in the process of finding a way to implement efficient graphics effect with Gtk+ and this approach is very interresting (pigment, etc). I tried to exercise it but without a lot of success (partly running). I have two requests for the devel community: 1) have your feelings about this way (or others) to had advanced graphics effects 2) have help to have this patch running svn co gtk+/trunk. The offscreen *rendering* portion is in SVN now and should be fairly stable. Next on my list are unit tests for this and then the offscreen event processing bits. Thanks for any help and thanks for this fantastic work. /me passes this on to Alexander Larsson Remi --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: My commit to glib and gtk+ - Bug #503071
On Tue, 20 May 2008, Yair Hershkovitz wrote: > Hi, > > For those who are still not familiar with the issue, you have a lot to > read in bug #503071 comments. > > I would like to explain my view of the un-allowed commits I've done in > glib and gtk+. Thanks for the patch and your input Yair, but for glib and gtk+ we have fairly simple rules, patches need review and approval before they can go in. The changes are reverted now, please use patch submission as future means for getting changes into GLib and Gtk+ like everyone else does. If you're not satisfied with our current processing speed and maintenance situation, please consider: http://blogs.gnome.org/timj/2008/05/16/16052008-becoming-a-gtk-maintainer/ > Thanks for reading, > Yair. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fixing 32/64 bit semantics of long (Re: GLib and 64-bit Windows)
On Wed, 30 Jan 2008, Owen Taylor wrote: > I'm not sure what you you are asking here. What I was saying is that > changing vtable members is more likely to break things than changing > function prototypes. Ok, but then, every prototype change can be a "vtable change", given a custom vtable that has a slot expecting a certain glib API function type, as in the g_realloc() pointer example. (Yes, i realize that you were referring only to vtables exported by glib ;) >> if i understand you correctly, you mean to imply that we also fix the >> signatures from *long to *size as well for the following functions >> (comprehensive list of *long API in glib/glib/*.h): >> >> >> gdouble g_timer_elapsed (GTimer *timer, >>gulong *microseconds); > [...] > > No, I didn't mean that, because > > gdouble g_timer_elapsed (GTimer *timer, > size_t *microseconds); > > gulong microseconds; > > g_timer_elapsed(timer, µseconds); > > Will warn in many many situations on many platforms, and MSVC will warn > about: > > gsize g_utf8_strlen (const gchar *p, > gssize max); > > long value = g_utf8_strlen(p, max); > > even when compiling for 32 bits. So I don't consider changing out > parameters and returns from long => size_t compatible. H... I think it makes sense to distinguish between changing long value types and *long pointer types. The former is unlikely to cause major breakage. The exception being custom vtables that expect particular prototypes in GLib and possibly return type size warnings (though a case can be made for wanting those warnings i think). We currently have these semantics for GLib types wrg 32/64bit portability: gint32 - 32bit on all platforms gint64 - 64bit on all platforms glong - 32bit on 32 bit platforms & Win64, 64bit on 64 bit platforms gsize - 32bit on 32 bit platforms, 64bit on 64 bit platforms ptrdiff_t - 32bit on 32 bit platforms, 64bit on 64 bit platforms That is, glong is pretty much useless. If a type is needed that reliably widens size on 64bit system (usually needed to store pointer values or larger memory offsets/sizes), we actually have to use gsize. These are the possibilities i see to solve this: 1) Define glong to ssize_t on Win64. This'll break the assumption that long==glong on all platforms though. 2) Search+replace our headers for glong -> gssize (i.e. what i suggested in my previous email). 3) Introduce a new type, e.g. "gwide/guwide": #ifdef _WIN64 typedef ssize_t gwide; typedef size_t guwide; #else /* !_WIN64 */ typedef glong gwide; typedef gulong guwide; #endif Then search+replace our headers for it, i.e. glong -> gwide. This preserves "long"-ness on all currently existing platforms, and still allows the repsective API for Win64 to be 64bit wide. Further notes: - Deprecate usage of "long/glong" in public headers. This should be part of our policy in any case. Long simply has unclear semantics, gint32/gint64/gsize have clear semantics wrt to 32bit/64bit platforms. Deprecate use of "gwide" in favor of gint32/gint64/gsize, this type is only needed in places where we used to have glong in public API for historical reasons. - When i say "search+replace", i'm including the types used in the G_TYPE_LONG API, e.g. g_value_set_long(). Changing glong->gssize or glong->gwide there might look surprising, but provides clear calling semantics. In retrospect, i shouldn't have added support for longs to GType in the first place... Out of the above, i think (1) provides potentially bad pitfalls, because it's surprisingly inconsistent with other glib types. The ideal solution might be (2), and i think it's worth putting it into place in a future devel branch of GLib, with the option of falling back to (3) if (2) turns out to cause bad breakage in practice. I.e. (3) might be needed anyway for long pointer types as you pointed out above, but that's the minority of API changes (11 out of 57). Functions with long pointers: g_timer_elapsed g_utf8_to_utf16 g_utf8_to_ucs4 g_utf8_to_ucs4_fast g_utf16_to_ucs4 g_utf16_to_utf8 g_ucs4_to_utf16 g_ucs4_to_utf8 gdk_colors_alloc gdk_colors_free GdkEventClient Functions/structures with long arguments and return values: GHookList g_hook_destroy g_hook_get G_STRUCT_OFFSET G_STRUCT_MEMBER_P GOptionEntry g_thread_create_full g_usleep g_time_val_add GTimeVal g_utf8_offset_to_pointer g_utf8_pointer_to_offset g_utf8_strlen g_snprintf g_vsnprintf g_bit_nth_lsf g_bit_nth_msf g_bit_storage g_signal_connect_object g_param_spec_long g_param_spec_ulong GParamSpecLong GParamSpecULong g_signal_add_emission_hook g_signal_remove_emission_hook g_signal_connect_closure_by_id g_signal_connect_closure g_signal_connect_data g_signal_handler_block g_signal_handler_unblock g_signal_han
Re: recurrent spam from applications developers [was: GtkListStore with GtkBuilder]
On Tue, 22 Apr 2008, Guillaume Cottenceau wrote: > How about renaming gtk-devel-list into gtk-core-library-devel or > something like that? Renaming the list would definitely take it too far, some noise will always be present and the current off topic emails are by no means at a critical volume. > Also, on http://gtk.org/mailing-lists.html: > > This list is for developers of GTK+ to discuss code. General GTK+ > questions should not be asked on this list, as that is more > appropriate for gtk-app-devel-list. > > => > > This list is for developers of the core GTK+ library to discuss > GTK+ implementation. GTK+ applications development, and general GTK+ > questions, should not be asked on this list, as that is more > appropriate for gtk-app-devel-list. Thanks, i've integrated this into the list info here: http://mail.gnome.org/mailman/listinfo/gtk-devel-list Martyn, i'd be nice to have the website updated accordingly as well. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
On Sun, 16 Mar 2008, Bastien Nocera wrote: > On Sat, 2008-03-15 at 21:48 +0100, Tim Janik wrote: >> Our headers currently state: >> * This library is free software; you can redistribute it and/or >> * modify it under the terms of the GNU Lesser General Public >> * License as published by the Free Software Foundation; either >> * version 2 of the License, or (at your option) any later version. > The LGPL also says: > To protect your rights, we need to make restrictions that forbid > anyone to deny you these rights or to ask you to surrender the rights. > > Which means you can't add more restrictions to the license without > effectively relicensing. We're not retro-changing the license of anything that has been released already, so we're not restricting rights anyone already has. We're talking about modifying & redistributing future versions of GLib & Gtk+ under LGPLv3, which the license clearly allows. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
On Sat, 15 Mar 2008, Andrew Cowie wrote: > This topic was discussed recently on foundation-list. > > http://mail.gnome.org/archives/foundation-list/2008-March/msg00032.html > > In summary, attempting to relicence the library would be, in practise, > impossible. > > No further benefit is gained by discussing this topic further. Updating the glib & gtk+ headers to LGPLv3 is not relicensing. Our headers currently state: * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. So, everone is allowed to "redistribute [...] under the terms of the GNU Lesser General Public License [...] version 2 [...] or [...] later", which LGPLv3 fullfills. Accepting LGPLv3 submissions in the future means that the library as a whole would effectively become LGPL >= 3 licensed. So then, we might as well adapt our headers to reflect this. > AfC > Berlin --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Visions from the hackweek
Hello Gtk+ Crowd. Together with Sven Herzberg, I'm currently sitting in an ICE back to Hamburg and would like to thank everyone for a really productive week. I think, i couldn't possibly list all the achievements of the various groups during these days, but thankfully some people have promised to send short summaries of sessions they attended ;) (We'll try to put more emphasis on note taking and/or recording when we do this again.) Monday morning we started out with a presentation of future visions around the Gtk+ project and possible ways to enabling them. We much appreciate the positive feedback we already got in response and tried to channel that into a document to fill in details about the presentation: http://developer.imendio.com/sites/developer.imendio.com/files/imendio-gtk-vision.pdf Original slides: http://inverted-tree.livejournal.com/58280.html Further comments are of course welcome, we intend to keep the document updated as new issues are raised/solved. Again, big thanks to everyone contributing to a productive week, especially the organizers and also sponsors that enabled us to get together and prepare the future of the toolkit that is vital for so many projects out there. I sincerely hope we'll manage to realize all the constructive plans we came up with during this. ;) --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk demo look and feel
On Fri, 7 Mar 2008, Alberto Ruiz wrote: > Hi all, > now that we have a new Gtk+ logo and we follow the Tango guidelines, > wouldn't be a good time to replace the so '90s-ish images from the demo? > > On my last blogpost[0] I demoed the Gdi+ pixbuf loader animation support > with new images using the Gtk+ logo and tango icons. > > Would it be okay to commit this stuff into trunk? can you please file a bug report with the patch attached, so this can go through normal review like everything else? > [0] http://aruiz.typepad.com/siliconisland/2008/03/gtk-foo.html > -- > Cheers, > Alberto Ruiz > --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
visible window rectangle in pixmap redirection
hi Alex. it'd be great if you could take a look at my latest comment on the offscreen windows bug report, i.e.: http://bugzilla.gnome.org/show_bug.cgi?id=318807#c48 it adresses just the pixmap redirection portions that you split off some while ago and lists remaining issues that need solving before inclusion. in particular, i'd like to know: - gtk_widget_get_snapshot() is supposed to snapshot whole widgets (i.e. all of widget->allocation.width/height). so why is gdk_window_end_paint() calling _gdk_window_calculate_full_clip_region() (indirectly via setup_redirect_clip()) to constrain the redirected area to the visible widget area? - why is _gdk_windowing_window_get_visible_rect() a backend specific function? couldn't we get the visible rectangle of a window from window->parent->width/height and window->x/y? - i'm wondering if there is a use case at all for snapshooting *only* the visible area of a widget. i think the semantics of gtk_widget_get_snapshot() are fine if it snapshoots all of a widgets allocation, and i'd like to get rid of all the clip-to-visible-rect logic. if there is indeed a use case for snapshoting only the visible portion of a widget (afaics relevant in scrolled window contexts only), we should be able to simply provide: void gtk_widget_get_visible_rect (Widget*, Rect*); that provides coordinates for use with gtk_widget_get_snapshot(). thanks for the patch in the first place. i think the above are the last major issues left before pixmap redirection can go in. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting -- 12 February 2008
On Tue, 12 Feb 2008, Emmanuele Bassi wrote: > hi everyone; > > this is the usual reminder for the IRC GTK+ Team Meeting. the meeting > will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 > UTC[1]. thx. > the points are: > > * Remove linux-fb backend because it's unmaintained since stone age (mitch) > * Add GRegion (bug 508540) (Benjamin Otte) > * Offscreen redirection (bug 318807) (ebassi) > * Miscellaneous i'd like to add: * Migrating gtk.org contents to the machine that is currently cube.gtk.org hope Shawn will attend. > eventual changes will be notified on the wiki page[0]. > > everyone can participate, as usual. > > ciao, > Emmanuele. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Hosting Windows Binaries
On Thu, 24 Jan 2008, Shawn Amundson wrote: > Martyn Russell wrote: >> no sysadmins seems to be stepping forward regarding this. >> >> As a result, this will have to wait. >> > > I'm willing to do whatever it takes to help improve gtk.org. As > such, I will provide my services as sysadmin. thanks, that's much apprechiated, especially as the hardware/space situation on gtk.org is becoming worse and worse (we're aware of HW resource shortages for probably 3 years now, and they have been increasing). > I think a CMS is an excellent idea. Are there any opinions on > what would be the best solution? How about drupal? i think we should approach this incrementally. i.e. it's probably best to: 1) get the new web design in place that Andreas and Martyn have been working on. 2) setup a cloned web site on cube. (i'll drop you a line when i have time to look into replicating the web installation setup there.) 3) switch over DNS. 4) look into any future extensions like CMSes. (currently we're fine with using live.gnome.org, so we don't have any urgent issues to fix here.) > Mid-march will be gtk.org's 10th birthday! ;-) > -Shawn --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
On Mon, 28 Jan 2008, Olav Vitters wrote: > On Mon, Jan 28, 2008 at 02:30:14PM +, Martyn Russell wrote: >>> http://imendio.com/~martyn/gtk/draft-final/download-linux.html >>> * outdated versions >> >> You disagree? It might not make sense to list unsupported versions here >> I agree, but we should definitely list older versions. > > No, I mean that it doesn't show e.g. 2.12. Don't mind about older > versions. > >>> http://imendio.com/~martyn/gtk/draft-final/documentation.html >>> * under API, perhaps s/Library/Component/ or something? >> >> I prefer Library, since they are libraries. > > Shouldn't Library be used for the collection of API docs? IMO gtk+ has > e.g. an API reference. The combination of all that stuff could be called > a library. gtk.org already links to library.g.o for API docs, it also redirects faq and tutorial2.0 accesses to library.g.o now. we still have a static version of the tutorial1.2 there though, because it's not provided by library.g.o. what is most unfortunate is that library.g.o only has glib development docs, but not gtk development docs. having development docs readily available is fairly important to talk about new stuff and get reviewers interest. (building those can easily be automated via buildign the gtk+.module jhbuild module.) > -- > Regards, > Olav --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and 64-bit Windows
On Mon, 5 Mar 2007, Owen Taylor wrote:
> On Mon, 2007-03-05 at 12:21 -0500, Jake Goulding wrote:
>> goption.c(994) : warning C4267: 'function' : conversion from 'size_t' to
>> 'gulong', possible loss of data
>> change->allocated.array.data = g_renew (gchar *,
>> change->allocated.array.data, change->allocated.array.len + 2);
>>
>> And more. It sure looks like most of them have to do with the allocation
>> functions, which all seem to take ulongs as opposed to size_t.
>
> Hmm. I think in terms of gmem.h we probably should try to fix the
> ulong/size_t situation. There is currently no ABI for GLib/Win64, so we
> don't have to worry about a binary compatibility issue with changing the
> prototype. And on all other platforms I know of gsize and ulong are the
> same size.
agree. this exact API was actually written with sizeof(long)==8 on 64-bit
platforms in mind:
2008-01-29 14:58:31 Tim Janik <[EMAIL PROTECTED]>
* glib/gmem.[hc]: changed size argument type from gulong to gsize as
discussed on gtk-devel-list:
http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
this should be ABI compatible on all platforms except win64 for which
no ABI binding port exists yet.
> There *are* platforms where gssize is an unsigned integer rather than an
> unsigned long, but my general feeling is that just changing the gmalloc
> prototypes is unlikely to cause problems; GMemVTable, which would be
> more likely to cause warnings already has gsize there.
i suppose you mean gsize (which is always unsigned), because gssize is
always signed.
> There are going to be other situations however, where the fix isn't so
> obvious.
>
> - When 64-bit proofing the Unicode string bits of GLib (years ago)
> I took the policy that:
>
>- Counts of bytes were sized as gsize
>- Counts of "items" sized larger than a byte are longs
>
> because it seemed very strange to me to use size_t for non-byte
> counts.
C++ does this all the time though (also calls it's .get_number_of_elements()
methods .size()), so you get used to it after a bit of STL fiddling.
> But that means that something like the return value from
> g_utf8_strlen() is wrong for win32. This can't be changed in a
> source-compatible fashion.
>
> Probably the right thing to do for g_utf8_strlen() is to compute
> things internally as 64-bit, then clamp the result to 32-bits
> on return. Without the clamp:
>
> long size = g_utf8_strlen(str);
> gunichar chars = g_new(gunichar, size);
> for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
> *c = g_utf8_get_char(p);
> }
>
>Is a potential buffer overflow, though a hard one to trigger.
>(Actually, it's a potential overflow currently for 32-bits. We really
>should make g_new0() not a g_malloc()-wrapping macro so we can protect
>the multiplication.)
if i understand you correctly, you mean to imply that we also fix the
signatures from *long to *size as well for the following functions
(comprehensive list of *long API in glib/glib/*.h):
gdouble g_timer_elapsed (GTimer *timer,
gulong *microseconds);
void g_usleep(gulong microseconds);
void g_time_val_add (GTimeVal*time_,
glongmicroseconds);
gchar* g_utf8_offset_to_pointer (const gchar *str,
glongoffset) G_GNUC_PURE;
glongg_utf8_pointer_to_offset (const gchar *str,
const gchar *pos) G_GNUC_PURE;
glong g_utf8_strlen (const gchar *p,
gssize max) G_GNUC_PURE;
gunichar2 *g_utf8_to_utf16 (const gchar *str,
glong len,
glong*items_read,
glong*items_written,
GError **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4 (const gchar *str,
glong len,
glong*items_read,
glong*items_written,
GError **error) G_GNUC_MALLOC;
gunichar * g_utf8_to_ucs4_fast (const gchar *str,
glong len,
glong*items_written)
G_GNUC_MALLOC;
gunichar * g_utf16_to_ucs4 (const gunichar2 *str,
glong len,
glong*items_read,
Re: using jhbuild and gtk+ branches
On Fri, 25 Jan 2008, Dr. Michael J. Chudobiak wrote: > Hi all, > > Could someone explain to me how exactly people work on bleeding-edge > gtk+ (trunk)? > Reading the gtk+ Changelog shows that people are working on trunk, and > merge back into 2-12 as needed. Are developers tweaking their own > moduleset to pull in gtk+ trunk, or using a different moduleset (is > there an all-trunk one?), or some other approach? we just use the gtk+ module set. it doesn't build gnome, but gtk+ trunk: modules = [ 'gtk+' ] > > Thanks for any guidance... > > > - Mike --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Seg Fault using offscreen patch
On Tue, 22 Jan 2008, iluvlinux wrote: > > hi > i am trying to use the offscreen patch that is available at > http://bugzilla.gnome.org/show_bug.cgi?id=318807 > http://bugzilla.gnome.org/show_bug.cgi?id=318807 > > some times i get segfault while pressing a button or checking a check box (i > have tried with these two widgets till now) > > Actually i am trying to use a clutter-stage embedded in a GtkWindow and than > i take snapshot of the window and try to display it on clutter stage. > Program received signal SIGSEGV, Segmentation fault. > gdk_event_translate (display=0x310088, event=0x312240, xevent=0xbebb1c38, > return_exposes=0) at gdkevents-x11.c:953 > 953 window_impl = GDK_WINDOW_IMPL_X11 (window_private->impl); > (gdb) bt > #0 gdk_event_translate (display=0x310088, event=0x312240, > xevent=0xbebb1c38, return_exposes=0) at gdkevents-x11.c:953 > #1 0x404b9d60 in _gdk_events_queue (display=0x310088) at > gdkevents-x11.c:2297 > #2 0x404b9f58 in gdk_event_dispatch (source=0x3, callback=0xc00019, > user_data=0x313a20) at gdkevents-x11.c:2358 > #3 0x4079b750 in IA__g_main_context_dispatch (context=0x305338) at > gmain.c:2061 > #4 0x4079d4f4 in g_main_context_iterate (context=0x305338, block=1, > dispatch=1, self=0x3dfcd8) at gmain.c:2694 > #5 0x4079d854 in IA__g_main_loop_run (loop=0x492c58) at gmain.c:2898 > #6 0x4024b7e0 in IA__gtk_main () at gtkmain.c:1144 > #7 0xa7b8 in main (argc=1, argv=0xbebb1e34) at theme_main.c:318 > (gdb) p window_impl > $1 = (GdkWindowImplX11 *) 0x0 please provide the backtrace in the bug tracker, along with information of what glib/gtk version you were using, and if you had to apply any additional changes apart from the offscreen patch. most importantly, please provide exact information on how to reproduce the segfault, we can't help you fix it otherwise. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: weakref semantics
On Thu, 17 Jan 2008, Yevgen Muntyan wrote: > Alexander Larsson wrote: >> On Thu, 2008-01-17 at 07:50 -0600, Yevgen Muntyan wrote: >>> A GWeakNotify function can be added >>> to an object as a >>> callback that gets triggered when the object is finalized. >>> Since the object is already being finalized when the >>> GWeakNotify is called, there's not >>> much you could do with >>> the object, apart from e.g. using its adress as hash-index or the like. >>> >>> I have never seen the docs quoted in the original mail, >>> and what docs say about g_object_weak_ref() implies >>> that weak ref callback is called 1) exactly once; 2) after >>> the object is finalized (and so I got some code which >>> supposes that the callback is called exactly once). So >>> what is the truth? Possibly more than once, and before >>> finalize()? >>> >> >> Only once (per time you register it), > > But it contradicts with "As such, each weak ref can be invoked more > than once upon object finalization (since dispose can run more than > once during object finalization)." that's bogus. each installed weakref can only ever be called once, just like GData destroy handlers. also, dispose is never called *during* finalization, the docs should say "dispose can run more than once before object finalization". > But is consistent with what John > said. > > So, two docs bugs? yep. > Best regards, > Yevgen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: weakref semantics
On Thu, 17 Jan 2008, Alexander Larsson wrote: > > On Wed, 2008-01-16 at 15:03 +, [EMAIL PROTECTED] wrote: >> I noticed the weakref introduction says that notifies can be called many >> times: >> >> http://library.gnome.org/devel/gobject/unstable/gobject-memory.html#gobject-memory-weakref >> >>... which is invoked when the object runs its dispose method. As such, >>each weak ref can be invoked more than once upon object finalization >>(since dispose can run more than once during object finalization). >> >> I'm not sure this is right: looking at the source for gobject it seems >> that the notifies are a fire-once thing, and are removed upon firing. >> >> Should I open a docs bug on this? (or am I confused?) you mis the facts that new weak refs can be added at any point in time, such as after dispose, in finalize or even during weakref notifies. (that's actually the semantics of GObject's GData mechanism which is used to implement weakrefs) > I actually have a related question. I remember that weak refs weren't > allowed to ressurect the object. However, with the weak ref callbacks > running from dispose, and dispose being allowed to ressurect the object, > why can't weak refs ressurect? because weakrefs will also run during finalization, and an object can not be resurrected from finalization. > Maybe weak ref callbacks should be moved to finalization? conceptually yes. regarding backwards compatibility, no. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: API break request for file monitoring
On Mon, 14 Jan 2008, Alexander Larsson wrote: > This bug: > http://bugzilla.gnome.org/show_bug.cgi?id=508564 > > requests and addition of a GError to g_file_monitor_directory and > g_file_monitor_file. > > Its imho, correct, but does break API which some users have started > using. I'd like to change this, but I'm not sure if that is acceptable > at this point. feel free to break API and ABI all the way throughout development versions, as long as the next stable branch ist ABI and backwards compatible with the last stable branch. after all, that's what development releases are for (and what they are named after, so no user can complain about interface breakage as long as it's in *development*). --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIcon thoughts
On Mon, 14 Jan 2008, Alexander Larsson wrote: > On Mon, 2008-01-14 at 10:12 +0100, Tim Janik wrote: >>> Of course, this is slightly harder, as GdkPixbuf is a public GObject >>> where we can't use toggle references. We could however implement this >>> with some help from the GdkPixbuf implementation. For instance, if we >>> add a resurrect signal to GdkPixbuf and have the dispose() >>> implementation emit this then the cache could connect to this and grab a >>> ref (for some time) before finalization. (The dispose call must also >>> detect that the object is ressurected and avoid chaining to dispose.) >> >> you're not free to skip chaining in dispose() implementations (just >> like you aren't free to skip chaining in finalize() or anywhere else). >> adding a reference count in dispose is enough to "resurrect" an object >> though, so just do ref(self); in dispose() but don't forget to chain up. >> this'll prevent finalization (finalize() is only called for objects with >> ref_count==0). > > Why is that forbidden? You can resurrect things by grabbing a ref, yes, > but if you then chain up it'll free things like user data, etc, which we > don't want in the case of a cache. because code can do stuff like: this->foo = acquire_resource(); class->release_resource (this); where foo, acquire_resource, release_resource can be arbitrary names of course, e.g. dispose. if you break the assumption that some_class_real_method() is always being called when class->method() is being called (either directly or via chaining), you'll break random code portions. (ancestor classes need to be able to make *some* assumptions about an object in order to be implemented, and method calls working correctly is one very fundamental assumption.) --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIcon thoughts
On Thu, 10 Jan 2008, Alexander Larsson wrote: > On Wed, 2008-01-09 at 13:53 -0500, Matthias Clasen wrote: >> We can't implement the cache using toggle references for 2 reasons: >> a) GtkIconSize is a boxed, not an object >> b) toggle references only work for a single user, thus they have >>to be reserved for bindings, at least bindable objects. >> I propose to instead turn GtkIconInfo into a refcounted boxed object, >> and then implement the caching logic for the case that the refcount >> drops to one. > > I'm not sure this is enought, cache-wise. In many cases you'd get a > GtkIconInfo, then get the pixbuf for that, save the pixbuf (e.g. in a > widget) and unref the info. In fact, it seems unlikely that apps would > keep the GtkIconInfo alive for long periods of time. It would be nice if > we could get the GtkIconInfo cached until the last ref is dropped to the > pixbuf. sounds like you should simply keep a reference count from the pixbuf onto the corresponding GtkIconInfo. using object data for instance. > Of course, this is slightly harder, as GdkPixbuf is a public GObject > where we can't use toggle references. We could however implement this > with some help from the GdkPixbuf implementation. For instance, if we > add a resurrect signal to GdkPixbuf and have the dispose() > implementation emit this then the cache could connect to this and grab a > ref (for some time) before finalization. (The dispose call must also > detect that the object is ressurected and avoid chaining to dispose.) you're not free to skip chaining in dispose() implementations (just like you aren't free to skip chaining in finalize() or anywhere else). adding a reference count in dispose is enough to "resurrect" an object though, so just do ref(self); in dispose() but don't forget to chain up. this'll prevent finalization (finalize() is only called for objects with ref_count==0). > That might be useful for other pixbuf caches too. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_test with mainloop integration?
On Sun, 6 Jan 2008, Mikkel Kamstrup Erlandsen wrote:
> On 05/01/2008, Tim Janik <[EMAIL PROTECTED]> wrote:
> test would look like the below pseudo code:
>
> -
>
> setup (fix) {
> fix->search = create_search_on_search_engine()
> }
>
> test_run (fix) {
> Hits hits;
>
> start_search(fix->search);
>
> // below call returns control back to the main loop until the
> // signal is emitted on fix->search and then magically writes
> // the signal arg into &hits
> wait_for_signal(fix->search, "hits-added", &hits);
> assert(hits->count > 0);
> }
>
> teardown (fix) {
> clean_up (fix);
> }
>
> main () {
> add_test_with_main_loop (setup, test_run, teardown);
> }
>
> -
>
> The two interesting calls are wait_for_signal() and add_test_with_main_loop().
>
> The wait_for_signal() method process the main loop until a signal is
> emitted on a given object - or maybe until a timeout is reached[1].
this can be done by running a main loop within wait_for_signal().
> The whole idea about that method is that it should be possible to
> write your tests without using callbacks. This will help make the
> tests more expressive and easily maintained.
>
> To flag that some test case should run in a main loop you use some
> special way of registering it. Like add_test_with_main_loop. There are
> a lot of open questions on that one... Fx:
> - Should all three functions, setup, test_run, and teardown, be run
> in the mainloop, or just test_run()
> - Should the mainloop process events in between calling the three functions?
i still fail to see why your main test function should run as part
of a main loop. (and in what way, idler/timer/io-driven, with what
priority, etc.)
> Cheers,
> Mikkel
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Test Framework
On Wed, 2 Jan 2008, Asbjørn wrote: I'm checking out the Test Framework and here is my first test program: glib/glib/tests/testingbase64.c Output: TEST: testingbase64... (pid=15393) /misc/base64/encode: OK /misc/base64/decode: OK /misc/base64/encode_decode: OK It's based on tests/base64-test.c . thanks, added to SVN with coding style fixes. can you please provide your full real name for the copyright line? --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Comments on glib testing framework
On Wed, 9 Jan 2008, Tommi Komulainen wrote:
> Hi,
> make -k test probably shouldn't abort gtester on first failing assertion
hm, currently, we have these test framework makefile rules:
test: run all tests recursively, abort on first error
test-report:run tests in subdirs, generate report, continue on error
perf-report:run tests like test-report, include performance tests via -m
perf
full-report:like test-report, include all tests with -m perf and -m slow
so if you want to run tests and not abort, you're probably looking for
test-report:. one rule needs to be there to abort immediately for developers
to trace test failures, and currently that is test:.
i wouldn't know of a portable way to detect "make -k" invocations to make
the test: rule behave differently. and, is there really a need for that,
given that you could run test-report: instead?
> glib/gtestutils.h references g_object_unref() which requires gobject.
this is "hidden" in a macro ;) i.e.:
#define g_test_queue_unref(gobject) g_test_queue_destroy (g_object_unref,
gobject)
so if you use g_test_queue_unref() on a GObject, you usually need to have
glib-object.h included already, and g_test_queue_unref() will work without
problems.
(i guess one could argue for g_test_queue_unref() to be moved to a gobject/
header for "cleanliness", but then we'd have to find a proper place for it,
and probably have documentation splits as well...)
> It would be nice to have g_assert_cmpenum and g_assert_cmpflags to
> pretty print the name of enum/flags rather than plain numerical value
> (See example code for cmpenum attached, needs to be in gobject.) For
> example:
>
>assertion failed (mode == GTK_SIZE_GROUP_HORIZONTAL): (3
> (GTK_SIZE_GROUP_BOTH) == 1 (GTK_SIZE_GROUP_HORIZONTAL))
hm, it looks a bit cumbersome to use, since you always need to provide
to correct enum type id as well:
g_assert_cmpenum (mode, ==, GTK_SIZE_GROUP_BOTH, GTK_TYPE_SIZE_GROUP_MODE);
judging from other gtk code errors, those type ids are easily gotten wrong
if unchecked, and in your implementation, the type id is used very seldomly,
i.e. only if the actual assertion fails...
also, g_assert_cmpint() will already provide a lot of information (in
particular the stringified assertion macro arguments):
gint mode = GTK_SIZE_GROUP_HORIZONTAL;
g_assert_cmpint (mode, ==, GTK_SIZE_GROUP_BOTH);
generates
** ERROR:(testing.c:195):main: assertion failed (mode ==
GTK_SIZE_GROUP_BOTH): (1 == 3)
i guess you're mostly aiming for cases where both macro arguments are
variables?
> While we are on this topic, does it make sense to add something like
> g_enum_get_name (GType, gint)? The g_enum_* functions can be used to do
> this, but are a bit cumbersome to use.
this has been raised a lot of times. there's one thing to keep in mind
here, like all other types, enum classes may be implemented by a plugin
that needs to be dlopen()ed. so strings provided by the enum class will
not neccessarily persist in memory, i.e. g_enum_get_name() can not return
a const char* but would have to g_strdup() the returned string.
and, adding such API will hide the fact that classes my need to be loaded,
which can lead to code like:
gchar *name = g_enum_get_name (GTK_TYPE_SIZE_GROUP_MODE,
GTK_SIZE_GROUP_BOTH);
gchar *nick = g_enum_get_nick (GTK_TYPE_SIZE_GROUP_MODE,
GTK_SIZE_GROUP_BOTH);
gchar *blurb = g_enum_get_blurb (GTK_TYPE_SIZE_GROUP_MODE,
GTK_SIZE_GROUP_BOTH);
g_print ("enum value: name=%s nick=%s blurb=%s\n", name, nick, blurb);
g_free (name);
g_free (nick);
g_free (blurb);
which looks harmless, but behind the scenes does
dlclose (dlopen("EnumPLugin.so"));
3 times.
> gtk_test_create_widget is nice, but unfortunately won't be usable in the
> cases where a widget does more than a g_object_new call in its _new
> function (GtkSpinButton, text variants of comboboxes, GtkAspectFrame,
> any other third party widget, ...). Maybe not too important, but worth
> noting.
widgets that do more than g_object_new() in their _new() functions are
broken and need to be fixed to provide the functionality of all
_new(arguments) through the GObject property interface.
(they are also problematic for gui builders, docu generation and
language bindings).
> gtk_test_teardown. See bug #507256
>
> There are two technologies that could help in the creation of testcases:
> * A way to record a series of events and replay them at will.
>(Already exists?)
yeah, Gerd (Gtk+ Event Recorder) does this:
http://testbit.eu/~timj/historic/gerd/
the code is faily old though (2000), and with Gtk+/Gdk's infrastructure
will also work on X11 only.
> * A way to record either the static aspect (screenshot) or an
>extended period of time (video, or series of images matched with
>a checkpoint) and compare it against a pre-defined image/video.
this has been implemented in a spun off of Gerd by some solaris people
a couple years ago. doing pixel-by
Re: GLib test framework for your own project
On Wed, 9 Jan 2008, Tommi Komulainen wrote: > Hi, > > Here's a quick guide for setting up GLib testing framework for your own > project. It is the result of some trial and error when integrating for > hildon widgets the test framework from current trunk. There are some > autotools related details that might not be immediately obvious for mere > mortals. Thought it good to collect the details in one place. Hope it > helps. thanks for doing that. > 1. Copy Makefile.decl > >[glib or gtk+ currently does not install any usable >Makefile.decl] yeah, i was thinking about that when i wrote it. once the current testing rules have stabelized and turn out to be actually useful for testing glib/gtk+, it could make sense to install a Makefile.gtkrules or similar for other projects to include that provides the rather complex test framework rules. it'll be a bit tricky to include that though, given that the include paths may vary. an alternative could be to provide the rules in an automake macro, setup by AM_PATH_GTK_2_0(). >Copy Makefile.decl from glib or gtk+ source directory to the >root directory of your project. The difference is that >Makefile.decl from gtk+ will run the tests in Xvfb and thus only >works for x11 backend. right, for non-X11 targets, the tests will currently be skipped. if people can provide alternatives to Xvfb for non-X11 platforms to hide GUI program execution, that'd be much apprechiated. >Edit Makefile.decl so that GTESTER and GTESTER_REPORT are >correct for non-GLIB packages: > >GTESTER= gtester# in $PATH for non-GLIB > packages >GTESTER_REPORT = gtester-report # in $PATH for non-GLIB > packages > > >When using Makefile.decl from gtk+ also add the following line >after GTESTER_REPORT. This is needed for properly starting Xvfb >for the test. > >gdktarget := $(shell pkg-config --variable=target gdk-2.0) good point. however $(shell) is a GNU-make-ism, so for projects that need to be portable across GNU-make, it might be good to provide @GTK_GDKTARGET@ by AM_PATH_GTK_2_0(). > 2. Edit every Makefile.am > >Add the following line to the top of every Makefile.am. This is >needed to enable recursive 'make test' and friends. > >include $(top_srcdir)/Makefile.decl one word about recursion here. gtk+/Makefile.decl currently ignores and won't recurse into subdirs with the names "po" or "po-properties". this may or may not be appropriate for other projects (it usually is though, because po/Makefile.in is usually not under the project maintainers control, and so is hard to extend for additional recursive rules). > 4. Write src/tests/testwidget.c > >Make sure your normal build flags do not include -DG_DISABLE_ASSERT >(or add #undef G_DISABLE_ASSERT at the top of the file) as it will > disable >all checks using g_assert() -- though not any of g_assert_cmp*() > >[See some other tutorial and API reference for how to organize >the C code and which functions/macros to use. Currently glib >trunk does not generate any documentation for the testing >framework.] hm, right. the API docs are there in glib/glib/gtestutils.c, but nothing is generated for the web atm. will have a look. > 5. Run the tests > >$ make test > >When running in emacs/vim the first failing test should be >recognized and the cursor should be placed on the line of >failing assertion. > >[See some other tutorial/reference for how to run tests more >fine grained (./testwidget -p /foo, ./testwidget --help?)] gtester --help works. test programs currently do not provide a --help output, because they are programs in their own right. they do interpret a bunch of options though, such as --g-fatal-warnings, -p=path, -m=mode, -q, --quiet, --verbose, -l, --seed=randomseed, all of which correspond to the respective gtester options, described by gtester --help. given that g_test_init() parses all these args and that test programs are unlikely to implement sophisticated argument parsing and --help themselves though, it's probably best to hard code --help output into g_test_init()... > -- > Tommi Komulainen<[EMAIL PROTECTED]> --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dedicated machine for gtk.org website project
On Wed, 9 Jan 2008, Shawn Amundson wrote: > Olav Vitters wrote: >> On Wed, Jan 09, 2008 at 09:25:16AM +, Martyn Russell wrote: >>> I must confess, I have quite limited knowledge when it comes to our >>> hosting services for GNOME and GTK+ (i.e. where machines are hosted >>> physically and who looks after them, etc - is this information available >>> somewhere?). Perhaps some sysadmins could comment here too. >> >> Probably known but in case not (from gnome-sysadmin POV): GTK does most >> things for themselves. Machines, website, DNS, mail, etc etc. The only >> slight relation is the SVN repository for the website and its >> post-commit hook to trigger an update of the site. >> > > Yes, but it does not have to remain that way. > > Perhaps cube.gtk.org should run the gtk.org resources but with > the assistance of the gnome-sysadmin team. Or maybe gtk.org should > just be completely absorbed into gnome-sysadmin's existing > infrastructure. since it doesn't look like the gtk.org hardware is going to be updated anytime soon, moving the gtk.org domain to another machine definitely should be considered. anything else than just moving the current content, like changing the current sysadmin structure and/or integrating it into gnome sysadmin's hosting sounds like it will require planning and some kind of migration plan though. i.e. someone volunteering to do that. > -Shawn --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_test with mainloop integration?
On Fri, 4 Jan 2008, Mikkel Kamstrup Erlandsen wrote: > Hi, > > I am playing around with using the new glib testing utilities for > xesam-glib and I am wondering if there is any smart way to integrate > tests with a GMainLoop. > > The situation is that I need to test a bunch of async dbus > communications and for that I need a running GMainLoop. For now I have > a mainloop instantiated in my fixture and then start and exit the loop > in each test function. It seems a bit awkward to do it like this > because it introduces some boilerplatish code in each test case. that's what the fixture functions are for, to take over common builerplate parts of test functions. > So my question: Is there a Smart (TM) way to do this or can we add > something to gtestutils to make this easy peasy? I suspect that it > might not be that uncommon since many apps/libs revolve around a > GMainLoop. it's not clear to me what exactly you'd like to add to the test framework (since main loops can easily be created/destroyed in fixture functions). is there any concrete API to add you have in mind? > Cheers, > Mikkel --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'd like to contribute
On Fri, 28 Dec 2007, Cody Russell wrote: > On Fri, 2007-12-28 at 18:35 -0800, Bobby Walters wrote: >> I would like to contribute a little to the project. Is there anything >> I could do? Let me know how to get started, and who to talk to please. > > Hey Bobby, > > Welcome! Maybe start off by letting us know more of what kind of work > you're interested in doing. If you're interested in programming, the > best thing to do is to start off by searching through Bugzilla [1] for > bugs to work on fixing. Or better yet, you might look at the GtkLove > bug list [2] for starting places. > > You could also work on documentation or test/demo programs. Maybe > someone else can give a better idea of where to get involved with that. here's a page with a list of contributor task descriptions: http://live.gnome.org/GtkTasks > > [1]. http://bugzilla.gnome.org/buglist.cgi?query=product%3Agtk%2B > [2]. http://live.gnome.org/GtkLove > > Cheers, > Cody --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib Testframework API
On Tue, 18 Dec 2007, Johan Dahlin wrote:
> Sorry for being late in the game for comments, but here we go.
>
> In general this api differs slightly from JUnit/python, which has the
> following (main) methods:
>
> assertEqual
> assertNotEqual
> assertTrue
> assertFalse
> assertRaises
yeah, i've looked at the JUnit API when designig the glib test API, but
didn't find those assertions to be too applicable. e.g. there's not too
much difference in:
g_assert (condition == TRUE);
g_assert_true (condition);
g_assert (condition == FALSE);
g_assert_fail (condition); // suggested by Behdad
if people strongly feel those need to be added we can do that, i just
fail to see a significant benefit.
> Perhaps the term "equals" could be used instead of "cmp".
the existing API uses "cmp" because it implements memcmp(3) result semantics,
i.e. -1,0,+1 instead of eaqulity ('==') semantics.
for int/hex/float, this should obviously make sense, and for strings it
mimicks the most common comparison API, i.e. strcmp().
> I haven't looked in detail at the trap api, but having something similar to
> assertRaises for g_error & friends would be a good thing.
hm, i'd say the closest thing to assertRaises in glib *is* g_error().
maybe you meant GError? that might be useful to have, patches welcome ;)
> g_assert_cmpstr, accepts a comparison operator, while this makes sense for
> comparing floats and integers I don't think it should be included in the api
> for strings.
> Basically, the only thing you want to check if is a string is equal to
> another or not, so perhaps it could be replaced with:
>
> g_assert_equals_str
> g_assert_not_equals_str
>
> Or do you see a use case for using other operators besides == and != ?
sure, if you use strcmp() to sort a list of strings, you'd use
g_assert_cmpstr() to test the invariants. and as i wrote above, offering
'cmp' here instead of 'equals' is what C coders are most used to anyway
(and consistent with the other g_assert_cmp*() variants).
keep in mind that the g_assert_*() family is about convenience anyway,
everyone is free to fallback to g_assert() or if(...)g_error() for his
checks.
a remaining issue i see with g_assert_cmpstr() however is that we should
probably also have g_assert_casecmpstr(), similar to g_strcasecmp().
> Johan
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Test reports and commit policies
Hey All. A quick update on the unit test reports, a script for test report generation has now been comitted to GLib and will be used to generate HTML reports for the test report rules test-report, perf-report and full-report. The reports should render in all browsers and support colorization and collapsed/popup details for CSS and javascript enabled browsers. Example reports generated from today's SVN are provided here: http://people.imendio.com/timj/examples/glib-full-report.html http://people.imendio.com/timj/examples/gtk+-full-report.html Percentages are reported for the amount of tests that failed or succeeded, e.g. gtk+/tests/.libs/lt-objecttests is reported with a result of 80.39%, because ca. 20% of our automated widget property tests fail (generate some warnings or crash Gtk+, volounteers to look into those cases highly needed). It'd be nice if someone in the community could set up a build machine for jhbuild/modulesets/gtk.modules that builds, runs test-report, perf-report and full-report and uploads the resulting test-report-html, perf-report.html and full-report.html from GLib and Gtk+ to some public location. About commit policies, now that we have a test framework in place that distinguishes between slow (make full-report) and fast (make check) tests, and allows subcomponent related tests (e.g. make check -C gtk+/gtk/), it'd be nice to actually make ue of it. So i'd like to suggest that we establish some basic commit/test policies, e.g.: 1) Before committing changes in glib/ or gtk+/, a developer needs to ensure that make check -C glib/ (or make check -C gtk+/) passes. 2) For major changes (adding new components, changing lots of files, changing Makefiles, etc.), developers should run make full-report on the whole module and investigate the failing test cases before committing. The exact rules/process is open for discussion of course, the above is meant as some initial food for thought. Please discuss! ;-) --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Test Framework Mini Tutorial
Hey All.
The following gives a mini tutorial on writing test programs for GLib
and Gtk+ with the new framework. We have a good number of example test
programs in SVN now and appreciate help from everyone in implementing
new tests.
First, we'll have a quick introduction into the main rationale on
test writing.
The main goals in writing tests are:
- In example (test) driven development (EDD or TDD), an example or test
program is written first, and then the newly used API gets implemented.
This ensures early testability and gives programmers early feedback on
their implementation.
- For untested legacy code, new tests are written to get about to be changed
code portions under automated tests to catch behavior changes as code is
changed.
- Most tests are written to ensure basic functionality checks of the code
area in change. Tests usually cannot perform comprehensive checks, but
can check for specific known to be tricky corner cases or often test a
representative subset of an API.
In general, working on code that is sufficiently under automated tests
makes programmers feel much more confident about their changes and helps
to spot errors shortly after introduction. So well tested code bases
tend to increase productivity and fun in working with the code.
The following list of steps is hopefully helpful when approaching the
implementation of a new test for GLib or Gtk+:
1) Figure a place for the test case. For this it's useful to keep in mind
that make check will traverse CWD recursively. So tests that should be
run often when glib, gdk or gtk changed should go into glib/glib/tests/,
gtk+/gtk/tests/ or gtk+/gdk/tests/. Tests more thorough or planned to
be run less frequently can go into glib/tests/ or gtk+/tests/. This is
e.g. the case for the generic object property tester in
gtk+/tests/objecttests.c. To sum up:
glib/tests/ # less frequently run GLib tests
glib/glib/tests/ # frequent GLib testing
glib/gobject/tests/ # frequent GObject testing
gtk+/tests/ # less frequently run Gdk & Gtk+ tests
gtk+/gdk/tests/ # frequent Gdk testing
gtk+/gtk/tests/ # frequent Gtk+ testing
Also, not all tests need to go into an extra test binary. Building and
linking many test binaries can be quite time consuming, so linking
multiple .c files with tests into a single test binary can be advisable.
2) Write the test fixture setup and teardown code if necessary.
See e.g. ScannerFixture in glib/tests/scannerapi.c for a simple
example fixture that creates and sets up an object to be used
freshly in various different tests.
3) Implement the actual test function, possibly taking a fixture argument.
Tests should try to avoid duplicating logic or tests and often consist
of a series of calls and checks to use a component and verify its
behavior, e.g.:
string = g_string_new ("first");
g_assert_cmpstr (string->str, ==, "first");
g_string_append (string, "last");
g_assert_cmpstr (string->str, ==, "firstlast");
The current set of useful test assertions provided by GLib is:
g_assert_not_reached ();
g_assert (expression);
g_assert_cmpstr (s1, cmpop, s2);
g_assert_cmpint (n1, cmpop, n2);
g_assert_cmpuint (n1, cmpop, n2);
g_assert_cmphex (n1, cmpop, n2);
g_assert_cmpfloat(n1, cmpop, n2);
Where 'cmpop' is the compare operator, such as '==' or '>='.
Of course g_error() can also be used once a test error is discovered.
Note that g_warning() will usually also abort test programs, because
tests generally run with --g-fatal-warnings enabled.
4) Verify stdout and stderr output or assert failures.
Tests can be started in a separate forked off sub process to capture
premature failure, exit status and output. Here is a sample snippet:
if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDOUT |
G_TEST_TRAP_SILENCE_STDERR))
{
g_warning ("harmless warning with parameters: %d %s %#x", 42, "Boo",
12345);
exit (0); // should never be triggered
}
g_test_trap_assert_failed(); // we have fatal-warnings enabled
g_test_trap_assert_stderr ("*harmless warning*");
More example uses of the test_trap API can be found in:
glib/tests/testglib.c
glib/tests/scannerapi.c
glib/glib/tests/testing.c
5) Conditionalize slow or fragile tests.
While unit tests are most effective if they are fast, to allow quick
turn around times during development, slow or more thorough tests
also have their place. Test routines can be conditionalized in case
they contain fragile or slow code with the following API:
gboolean g_test_perf (); // TRUE to enable (slow) performance tests
gboolean g_test_slow (); // TRUE to execute possibly slow test cod
Re: Contributing to Glib
On Mon, 26 Nov 2007, Bryan Christ wrote: > Can anyone point me to some resources for contributing to Glib. I > have combed the gtk.org website looking for a FAQ or contributor guide > but can't find anything. people can sign up for individual tasks for contributing to glib/gtk+ hee: http://live.gnome.org/GtkTasks there's also a resource for novice bug fixing: http://live.gnome.org/GtkLove and you can of course pick any existing glib bug and start hacking on it: http://bugzilla.gnome.org/buglist.cgi?query=product:glib other than that, it might help to know in which way you'd like to contribute. > -- > Bryan > <>< --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Suggested even/odd convention for the micro version numbers (like cairo)
On Tue, 11 Dec 2007, Tor Lillqvist wrote: > I humbly suggest that the versioning recommendation for the GTK+ stack > and GNOME in general is amended for the third "micro" part of the > version numbers to match the convention used in cairo. > > See http://cairographics.org/manual/cairo-Version-Information.html . > > In a nutshell, the idea is that released tarballs have an even micro > version. The micro version is bumped both immediately before and after > building the release tarball. The even micro number is never committed > to SVN. In SVN the micro number is always odd. the scheme sounds good and well applicable to glib/gtk. > I guess one disadvantage of this is that it might take a time before > people stop asking "what happened to version x.y.z". Also, one > probably needs to script the bump-make dist-bump sequence in order not > to forget it, at least initially. yeah, i think a problem in practice is that it's easily forgotten to bump the SVN version number after distcheck. i don't quite see how a script could solve this, because i don't see an obvious point where a script could check/enforce the bump. given that the release process is usually (some parts can be parallelized): - commit development stuff to SVN - bump version to x.y.even - build and fix things until distcheck succeeds - final updates (NEWS, README, ChangeLog, etc) - final make distcheck, yields tarball x.y.even - commit release changes to SVN - upload tarball the time to run a script to check/enforce x.y.odd would be after comitting release changes, around tarball uploading... suggestions for hooking up a script welcome. > --tml --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
On Mon, 19 Nov 2007, Stefan Kost wrote: > Tim Janik schrieb: >> the logic from the makefile might be useful to factor out into a script >> for other GUI projects though, since it involved quite some tweaking to >> handle missing Xvfb gracefully, find free display ids and provide >> meaningful >> error messages on errors. > > Yep, My code had to pass several revision to mature. E.g. its good to cleanup > dead display and lock files. While looking at your code, it seems you use > display ids ranging from 101-199, is that right (did not know this would > work). yes, and via shell traps, the Xvfb is killed away if everything (program, make, etc.) crashes. so it'll efectively never leak Xvfb server processes (which is likely to happen with if test apps spawn Xvfb away themselves and crash). also, the Xvfb presence is simply checked in the makefile, so we don't need to depend on configure time checks and could conceivably exchange it for Xnest/ Xephyr/etc via environment variables. > Stefan > --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Gtk+ branched for 2.15.0
On Mon, 19 Nov 2007, Alexander Larsson wrote: > > On Mon, 2007-11-19 at 11:18 +0100, Tim Janik wrote: >> Hay all. >> >> upstream GLib and Gtk+ have been branched now. as of this morning, both >> trunks >> are at 2.15.0, and stable branches have been created for bugfixes: >>http://svn.gnome.org/viewvc/glib/branches/glib-2-14/ >>http://svn.gnome.org/viewvc/gtk+/branches/gtk-2-12/ >> >> so the plan is to release GLib-2.16.0 and Gtk+-2.16.0 in sync again at the >> end >> of this development phase. > > Oh? Is the plan still to release a glib with gio a bit earlier so that > it can hit Gnome 2.22 (without the corresponding Gtk+ release)? it'd probably be good to resume (bi-)weekly IRC meetings to discuss this and similar issues. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
On Fri, 16 Nov 2007, Tommi Komulainen wrote: > Some quick and random comments that come to mind... > >> /* syncronize rendering operations with X server rendering queue */ >> voidgtk_test_xserver_render_sync(GdkWindow *window); > >> /* synthesize and send key press or release event */ >> gbooleangtk_test_simulate_key (GdkWindow *window, > >> /* synthesize and send button press or release event */ >> gbooleangtk_test_simulate_button(GdkWindow *window, > > Shouldn't the above be named gdk_test or take GtkWidget as parameter? hmm, strictly speacking, you could argue for creating gdktestutils.h in gdk and moving this there, yes. i wasn't sure opening up the gdk_test namespace is really worth the hassle, but considering that we'd hopefully extend Gdk tests and test utils in the future, your change would probably be for the better. >> while (gtk_events_pending ()) >> gtk_main_iteration (); > > The test examples had quite a few of these, adding noise. not sure what you mean with "adding noise"? > Most of them > were related to spin buttons, so I suppose in general tests shouldn't > have many of these? Would it make sense to flush the events in > gtk_test_spin_button_click instead, for example? if you do GUI interaction tests with an X server, you'll not be able to avoid processing events from within your test programs. here's a simplified example: button = create_button(); gtk_widget_show_now (button); /* the above calls the main loop recursively until button is visible */ /* button is now mapped on screen */ gtk_test_widget_click (button, 1, 0); /* button click events are in the outgoing queue */ gdk_flush(); /* force sending of button events to x server now */ g_assert (button_clicked_callback_called == TRUE); /* assertion fails, because button events weren't received by the app yet */ while (gtk_events_pending ()) /* receive x events (button clicks) */ gtk_main_iteration (); /* handle x events (call clicked callback */ g_assert (button_clicked_callback_called == TRUE); /* assertion passes, because main loop handled button clicks now */ on top of that, the spin button code sets up its own asyncronous main loop handlers to process event updates. so there's no way around intermediate recursive main loop invocations to verify GUI interaction logic. also gdk_flush() is not a suitable replacement as it only sends events, but doesn't cause the application to receive and process GUI events. > Tommi Komulainen<[EMAIL PROTECTED]> --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
On Sat, 17 Nov 2007, Stefan Kost wrote: > Hi, > > Tim Janik schrieb: >> hey All. >> >> first, a quick update on the GLib testing framework. allmost all of it >> has been implemented at this point and is available here: >> http://git.imendio.com/?p=timj/glib-testing.git;a=shortlog;h=gtester2 >> we're currently working on finishing the documentation. and now that glib >> has been branched, we'll look into integrating it into upstream next week. >> >> below is the proposed API for Gtk+ testing utility functions. >> they are mostly derived from the needs to automate user interaction >> tests of dialogs and widgets. >> a myriad of other functions could of course also be useful for testing, >> but those are probably best found out and added to Gtk+ as time passes >> and specific needs arise. >> this basic set should be good enough to navigate and operate most >> dialogs programatically. >> the following is just a very brief API wrap up, attached is a Gtk+ program >> that implements and documents this API and has a bunch of example >> test cases to test this API. the attached test program is not yet dependant >> on the new glib testing framework, so it's easier for people to try out. >> > What about Xvfb support? I have 4 funtions in buzztards check test suite: i've setup a similar environment, albeit in the Makefile: http://git.imendio.com/?p=timj/gtk%2B-testing.git;a=blob;f=gtk/tests/Makefile.am;hb=72227f8f808a0343cb420f09ca480fc1847b6601 hardcoding Xvfb invokation in the executable doesn't seem very fortunate to me. e.g. depending on the system, you might want to use Xvfb, Xnest, Xephyr, etc or for debugging the X server of the current session. also, running Xvfb from the makefile will allow to share Xvbf invocations between multiple test programs. the logic from the makefile might be useful to factor out into a script for other GUI projects though, since it involved quite some tweaking to handle missing Xvfb gracefully, find free display ids and provide meaningful error messages on errors. > Stefan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Gtk+ branched for 2.15.0
On Mon, 19 Nov 2007, Kalle Vahlman wrote: > 2007/11/19, Tim Janik <[EMAIL PROTECTED]>: >> Hay all. >> >> upstream GLib and Gtk+ have been branched now. as of this morning, both >> trunks >> are at 2.15.0, and stable branches have been created for bugfixes: >>http://svn.gnome.org/viewvc/glib/branches/glib-2-14/ >>http://svn.gnome.org/viewvc/gtk+/branches/gtk-2-12/ >> >> so the plan is to release GLib-2.16.0 and Gtk+-2.16.0 in sync again at the >> end >> of this development phase. > > Not that I'm against it, but is there a rationale/discussion for this > somewhere? there is no strong technical reason either way. having different MINOR version numbers for glib and gtk+ has been a constant matter of confusion in emails and during meetings, so syncing them is simply going to make things easier for humans. > Kalle Vahlman, [EMAIL PROTECTED] --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib and Gtk+ branched for 2.15.0
Hay all. upstream GLib and Gtk+ have been branched now. as of this morning, both trunks are at 2.15.0, and stable branches have been created for bugfixes: http://svn.gnome.org/viewvc/glib/branches/glib-2-14/ http://svn.gnome.org/viewvc/gtk+/branches/gtk-2-12/ so the plan is to release GLib-2.16.0 and Gtk+-2.16.0 in sync again at the end of this development phase. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
On Fri, 16 Nov 2007, Richard Hult wrote: > Tim Janik wrote: >> hey All. > > Hi Tim, > > [snip] > >> /* syncronize rendering operations with X server rendering queue */ >> voidgtk_test_xserver_render_sync(GdkWindow *window); > > Should this be named less X-ish? I noticed that some of the event > simulation functions are very X specific anyway, but if we have the API > at least look generic, we can make it work on other backends later. the API that generates button or key events should ideally be implemented for non-X backends as well at some point, yes. gtk_test_xserver_render_sync() however uses a technique that is only known to work for X servers (according to keith packard), please search for "XGetImage" in this email: http://mail.gnome.org/archives/gtk-devel-list/2006-October/msg00166.html if there's a chance we could use and implement a similar call for other windowing system backends though, a rename like you suggest would be good. Tml, any input? ;) > /Richard --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Owen Taylor wrote: > While I don't really consider > g_source_remove(some_id_that_I_might_already_have_removed) 100% valid, > the docs do imply that it is legal, so perhaps it would be worth fixing > up that case (say, by having a referencing internal variant of > find_source_by_id().) i think such a variant really needs to be exposed as public API. g_main_context_find_source*() is fairly pointless if it can only be used correctly if the caller must be holding a reference to the returned source already. i think this API should have in the first place, either: - returned an id, because g_source_remove(invalid_id) behaves gracefully, or - returned a GSource* with increased reference count, to ensure the returned pointer is alive and valid. > - Owen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Alexander Larsson wrote: > On Fri, 2007-11-16 at 14:04 +0100, Tim Janik wrote: >> On Fri, 16 Nov 2007, Alexander Larsson wrote: >> >>> I'm doing something where i have one thread queueing idles and timeouts >>> in a thread, and the main loop consumes this. In some cases i want to >>> remove the sources (to replace a timeout with an idle). However: >> >>> Am I missing something obvious here? >> >> simply use g_source_remove (id) instead. > > Eh, thats the call I talked about. sorry, i mistook the call to g_source_destroy(GSource*) for your own code, and thought you'd wrongly try to use g_source_destroy() instead of g_source_remove(guint). yes, you're right, there's a race in the implementation of g_source_remove() and also g_source_remove_by_user_data, g_source_remove_by_funcs_user_data. this must have been introdcued when we moved away from hook lists, for which removal by id was safe. the code here needs fixing to either move the searching into internal functions so a single lock can be held around searching and destroying the sources, or by just making g_source_remove() thread safe again via inlining of find_source_by_id, and then provide alternative APIs to search for source *ids* instead of pointers from user_data and funcs. changing the API for source searching is actually needed anyway to get rid of the thread race inherent in the current API (g_main_context_find_source*() return GSource pointers but no lock is held when they return and they don't add a reference count to the sources. so the pointer may already be invalid when the functions return). --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Alexander Larsson wrote: > I'm doing something where i have one thread queueing idles and timeouts > in a thread, and the main loop consumes this. In some cases i want to > remove the sources (to replace a timeout with an idle). However: > Am I missing something obvious here? simply use g_source_remove (id) instead. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Thu, 8 Nov 2007, Mikkel Kamstrup Erlandsen wrote: > On 07/11/2007, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> wrote: >> How about token concatenation[1]? i have to use that already for the current implementation, see my recent header: http://git.imendio.com/?p=timj/glib-testing.git;a=blob;f=glib/gtestframework.h;hb=617f2d3398e969bc2c38e1e6138a98cfaf91c7b9 > If anybody agrees with me that we must have an IDE friendly syntax, or have > other reasons to believe that > > g_assert_cmpint (1, G_EQUALS, 2); i don't quite see the benefit here. if there was a need to avoid the operator notation however, i'd definitely prefer something like: g_assert_int_lt (1, 2); g_assert_int_le (1, 2); g_assert_int_eq (1, 2); g_assert_int_ne (1, 2); for <, <=, ==, != respectively. > I shall gladly make it into a real implementation. Tim? > > Cheers, > Mikkel --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtester git repo (Re: GLib testing framework)
On Tue, 6 Nov 2007, Tim Janik wrote: > i've checked in Sven's and my code into a git-svn mirror of glib on > testbit.eu. so you can browse the recent changes here: > http://testbit.eu/gitdata?p=glib.git;a=shortlog;h=gtester > > e.g. todays latest version of the testing examples is here: > http://testbit.eu/gitdata?p=glib.git;a=blob;f=glib/tests/testing.c;hb=9c8ae8c0097b8f7c098970e87bf413cd9c4f6a22 i've created a different repo for testing framework previews now, as cloning the above includes dozens of megabytes for all of the GLib history. the new shallow repo is here: http://git.imendio.com/?p=timj/glib-testing.git;a=summary the branch i'm currently pushing to is: http://git.imendio.com/?p=timj/glib-testing.git;a=shortlog;h=gtester1 i'll create gtester2, etc. everytime the branch is rebased onto recent upstream changes. the repo can be cloned with: git-clone git://git.imendio.com/timj/glib-testing however building it might require this before autogen.sh: mkdir -p build/win32/dirent build/win32/vs8 && touch build/win32/vs8/Makefile.am build/win32/dirent/Makefile.am build/win32/Makefile.am build/Makefile.am --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Wed, 7 Nov 2007, Morten Welinder wrote: >> nobody has to use this syntax. you can stick to the ever simple: >>g_assert (foo > bar); >> >> however if you want the value of 'foo' and 'bar' be printed out, instead >> of just the value of (foo > bar) which would be 0 or 1, then there are >> no other means than using something simialr to: >>g_assert_cmpfloat (foo, >, bar); > > No other way? You just need to think outside the box^w^wcpp. How > about a pre-cpp filter that looks at the source code, finds the g_assert, > and does a little creative rewriting? how about that? bad. we don't use a preprocessor like moc before cpp+cc. if we did, GObject would look a million times different. people are coding such a thing after the fact these days though, look at vala to see how it looks like. also, for some out of the box thinking, see: http://blogs.gnome.org/timj/2007/07/14/13072007-switch-on-strings-in-c-and-c/ > Morten --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
bug test links (Re: RFC: GLib testing framework)
On Tue, 6 Nov 2007, Matthias Clasen wrote:
> On Nov 6, 2007 2:19 PM, Tim Janik <[EMAIL PROTECTED]> wrote:
>> On Tue, 6 Nov 2007, Matthias Clasen wrote:
>>
>>> On 11/1/07, Tim Janik <[EMAIL PROTECTED]> wrote:
>>
>>> One thing I find pretty useful, that has not been mentioned so far (or
>>> I missed it) is regression tests for bugs. For these it is very useful
>>> to have some standardized way to refer to the bug they are testing.
>>
>> people can use any naming scheme they want, there's no dictate for that in
>> the framework. e.g you could start to label your tests like this:
>>
>>g_test_add_func ("/gtk/bug/4711", test_rand1);
>>g_test_add_func ("/gtk/bug/4712", test_assertions);
>>g_test_add_func ("/gtk/bug/1313", test_timer);
>
>
> I was hoping for some way to associate bug numbers with test cases
> that would allow
> the report to contain a link to the bug.
tko suggested a very simple call "bug (12345);" inside a test case.
i think tihs could be feasible:
voidg_test_bugzilla (const gchar *bugzilla_url_prefix);
voidg_test_bug (guintbugid);
g_test_bugzilla() if called outside a testcase will set the default
bugzilla url for all test cases. if called inside a test case, it
sets the bugzilla url for the scope of the case only.
g_test_bug() can be called inside a testcase, and cause a #bugid
link to appear in the test report.
for gtk and glib specifically, g_test_bugzilla() could default to
the gnome bugzilla projects from some glib/gtk specific test program
boilerplate function, e.g. gtk_test_init (&argc, &argv).
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Tue, 6 Nov 2007, Matthias Clasen wrote:
> On 11/1/07, Tim Janik <[EMAIL PROTECTED]> wrote:
> One thing I find pretty useful, that has not been mentioned so far (or
> I missed it) is regression tests for bugs. For these it is very useful
> to have some standardized way to refer to the bug they are testing.
people can use any naming scheme they want, there's no dictate for that in
the framework. e.g you could start to label your tests like this:
g_test_add_func ("/gtk/bug/4711", test_rand1);
g_test_add_func ("/gtk/bug/4712", test_assertions);
g_test_add_func ("/gtk/bug/1313", test_timer);
or stick to:
g_test_add_func ("/random-generator/rand-1", test_rand1);
g_test_add_func ("/misc/assertions", test_assertions);
g_test_add_func ("/misc/timer", test_timer);
>> - we provide an extended set of assertions for strings, ints and floats
>>that allow printing of assertion arguments upon failures to reduce
>>the need for debugging:
>> g_assert_cmpfloat (arg1, cmpop, arg2);
>> g_assert_cmpint (arg1, cmpop, arg2);
>> g_assert_cmpstr (arg1, cmpop, arg2);
>>used like:
>> g_assert_cmpstr ("foo", !=, "faa");
>> g_assert_cmpfloat (3.3, <, epsilon);
>>g_assert() is still available of course, but using the above variants,
>>assertion messages can be more elaborate, e.g.:
>> ** testing.c:test_assertions(): assertion failed '(3.3 < epsilon)':
>> (3.3 < 0.5)
>
> This syntax strikes me as not particularly elegant and a pretty severe
> clash with
> C syntax. I don't think I can get myself to insert random commas into
> expressions like that.
>
> How about this instead ?
>
> g_assert_with_message ("foo not smaller than bar", foo > bar)
nobody has to use this syntax. you can stick to the ever simple:
g_assert (foo > bar);
however if you want the value of 'foo' and 'bar' be printed out, instead
of just the value of (foo > bar) which would be 0 or 1, then there are
no other means than using something simialr to:
g_assert_cmpfloat (foo, >, bar);
i've checked in Sven's and my code into a git-svn mirror of glib on
testbit.eu. so you can browse the recent changes here:
http://testbit.eu/gitdata?p=glib.git;a=shortlog;h=gtester
e.g. todays latest version of the testing examples is here:
http://testbit.eu/gitdata?p=glib.git;a=blob;f=glib/tests/testing.c;hb=9c8ae8c0097b8f7c098970e87bf413cd9c4f6a22
and the latest API here:
http://testbit.eu/gitdata?p=glib.git;a=blob;f=glib/gtestframework.h;hb=9c8ae8c0097b8f7c098970e87bf413cd9c4f6a22
> Matthias
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GLib testing framework
On Thu, 1 Nov 2007, Stefan Kost wrote:
> Hi Tim,
> Now some comments about the API
> g_test_create_case -> g_test_case_create
> g_test_create_suite -> g_test_suite_create
i think this is a bit of a philosophy issue. i'd like to think about
the new testing framework as one integrated thing, and that allows creation
of suites and cases (that leads to the names i suggested).
alternatively, GTestCase and GTestSuite can be viewed as self standing
objects with API, which would lead to the names you suggest.
due to the very limited scope of the object APIs and the tight coupling
with the rest of the suite for actually running suites/cases, i'm more
inclined to the former naming/view though ;)
> I would not export g_test_trap_fork(), it should be a parameter to the test
> runner wheter it forks all tests or not. Does -k (keep-going) implies that
> tests
> are forked?
no, the forking API is used only by test developers and only for tests that
are supposed to fail or run asyncronously. i have parts of that already
implemented, so these are working examples that use the forking API:
/* prototype, updated from the initial proposal */
gboolean g_test_trap_fork (guint64 usec_timeout,
GTestTrapFlags test_trap_flags);
/* fork around a failing test and assert the intended cause of failure */
if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDERR))
{
g_assert_not_reached();
}
g_test_trap_assert_failed();
g_test_trap_assert_stderr ("*ERROR*should not be reached*");
/* fork out to interrupt the test after a specific timeout */
if (g_test_trap_fork (1.5 * 100, 0)) // give it 1.5 secs at maximum
{
/* loop and sleep forever */
while (TRUE)
g_usleep (1000 * 1000);
}
g_test_trap_assert_failed(); // testing timeout logic here
g_assert (g_test_trap_reached_timeout()); // ensure it failed due to timeout
/* fork out to assert stdout pattern */
if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDOUT))
{
g_print ("some stdout text: somagic17\n");
exit (0);
}
g_test_trap_assert_passed();
g_test_trap_assert_stdout ("*somagic17*");
the idea is to let the actual test binaries never do forks unless the above
API is used (but then, it's the test writer who forks out) and to let the
runner always fork+exec the test binaries. that way, test binaries stay
very simple and straight forward according to the test implementation,
so can be easily debugged in gdb.
then, if launched via the runner, if a test binary actually fails a test
(and thus needs to abort because we can't catch exceptions in C), the runner
can fork+exec a new instance of the test binary to execute the next test,
in case --keep-going was specified.
> Would it make sense to allow overridable test_result loggers. This way a ide
> can
> drive the test and gather result without the need to parse stdout.
we intend to either allow multiple runner implementations (e.g. gtester for the
command line, and another for ide integration), or to simply interface with the
xml logging output that gtester is supposed to produce.
> One problem with unit-tests is that one can only tests the public api. The can
> sometimes be worked around a bit with providing mock obejects. I am wondering
> if
> it would be useful to have internal tests inside the real code, call this from
> the tests (maybe a separate aspect) and wrap those internal function with some
> #ifdef so that is can be ommited by default from releases.
i think at the very least, we'll need some hooks into Gtk+ for things like
installing mock object vtable. my current idea is to wrap that up like:
#ifdef GTK_INTERNAL_ABI
void gtk_test_install_widget_vtable (GtkTestVTableWithManyHooks *vtable);
#endif
so it's not part of the public API, but can be used by test binaries built
inside the gtk+ package tree which link against libgtk-2.0.so.
but this isn't part of the glib testing framework, and as i said, i'll
send out an email on gtk testing routines at another point.
> Finally, how would the logger output look like. check support a normal and
> verbose mode. Providing similar formated logs would give us instant reports on
> http://build.gnome.org
i'd ideally like gtester to supply all valuable information in an xml file,
so we can implement arbitrary report generators on top of that. there are
so many different report targets and needs by various people, that i think
we can only cover all if people can plug their report generators.
> Okay, before my mail exceeds yours, I'll stop here,
heh ;) thanks for the input.
> Stefan
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: GLib testing framework
(testpath, sizeof (Fixture), fsetup, ftest, fteardown)
/* measure test timings */
voidg_test_timer_start (void);
double g_test_timer_elapsed(void); // elapsed seconds
double g_test_timer_last (void); // repeat last elapsed() result
/* automatically g_free or g_object_unref upon teardown */
voidg_test_queue_free (gpointer gfree_pointer);
voidg_test_queue_unref (gpointer gobjectunref_pointer);
/* provide seed-able random numbers for tests */
long double g_test_rand_range (long double range_start,
long double range_end);
/* semi-internal API */
GTestCase* g_test_create_case (const char *test_name,
gsize data_size,
void (*data_setup) (void),
void (*data_test) (void),
void (*data_teardown) (void));
GTestSuite* g_test_create_suite (const char *suite_name);
GTestSuite* g_test_get_root (void);
voidg_test_suite_add(GTestSuite *suite,
GTestCase *test_case);
voidg_test_suite_add_suite (GTestSuite *suite,
GTestSuite *nestedsuite);
int g_test_run_suite(GTestSuite *suite);
/* internal ABI */
voidg_assertion_message (const char *domain,
const char *file,
int line,
const char *func,
const char *message);
voidg_assertion_message_expr(const char *domain,
const char *file,
int line,
const char *func,
const char *expr);
voidg_assertion_message_cmpstr (const char *domain,
const char *file,
int line,
const char *func,
const char *expr,
const char *arg1,
const char *cmp,
const char *arg2);
voidg_assertion_message_cmpnum (const char *domain,
const char *file,
int line,
const char *func,
const char *expr,
long double arg1,
const char *cmp,
long double arg2,
charnumtype);
voidg_test_add_vtable (const char *testpath,
gsize data_size,
void (*data_setup)(void),
void (*data_test) (void),
void (*data_teardown) (void));
/* GLib testing framework examples
* Copyright (C) 2007 Tim Janik
*
* This work is provided "as is"; redistribution and modification
* in whole or in part, in any medium, physical or electronic is
* permitted without restriction.
*
* This work is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
* In no event shall the authors or contributors be liable for any
* direct, indirect, incidental, special, exemplary, or consequential
* damages (including, but not limited to, procurement of substitute
* goods or services; loss of use, data, or profits; or business
* interruption) however caused and on any theory of liability, whether
* in contract, strict liability, or tort (including negligence or
* otherwise) arising in any way out of the use of this software, even
* if advised of the possibility of such damage.
*/
#include "testapi.h"
/* test assertion variants */
static void
test_assertions (void)
{
g_assert_cmpint (1, >, 0);
g_assert_cmpint (2, ==, 2);
g_assert_cmpfloat (3.3, !=, 3.4);
g_assert_cmpfloat (7, <=, 3 + 4);
g_assert (TRUE);
g_assert_cmpstr ("foo", ==, "foo");
g_assert_cmpstr ("foo", !=, "faa");
Re: let g_warn_if_fail replace g_assert
On Fri, 19 Oct 2007, Federico Mena Quintero wrote: > On Wed, 2007-10-17 at 11:56 +0200, Tim Janik wrote: >> - extend the g_assert() docs to note that: >>1) programmers are more likely to want to use g_warn_if_fail instead >> (particularly for libraries, allthough the destabilizing effects >> of g_assert are also worth avoiding in applicaiton code); > > This is the part I don't like. Making failed sanity checks not exit the > program will *not* make your program more robust; it will just make > people ignore broken programs. Nobody paid attention to critical > warnings until we started actively crashing programs that printed them > during development versions --- grep for g_log_set_always_fatal() in > gnome-session/main.c. the fact that a crasher gets more attention than a warning doesn't make it better usability wise. an example for a better solution would be an unconditional dialog along: === Warning: stability compromised === Application failed an internal integrity check. Please save your data and exit as soon as possible. Additionally, it'd be nice if you reported the failure notice detailed below to the upstream project. +-[>]--- Details --+ | Bug reporting: htttp://upstream/bugzilla/url | | Failure notice: | | ** WARNING **: frobnicate(): assertion 'ref_count != 0' | | failed. | +--+ such a thing should be triggered upon every critical/warning (and most if not all assertions should be turned into a warning). > Federico --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
let g_warn_if_fail replace g_assert
hey All. proposing to turn g_asert into a warning: http://mail.gnome.org/archives/gtk-devel-list/2007-October/msg00053.html was obviously not perceived too well. as i read it, most people are not against my basic reasoning, but are clearly in favour of adding g_warn_if_fail or a similar variant thereof. so i'd like to change course and suggest we do this: - add g_warn_if_fail (condition); which produces a critical warning about failing assertions but contrary to g_assert returns. - extend the g_assert() docs to note that: 1) programmers are more likely to want to use g_warn_if_fail instead (particularly for libraries, allthough the destabilizing effects of g_assert are also worth avoiding in applicaiton code); 2) for code portions that positively have to rely on program termination, only g_error() will deterministically achive that. - proceed analogously for g_warn_if_reached() and g_assert_not_reached(). comments apprechiated, particularly on the new function names. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Owen Taylor wrote: > On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote: > >> i'd like to propose to turn g_assert and friends like g_assert_not_reached >> into warnings instead of errors. i'll give a bit of background before the >> details though. > > This is an incompatible change. The contract now is that unless you > compile with G_DISABLE_ASSERT, g_assert(FALSE) will cause your program > to exit with a non-zero status. i don't think a function contract is anything worth if it depends on build time options. if there is any contract breach here, it was the introduction of G_DISABLE_ASSERT (Thu Feb 19 01:11:48 1998 in gtk+-0.99.4 ;) however, due to the g_warn_if_fail variant having quite a following, i intend to change my proposal anyway. so persuing this argument is moot. > - Owen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Mathias Hasselmann wrote:
> Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
>> note that in practice, this shouldn't change anything for programmers
>> (except for the ability to write better code ;)
>> because of G_DISABLE_ASSERT, programmers can already not rely on
>> failing assertions to abort their programs (only g_error will reliably
>> do that).
>
> I was in strict "HELL, NO!" mode until I read this reasoning. Still I am
> not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
> instead of g_return* or g_warning you usually really have no good
> fallback strategy and therefore accept the program crashing.
>
> So for better error handling I'd suggest keeping the old and boring "if
> (blub) { g_warning ... } paradigm.
>
> So I guess what you really want is some kind of "g_soft_assert" or some
> "g_warn_if_fail".
thanks for the input, however i'm not surprised you bring this up ;)
i thought about suggesting some g_assert_warn() myself before i proposed
changing g_assert.
i didn't suggest introducing that because i fail to see a considerable
benefit in introducing it over adapting g_assert.
it boils down to these two properties of g_assert:
a) g_assert issues a warning about failing assertions, so in this regard
it already achieves what we'd otherwise use g_warn_if_fail() for;
b) we already can't rely on g_assert abort()-ing a program, depending on
the build time flag G_DISABLE_ASSERT.
given (b) in particular, g_assert already provides no stronger guarantees
than g_warn_if_fail would, so i think it'd be most straight forward if
we adopted the code to be more consistent about (b) so we only abort for
--g-fatal-warnings, and be more explicit (in the docs) about the existing
need that you have to use g_error() to reliably abort.
to some extend, this could be seen as just enabling a runtime switch
(--g-fatal-warnings) for an existing build time option (G_DISABLE_ASSERT).
> Also remember that such a dramatic that (external) programmers most
> certainly do not expect their program to continue after a failed
> assertion (despite the G_DISABLE_ASSERT misfeature). So not calling
> abort on failed assertions could make the program eat little children,
> if not worse.
the same reasoning applies to g_return_if_fail(), so i'll extend on it
here for a bit.
for development phase i welcome all available aid for developers and
support early catching + fixing of program errors, often done best with
gdb + --g-fatal-warnings (after all, that's why this option was introduced
in the first place).
for end-users however (i.e. production phase), it simply turned out that
warn + return for our many function call guards is much friendlier.
contrary to a developer, a user can't fix the program if it aborts, and
contrary to a developer, the user can loose critical data due to an
unneccesarily forced abort. (if developers trust critical data to their
programs during development phase, that's their own responsibility ;)
i'm not proposing any change in semantics here, glib/gtk+ programs
that spew a critical, warning or error are by definition in an undefined
state. the cause of which must be fixed, and no support or guarantees
for program behavior after a warning can be made.
however, the above end-user friendly reasoning about g_return_if_fail
also applies to g_assert, so i think assertions should be adapted to
act accordingly (abort on --g-fatal-warnings and not otherwise like
g_return_if_fail).
> Ciao,
> Mathias
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Yevgen Muntyan wrote:
> Hey,
>
> Why not introduce a new check, some g_check_stuff() which would
> do what you propose? And let g_assert() be what it is, a glib analog
> of C assert(). When an assertion fails, you can't possibly expect the
> code to function in any meaningful way, e.g.
>
> int idx;
>
> g_assert (idx >= 0);
> array[idx] = 8;
>
> you get segfault or worse here if g_assert() above fails to bring program
> down, you simply can't change g_assert() now to behave in such a
> different way.
please reread my reasoning about G_DISABLE_ASSERT, there already is no behavior
of g_assert() you could rely on. (and some distributions do build their
binaries with G_DISABLE_ASSERT and/or G_DISABLE_CHECKS defined).
if you really meant the above assertion as an essential program
logic part and want to depend on the program exiting before array[]
is accessed, you already have to use if (idx >= 0) g_error ("off bounds");
> Best regards,
> Yevgen
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
turning g_assert* into warnings
hey All.
i'd like to propose to turn g_assert and friends like g_assert_not_reached
into warnings instead of errors. i'll give a bit of background before the
details though.
the main reasons we use g_return_if_fail massively throughout the glib and
gtk+ code base is that it catches API misuses verbosely and gives programmers
a chance to fix their code. this could be achieved with either a g_warning
(mourn on stderr) or a g_error (mourn and abort).
the reasons for the default behavior to use g_warning:
a) a warning usually fullfills its purpose, the programmer knows there's
something to fix and can start to trace the root cause.
b) for easy tracing in gdb with backtraces, programmers can use
--g-fatal-warnings to force abort behavior.
c) programs that aren't 100% bug free could possibly trigger these warnings
during production. aborting would take all the end user data with it,
created/modified images, text documents, etc.
issuing just a warnig preserves the possibility to still save crucial
data if the application logic state still permits (which is most often
the case in practice).
in a recent discussion, i figured that (c) perfectly applies to g_assert
and g_assert_if_reached() also. but we're actually aborting here:
void
g_assert_warning ([...])
{
[...]
abort ();
}
i'd like to change that to:
void
g_assert_warning ([...])
{
[...]
- abort ();
+ if (--g-fatal-warninngs)
+ abort ();
}
for a few reasons:
1) allow users to save their data if still possible; i.e. (c) from above.
2) for glib/gtk+ unit tests (more on that later), failing but
non-aborting tests are interesting for overall report generation; and the
ability to force immediate aborts for debugging is preserved with
--g-fatal-warninngs.
3) assertions can help to document programmer intentions and frequent (but
regulated) use as we have it with g_return_if_fail can significantly
reduce debugging time. i have so far been fairly strict about not adding
assertions to the glib/gtk+ core though, because they also tend to make
the code and end-user experiences more brittle, especially an
occasional wrong assertions that'd have to be revoked upon closer
inspection.
conditionalizing the abort removes the brittleness and allows for
adding more helpful assertion statements.
note that in practice, this shouldn't change anything for programmers
(except for the ability to write better code ;)
because of G_DISABLE_ASSERT, programmers can already not rely on
failing assertions to abort their programs (only g_error will reliably
do that).
it should however take down programs in end user scenarios less often,
and code review can be more lax about adding assertions.
as a side note, it'd probably make sense to present the end users with more
prominent warnings if one of his applications ran into a glib warning/
critical/assertion, and he should be notified about needing to save
his data and exit ASAP. but that's really another topic, probably
best tackled by gnome.
comments welcome and thanks for the interest.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
branching GLib-2.15 and Gtk+-2.13
hey All. there have been some pings recently on API changing bugs in bugzilla, and i've heared about other API related bugs coming up soon. so i guess next week would be a good time to branch Gtk+ for 2.13 and GLib for 2.15. at least, i intend to do it then if no one beats me at it. ;) feedback welcome. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
On Fri, 14 Sep 2007, Alexander Larsson wrote: > I got some feedback on gio about a getter function that returned a ref, > and now I'm reviewing the gio APIs for things like that, making sure its > internally consistent and consistent with gtk+/glib. > > However, I'm not sure what the gtk+ standard for this is. I heard "no > reffing getters", but that is somewhat limited. [without following the rest of this thread...] we discussed this back in the day when we still could have changed matters to be consistently across the platform. i believe the general getter/dup/peek discussion should be in the gnome-hackers archive around 2000. the short story is this: - it was suggested to name getters 'peek' if they returned pointers to memoery that was not duplicated or referenced. i.e. not owned by the caller. - it was suggested to name getters 'dup' (or 'ref') if they returned pointers to memoery that was allocated or referenced for the purpose of the getter, i.e. owned by the caller. - after a lengthy discussion, both suggestions got rejected and we stuck with: a) a getter is usually named '_get_' b) memory returned by a getter can be duplicated/referenced or not, that depends on the getter. the user always has to refer to the documentation or source code here. c) for strings, getters that return memory not owned by the caller should use G_CONST_RETURN. a good reason for why there is no simple convention for getters is the case of getting a list of objects. in some cases you'd want to be able to peek at the internally stored list nodes for performance reasons, e.g.: /* returned list *not* owed by caller */ GSList* gtk_window_peek_toplevels (void); free: /*noop*/ in others, you'd e.g. buy the overhead of a list copy for the sake of always returning doubly linked lists and do: /* returned list owed by caller, but not references */ GList* gtk_window_list_toplevels (void); free: g_list_free (return_value); and then again, for some object lists where it's common practice to modify or destroy some of the returned instances, or where it's likely to have a concurrent entity deleting/adding/shuffling items in the list, it may make most sense to hand out extra object references: /* returned list and additional references owed by caller */ GList* gtk_window_list_toplevels_refed (void); free: g_list_foreach (return_value, g_object_unref, NULL); g_list_free (return_value); --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 20 Sep 2007, Raffaele Sandrini wrote:
> On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote:
>> erm, no. that's at least not a clean solution, ref counts may increase and
>> decrease at any point in time for random reasons (caches, garbage collection
>> algorithms, etc...), even from concurrently running threads without holding
>> the GDK lock.
>>
>>> Take a look at the GtkFileChooser interface
>>> there this hack is used several times. (and annotated as such)
>>
>> hm, not here:
>> $ fgrep ref_count gtk/gtkfilechooser*.c
>> $
>
> Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack
> done there is somehow possible with objects it is not with strings.
>
> GtkWidget *
> gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser)
> {
> GtkWidget *preview_widget;
>
> g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL);
>
> g_object_get (chooser, "preview-widget", &preview_widget, NULL);
>
> /* Horrid hack; g_object_get() refs returned objects but
> * that contradicts the memory management conventions
> * for accessors.
> */
> if (preview_widget)
>g_object_unref (preview_widget);
this code is not peeking at preview_widget->ref_count, it
just always unrefs because by getting it always owns a returned reference.
>
> return preview_widget;
> }
>
>>
>>> All we need from you is either a solution or the statement that this is
>>> not possible with gobject properties ;).
>>
>> i don't quite get what you're trying to achive.
>> but if efficiency is your only concern, i do think that you
>> can spare a string copy by using g_object_get_property()
>> instead of g_object_get(). it just still will be internally
>> copied when it's passed around as a GValue (g_object_get
>> just does two copies alltogether, the second of which needs
>> to be freed by tha caller).
>
> That might be true but does not help here.
well, you still fail to say *why* this does not help
or poses a problem for you.
> We use getters/setters all
> through Vala for several reasons including the ability to embed a
> getter/setter in any kind of C expression and due to speed concerns with
> GValue. The memory convention of getters/setters is to return "weak"
> references.
this is *not* a convention of getters in glib/gtk programs.
like i said in my first email, some getters return peeked contents,
some return duped/referenced contents.
technically, it is *not* possible to implement all getters as peeking
functions because return values may be constructed on the fly.
so any convention that demanded only peeking getters would be in error
because it'd be technically impossible to implement thoroughly.
(maybe what you're saying is that this is a convention for vala
getters... but then, that's something you'd very badly have to fix,
because it is *not* implementable for all C programs, even beyond
glib/gtk programs.)
> cheers,
> Raffaele
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 19 Sep 2007, Raffaele Sandrini wrote: > On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote: >> On Wed, 19 Sep 2007, Raffaele Sandrini wrote: >> callers of getters have to free the returned string in C. >> for glib/gtk programs, if the caller doesn't need to free the string, >> the return value should be G_CONST_RETURN gchar*. > > That's right since the getters do not claim ownership they do not need > to free the strings. The problem is the caller assumes a weak reference > and will dup it if it needs ownership. > The point here is that we are talking about *abstract* properties i.e. i > do not know whether the implementation uses a static string or not. I > have to call g_object_get whether i want to or not. i'm not quite sure why you'd *not* want to call g_object_get if you want to get the property ;) btw, if you're autogenerating code, you should be better off with using g_object_get_property() which is more efficient than g_object_get() to use, especially if the caller doesn't mind initializing and unsetting his own GValue. >>> Since we do not see a way around this (yet) and we could not find an >>> example with strings in another project. I'm asking here if there is a >>> nice way around this. >> >> i'm really not sure i understand your problem here... > > We need a way to steal the string from the property i.e. to make sure > its not a copy of the original. well, why do you want to peek at the original string at all? there's no API with which you'd ever be allowed to modify such a string pointers contents, so always getting a copy should be no problem for you. >>> BTW: There are equal issues with properties returning objects only there >>> you can add a hack into the getter unrefing the object before returning >>> it. This is not applicable with strings. >> >> this is not applicable with objects. as soon as you called unref(obj), >> the object will be destructed and gone, you can't hand it on any further, >> "obj" will point to freed memory. >> in some rare cases and if you're lucky, the object might stay around >> a little longer because someone else could coincidentally hold another >> reference. but this can't be relied upon. >> a well formed getter implementation might do: >>return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL)); >> once you g_object_unref() this return value, it'll be instantly vaporized >> with >> a crushing noise (if you hooked up pulseaudio via destruction emission hooks >> ;) > > You can check the ref count first. erm, no. that's at least not a clean solution, ref counts may increase and decrease at any point in time for random reasons (caches, garbage collection algorithms, etc...), even from concurrently running threads without holding the GDK lock. > Take a look at the GtkFileChooser interface > there this hack is used several times. (and annotated as such) hm, not here: $ fgrep ref_count gtk/gtkfilechooser*.c $ > All we need from you is either a solution or the statement that this is > not possible with gobject properties ;). i don't quite get what you're trying to achive. but if efficiency is your only concern, i do think that you can spare a string copy by using g_object_get_property() instead of g_object_get(). it just still will be internally copied when it's passed around as a GValue (g_object_get just does two copies alltogether, the second of which needs to be freed by tha caller). > Forgot to post the bug against Vala: > http://bugzilla.gnome.org/show_bug.cgi?id=472904 > > Hope things are more clear now. > > cheers, > Raffaele > --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
> Hi there,
>
> While implementing abstract properties in Vala we encountered a problem
> regarding string properties with getter and setter functions:
>
> public interface Test.MyIface {
> public abstract string text { get; }
> }
>
> A getter function of an abstract string property looks like:
> char* test_my_iface_get_text (TestMyIface* self) {
>char* value;
>g_object_get (G_OBJECT (self), "text", &value, NULL);
>return value;
> }
>
> Property accessors in Vala always return weak references. This leads to
> a memory leak in the calling function of the getter.
i'm not sure what you mean with weak/strong references when it
comes to strings. in C, pointers can be handed out which point to
0-terminated char arrays that represent strings. there's on reference
counting for strings in C as there is in C++. per convention,
for glib/gtk programs, some such string pointers must be g_free()-ed once.
callers of getters have to free the returned string in C.
for glib/gtk programs, if the caller doesn't need to free the string,
the return value should be G_CONST_RETURN gchar*.
> We want property accessors to return weak references so just redefine
> the accessors to return a strong reference is only a last-resort-option.
requesting that all string return types should be const char* is technically
not possible, because some strings need to be constructed in getters.
people who don't want to deal with these memory allocation issues (const
strings vs. caller-needs-to-free strings) should stay away from C, maybe
even C++, and use python, java, scheme, other-garbage-collected languages.
> Since we do not see a way around this (yet) and we could not find an
> example with strings in another project. I'm asking here if there is a
> nice way around this.
i'm really not sure i understand your problem here...
> BTW: There are equal issues with properties returning objects only there
> you can add a hack into the getter unrefing the object before returning
> it. This is not applicable with strings.
this is not applicable with objects. as soon as you called unref(obj),
the object will be destructed and gone, you can't hand it on any further,
"obj" will point to freed memory.
in some rare cases and if you're lucky, the object might stay around
a little longer because someone else could coincidentally hold another
reference. but this can't be relied upon.
a well formed getter implementation might do:
return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
once you g_object_unref() this return value, it'll be instantly vaporized with
a crushing noise (if you hooked up pulseaudio via destruction emission hooks ;)
> cheers,
> Raffaele
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GSource finalization lock (Re: [Bug 459555] gdk_threads_add_* docs question)
On Wed, 22 Aug 2007, gtk+ (bugzilla.gnome.org) wrote: > http://bugzilla.gnome.org/show_bug.cgi?id=459555 > > gtk+ | gdk | Ver: unspecified > > Tim Janik changed: > > What|Removed |Added > > CC||[EMAIL PROTECTED] > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > --- Comment #1 from Tim Janik 2007-08-22 09:47 UTC --- > unfortunately the glib main loop mechanism allows sources to be destroyed > during dispatching (e.g. when a timeout/idler is removed while the gdk lock > is > being held) and also after all GSources have been dispatched (e.g. due to a > reference count which was held across dispatch()). so whether the gdk lock is > being held during destroy is unpredictable. hi Owen. while writing this comment i had some more thoughts on attempting to fix the unpredictable lock issue with main loops. do you see compelling reason to not implement the following? we defer this code snippet from g_source_unref_internal: if (source->source_funcs->finalize) source->source_funcs->finalize (source); g_slist_free (source->poll_fds); source->poll_fds = NULL; g_free (source); for later invocation by keeping a list of need-to-finalize sources on GMainContext. this list is to be processed: - immediately by g_source_destroy if this context is not currently in prepare/check/dispatch, i.e. when g_main_current_source()==NULL - directly after the toplevel source->dispatch() returns, i.e. when done dispatching && g_main_depth() == 0. the above is basically applying the example free_allocated_memory() technique from the g_main_depth() docs to our GSource finalization problem. with this we can finally document that there's never any main loop lock being held (or custom dispatch lock like the one from gdk) during GSource finallization. however, we will temporarily starve and stack-up GSource finalizers during recursive main loops. the question is prolly whether the starving during recursive main loops can be considered minor enough... --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library? (fwd)
On Thu, 16 Aug 2007, Frederic Peters wrote: > Tim Janik wrote: >> - the most requested documentation feature at linuxtag was to make >>our docs searchable, http://developer.gnome.org/doc/API/ has >>a site specific google search entry now. this functionality >>needs to be preserved. > > It is most certainly possible; I don't know how site-specific Google > search works. here's the change for developer.g.o: http://svn.gnome.org/viewcvs/web-devel-2?view=revision&revision=4584 the same snippet is needed for library.g.o, just with both occourances of value="developer.gnome.org" replaced by value="library.gnome.org". or i can do the change to the library-web module myself if you prefer. >> - currently, new trunk based docs can be put up (fixed) immediately >>by doing a new upload (a 24h lag due to automated builds would be >>acceptable here though). you say you're building docs nightly >>from release tarballs only? >>how can we get trunk based docs up then? > > You could just push the trunk tarball at at known location. ah, interesting, which location is that going to be? >Frederic --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
On Wed, 15 Aug 2007, Frederic Peters wrote:
David Neÿÿas (Yeti) wrote:
do you believe a "latest" symlink would
be useful ? As well as a "stable" symlink ?
A stable or latest alias would be definitely useful, but...
This has been taken care of.
Let me explain: The conclusion on gtk-doc was that it is not
feasible to keep the on-line location of everything in
gtk-doc, instead libraries should advertise their on-line
reference base URLs (if there is any) and a mechanisms for
this and for base URL switching/correction have been already
implemented.
This would work well with the current state when each
library has one on-line location (containing the latest
version). The new scheme leaves me wondering what to do
when one just wants to link to GObject (gboolean, whatever)
documentation. What is the canonical link? Is there any?
Okay, I understand your problem now. Although I don't have a perfect
answer. Canonical link would be
http://library.gnome.org/developers/{doc_module}/latest/{whatever}
Current directory layout is the only one making sense if we want to
maintain several versions in library.gnome.org; however we could
probably devise a few mod_rewrite rules to expose other URI schemes,
such as http://library.gnome.org/api/{doc_module}/{whatever}.
i don't really see the necessity for this if we start a new site.
we just need to make sure that all currently existing
http://developer.gnome.org/doc/API/{VERSION}/{MODULE}/{whatever}
links continue to remain valid. i.e. if i understand your new
scheme correctly, they'd need to point to:
http://library.gnome.org/developers/{MODULE}/trunk/{whatever}
or s/trunk/latest/, depending on whether you mean "latest" to
link to the last released version or trunk.
Frederic
---
ciaoTJ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
On Tue, 14 Aug 2007, Olav Vitters wrote: > GTK+ is the main user of the developer API reference with links from: > http://www.gtk.org/api/ > > I want to redirect: > http://developer.gnome.org/doc/API/2.0/ > to: > http://library.gnome.org/developer/ > > See for instance the GTK+ API reference on: > http://library.gnome.org/developers/gtk/2.11/ > > Note: GNOME Library currently finds new tarballs every night. At one > point this will start after install-module runs (low priority right > now). > > If nobody objects within a week I'll make this change. i'm currently uploading the glib/atk/pango/gtk+ docs to http://developer.gnome.org/doc/API/2.0/ manually and have a couple issues/questions before the move: - the above link http://library.gnome.org/developer/ doesn't actually work - the front page links to http://library.gnome.org/devel/ which is a directory listing - i was going to say something about the new reference API titles page, but can't currently browse/verify it due to the directory listings... - the API overview here: http://developer.gnome.org/doc/API/ is ordered by dependencies, this ordering needs to be preserved - the module names/titles shouldn't be marked in red (red is far too intrusive for normal text it allmost looks like error messages) - links should be clearly identifiable as links like on the current pages (blue with underline) - the most requested documentation feature at linuxtag was to make our docs searchable, http://developer.gnome.org/doc/API/ has a site specific google search entry now. this functionality needs to be preserved. - i personally find the grey background image star on http://library.gnome.org/developers/gtk/2.11/ fairly irritating when reading the index. i'd prefer the index text to not change contrast by removing the grey star from the areas which display actual code (i.e. below the "GTK+ Reference Manual" block) - currently, new trunk based docs can be put up (fixed) immediately by doing a new upload (a 24h lag due to automated builds would be acceptable here though). you say you're building docs nightly from release tarballs only? how can we get trunk based docs up then? > -- > Regards, > Olav --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
missing -lm for gtk+/gdk-pixbuf/pixops/pixops.c
hi Tor. your recent change: 2007-07-03 Tor Lillqvist <[EMAIL PROTECTED]> * configure.in: Handle GDK_PIXBUF_EXTRA_LIBS like GDK_EXTRA_LIBS, i.e. clear it if enable_explicit_deps isn't on. If we build with --with-included-loaders and --enable-explicit-deps=no we don't want -ltiff -ljpeg etc in the gdk-pixbuf-2.0.pc file. breaks the build due to missing -lm: $ fgrep MATH_LIB * -n configure.in:116:MATH_LIB=-lm configure.in:121:MATH_LIB= configure.in:517:MATH_LIB= configure.in:1051:GDK_PIXBUF_EXTRA_LIBS="$STATIC_LIB_DEPS $MATH_LIB $MEDIA_LIB" $ make Making all in pixops make[4]: Entering directory `/usr/src/gtk+doc/gtk+/gdk-pixbuf/pixops' /bin/bash ../../libtool --mode=link gcc -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -o timescale timescale.o libpixops.la -pthread -L/usr/src/gtk+doc/installation/lib -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 gcc -DG_DISABLE_DEPRECATED -g -O2 -g -Wall -o timescale timescale.o -pthread ./.libs/libpixops.a -L/usr/src/gtk+doc/installation/lib /usr/src/gtk+doc/installation/lib/libgobject-2.0.so /usr/src/gtk+doc/installation/lib/libgmodule-2.0.so -ldl /usr/src/gtk+doc/installation/lib/libgthread-2.0.so -lpthread -lrt /usr/src/gtk+doc/installation/lib/libglib-2.0.so -Wl,--rpath -Wl,/usr/src/gtk+doc/installation/lib -Wl,--rpath -Wl,/usr/src/gtk+doc/installation/lib ./.libs/libpixops.a(pixops.o): In function `bilinear_box_make_weights': /usr/src/gtk+doc/gtk+/gdk-pixbuf/pixops/pixops.c:1529: undefined reference to `ceil' ./.libs/libpixops.a(pixops.o): In function `bilinear_magnify_make_weights': /usr/src/gtk+doc/gtk+/gdk-pixbuf/pixops/pixops.c:1434: undefined reference to `ceil' ./.libs/libpixops.a(pixops.o): In function `tile_make_weights': /usr/src/gtk+doc/gtk+/gdk-pixbuf/pixops/pixops.c:1380: undefined reference to `ceil' ./.libs/libpixops.a(pixops.o): In function `pixops_process': /usr/src/gtk+doc/gtk+/gdk-pixbuf/pixops/pixops.c:1265: undefined reference to `floor' collect2: ld returned 1 exit status make[4]: *** [timescale] Error 1 reverting your attached patch fixes the build for pixops.c. --- ciaoTJIndex: configure.in === diff -Nup /tmp/tmp /tmp/tmp.2 --- configure.in(revision 18360) +++ configure.in(revision 18361) @@ -1053,13 +1053,6 @@ GDK_PIXBUF_EXTRA_CFLAGS= GDK_PIXBUF_DEP_LIBS="`$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES` $GDK_PIXBUF_EXTRA_LIBS" GDK_PIXBUF_DEP_CFLAGS="`$PKG_CONFIG --cflags gthread-2.0 $GDK_PIXBUF_PACKAGES $PNG_DEP_CFLAGS_PACKAGES` $GDK_PIXBUF_EXTRA_CFLAGS" -AC_SUBST(GDK_PIXBUF_PACKAGES) -AC_SUBST(GDK_PIXBUF_EXTRA_LIBS) -AC_SUBST(GDK_PIXBUF_EXTRA_CFLAGS) -AC_SUBST(GDK_PIXBUF_DEP_LIBS) -AC_SUBST(GDK_PIXBUF_DEP_CFLAGS) - - # Windowing system checks @@ -1530,6 +1523,16 @@ ATK_PREFIX="`$PKG_CONFIG --variable=pref PANGO_PREFIX="`$PKG_CONFIG --variable=prefix pango`" CAIRO_PREFIX="`pkg-config --variable=prefix cairo`" +if test $enable_explicit_deps != yes ; then + GDK_PIXBUF_EXTRA_LIBS= +fi + +AC_SUBST(GDK_PIXBUF_PACKAGES) +AC_SUBST(GDK_PIXBUF_EXTRA_LIBS) +AC_SUBST(GDK_PIXBUF_EXTRA_CFLAGS) +AC_SUBST(GDK_PIXBUF_DEP_LIBS) +AC_SUBST(GDK_PIXBUF_DEP_CFLAGS) + AC_SUBST(GTK_PACKAGES) AC_SUBST(GTK_EXTRA_LIBS) AC_SUBST(GTK_EXTRA_CFLAGS) Index: ChangeLog === diff -Nup /tmp/tmp /tmp/tmp.2 --- ChangeLog (revision 18360) +++ ChangeLog (revision 18361) @@ -1,5 +1,12 @@ 2007-07-03 Tor Lillqvist <[EMAIL PROTECTED]> + * configure.in: Handle GDK_PIXBUF_EXTRA_LIBS like GDK_EXTRA_LIBS, + i.e. clear it if enable_explicit_deps isn't on. If we build with + --with-included-loaders and --enable-explicit-deps=no we don't + want -ltiff -ljpeg etc in the gdk-pixbuf-2.0.pc file. + +2007-07-03 Tor Lillqvist <[EMAIL PROTECTED]> + * gdk/win32/gdkkeys-win32.c (gdk_keymap_have_bidi_layouts): Implement. Just return FALSE for now. What should this function actually do? Does keyboards layouts being "in use" mean that such ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK internals
On Mon, 2 Jul 2007 [EMAIL PROTECTED] wrote: > Hi, > > Is there any document like this: > http://www.sunsite.ualberta.ca/Documentation/Graphics/by-node/gtk+-1.1.1/gtk_toc.html > > Showing the internal details of GTK. This one is pretty outdated(almost 9 > yrs old) and incomplete. I wanted to know the details regarding the > signaling system of GTK. Does anyone have any documents?? like for all things in glib/gtk, we have documentation and/or API reference: http://developer.gnome.org/doc/API/2.0/gobject/signal.html http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html for anything you want to know beyond that, you either need to read the source (gsignal.c) or ask the authors (that'd be me for GSignal). > rgds, > --Abhishek --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: event handling
On Tue, 3 Jul 2007 [EMAIL PROTECTED] wrote: > Hello, > > does anyone have any documents describing how the evnting is handled in > GTK. I this mailing list is about the development of glib and gtk+ itself, so such things should rather be asked on gtk-list or gtk-app-devel-list: http://mail.gnome.org/mailman/listinfo/gtk-list http://mail.gnome.org/archives/gtk-list/ http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list http://mail.gnome.org/archives/gtk-app-devel-list/ > would like to know how a particular widget is identified to deliver an > event for both keyboard type events and mouse type events. first, read http://ftp.xfree86.org/pub/XFree86/4.6.0/doc/xlib.txt for general X related event processing and the terminology i'm using. second, note that all !NO_WINDOW widgets in gtk+ have their own xwindow (wrapped as GdkWindow), and possibly subwindows by which they can process events. some NO_WINDOW widgets also can process events by using input-only xwindows. third, note that events in gtk+ are propagated between widgets until they are handled by an instance, the workings of which can be understood by reading gtkmain.c:gtk_propagate_event. > --abhishek --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Mon, 2 Jul 2007, Elijah Newren wrote: > Hi, > > Sorry to be a pest, but I noticed gtk+-2.11.5 was out, and was > surprised to not see the tips_data_list vs. _tips_data_list issue > reverted. So... > > On 6/25/07, Elijah Newren <[EMAIL PROTECTED]> wrote: >> On 6/22/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: >> > Thats fine. Can we still please revert the field name change to make >> existing >> > pygtk versions compile against 2.11.x ? >> >> And is there any chance we could get a new tarball so we can release >> GNOME 2.19.4? > > Is this in the plans any time soon, or was the reversion decided against? i've made a new suggestion about the rename to deal with the fallout of the field rename on the relevant bug and haven't seen a specific reply to that yet: http://bugzilla.gnome.org/show_bug.cgi?id=447214#c16 i apprechiate further comments... > [Yes, I know I need to also pester the pygtk folks some more to get a > new pygtk tarball as well.] > Thanks for all your hard work, > Elijah --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Mon, 25 Jun 2007, Kristian Rietveld wrote: > On Mon, Jun 25, 2007 at 09:34:56PM +0100, Damon Chaplin wrote: >> Tim said we get motion hints everywhere now anyway (though I can't see >> where that is done in the code). See the last paragraph here: >> http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00230.html > > I don't think Tim was talking about GTK+ in general in that paragraph, > but I am not sure either. right, i was referring to the tooltip system automatically setting the neccessary motion event masks, and why that is required, in response to Damon's suggestion to let the users take care of it. recap: - setting up event masks is too hard for users - GtkTooltip forcefully requests motion events on the right window - GtkTooltip needs to know *when* to force motion events, for this, we need ::has-tooltip. > -kris. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
