Re: GRegex
On Tue, 24 Oct 2006 16:38:30 -0400 Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > This is broken. It should err at configure time, not run time. The > user shouldn't need to check the output of g_regex_new for failures, > just like any other thing we do with glib. I would argue it should do both. Don't compile against a PCRE that doesn't do UTF-8, but also check the installed library on each startup. That would guard against the system's library being upgraded at some later time, to one that doesn't support UTF-8. -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GRegex
On 10/24/06, Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > On Tue, 2006-10-24 at 16:05 -0400, Marco Barisione wrote: > This is broken. It should err at configure time, not run time. The > user shouldn't need to check the output of g_regex_new for failures, > just like any other thing we do with glib. I have just uploaded a new patch that corrects this and some other problems. I kept the run-time check, it's useful if cross-compiling or if the installed PCRE library is updated. -- Marco Barisione http://www.barisione.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GRegex
On 10/24/06, Marco Barisione <[EMAIL PROTECTED]> wrote: > As discussed some times ago [1] I propose to add a PCRE wrapper to GLib. > Bug #50075 [2] contains a patch that adds it as a separate libgregex. > The documentation of the new API is at [3] (yes, there are some > unresolved problems with gtk-doc). > > Owen Taylor would prefer to have GRegex directly in the main GLib > library: > [...] To give you an idea of the size of libgregex and libpcre, these are the sizes of the stripped .so files on my computer: libgregex with internal PCRE 138 KB libgregex with system PCRE24 KB libpcre with Unicode support 125 KB libpcre without Unicode support 96 KB -- Marco Barisione http://www.barisione.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Mon, 2006-10-23 at 14:39 +0100, Emmanuele Bassi wrote:
> Hi everyone;
...
> * API Overview
> ==
>
> The base cass is GtkApplication - an abstract G_TYPE_OBJECT with a bunch
> of methods to be overridden:
>
> struct _GtkApplicationClass
> {
> GObjectClass parent_class;
> ...
>
> We have a document-based API using these five vfuncs:
>
> ...
> gchar * (*new_document) (GtkApplication *application);
> gboolean (*save_document) (GtkApplication *application,
> const gchar *document_name,
> const gchar *document_uri,
> gboolean save_backup,
> gboolean overwrite,
> GError **error);
> gboolean (*open_document) (GtkApplication *application,
> const gchar *document_uri,
> gboolean read_only,
> GError **error);
> gboolean (*close_document)(GtkApplication *application,
> const gchar *document_name,
> GError **error);
> GSList * (*list_documents)(GtkApplication *application);
> ...
>
> The vfunc signatures should be self-explanatory.
>
> Each document is addressed by a unique id, using a string; newly created
> documents might have a "document-" id string, or a
> "document-" id string; opened documents might use the
> MD5 hash of the document URI. Documents have an unique id because there
> can be multiple views of the same document and we need to keep a list of
> documents as well as windows (and windows for documents) of the
> GtkApplication.
>
> Subclasses of GtkApplication *must* override the new_document,
> save_document and open_document vfuncs; close_document and list_document
> can offer a default implementation (close_document calls save_document
> and if successful will remove the document id from the list of known
> documents, and list_documents returns the list of known document ids).
>
so, who would be calling those vfuncs? Gtkapplication internals? If so,
how? Since below you say the app is responsible for creating the UI, how
does Gtkapplication know Open/Close/Save have been selected?
I would really like to have a more generic GtkApplication object, not
really tied to a window (even though it could perfectly have ways for
binding it to a Window). That way, any app (think GUI daemons, like
power manager, for instance) could use it as a central point of access
to the session management, unique apps, main windows, etc.
--
Rodrigo Moya <[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Mon, 2006-10-23 at 19:14 +0100, Emmanuele Bassi wrote:
> struct _GtkDocumentModelClass
> {
> GTypeInterfaceClass iface;
>
> GtkDocumentHandle *(*document_open) (GtkDocumentModel *model,
>const gchar *uri,
>gboolean read_only,
>GtkDocumentOpenCallback callback,
>gpointer
> callback_data,
>GError **error);
> GtkDocumentHandle *(*document_save) (GtkDocumentModel *model,
>const gchar *uri,
>gboolean save_backup,
>gboolean overwrite,
>GtkDocumentSaveCallback callback
>gpointer
> callback_data,
>GError **error);
>
these should be open_document and save_document, not document_... :-)
>
> Not every application has the same needs; but many of them use the same
> logic, or share the same structure. Bindings for object oriented
> programming languages already offer such a base class, abstracting some
> of the GTK+ functions like gtk_init(), gtk_main() and gtk_main_quit(),
> in order to fit them into an OOP approach.
>
yes, a gtk_application_new() could do all that (gtk_init, gtk_main and,
when destroyed, gtk_main_quit).
> There has been also a definite movement towards a set of abstractions
> for desktop usage: the GtkSession API from Dan Winship, the
> GdkScreensaver API from Rodrigo Moya, the network state abstraction I
> proposed; all of these makes sense when handled by a single application
> class.
>
> Finally, the GtkUniqueApplication class makes little sense if we don't
> provide non-unique application class.
>
rather than GtkApplication/GtkUniqueApplication, I guess it would make
more sense to have a "unique" property on the GtkApplication class.
--
Rodrigo Moya <[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Wed, 2006-10-25 at 16:03 +0200, Rodrigo Moya wrote:
> On Mon, 2006-10-23 at 14:39 +0100, Emmanuele Bassi wrote:
> > Hi everyone;
>
> ...
>
> > * API Overview
> > ==
> >
> > The base cass is GtkApplication - an abstract G_TYPE_OBJECT with a bunch
> > of methods to be overridden:
> >
> > struct _GtkApplicationClass
> > {
> > GObjectClass parent_class;
> > ...
> >
> > We have a document-based API using these five vfuncs:
> >
> > ...
> > gchar * (*new_document) (GtkApplication *application);
> > gboolean (*save_document) (GtkApplication *application,
> > const gchar *document_name,
> > const gchar *document_uri,
> > gboolean save_backup,
> > gboolean overwrite,
> > GError **error);
> > gboolean (*open_document) (GtkApplication *application,
> > const gchar *document_uri,
> > gboolean read_only,
> > GError **error);
> > gboolean (*close_document)(GtkApplication *application,
> > const gchar *document_name,
> > GError **error);
> > GSList * (*list_documents)(GtkApplication *application);
> > ...
> >
> > The vfunc signatures should be self-explanatory.
> >
> > Each document is addressed by a unique id, using a string; newly created
> > documents might have a "document-" id string, or a
> > "document-" id string; opened documents might use the
> > MD5 hash of the document URI. Documents have an unique id because there
> > can be multiple views of the same document and we need to keep a list of
> > documents as well as windows (and windows for documents) of the
> > GtkApplication.
> >
> > Subclasses of GtkApplication *must* override the new_document,
> > save_document and open_document vfuncs; close_document and list_document
> > can offer a default implementation (close_document calls save_document
> > and if successful will remove the document id from the list of known
> > documents, and list_documents returns the list of known document ids).
> >
> so, who would be calling those vfuncs? Gtkapplication internals? If so,
> how? Since below you say the app is responsible for creating the UI, how
> does Gtkapplication know Open/Close/Save have been selected?
>
> I would really like to have a more generic GtkApplication object, not
> really tied to a window (even though it could perfectly have ways for
> binding it to a Window). That way, any app (think GUI daemons, like
> power manager, for instance) could use it as a central point of access
> to the session management, unique apps, main windows, etc.
>
in fact, if we want to make it easier for the user to create windows
with toolbars and menus, why don't we add convenience functions to
GtkWindow and leave GtkApplication as an 'application management class',
to deal with initialization, list of windows, list of open documents,
access to session management and any other desktop operations, etc, etc?
--
Rodrigo Moya <[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
Rodrigo Moya wrote: [...] > rather than GtkApplication/GtkUniqueApplication, I guess it would make > more sense to have a "unique" property on the GtkApplication class. I actually had the very same impression :) > > in fact, if we want to make it easier for the user to create windows > with toolbars and menus, why don't we add convenience functions to > GtkWindow and leave GtkApplication as an 'application management class', > to deal with initialization, list of windows, list of open documents, > access to session management and any other desktop operations, etc, etc? That could be a route to explore - I think its really important to keep GtkWindow really simple in that respect though - it could be a dialog - it could be a popup window, a popup menu - or even a tooltip, So I would suggest that if we bind such logic into GtkWindow - making it some kind of hybrid composite widget - we should definitly do that in a GtkAppWindow subclass (that could be then used by the GtkApplication in question). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests suite
On Mon, 9 Oct 2006, Iago Toral Quiroga wrote: Hi, as part of the build-brigade (http://live.gnome.org/BuildBrigade) I have been working a bit on developing a set of unit tests for Gtk+ using Check (http://check.sourceforge.net/). Gtk+ definietely lacks a unit test frame work, so it's good to try to get the ball rolling on this some. i've recently worked on improving unit test integration in another project, a brief summary of that can be found in my last blog entry: http://blogs.gnome.org/view/timj/2006/10/23/0 # Beast and unit testing I have set up a temporary modified version of Gtk+ here: cvs -d :pserver:[EMAIL PROTECTED]:/var/publiccvs co gtk+ Currently, this modified version includes a small set of unit tests for several widgets that would grow in ammount if the project seems interesting to the Gtk+ community. first i have to say that copying a random Gtk+ CVS version and adding tests to it is not the most conveninent review basis. getting a reviewable diff of your changes took figuring of an exact CVS version (-D "2006/09/17 11:59:00") and significant manual cleanups. i've attached the resulting diff for future reference. second, your code is missing a license, releasing/publishing code should always be accompanied by *some* kind of license information. in our current society, there's little point in publishing something without telling what can legally be done and not done with the published material. I would like to know your opinion about this project (the tests), specially if you think it is interesting enough to be (now or in the future) inside the official GTK+ repository. In case you think it is interesting, I would like to know if you have any recomendations or suggestions about whatever you think might improve it. Any feedback would be very appreciated. ok, running your tests and reading through some of your code, i collected a few comments: i'm not very fond of the introduction of a new library/package dependency for Gtk+ (or GLib) just for writing unit tests. Check in particular has a few quirks that i find particularly undesirable, such as the prefix/postfix magic macros around each test function which also tend to break C syntax parsers, see: http://bugzilla.gnome.org/show_bug.cgi?id=364672 for more details. other oddities involve e.g. its automake/configure.in integration. i'll get into more details about this in another email. the way you're using fail_if(assert_expr,error_string) tends to state too much the obvious, e.g.: + button = GTK_BUTTON (gtk_button_new_with_label (set_label)); + + fail_if (!GTK_IS_BUTTON (button), + "gtk_button_new_with_label fails"); this can really be shortened to: button = gtk_button_new_with_label (label); ASSERT (GTK_IS_BUTTON (button)); other things are arguably not worth checking: + get_label = gtk_button_get_label (button); + + fail_if (strcmp (set_label, get_label) != 0, + "Retrieved label is not the same as the one used at construction: (%s,%s)", + set_label, get_label); i.e. i'd not be surprised if a future or tailored version of Gtk+ returned a translated or maybe space-stripped string here. and then there's a number of tests which are plain wrong (edited for brevity): + GtkWidget *widget = NULL; + widget = gtk_hbox_new (0, FALSE); + /* Test 3 */ + get_text_buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (widget)); + fail_if (get_text_buffer != NULL, + "gtk_text_view_get_buffer does not return NULL when " + "applied to an object that is not a GtkTextView"); the g_return_val_if_fail() statement in gtk_text_view_get_buffer() is NOT part of the API contract, it may even be optimized away in some configurations. the point in having unit tests is to check that the use cases meant to be covered by the code base are working correctly. not that things which weren't accounted for in the design and implementation do not work. (if that was the case, the number of tests we had to write would be endless.) that's simply because the libraries get used for what they CAN do, not what they CANNOT do ;) you should call gtk_init (&argc, &argv); with real argc/argv from main(). using: + int argc = 0; + gtk_init (&argc, NULL); all over the place is not the best idea (maybe this is due to using Check in fork mode, but it's still a bad idea), because this elimintaes the ability to (manually) try out test cases in different modes (--sync, --display, --test-slow, etc...) about using fork mode, there really is no need to fork at all for a test, except when checking tests that are supposed to fail (which is rarely the case), e.g. when you need to assert proper abort()-like behavior of e.g. g_error(). Iago. in general, i think it's great that you started on writing unit tests for Gtk+, however, i'd say that what Gtk+ needs differs significantly from your approach. i'll provide more detailed thoughts on this in a follow up. --- ciaoTJ xutpatch.diff.bz2 Descripti
Re: GTK+ Application class
Hi; On Wed, 2006-10-25 at 16:07 +0200, Rodrigo Moya wrote: > > > Not every application has the same needs; but many of them use the same > > logic, or share the same structure. Bindings for object oriented > > programming languages already offer such a base class, abstracting some > > of the GTK+ functions like gtk_init(), gtk_main() and gtk_main_quit(), > > in order to fit them into an OOP approach. > > > yes, a gtk_application_new() could do all that (gtk_init, gtk_main and, > when destroyed, gtk_main_quit). Maybe we could avoid gtk_init() (but we'd have to pass the args anyway to GtkApplication) and gtk_main_quit() (just unref'ing the application object would do) but gtk_main() would be still needed - maybe masked as gtk_application_run(). > > There has been also a definite movement towards a set of abstractions > > for desktop usage: the GtkSession API from Dan Winship, the > > GdkScreensaver API from Rodrigo Moya, the network state abstraction I > > proposed; all of these makes sense when handled by a single application > > class. > > > > Finally, the GtkUniqueApplication class makes little sense if we don't > > provide non-unique application class. > > > rather than GtkApplication/GtkUniqueApplication, I guess it would make > more sense to have a "unique" property on the GtkApplication class. It's possible, but I'm not sure it makes "more sense". I think that a single instance application is a corner case of application and I like the idea of keeping the two classes separated; inheriting would make the switch trivial: GtkUniqueApplication would do everything a GtkApplication does, plus two methods: gtk_unique_application_is_running (GtkUniqueApplication *application) gtk_unique_application_send (GtkUniqueApplication *application, GdkUniqueCommand command, const gchar *command_data); Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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
Gtk+ unit tests (brainstorming)
Hi all.
as mentioned in another email already, i've recently worked on improving
unit test integration in Beast and summarized this in my last blog entry:
http://blogs.gnome.org/view/timj/2006/10/23/0 # Beast and unit testing
while analysing the need for a testing framework and whether it makes sense
for GLib and Gtk+ to depend on yet another package for the sole purpose of
testing, i made/had the following observations/thoughts:
- Unit tests should run fast - a test taking 1/10th of a second is a slow
unit test, i've mentioned this in my blog entry already.
- the important aspect about a unit test is the testing it does, not the
testing framework matter. as such, a testing framework doesn't need to
be big, here is one that is implemented in a whole 4 lines of C source,
it gets this point across very well: ;)
http://www.jera.com/techinfo/jtns/jtn002.html
- in the common case, test results should be reduced to a single boolean:
"all tests passed" vs. "at least one test failed"
many test frameworks provide means to count and report failing tests
(even automake's standard check:-rule), there's little to no merit to
this functionality though.
having/letting more than one test fail and to continue work in an
unrelated area rapidly leads to confusion about which tests are
supposed to work and which aren't, especially in multi-contributor setups.
figuring whether the right test passed, suddenly requires scanning of
the test logs and remembering the last count of tests that may validly
fail. this defeats the purpose using a single quick make check run to
be confident that one's changes didn't introduce breakage.
as a result, the whole test harness should always either succeed or
be immediately fixed.
- for reasons also mentioned in the afformentioned blog entry it might
be a good idea for Gtk+ as well to split up tests into things that
can quickly be checked, thoroughly be checked but take long, and into
performance/benchmark tests.
these can be executed by make targets check, slowcheck and perf
respectively.
- for tests that check abort()-like behvaior, it can make sense to fork-off
a test program and check whether it fails in the correct place.
allthough this type of checks are the minority, the basic
fork-functionality shouldn't be reimplemented all over again and warrants
a test utility function.
- for time bound tasks it can also make sense to fork a test and after
a certain timeout, abort and fail the test.
- some test suites offer formal setup mechnisms for test "sessions".
i fail to see the necessity for this. main() { } provides useful test
grouping just as well, this idea is applied in an example below.
- multiple tests may need to support the same set of command line arguments
e.g. --test-slow or --test-perf as outlined in the blog entry.
it makes sense to combine this logic in a common test utility function,
usually pretty small.
- homogeneous or consistent test output might be desirable in some contexts.
so far, i've made the experience that for simple make check runs, the most
important things are that it's fast enough for people to run frequently
and that it succeeds.
if somewhat slowly perceived parts are hard to avoid, a progress indicator
can help a lot to overcome the required waiting time. so, here the exact
oputput isn't too important as long as some progress is displayed.
for performance measurements it makes sense to use somewhat canonical
output formats though (ideally machine parsable) and it can simplify the
test implementations if performance results may be intermixed with existing
test outputs (such as progress indicators).
i've mentioned this in my blog entry as well, it boils down to using a
small set of utility funcitons to format machine-detectable performance
test result output.
- GLib based test programs should never produce a "CRITICAL **:" or
"WARNING **:" message and succeed. the reasoning here is that CRITICALs
and WARNINGs are indicators for an invalid program or library state,
anything can follow from this.
since tests are in place to verify correct implementation/operation, an
invalid program state should never be reached. as a consequence, all tests
should upon initialization make CRITICALs and WARNINGs fatal (as if
--g-fatal-warnings was given).
- test programs should be good glib citizens by definineg G_LOG_DOMAIN, so
WARNING, CRITICAL, and ERROR printouts can correctly indicate the failing
component. since multiple test programs usually go into the same directory,
something like DEFS += -DG_LOG_DOMAIN='"$(basename $(@F))"' (for GNU make)
or DEFS += -DG_LOG_DOMAIN='"$@"' (for portable makefiles) needs to be used.
as far as a "testing framework" is needed for GLib/Gtk+, i think it would
be sufficient to have a pair of common testutils.[hc] files that provide:
1- an initialization
Re: GTK+ Application class
Hi Rodrigo; On Wed, 2006-10-25 at 16:03 +0200, Rodrigo Moya wrote: I'll have to update the GtkApplication class vfuncs; I'm afraid that makes more sense to use the wiki for discussing this - cutting and pasting stuff on emails is a lot cruftier. :-) > > Subclasses of GtkApplication *must* override the new_document, > > save_document and open_document vfuncs; close_document and list_document > > can offer a default implementation (close_document calls save_document > > and if successful will remove the document id from the list of known > > documents, and list_documents returns the list of known document ids). > > > so, who would be calling those vfuncs? Gtkapplication internals? The implementers of the actual GtkApplication subclass - that is you and me. :-) Some trivial stuff like "list_documents" or "add_window" can have a default implementation (this is why I used a GObject instead of a GTypeInterface, even though GTypeInterface objects *in C* can have default implementations). Anyway, after the remarks from Tristan, Paolo and you, we can split the document model stuff from GtkApplication into its own interface and just use GtkApplication as a controller object for: * documents * windows * session related stuff (session client) * desktop related stuff (screensaver, network state, ...) We could even *not* subclass GtkApplication and still have a working application - for those not into subclassing stuff in C. :-) > I would really like to have a more generic GtkApplication object, not > really tied to a window (even though it could perfectly have ways for > binding it to a Window). That way, any app (think GUI daemons, like > power manager, for instance) could use it as a central point of access > to the session management, unique apps, main windows, etc. I agree. I'll update the page on the wiki[1] and keep working on this stuff in order to get the structure and the objects more fleshed out. Ciao, Emmanuele. +++ [1] http://live.gnome.org/GTK+/ApplicationClass -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: Gtk+ unit tests (brainstorming)
Hi, When coding dbus I thought I'd try a project with a focus on unit tests. It has (or at least had for a while) exceptionally high test coverage, around 75% of basic blocks executed in make check. The coverage-analyzer has been busted for a couple years though. Here are my thoughts from dbus: - the "make coverage-report" was by far the biggest win I spent time on. It gave percentage basic blocks tested, globally, by module, and by file. Then for each file, it did the gcov-style annotation to show what was not covered. So when coding, you could make coverage report, then see what you had failed to test. Also, if you just wanted to work on improving test coverage, you could use make coverage-report to find areas to work on. the coverage-report target simply depended on make check, so it was only a single command to run all the tests and look at their coverage in a helpful format. - frequently I needed to add extra interfaces or levels of abstraction to be able to test effectively. For example, allowing "dummy" implementations of dependency module to be inserted underneath a module I was testing. dbus is heavily conditionalized on a DBUS_BUILD_TESTS parameter, which allows adding all kinds of test-only code without fear of bloating the production version. One price of this is that the tested lib is slightly different from the production lib. - based on how nautilus does unit tests, I put the tests in the file with the code being tested. The rationale is similar to the rationale for inline documentation. I think it's a good approach, but it does require a distinct "test build" (DBUS_BUILD_TESTS). Another advantage of this is that internal code can be tested, while it may not be possible to fully exercise internal code using the public API. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Wed, 2006-10-25 at 10:50 -0400, Tristan Van Berkom wrote: > Rodrigo Moya wrote: > [...] > > rather than GtkApplication/GtkUniqueApplication, I guess it would make > > more sense to have a "unique" property on the GtkApplication class. > > I actually had the very same impression :) > > > > > in fact, if we want to make it easier for the user to create windows > > with toolbars and menus, why don't we add convenience functions to > > GtkWindow and leave GtkApplication as an 'application management class', > > to deal with initialization, list of windows, list of open documents, > > access to session management and any other desktop operations, etc, etc? > > That could be a route to explore - I think its really important to > keep GtkWindow really simple in that respect though - it could be > a dialog - it could be a popup window, a popup menu - or even a tooltip, > So I would suggest that if we bind such logic into GtkWindow - making > it some kind of hybrid composite widget - we should definitly do > that in a GtkAppWindow subclass (that could be then used by the > GtkApplication in question). > and why not have: gtk_window_new -> as it is now gtk_window_new_dialog (buttons,...) gtk_window_new_main_app(menus, toolbar, etc) ? -- Rodrigo Moya <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Wed, 2006-10-25 at 16:03 +0200, Rodrigo Moya wrote: > so, who would be calling those vfuncs? Gtkapplication internals? If > so, > how? Since below you say the app is responsible for creating the UI, > how > does Gtkapplication know Open/Close/Save have been selected? You can have default handlers (even if you have to connect those handlers yourself) for Open/Close/Save/SaveAs etc that just do everything in terms of the generic vfuncs, without us having to constantly reimplement the same logic. Here are just a few of the those things: - Show the file open dialog, and handle all the possible responses, load the document and handle any errors, warning the user. - Show the file save dialog, setting the modified status of the document, and indicating that in the titlebar or document menu, handling errors such as saving to read-only files or directories. - Warn about saving changes when closing. There's a lot of this stuff. We reimplement it again and again, introducing far too many unnecessary bugs and inconsistencies, and wasting too much time doing it. We don't even have to do everything at once - we can try to abstract the most simple stuff at first. This can be simplified. I know because I've done it in Bakery for C++. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
Hi Rodrigo; On Wed, 2006-10-25 at 18:33 +0200, Rodrigo Moya wrote: > > That could be a route to explore - I think its really important to > > keep GtkWindow really simple in that respect though - it could be > > a dialog - it could be a popup window, a popup menu - or even a tooltip, > > So I would suggest that if we bind such logic into GtkWindow - making > > it some kind of hybrid composite widget - we should definitly do > > that in a GtkAppWindow subclass (that could be then used by the > > GtkApplication in question). > > > and why not have: > > gtk_window_new -> as it is now > gtk_window_new_dialog (buttons,...) > gtk_window_new_main_app(menus, toolbar, etc) > > ? Because we have a clear separation: a GtkDialog is a GtkWindow but not the other way around. GtkWindow is a primitive object which should be specialised in subclasses. I'm not sure that having a GtkApplicationWindow is the road to go - it would be a fairly specialised subclass of GtkWindow, and should bind together a bunch of stuff (toolbars, menus, status bar, session state) that might be too generic to effectively be usable by projects. Anyway, a GtkApplicationWindow would be better than shoving stuff directly inside the GtkWindow class. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: GTK+ Application class
Rodrigo Moya wrote: [...] >>That could be a route to explore - I think its really important to >>keep GtkWindow really simple in that respect though - it could be >>a dialog - it could be a popup window, a popup menu - or even a tooltip, >>So I would suggest that if we bind such logic into GtkWindow - making >>it some kind of hybrid composite widget - we should definitly do >>that in a GtkAppWindow subclass (that could be then used by the >>GtkApplication in question). >> > > and why not have: > > gtk_window_new -> as it is now > gtk_window_new_dialog (buttons,...) > gtk_window_new_main_app(menus, toolbar, etc) > > ? Simple - dialogs already pull in alot of irrelevant crap into the gtkwindow as a composite widget (response id management, embedded mainloop running etc, logic that is particular of a dialog). A tooltip or a context menu is a GtkWindow - a tooltip is not a dialog and a tooltip is not a "main_app" either, I'm convinced that adding such a convenience wrapper to transform a GtkWindow as is into a composite widget will undoubtedly pull in more "main_app" related logic, accessories, more convinience - basicly alot of cruft that dont need to be associated with a base class that is currently strictly/simply a toplevel widget in gtk+ (maybe not that strictly, but should be IMO), and is way way complex enough as it is. That is not to mention the extra headache and hackery/trickery I would have to play to handle the GtkWindow genericly in Glade, consider that twisted "items" property on the combobox that when libglade finds an item - it will create the liststore for the combobox as if it were created with _new_text()... I just think we'll have a much more powerfull/simple toolkit all around if stick to simple building blocks that make sence. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
Emmanuele Bassi wrote: [snip] >We have a document-based API using these five vfuncs: > >... > gchar * (*new_document) (GtkApplication *application); > gboolean (*save_document) (GtkApplication *application, > const gchar *document_name, > const gchar *document_uri, > gboolean save_backup, > gboolean overwrite, > GError **error); > gboolean (*open_document) (GtkApplication *application, > const gchar *document_uri, > gboolean read_only, > GError **error); > gboolean (*close_document)(GtkApplication *application, > const gchar *document_name, > GError **error); > > What are these going to do and who is going to call them? [snip] >Each GtkApplication should declare which MIME types it supports: > > void (*set_mime_types)(GtkApplication *application, > const gchar * const mime_types[], > gint n_mime_types); > GSList *(*get_mime_types)(GtkApplication *application); > > What's the purpose of this? [snip] > void (*add_window)(GtkApplication *application, > const gchar *document_name, > GtkWindow*window); > void (*remove_window) (GtkApplication *application, > const gchar *document_name, > GtkWindow*window); > > What does it mean to "add window"? And is this one-window-one-document setup? [snip] >I'd like to hear from developers using an "application" abstraction in >their code (like Gedit, Evince and Epiphany) what they think about this >API and what they think an application API should provide for their >needs. For instance, this API is designed for document-based >applications; > All in all, it's really not clear what this api is doing. The document stuff looks like it's a desktop file taken to the next level, but what for? And a minor thing: there should be something like try-quit and really-quit methods; the latter must always be called when application quits, and it should not be delegated to finalize(). Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
On Wed, 2006-10-25 at 17:52 +0200, Tim Janik wrote: > while analysing the need for a testing framework and whether it makes sense > for GLib and Gtk+ to depend on yet another package for the sole purpose of > testing, i made/had the following observations/thoughts: Wooo! Thanks for working on this, Tim; it would be *fantastic* to unify all the disparate tests that we have right now, as well as write new ones. > - for reasons also mentioned in the afformentioned blog entry it might >be a good idea for Gtk+ as well to split up tests into things that >can quickly be checked, thoroughly be checked but take long, and into >performance/benchmark tests. >these can be executed by make targets check, slowcheck and perf >respectively. This is a good idea. For testing the file chooser, it helped a lot to write some "black box tests" which are essentially smoke tests. They just test the very basic functionality of the chooser, without going into the whole test suite. The black box tests helped me fix a bug with many ramifications quickly, since at all times I could ensure that none of the basic functionality was broken. Performance tests should definitely be separate. > - for time bound tasks it can also make sense to fork a test and after >a certain timeout, abort and fail the test. Yes. Hans Petter uses this approach for hiw Flow testing, and it's very cool. > - homogeneous or consistent test output might be desirable in some contexts. >so far, i've made the experience that for simple make check runs, the most >important things are that it's fast enough for people to run frequently >and that it succeeds. One thing about this... it would be good to keep megawidgets in separate tests, but then to have "make check" run all the tests for all megawidgets. That is, I'd like a single "test-all-the-stuff-in-the-treeview" and a single "test-all-the-stuff-in-the-file-chooser": when coding in one, I normally don't care about the other one. So if all the test-* programs spit the same output, we can collect it easily from "make check". Cairo has a very nice testing framework. We can surely steal ideas from it. > - GLib based test programs should never produce a "CRITICAL **:" or >"WARNING **:" message and succeed. Definitely. I have some simple code in autotestfilechooser.c to catch this and fail the tests if we get warnings/criticals. > 5- simple helper macros to indicate test start/progress/assertions/end. > (we've at least found these useful to have in Beast.) For the file chooser tests, I just return a boolean from the test functions, which obviously indicates if the test passed or not. What sort of macros are you envisioning? > - for a specific widget type, test input/output conditions of all API >functions (only for valid use cases though) > - similarly, test all input/output conditions of the Gdk API > - try setting & getting all widget properties on all widgets over the full >value ranges (sparsely covered by means of random numbers for instance) > - try setting & getting all container child properties analogously I believe the OSDL tests do this already. We should steal that code; there's a *lot* of properties to be tested! > - check layout algorithms by layouting a child widget that does nothing but >checking the coordinates it's layed out at. Oh, nice idea. This would be *really* nice even for non-widget stuff, such as all the tricky layout going on in GtkTreeView and its cell renderers. > - generically query all key bindings of stock Gtk+ widgets, and activate them, >checking that no warnings/criticals are generated. Nice. > - for all widget types, create and destroy them in a loop to: >a) measure basic object setup performance >b) catch obvious leaks >(these would be slowcheck/perf tests) Yeah. GtkWidgetProfiler (in gtk+/perf) will help with this. Manu Cornet has improved it a lot for his theme engine torturer, so we should use *that* version :) > as always, feedback is appreciated, especially objections/concerns > regarding the ideas outlined ;) Again, thanks for working on this. It will be reasurring to have a good way to plug in new tests as we add new code to gtk+. After the infrastructure in autotestfilechooser was done, it was quite fun to add new tests; before that, it was extremely cumbersome to start with a blank sheet of paper every time I wanted to test something. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
Hi Yevgen; On Wed, 2006-10-25 at 12:24 -0500, Yevgen Muntyan wrote: > Emmanuele Bassi wrote: > > >... > > gchar * (*new_document) (GtkApplication *application); > > gboolean (*save_document) (GtkApplication *application, > > const gchar *document_name, > > const gchar *document_uri, > > gboolean save_backup, > > gboolean overwrite, > > GError **error); > > gboolean (*open_document) (GtkApplication *application, > > const gchar *document_uri, > > gboolean read_only, > > GError **error); > > gboolean (*close_document)(GtkApplication *application, > > const gchar *document_name, > > GError **error); > > > > > What are these going to do and who is going to call them? Those vfuncs have been changed to be asynchronous, and moved to the GtkDocumentModel interface. In any case, vfuncs are supposed to be implemented by the sub-classes of GtkApplication - which should be an abstract type. You can then use the GtkApplication API (which I did not include in the email for sake of brevity) inside your application's code. > [snip] > > >Each GtkApplication should declare which MIME types it supports: > > > > void (*set_mime_types)(GtkApplication *application, > > const gchar * const mime_types[], > > gint n_mime_types); > > GSList *(*get_mime_types)(GtkApplication *application); > > > > > What's the purpose of this? These vfuncs have been moved too to the GtkDocumentModel interface, inside a more complex GtkDocumentInfo boxed type. The rationale between setting and getting the document's MIME type is to advertise which documents can be read/written by the application. It's a "declaration of intent", if you want. Let's assume that you have a GtkWindow with a 'Open...' menu item bound to a yourapp_file_open_cb callback; inside the callback you'll create a FileChooserDialog widget and set the GtkFileFilter on the MIME types - by getting them from the GtkApplication (or the GtkDocumentModel provided by the application and bound to the window): gchar *types; gsize types_len, i; types = gtk_application_get_mime_types (application, &types_len); for (i = 0; i < len; i++) gtk_file_filter_add_mime (filter, types[i]); If you application supports plugins for input/output operations, which allow you to read or write new MIME types, you'll have to add the MIME types to the application and keep them there. Probably, though, the alternative design (GdkMimeEntry, working like GdkTargetEntry) with an integer id and a flag (_READ/_WRITE/_BOTH) is better and more flexible. > [snip] > > > void (*add_window)(GtkApplication *application, > > const gchar *document_name, > > GtkWindow*window); > > void (*remove_window) (GtkApplication *application, > > const gchar *document_name, > > GtkWindow*window); > > > > > What does it mean to "add window"? And is this one-window-one-document > setup? No; "add window" means adding a GtkWindow to the list of windows belonging to the application; a window is bound to a document (hence the document id) so that multiple windows can show the same document. > [snip] > > >I'd like to hear from developers using an "application" abstraction in > >their code (like Gedit, Evince and Epiphany) what they think about this > >API and what they think an application API should provide for their > >needs. For instance, this API is designed for document-based > >applications; > > > All in all, it's really not clear what this api is doing. The document > stuff looks like it's a desktop file taken to the next level, but what for? Where did you get the "desktop file" part from? :-) The GtkApplication is a controller object: it controls the lifetime of documents and windows, and binds them in a ::[, *] relation. It's a bit of high-level object orientated design for document-oriented applications - even though you don't really need real documents to implement a GtkDocumentModel interface, for instance. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
On Wed, 25 Oct 2006 12:40:27 -0500, Federico Mena Quintero wrote: > Cairo has a very nice testing framework. We can surely steal ideas from > it. I don't know that cairo's "make check" stuff has much worth stealing directly. But I will share some experiences at least. There are some things I really don't like in cairo's "make check" suite right now: 1. We are exporting a (very few, very tiny) test-specific functions in the library just so the test suite can get at it. These are explicitly not "part of" the API, but they do exist. They're mostly on the order of flipping an internal bit to change the behavior to exercise some specific piece of the library. But this approach really doesn't scale. It would probably be better to do this kind of thing in a "test build" as Havoc recently mentioned, (cairo currently doesn't have such a build). 2. The tests take forever to link. Each test right now is a separate program. I chose this originally so that I could easily execute individual tests, (something I still do regularly and still require). The problem is that with any change to the library, "make check" goes through the horrifically slow process of using libtool to re-link the hundred or so programs. One idea that's been floated to fix this is something like a single test program that links with the library, and then dlopens each test module (or something like this). Nothing like that has been implemented yet. We do have log files and HTML output, both of which are very useful, but the format of each is very ad-hoc and nothing that I would recommend anybody copying. That stuff is also very strongly oriented toward tests which can be verified by "visual diff" of two images---this works well for cairo, of course, but wouldn't generalize well. We also did some work on hooking gcov up to our makefiles and getting lovely HTML reports of how much coverage their is in the test suite. As Havoc points out, this is really important, (but sadly, we haven't yet made a good effort at using this data and writing directed tests to improve the coverage). I'm not even 100% sure the gcov stuff in the Makefiles works right now, but it might still be useful for someone looking to how to start that kind of thing, (though the gcov documentation might be even better). > > - for all widget types, create and destroy them in a loop to: > >a) measure basic object setup performance > >b) catch obvious leaks > >(these would be slowcheck/perf tests) > > Yeah. GtkWidgetProfiler (in gtk+/perf) will help with this. Manu > Cornet has improved it a lot for his theme engine torturer, so we should > use *that* version :) Something that is worth stealing is some of the work I've been doing in "make perf" in cairo. I've been putting a lot of effort into getting the most reliable numbers out of running performance tests, (and doing it is quickly as possible yet). I started with stuff that was in Manu's torturer with revamping from Benjamin Otte and I've further improved it from there. Some of the useful stuff is things such as using CPU performance counters for measuring "time", (which of course I didn't write, but just got from liboil---thanks David!), and then some basic statistical analysis---such as reporting the average and standard deviation over many short runs timed individually, rather than just timing many runs as a whole, (which gives the same information as the average, but without any indication of how stable the results are from one to the next). The statistical stuff could still be improved, (as I described in a recent post to performance-list), but I think it is a reasonable starting point. Oh, and my code also takes care to do things like ensuring that the X server has actually finished drawing what you asked it to, (I think GtkWidgetProfiler does that as well---but perhaps with a different approach). My stuff uses a single-pixel XGetImage just before starting or stopping the timer. > > as always, feedback is appreciated, especially objections/concerns > > regarding the ideas outlined ;) Excellent stuff. Testing is really important and often neglected. Never forget the truth that Keith Packard likes to share often: Untested code == Broken code -Carl pgpCKu4i5Axnp.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
Emmanuele Bassi wrote: >Hi Yevgen; > >On Wed, 2006-10-25 at 12:24 -0500, Yevgen Muntyan wrote: > > >>Emmanuele Bassi wrote: >> >> >> >>>... >>> gchar * (*new_document) (GtkApplication *application); >>> gboolean (*save_document) (GtkApplication *application, >>> const gchar *document_name, >>> const gchar *document_uri, >>> gboolean save_backup, >>> gboolean overwrite, >>> GError **error); >>> gboolean (*open_document) (GtkApplication *application, >>> const gchar *document_uri, >>> gboolean read_only, >>> GError **error); >>> gboolean (*close_document)(GtkApplication *application, >>> const gchar *document_name, >>> GError **error); >>> >>> >>> >>> >>What are these going to do and who is going to call them? >> >> > >Those vfuncs have been changed to be asynchronous, and moved to the >GtkDocumentModel interface. In any case, vfuncs are supposed to be >implemented by the sub-classes of GtkApplication - which should be an >abstract type. You can then use the GtkApplication API (which I did not >include in the email for sake of brevity) inside your application's >code. > > See below. > > >>[snip] >> >> >> >>>Each GtkApplication should declare which MIME types it supports: >>> >>> void (*set_mime_types)(GtkApplication *application, >>> const gchar * const mime_types[], >>> gint n_mime_types); >>> GSList *(*get_mime_types)(GtkApplication *application); >>> >>> >>> >>> >>What's the purpose of this? >> >> > >These vfuncs have been moved too to the GtkDocumentModel interface, >inside a more complex GtkDocumentInfo boxed type. The rationale between >setting and getting the document's MIME type is to advertise > But it can't "advertise" it to anyone but itself. Maximum useful thing can be here is if gtk uses mime types for something, but it's not going to. > which >documents can be read/written by the application. It's a "declaration >of intent", if you want. > >Let's assume that you have a GtkWindow with a 'Open...' menu item bound >to a yourapp_file_open_cb callback; inside the callback you'll create a >FileChooserDialog widget and set the GtkFileFilter on the MIME types - >by getting them from the GtkApplication (or the GtkDocumentModel >provided by the application and bound to the window): > > gchar *types; > gsize types_len, i; > > types = gtk_application_get_mime_types (application, &types_len); > for (i = 0; i < len; i++) >gtk_file_filter_add_mime (filter, types[i]); > > If *I* create that dialog, then I don't need GtkApplication api. But see below anyway. >If you application supports plugins for input/output operations, which >allow you to read or write new MIME types, you'll have to add the MIME >types to the application and keep them there. > >Probably, though, the alternative design (GdkMimeEntry, working like >GdkTargetEntry) with an integer id and a flag (_READ/_WRITE/_BOTH) is >better and more flexible. > > This is not going to work on windows; then, even on linux it's often impossible to use mime only - e.g. missing mime types, like "*.g,*.gd,*.gi" files. > > >>[snip] >> >> >> >>> void (*add_window)(GtkApplication *application, >>> const gchar *document_name, >>> GtkWindow*window); >>> void (*remove_window) (GtkApplication *application, >>> const gchar *document_name, >>> GtkWindow*window); >>> >>> >>> >>> >>What does it mean to "add window"? And is this one-window-one-document >>setup? >> >> > >No; "add window" means adding a GtkWindow to the list of windows >belonging to the application; a window is bound to a document (hence the >document id) so that multiple windows can show the same document. > > So one window may contain no more than one document? And, what does this api buy if it still has no idea about documents? Keeping a GSList of documents is not very useful, since you might need more stuff. Then, what about moving documents between windows? I mean, it's not bad that application object is going to be aware of documents; but it's useless if there's not enough intelligence inside the application object. The only good thing I can see here is som
Re: GRegex
Murray Cumming wrote:
>On Tue, 2006-10-24 at 22:05 +0200, Marco Barisione wrote:
>
>
>>Il giorno mar, 24/10/2006 alle 13.17 -0400, Dominic Lachowicz ha
>>scritto:
>>
>>
>>>1) Please don't name variables 'string', as there may be a conflict
>>>with C++'s std::string
>>>
>>>
>>I think they were called "string" in the original version of GRegex
>>written by Scott Wimer in 1999. PCRE calls the string "subject".
>>
>>However it's not a problem with C++, this program is valid:
>>#include
>>#include
>>
>>using namespace std;
>>
>>int main ()
>>{
>> string string = "hello";
>> cout << string << endl;
>>}
>>
>>
>
>It's not necessary to challenge every compiler and every build
>environment with that. A rename is easy.
>
>
There are already stdin, stdout, and stderr forbidden thanks
to nice C macros. Are you saying that now we must not use a nice
word "string" because there may be a broken C++ compiler?
Which C++ compiler will break on "void func (const char *string);" ?
>>>2) I noticed that there are g_regex_ref/unref() methods. Why did you
>>>choose to do this, rather than subclass GObject? You would also then
>>>have easy GObject-style accessors for the regex's "pattern" and
>>>"match_options".
>>>
>>>
>>The original plan was to include directly GRegex in GLib, so it cannot
>>depend on GObject. This could be changed if we decide to include GRegex
>>in a separate library.
>>
>>However is really necessary to have a real object?
>>
>>I added _ref and _unref because the only two programs that are currently
>>using my modified version of EggRegex are GtkSourceView and MooEdit.Both
>>programs need reference counting for regular expressions.
>>
>>
>[snip]
>
>Do they need to reference count plain strings too?
>
>
Of course we do, we also reference count plain ints and chars.
Regards,
Yevgen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What about official GTK+ installer for win32?
On Wed, 25 Oct 2006, Tor Lillqvist wrote: > Tomasz Jankowski writes: > > I want to make installer for my program and I'm not sure if adding copy of > > GTK+ libraries to it will be a good idea. > > Yes, it is. > > I think experience has shown that it is futile to try to use a > single common GTK+ installation on Windows for all applications. > One of the reasons for this is that, despite the best efforts of > maintainers, the fact is that diferent versions of GLib, Pango > and GTK+ for Windows can and do differ in details in how various > functionality is implemented... I agree with Tor on this (chiming in as author/maintainer of a GTK-based program that has a Windows version). Sometimes I am _almost_ inclined to see this as a plus. If you distribute the GTK runtime with your program, you know exactly what's available in terms of API. If you're distributing a GTK program for Linux -- depending on a common, shared set of GTK libraries -- you have to program defensively, trying to ensure that your application will work correctly with the lowest common denominator of (acceptable) GTK installations. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What about official GTK+ installer for win32?
On Tue, Oct 24, 2006 at 10:41:09PM +0200, Tomasz Jankowski wrote: > > [...] > Moreover, many applications, which use GTK+ and, which was ported on win32 > provides their own copy of GTK+ (Gaim, Workrave). > > I think, that it will be very good idea to create GTK+'s official installer > for Windows (two versions: runtime and for developers). Such installer can > be base on some open installer like http://sourceforge.net/projects/nsis/ . > I can't make it because I don't know NSIS (I just started learning it), but > it will be grate if someone will handle it. > > What do you think? I has read also the mail from Tor Lillqvist. My experience on Windows are small. I hope that a stable GTK+ for Win32 make it possible to maintain an official installer for Windows. Enhance the GTK+ support for Visual Studio is also an importing point for me. pkg-config is fine on Linux/Unix but not practical to work with VS. On Linux/Windows I use MPC. There is a small articel: http://napali.ch/svn/doc/trunk/MPC_GTKmm_Demo/index.html Sorry this is not translated to english in the moment. An official GTK+ installer is a nice idea. But it should contain the whole GTK+ family with glade, libglade, libglademm and GTKmm. To maintain such a project it need automated builds and testing. Tor Lillqvist has written about the problems with differend version of GTK+ on Win32. Could be the installation to differend directories and a program loader a solution? The program loader set the enviroment for the GTK+ program an start it. Regards, Urs ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
On 10/25/06, Tim Janik <[EMAIL PROTECTED]> wrote: > - GLib based test programs should never produce a "CRITICAL **:" or >"WARNING **:" message and succeed. It would be good not to make it impossible to test WARNINGs and CRITICALs. After all, error cases are often the least tested part of an application, so it's important to make sure the base library detects and handles the error cases correctly. -- Michael Urman ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
Michael Urman wrote: > On 10/25/06, Tim Janik <[EMAIL PROTECTED]> wrote: >> - GLib based test programs should never produce a "CRITICAL **:" or >>"WARNING **:" message and succeed. > > It would be good not to make it impossible to test WARNINGs and > CRITICALs. After all, error cases are often the least tested part of > an application, so it's important to make sure the base library > detects and handles the error cases correctly. > Testing those is like testing segfault handling, i.e. just nuts. The behavior is undefined once they print. (Well, for critical anyway. g_warning seems to be less consistently used) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What about official GTK+ installer for win32?
On 10/25/06, Urs Stotz <[EMAIL PROTECTED]> wrote: On Tue, Oct 24, 2006 at 10:41:09PM +0200, Tomasz Jankowski wrote:>> [...] To maintain such a project it need automated builds and testing.Tor Lillqvist has written about the problems with differend version ofGTK+ on Win32. Could be the installation to differend directories anda program loader a solution? The program loader set the enviroment for the GTK+ program an start it.Given the current prevalence of GTK-based apps on Windows, it seems reasonable to just bundle the binaries with the application. However, as the number of GTK-based packages grows, the inherent inefficiency of monolithic installations will take its toll. Modular systems are simply easier to maintain. I don't want to have to release a new installer every time a bug-fix release of some dependency is released. The user should have the freedom to easily update everything at will. I have trouble accepting the argument that stuff on Windows changes too fast for apps to adapt. It's true that software originally developed for unix-like systems will have some growing pains when moving to Windows, but these should fade with time. Also, with modern package management systems on Linux, I rarely feel constrained to depend on a earlier version of a package. The dependency system will handle it for me. I feel that a sophisticated package management system for Windows is a must for open-source to become mainstream on Windows. Of course, the construction and maintenance of such a system would be a monumental task and far beyond the scope of GTK+. Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
