Re: Function completion for GVariant maybe types?
> - if the maybe contains a value, return the NULL of the same type Do any software developers dare to think about extensions around the function "g_variant_new_maybe" once more? http://developer.gnome.org/glib/2.35/glib-GVariant.html#glib-GVariant.description Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20/02/13 09:45, Markus Elfring wrote: > Do any software developers dare to think about extensions around the function > "g_variant_new_maybe" once more? Ryan and I have explained several times why we don't think the semantics you requested are useful to have in GLib. Repeatedly asking for the same functions, without providing any more information, is not going to get these functions added. Repeating Ryan's question from before: > Can you please explain, at a higher level, > what you are trying to accomplish? "I want to reset a variant variable" is not the explanation he asked for. The explanation we want might look more like "I want to use variants as values in a database, where 'maybe x' is a possible column type". Please explain. When you do, we will hopefully be able to either see why the functions and semantics you suggested are useful, or suggest a way you can achieve your high-level goal without them. If you want to use these functions in a particular module but you are not willing to explain why you need them, then they are not going to be added to GLib. Add them to that other module instead, or reconsider its design so you don't need them. - Returning to your original mail and making one last attempt to guess what it is that you want: It is important to distinguish between a variable that can point to a variant object (a variable of type GVariant *), and the variant object that it can point to. Variables of type GVariant * are mutable (can be set to point to a GVariant) and nullable (can be set to NULL). If what you want is a variable that contains "maybe x", the simplest way is to have a GVariant * variable whose value is either a variant object of type x, or NULL. Variant objects are immutable, and have a particular type and value. You cannot change the type or value of a variant object, at all. What you *can* do is to change the value of a GVariant * variable, so it points to a *different* variant object. You only need to get into 'maybe' types if you have a container (e.g. serialized structure or D-Bus message) containing 'maybe x', in which case the immutability of variant objects makes your proposed semantics not very useful. > g_variant_is_maybe I don't think this is worthwhile. If g_variant_is_maybe (GVariant *v) existed, it'd be exactly equivalent to: g_variant_is_of_type (v, G_VARIANT_TYPE_MAYBE) which is just as easy to write. > g_variant_can_be_nothing/undefined/optional/maybe This is not meaningful. A GVariant object (the thing pointed to by a GVariant *) has a definite, immutable value: either it is Nothing, or Just x (for some x). GVariant objects are value-objects, not "slots" for value objects. A variant v is a maybe containing Nothing if and only if this expression is true: (g_variant_is_of_type (v, G_VARIANT_TYPE_MAYBE) && g_variant_get_maybe (v) == NULL) If you are talking about a GVariant * variable (pointer to variant object) and you want a signature more like g_variant_location_can_be_null (GVariant **variable) then, no, that's impossible. GLib can't know what the semantics of your variable are: only you (and your code's documentation) can know that. Or, if you want the function's parameter to be a GVariantType rather than a GVariant, then this is just g_variant_type_is_maybe (type). > g_variant_convert_to_maybe > I see a need for a alternative to the interface > "g_variant_new_maybe". I would like to replace a maybe instance > directly instead of allocating a new one. You can't "replace a maybe instance". Variant objects are immutable: creating a new variant object with a different value is always a new allocation. It is possible to reassign a GVariant * variable to point to a different variant object, but that doesn't need a special function: just write the code. > 4. g_variant_set_to_nothing/none > How should a GVariant variable be reset to the special marker > "nothing" after > it was used with other concrete values for a while? Rather than messing about with "maybe x" types, I think you would find it much easier to have this structure: /* Contains a variant of type x, or NULL. * (transfer full) */ GVariant *my_variant = NULL; ... /* set the variable to a non-NULL value */ if (my_variant != NULL) g_variant_unref (my_variant); my_variant = g_variant_ref_sink (g_variant_new_int64 (y)); ... /* set the variable to a NULL value */ if (my_variant != NULL) g_variant_unref (my_variant); my_variant = NULL; and if you need to serialize it somewhere, *then and only then* wrap its current value in an immutable "maybe x" variant object: g_dbus_message_set_body (message, ..., g_variant_new_maybe (G_VARIANT_TYPE_INT64, my_variant), ...); (For "x" and "int64" substitute whatever type the thing has, which you should know already - either hard-coded, or by reading a GVariantType * variable from your database schema or whatever - because you can't do an
can gir files be installed in another directory
Hello, I trying to port Cinnamon to Crux linux. But I see that Gobject-introspection places the gir files in /usr/local/gir-1.0 But in Crux it is forbidden to place files in /usr/local/ So is it possible to tell gobject-introspection to place the gir files in another directory. Regards, Roelof Wobben ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
G_DEBUG_LOCKS - use G_(UN)LOCK macros internally
Hi,
does this patch makes any sense?
diff --git a/glib/gthread.c b/glib/gthread.c
index ee87574..60cff76 100644
--- a/glib/gthread.c
+++ b/glib/gthread.c
@@ -522,7 +522,7 @@ G_DEFINE_QUARK (g_thread_error, g_thread_error)
/* Local Data {{{1 */
-static GMutexg_once_mutex;
+static G_LOCK_DEFINE(once_mutex);
static GCond g_once_cond;
static GSList *g_once_init_list = NULL;
@@ -610,24 +610,24 @@ g_once_impl (GOnce *once,
GThreadFunc func,
gpointer arg)
{
- g_mutex_lock (&g_once_mutex);
+ G_LOCK(once_mutex);
while (once->status == G_ONCE_STATUS_PROGRESS)
-g_cond_wait (&g_once_cond, &g_once_mutex);
+g_cond_wait (&g_once_cond, &G_LOCK_NAME(once_mutex));
if (once->status != G_ONCE_STATUS_READY)
{
once->status = G_ONCE_STATUS_PROGRESS;
- g_mutex_unlock (&g_once_mutex);
+ G_UNLOCK (once_mutex);
once->retval = func (arg);
- g_mutex_lock (&g_once_mutex);
+ G_LOCK(once_mutex);
once->status = G_ONCE_STATUS_READY;
g_cond_broadcast (&g_once_cond);
}
- g_mutex_unlock (&g_once_mutex);
+ G_UNLOCK (once_mutex);
return once->retval;
}
@@ -669,7 +669,7 @@ gboolean
{
volatile gsize *value_location = location;
gboolean need_init = FALSE;
- g_mutex_lock (&g_once_mutex);
+ G_LOCK(once_mutex);
if (g_atomic_pointer_get (value_location) == NULL)
{
if (!g_slist_find (g_once_init_list, (void*) value_location))
@@ -679,10 +679,10 @@ gboolean
}
else
do
- g_cond_wait (&g_once_cond, &g_once_mutex);
+ g_cond_wait (&g_once_cond, &G_LOCK_NAME(once_mutex));
while (g_slist_find (g_once_init_list, (void*) value_location));
}
- g_mutex_unlock (&g_once_mutex);
+ G_UNLOCK (once_mutex);
return need_init;
}
@@ -710,10 +710,10 @@ void
g_return_if_fail (g_once_init_list != NULL);
g_atomic_pointer_set (value_location, result);
- g_mutex_lock (&g_once_mutex);
+ G_LOCK(once_mutex);
g_once_init_list = g_slist_remove (g_once_init_list, (void*) value_location);
g_cond_broadcast (&g_once_cond);
- g_mutex_unlock (&g_once_mutex);
+ G_UNLOCK (once_mutex);
}
/* GThread {{{1 */
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
I would like to see that information - even if I have no instant use for it - but I am pretty sure it will help a lot of people digging for information. Best Bernhard 2013/2/19 John Emmas : > On 4 Jan 2013, at 10:49, Matthew Brush wrote: > >> >> From the last few messages on this thread, it kind of sounds like your >> module search path is not set up correctly, that is, Python doesn't know >> where to look to import your modules/packages (try "print(sys.path)" to see >> which paths I mean). There's good docs about this on python.org (as well as >> all kinds of other excellent docs/tuts). >> > > Hi guys, > > I suppose everyone's probably forgotten all about this by now - so to recap... > > I was trying to use Visual Studio to do a complete build of libglib, > including the various perl and python scripts such as 'glib-mkenums' and > 'gdbus-codegen'. glib-mkenums eventually got solved but I couldn't build > gdbus-codegen (which needs Python). My builds were consistently failing at > lines which looked like this:- > > from . import > > A few people suggested changing those lines to a simplified version:- > > import > > but initial tests didn't look good, so I gave up. But yesterday I came > across this thread at StackOverflow which gave me some further information to > consider:- > > http://stackoverflow.com/questions/72852/how-to-do-relative-imports-in-python > > and finally, after a lot of patience I've just managed to make the build > work! It does seem to be a problem with paths and I'm not yet sure what the > minimum changes are. However, if anyone's still interested, I'll simplify it > as much as I can and post the solution here sometime. > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)
Hello, I was putting a GtkNotebook on a main window widget (using glade) and set the tab position to BOTTOM. This looks alright in glade. However, running the application itself one sees that the tabs are not drawn correctly (they retain round corners and the highlighting orange at the _top_ edge of the tab, while it should be at the bottom). see attach link. Looking through the code (git master gtknotebook.c) I can only guess where the respective drawing action might occur, and I can't see anything which might cause this behavior (specifically on windows). I was hesitating to file a bug report for this. Thomas NB: Alongside, I was curious whether the "windows code" is actually a separate code, a slight adaption of the trunk or completely the same (with switching #defines). http://www.imagetoo.com/images/gtk354win3.png + DAS BEDINGUNGSLOSE GRUNDEINKOMMEN [1]: Machen uns die Schweizer jetzt vor, wie es geht? JETZT IM UNI.DE MAGAZIN. Links: -- [1] http://uni.de/redaktion/bge-das-bedingungslose-grundeinkommen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: can gir files be installed in another directory
On Fri, 2013-02-15 at 14:14 +0100, Chantal Wobben wrote:
> Hello,
>
> I trying to port Cinnamon to Crux linux.
> But I see that Gobject-introspection places the gir files in
> /usr/local/gir-1.0
No; like every other Autotools using component, it places them in
whatever you specify as --datadir.
And if what you're actually asking for is for it to use something
other than ${prefix}/share/gir-1.0 because you have some moral
objection to directories there - well, good luck patching the world,
because *tons* of things in the GNOME stack do that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
Ryan and I have explained several times why we don't think the semantics you requested are useful to have in GLib. I replied to your concerns. I was missing a bit more feedback in the meantime. Now I hope that our small discussion can be continued in constructive ways. "I want to reset a variant variable" is not the explanation he asked for. The explanation we want might look more like "I want to use variants as values in a database, where 'maybe x' is a possible column type". I would appreciate the requested functionality also for such an use case. I need it for concrete adjustments in applications like a partition manager. Do you see the applicability by an open issue like "Improvements for partition in-use indication"? https://bugzilla.gnome.org/review?bug=621677&attachment=205643 ... - because you can't do anything useful with data of an unknown type.) Thanks for your detailed response. How would you like to achieve the feature to set a nullable object to the special marker "nothing" while keeping the previous data type information? Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20/02/13 16:37, Markus Elfring wrote: > I need it for concrete adjustments in applications like a > partition manager. I don't see how this is relevant to GVariant. How are you using variants? What does the variant represent? What type is it? What data structure are they stored in? Why are you using a 'maybe' type, as opposed to a GVariant * that may be NULL? > Do you see the applicability by an open issue like "Improvements for > partition in-use indication"? > https://bugzilla.gnome.org/review?bug=621677&attachment=205643 I don't see anything in that patch that has anything to do with variants. > How would you like to achieve the feature to set a nullable object to > the special marker "nothing" while keeping the previous data type > information? As far as I can see, not having this function in GLib doesn't prevent you from doing anything, because it's implementable in terms of GLib functions. That means this function should only exist in GLib if it is useful to other developers/other projects, and has an appropriate data model to be useful. Now, I don't think this *is* an appropriate data model in many (any?) situations: if you have a GVariant but you don't know what type it's meant to be, that probably means something has gone horribly wrong. If you're dealing with GVariants that mean something to your code, then your code should already know the right type. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
How are you using variants? I would like to achieve a mapping of nullable objects to indeterminate checkboxes for example. What data structure are they stored in? Candidate: template class "Gtk::TreeModelColumn" Why are you using a 'maybe' type, as opposed to a GVariant * that may be NULL? I would like to point out that a null pointer has got a different meaning in comparison to a specific object which was marked to contain "nothing" (representation for an "unknown" value). Such a nullable object can store valuable data type information, can't it? https://bugzilla.gnome.org/review?bug=621677&attachment=205643 I don't see anything in that patch that has anything to do with variants. You are right. - I could not introduce the affected feature so far because the class library "gtkmm" does not support nullable containers yet, does it? http://developer.gnome.org/glibmm/2.34/classGlib_1_1VariantBase.html See also discussion on a topic like "Clarification for the application of GVariant/Glib::Variant maybe types": https://mail.gnome.org/archives/gtkmm-list/2011-October/msg00051.html http://article.gmane.org/gmane.comp.gnome.gtkmm/25571 If you're dealing with GVariants that mean something to your code, then your code should already know the right type. I have got a different opinion for this design detail. I am also interested in generic programming for the design pattern "Model-View-Controller". http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20/02/13 18:11, Markus Elfring wrote:
>> How are you using variants?
>
> I would like to achieve a mapping of nullable objects to indeterminate
> checkboxes for example.
A GVariant with 'maybe' type seems far too complicated for this. I'd use
an integer holding a tristate enum, { NO, INDETERMINATE, YES } (or
possibly a pair of booleans, to match how GtkCheckButton works).
If you need variants for some reason, { GVariant of type 'b' with value
FALSE, NULL, GVariant of type 'b' with value TRUE } is also a perfectly
good tristate.
If, for some reason, you absolutely need non-NULL variants with type
'mb' ("maybe boolean"), then you already know that your data model is
that you have variants of that type; so you can just make one of these
objects whenever you need a new variant, and you're done:
/* "just true" */
yes = g_variant_ref_sink (g_variant_new_maybe (NULL,
g_variant_new_boolean (TRUE));
/* "just false" */
no = g_variant_ref_sink (g_variant_new_maybe (NULL,
g_variant_new_boolean (FALSE));
/* "@mb nothing" */
indeterminate = g_variant_ref_sink (g_variant_new_maybe (
G_VARIANT_TYPE ("mb"), NULL);
There's no need to add functions to GLib for this; and in the time
you've spent arguing about it, you could have implemented all three of
those possibilities and possibly more, chosen the one you liked best,
and got on with whatever high-level problem you were solving.
>> Why are you using a 'maybe' type, as opposed to a GVariant * that may
>> be NULL?
>
> I would like to point out that a null pointer has got a different
> meaning in comparison to a specific object which was marked to contain
> "nothing" (representation for an "unknown" value). Such a nullable
> object can store valuable data type information, can't it?
If your data model is "my value is a variant of type 'mb'" then you
already know that you're dealing with 'mb' variants; so you don't need
to copy the data-type from an existing variant, you can just say "mb".
If your data model is "I have a variant, and I don't really know what it
means" then... you don't really know what it means, and you can't do
anything particularly useful with it until you find out.
Model-view-controller programming shouldn't be an excuse for speculative
generalization. Don't make things more complicated than they need to be;
software is usually quite complicated enough already.
S
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
>> I would like to achieve a mapping of nullable objects to indeterminate
>> checkboxes for example.
>
> A GVariant with 'maybe' type seems far too complicated for this.
Why?
I find that "GVariant" provides a general interface for the handling of nullable
data types.
> I'd use an integer holding a tristate enum, { NO, INDETERMINATE, YES } (or
> possibly a pair of booleans, to match how GtkCheckButton works).
Why do you prefer to use an enumeration instead of the other general application
programming interface?
> If you need variants for some reason, { GVariant of type 'b' with value
> FALSE, NULL, GVariant of type 'b' with value TRUE } is also a perfectly
> good tristate.
I agree in principle. Now you try to reduce my request to a special case while I
am still looking for a more general solution.
> If, for some reason, you absolutely need non-NULL variants with type
> 'mb' ("maybe boolean"), then you already know that your data model is
> that you have variants of that type; so you can just make one of these
> objects whenever you need a new variant, and you're done:
I do not think that I can refer to such preallocated objects if I would like to
reuse a template class like "Gtk::TreeModelColumn".
> There's no need to add functions to GLib for this; and in the time
> you've spent arguing about it, you could have implemented all three of
> those possibilities and possibly more, chosen the one you liked best,
> and got on with whatever high-level problem you were solving.
I have got still a different opinion here which I tried to demonstrate in a
draft for the function "g_variant_new_nothing_from_type".
https://mail.gnome.org/archives/gtk-devel-list/2011-December/msg00018.html
http://article.gmane.org/gmane.comp.gnome.gtk+.devel.general/21768/
> If your data model is "I have a variant, and I don't really know what it
> means" then... you don't really know what it means, and you can't do
> anything particularly useful with it until you find out.
I disagree to your conclusion here. - I would like to copy the data type
information from the contained value into a new "Nothing GVariant" in an
efficient way. I do not really want to know the concrete copied data type if I
would like that this operation will be supported in a generic way so that it can
be reused by other class libraries like "glibmm".
> Model-view-controller programming shouldn't be an excuse for speculative
> generalization. Don't make things more complicated than they need to be;
> software is usually quite complicated enough already.
I see opportunities for further fine-tuning and improvement of the involved
APIs.
Regards,
Markus
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On Wed, Feb 20, 2013 at 1:44 PM, Markus Elfring wrote: > I do not think that I can refer to such preallocated objects if I would > like to > reuse a template class like "Gtk::TreeModelColumn". > > I disagree to your conclusion here. - I would like to copy the data type > information from the contained value into a new "Nothing GVariant" in an > efficient way. I do not really want to know the concrete copied data type > if I > would like that this operation will be supported in a generic way so that > it can > be reused by other class libraries like "glibmm". I can't say I really understand what you want, but in glibmm you can: Glib::VariantBase v = Glib::VariantBase(); Which will create C++ VariantBase object that does not actually have an allocated GVariant backing it, e.g. v.gobj() == NULL In glibmm 2.36 it will be possible to test whether the GVariant is null or not by just doing if (v), see bug 690121. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some shortcomings in gtestutils
Hi, everyone, I've been writing some tests for GtkFileChooserButton and putting them in gtk+/gtk/tests/filechooser.c - this is the old test suite, resurrected and alive. So, I've been learning what gtestutils provides. It is not bad, but it seems pretty pedestrian on some counts. These are some things I'd like to change, or at least for someone to point me in the right way of doing them: * Tests abort as soon as a test fails, since tests ultimately depend on variations of g_assert(). This is fine in that it makes the "ensure things are okay" code look the same as "generic sanity check" code. However, it also means that a test suite aborts as soon as it encounters the first test that doesn't pass. There is g_test_fail(), but the documentation pretty much only says, "You can use this function if your test failed in a recoverable way." I don't know if that means that the test couldn't find a data file (but can continue anyway), or if it means "call this if you want the test to fail but want the test suite to continue running". * It's hard to get a debugger up in the middle of "make check". I can't think of a way to do it other than manually inserting code to sleep in the middle of the faulty test, and then attaching with a debugger manually. Maybe having an environment variable or something, so that I could run $ G_PAUSE_ON_FAILED_TESTS=1 make check when a test fails, I would get told, "attach to $pid now" or somthing. Maybe even have a G_NAME_OF_TEST_TO_PAUSE_IN variable to pause for a specific test, not any one that fails. * The documentation on gtestutils is far from stellar :) * Now that the a11y infrastructure is included in-the-box with GTK+, it sounds like a good idea to start putting an a11y-based testing infrastructure in GTK+ itself. For the file chooser's tests, I had to do some manual hacks to simulate, "click this button", "find the dialog", "click the dialog's button"... this is tricky C code that assumes too much knowledge of the internals of the toolkit, and I'd love to write some higher-level stuff instead for such tests. (Feel free to reply about this in a different thread - this could derail *this* thread pretty fast) :) Thoughts? We have a useful battery of tests now, and it only seems that improving the testing infrastructure could lead to people actually wanting to write more test code. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)
On Tue, 2013-02-19 at 18:39 +0100, th-pitsc...@uni.de wrote: > I was putting a GtkNotebook on a main window widget (using glade) and > set the tab position to BOTTOM. This looks alright in glade. > > > However, running the application itself one sees that the tabs are not > drawn correctly (they retain round corners and the highlighting orange > at the _top_ edge of the tab, while it should be at the bottom). see > attach link. Please file a bug about this. If you have time, file it with a minimal test case - a little program and the corresponding .ui file, or a little program with the Glade stuff embedded and using gtk_builder_add_from_string(). Federco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 10:46 AM, Federico Mena Quintero wrote: > Hi, everyone, > > I've been writing some tests for GtkFileChooserButton and putting them > in gtk+/gtk/tests/filechooser.c - this is the old test suite, > resurrected and alive. > > So, I've been learning what gtestutils provides. It is not bad, but it > seems pretty pedestrian on some counts. These are some things I'd like > to change, or at least for someone to point me in the right way of doing > them: > Warning, controversial mail ahead. I've noticed that gtester and gtestutils is a little lackluster. I wanted to see what the GNOME community's thoughts on using an established xUnit framework like Google Test, CPPUnit or boost::test would be. I know, its C++. I get that's not appreciated around here. The only reason why I suggest considering frameworks like these is that they're incredibly powerful, easy to use and I've found that they can be applied to almost any situation, C or C++. Google Test addresses some of the concerns listed below, and does a lot more, like custom test environments, SetUp/TearDown fixtures, matchers (which allow you to do something like EXPECT_THAT (value, MatchesSomething ()), where that would be looking inside lists, variants, whatever). It also ties in really nicely with Google Mock, which allows you to define mock implementations of classes and control on a very fine level how those mock classes behave on a per-test basis. I've used Google Mock alongside in my own GObject projects to great effect[1], and I've been playing around with the idea to use GObject-Introspection to automatically generate them from GInterfaces. (Marketspeak: Google Test has some really strong credentials in this area. It is the test framework of choice for projects like Chromium, XBMC, Xorg and projects at Canonical, such as Unity, Nux and Compiz. Chromium in particular has tens of thousands of unit, integration, system and acceptance tests, mostly all written using Google Test. Self-promotion: Compiz has over 1350 Unit, Integration and Acceptance tests, and works very well with Google Test). Its just some food for thought - I agree with Federico that having a flexible, powerful and easy to use test framework certainly lowers a substantial barrier to entry . > *snip* I think that some of the ideas you've raised here are excellent. To address some of your concerns: 1. Most xUnit frameworks I know of have something like ASSERT_* and EXPECT_*. The former will set the test to failed and return directly. The latter will just set the test to "failed" and continue. Generally speaking, it is acceptable to have multiple ASSERT_ statements because they usually belong in SetUp/TearDown logic. ASSERT_ usually means "this test failed because it could not be run due to a failed precondition in SetUp". Ideally, every test should have only one EXPECT_* statement. The EXPECT_* statement is the essence of the test, and tests should test one thing so that you have pinpoint resolution as to which part of the unit failed. 2. The best way to handle this case is to expose the test binary in the build-directory so that users can run it directly. Sometimes you might have multiple test binaries, but that is fine. Ideally no test should have any dependency on the previous test finishing. If that happens, then you've got a serious problem with your code. 3. This is a good point 4. This is an excellent idea for bootstrapping an acceptance testing framework. Care should always be taken when writing acceptance tests though, in particular: a. They aren't a replacement for unit or integration tests. They run particularly slowly, and are usually more failure prone because they can be impacted by external factors that you might not expect. The best kind of code coverage is code covered at a unit, integration and acceptance level. b. Acceptance testing can also be tricky because they often rely on introspection through, eg, the a11y interface. That can create unwanted coupling between the internals of your system and the test, which means that you'll be constantly adjusting the tests as the code is adjusted. Determine what kind of interface you want to expose for test verification and make the tests rely on that. c. Running on some kind of dummy display server (eg, wayland, xorg with the "dummy" video driver[2]) is always a good idea because it means that you don't have awkward situations where you can't get tests running in continuous integration servers. Tests that aren't run are broken tests. d. Never ever ever ever ever ever ever ever ever rely on sleep()s, timing, or whatever in the tests when verifying conditions. Autopilot in Unity does this and it is a giant fail. Otherwise, great to see these topics are being talked about. [1] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/files/head:/gtk/window-decorator/tests/ [2] Xorg-GTest is good for this. > Federico > > > ___ > gtk-devel-list ma
Re: GUI Testing (was: Some shortcomings in gtestutils)
On Feb 20, 2013, at 6:46 PM, Federico Mena Quintero wrote: > > * Now that the a11y infrastructure is included in-the-box with GTK+, it > sounds like a good idea to start putting an a11y-based testing > infrastructure in GTK+ itself. For the file chooser's tests, I had to > do some manual hacks to simulate, "click this button", "find the > dialog", "click the dialog's button"... this is tricky C code that > assumes too much knowledge of the internals of the toolkit, and I'd love > to write some higher-level stuff instead for such tests. (Feel free to > reply about this in a different thread - this could derail *this* thread > pretty fast) :) There are two ways to go about GUI testing. One is to retrieve the coordinates of a control and inject a mouse or keyboard event at those coordinates, the other is to give every control an id that can be used to send events to. The first is incredibly brittle and the second is AFAIK supported only by wxWidgets. [1] ISTR that there was an implementation of the coordinate-tracking sort for Gtk1, but I've lost track of it. It would be a pretty big change to Gtk to introduce control ids and event injectability. Regards, John Ralls [1] http://wxguitest.sourceforge.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20 Feb 2013, at 21:44, Markus Elfring wrote: > > Why do you prefer to use an enumeration instead of the other general > application > programming interface? > Hi Markus. Until a couple of days ago I'd never even encountered GVariant so forgive me if I've misunderstood the concept - but from what you've written, it seems like you want to be able to map a nullable object to the state of a checkbox for some reason. However, according to the description for GVariant:- "GVariant instances always have a type and a value (which are given at construction time). The type and value of a GVariant instance can never change other than by the GVariant itself being destroyed." So GVariant doesn't seem to be a suitable type for mapping the state of something whose state can change. Could that be why there's so much reluctance to implement what you want? As I said, forgive me if I've misunderstood the concept. Just making an observation. John___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 11:27:03AM +0800, Sam Spilsbury wrote: > On Thu, Feb 21, 2013 at 10:46 AM, Federico Mena Quintero > wrote: > > Hi, everyone, > > > > I've been writing some tests for GtkFileChooserButton and putting them > > in gtk+/gtk/tests/filechooser.c - this is the old test suite, > > resurrected and alive. > > > > So, I've been learning what gtestutils provides. It is not bad, but it > > seems pretty pedestrian on some counts. These are some things I'd like > > to change, or at least for someone to point me in the right way of doing > > them: > > > > Warning, controversial mail ahead. > > I've noticed that gtester and gtestutils is a little lackluster. I > wanted to see what the GNOME community's thoughts on using an > established xUnit framework like Google Test, CPPUnit or boost::test > would be. > > I know, its C++. I get that's not appreciated around here. > > The only reason why I suggest considering frameworks like these is > that they're incredibly powerful, easy to use and I've found that they > can be applied to almost any situation, C or C++. Google Test > addresses some of the concerns listed below, and does a lot more, like > custom test environments, SetUp/TearDown fixtures, matchers (which > allow you to do something like EXPECT_THAT (value, MatchesSomething > ()), where that would be looking inside lists, variants, whatever). It > also ties in really nicely with Google Mock, which allows you to > define mock implementations of classes and control on a very fine > level how those mock classes behave on a per-test basis. I've used > Google Mock alongside in my own GObject projects to great effect[1], > and I've been playing around with the idea to use > GObject-Introspection to automatically generate them from GInterfaces. > > (Marketspeak: Google Test has some really strong credentials in this > area. It is the test framework of choice for projects like Chromium, > XBMC, Xorg and projects at Canonical, such as Unity, Nux and Compiz. > Chromium in particular has tens of thousands of unit, integration, > system and acceptance tests, mostly all written using Google Test. > Self-promotion: Compiz has over 1350 Unit, Integration and Acceptance > tests, and works very well with Google Test). > > Its just some food for thought - I agree with Federico that having a > flexible, powerful and easy to use test framework certainly lowers a > substantial barrier to entry . Having worked with googletest and xorg-gtest [1] for X integration testing, I can say the most annoying bit is to get the whole thing to compile. The C++ ODR prevents us from building gtest and xorg-gtest as library and then compiling against that. and autotools is not happy with having external source files. if you're planning to share a test framework across multiple source repositories, that can be a major pain. [1] http://cgit.freedesktop.org/~whot/xorg-integration-tests/ > > *snip* > > I think that some of the ideas you've raised here are excellent. To > address some of your concerns: > > 1. Most xUnit frameworks I know of have something like ASSERT_* and > EXPECT_*. The former will set the test to failed and return directly. > The latter will just set the test to "failed" and continue. > > Generally speaking, it is acceptable to have multiple ASSERT_ > statements because they usually belong in SetUp/TearDown logic. > ASSERT_ usually means "this test failed because it could not be run > due to a failed precondition in SetUp". Ideally, every test should > have only one EXPECT_* statement. The EXPECT_* statement is the > essence of the test, and tests should test one thing so that you have > pinpoint resolution as to which part of the unit failed. > > 2. The best way to handle this case is to expose the test binary in > the build-directory so that users can run it directly. Sometimes you > might have multiple test binaries, but that is fine. Ideally no test > should have any dependency on the previous test finishing. If that > happens, then you've got a serious problem with your code. fwiw, one of the drawbacks I found with the multiple binary case is that it reduces the chance of running all tests every time. there's a sweet spot somewhere between too many and too few binaries and I suspect it differs for each project. for the googletest case for example separate binaries will give you a separate junit xml output, which make some regression comparisons harder. > 3. This is a good point > > 4. This is an excellent idea for bootstrapping an acceptance testing > framework. Care should always be taken when writing acceptance tests > though, in particular: > > a. They aren't a replacement for unit or integration tests. They run > particularly slowly, and are usually more failure prone because they > can be impacted by external factors that you might not expect. The > best kind of code coverage is code covered at a unit, integration and > acceptance level. > b. Acceptance testing can also be tricky becau
Re: Some shortcomings in gtestutils
On Wed, Feb 20, 2013 at 08:46:34PM -0600, Federico Mena Quintero wrote: > Hi, everyone, > > I've been writing some tests for GtkFileChooserButton and putting them > in gtk+/gtk/tests/filechooser.c - this is the old test suite, > resurrected and alive. > > So, I've been learning what gtestutils provides. It is not bad, but it > seems pretty pedestrian on some counts. These are some things I'd like > to change, or at least for someone to point me in the right way of doing > them: > > * Tests abort as soon as a test fails, since tests ultimately depend on > variations of g_assert(). This is fine in that it makes the "ensure > things are okay" code look the same as "generic sanity check" code. > However, it also means that a test suite aborts as soon as it encounters > the first test that doesn't pass. There is g_test_fail(), but the > documentation pretty much only says, "You can use this function if your > test failed in a recoverable way." I don't know if that means that the > test couldn't find a data file (but can continue anyway), or if it means > "call this if you want the test to fail but want the test suite to > continue running". > > * It's hard to get a debugger up in the middle of "make check". I can't > think of a way to do it other than manually inserting code to sleep in > the middle of the faulty test, and then attaching with a debugger > manually. Maybe having an environment variable or something, so that I > could run > > $ G_PAUSE_ON_FAILED_TESTS=1 make check > > when a test fails, I would get told, "attach to $pid now" or somthing. > Maybe even have a G_NAME_OF_TEST_TO_PAUSE_IN variable to pause for a > specific test, not any one that fails. not sure how well this applies in your case, but what I do in the xorg integration tests is to send a SIGSTOP to the server based on some environment variables. then you can attach gdb, SIGCONT it and debug it. (I don't do this on test failure but on server startup, but the principle should work either way) Cheers, Peter > > * The documentation on gtestutils is far from stellar :) > > * Now that the a11y infrastructure is included in-the-box with GTK+, it > sounds like a good idea to start putting an a11y-based testing > infrastructure in GTK+ itself. For the file chooser's tests, I had to > do some manual hacks to simulate, "click this button", "find the > dialog", "click the dialog's button"... this is tricky C code that > assumes too much knowledge of the internals of the toolkit, and I'd love > to write some higher-level stuff instead for such tests. (Feel free to > reply about this in a different thread - this could derail *this* thread > pretty fast) :) > > Thoughts? We have a useful battery of tests now, and it only seems that > improving the testing infrastructure could lead to people actually > wanting to write more test code. > > Federico > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 1:17 PM, Peter Hutterer wrote: > Having worked with googletest and xorg-gtest [1] for X integration testing, > I can say the most annoying bit is to get the whole thing to compile. The > C++ ODR prevents us from building gtest and xorg-gtest as library and then > compiling against that. and autotools is not happy with having external > source files. if you're planning to share a test framework across multiple > source repositories, that can be a major pain. > > [1] http://cgit.freedesktop.org/~whot/xorg-integration-tests/ I agree, this is the one drawback of google-test. > >> > *snip* >> > > fwiw, one of the drawbacks I found with the multiple binary case is that it > reduces the chance of running all tests every time. there's a sweet spot > somewhere between too many and too few binaries and I suspect it differs for > each project. > A good way to handle that is to have a separate test-runner that runs the make check/test target. That can usually just be a makefile rule or something else (in compiz we use ctest) > for the googletest case for example separate binaries will give you a > separate junit xml output, which make some regression comparisons harder. We ran into this problem as well. I think the solution was two fold: 1. First of all, we wanted to be able to introspect test binaries so that the test runner would be able to show each individual one. [1] is a massive hack, but it works. 2. Second of all, we had to patch google-test to shut up about skipped tests in the junit.xml so that Jenkins didn't think you had like 600,000 tests or something. I can provide this patch upon request, its just somewhere in the midsts of the Canonical Jenkins deployment. [1] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/view/head:/cmake/src/compiz/compiz_discover_gtest_tests.cpp -- Sam Spilsbury ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 02:39:21PM +0800, Sam Spilsbury wrote: > On Thu, Feb 21, 2013 at 1:17 PM, Peter Hutterer > wrote: > > Having worked with googletest and xorg-gtest [1] for X integration testing, > > I can say the most annoying bit is to get the whole thing to compile. The > > C++ ODR prevents us from building gtest and xorg-gtest as library and then > > compiling against that. and autotools is not happy with having external > > source files. if you're planning to share a test framework across multiple > > source repositories, that can be a major pain. > > > > [1] http://cgit.freedesktop.org/~whot/xorg-integration-tests/ > > I agree, this is the one drawback of google-test. > > > > >> > *snip* > >> > > > > fwiw, one of the drawbacks I found with the multiple binary case is that it > > reduces the chance of running all tests every time. there's a sweet spot > > somewhere between too many and too few binaries and I suspect it differs for > > each project. > > > > A good way to handle that is to have a separate test-runner that runs > the make check/test target. That can usually just be a makefile rule > or something else (in compiz we use ctest) yeah, I've hooked it up to make check, but that has other issues too. I should really write a script for that. fwiw, we still have multiple binaries (evdev, synaptics, server, libXi, etc.) But initially I had multiple binaries for the server to test various server features (grab, multihead, touch, etc.). Since the features aren't clear-cut though (where do you put touch grab tests?) I found having a single server binary was better. This is what I meant with there being a sweet spot for each project that needs to be found. > > for the googletest case for example separate binaries will give you a > > separate junit xml output, which make some regression comparisons harder. > > We ran into this problem as well. > > I think the solution was two fold: > > 1. First of all, we wanted to be able to introspect test binaries so > that the test runner would be able to show each individual one. [1] is > a massive hack, but it works. > 2. Second of all, we had to patch google-test to shut up about > skipped tests in the junit.xml so that Jenkins didn't think you had > like 600,000 tests or something. I can provide this patch upon > request, its just somewhere in the midsts of the Canonical Jenkins > deployment. oh, right. that hasn't been a problem for me so far, the jenkins install always runs all tests. the tricky bit for me was tracking which tests are supposed to fail (e.g. on RHEL6 tests for newer features are known-to-fail). so far I'm tracking this largely manually, but the known-to-fail case shouldn't be much of an use-case for an upstream project. Cheers, Peter > > [1] > http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/view/head:/cmake/src/compiz/compiz_discover_gtest_tests.cpp > > -- > Sam Spilsbury ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
