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: GLib and Gtk+ branched for 2.15.0
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? Don't remember seeing anything on this list, but that might be just me and my million mailing lists... -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ 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
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: 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: GLib and Gtk+ branched for 2.15.0
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)? ___ 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: GLib and Gtk+ branched for 2.15.0
Am Montag, den 19.11.2007, 11:18 +0100 schrieb Tim Janik: > Hay all. > > upstream GLib and Gtk+ have been branched now. That's cool. So I'd like to merge my extended layout work[1] now - unless someone says "STOP, want to review first". Ciao, Mathias [1] As found in the extended-layout branch and Bug #101968. -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ 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, 2007-11-19 at 16:23 +0100, Tim Janik wrote: > >> 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. yep: I've just updated the wiki page[1] and will send the reminder on gtk-devel-list and the announces list later today. current meeting points: * gio/gvfs * gsettings * extended-layout hints ciao, Emmanuele +++ [1] http://live.gnome.org/GTK+/Meetings -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
Tim Janik schrieb: > 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. > I was thinking the same and actually started from make too. My configure checks fro Xvfb. Although I never thought about the alternatives you mention - good idea! I've been using code because its a bit easier to check for the free display and also cleanup. And my code reuses the Xvfb instance, therefore the separate server and display code. For the future I was planning to run with different themes and/or different locales (later is good for docs). > > 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). > >> Stefan > > --- > ciaoTJ Stefan ___ 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
