On Mon, 2011-03-07 at 16:08 -0500, Matthias Clasen wrote: > On Mon, Mar 7, 2011 at 1:22 AM, Tristan Van Berkom > <trista...@openismus.com> wrote: > > On Sat, 2011-02-26 at 10:37 -0500, David Zeuthen wrote: > > > > ... do I have to pull out that change while > > GApplication is still unstable ? > > GApplication is not unstable. > > It is true that after all the back-and-forth, nobody has gotten around > to writing a non-dbus backend. >
Ok but regardless of what's there and what's missing, this still does not answer my question. Will use of GtkApplication cause my app to simply fail just because a win32/osx implementation is missing ? or will it silently succeed ? And I think we need to be very clear here about what is supported on all platforms and what is not, being a cross-platform toolkit is probably still GTK+'s leading selling points. There are different levels of "supported" on different platforms, for instance it is very clear that GtkUnixPrint widgets are only available on x11, so you dont compile it for win32 or quartz. If GTK+ lets you compile it for win32 or another platform, it should be safe to call the APIs from that platform, even if it doesn't work. For instance, a query of "content-types" on win32, if not implemented can return no results... if it causes your program to abort() on win32 just because a public cross-platform API is unimplemented... that *is* indeed unstable if you ask me. As I mentioned before, I'm not asking for an implementation on win32 of GtkApplication, I'm just asking for it to succeed, run a mainloop and "do something" as a fallback for a missing implementation. a.) GtkApplication only available as GtkX11Application is acceptable, because people only expect it to work on x11 (the actual stubs should in this case only be created on x11 and the docs should mention that it an x11-only object). b.) GtkApplication as a public and clearly cross-platform API that has a fallback that runs the main loop is acceptable, win32 apps that adopt early will benefit from single instance and other details once the win32 backend for GtkApplication is created. c.) GtkApplication that is public and causes your application to simply fail just because of a missing backend, is just broken (and I think that's what happens now but I dont have a win32 machine to try it on). So where do we stand ? If we are falling into case "c.)" then it's simply a bug (and yes, I would say it's a serious bug, enough to say the api is unstable and likely to cause your app to fail under certain weather conditions) the application should "just work" on other platforms without implementing any of the dbus features. > It shares that fate with many other features, like file monitoring, > content types, etc. where native implementations on other platforms > are sadly missing. Do we really have other instances like this ? I mean, how do file monitoring apis and content type apis fail under win32/osx ? I suspect that we have either... a function that lists content types which simply returns no results... that does not break a program as far as I can see. Or a GInitable object that is created for a file and has a signal to tell you when the monitored file has changed ? Again not such a problem, people are supposed to check the return values of initable objects and deal with the fact that they could not get a GFileMonitor this time. If there are other cases of public apis that cause multi-platform apps to actually break directly, we should fix the bugs as a priority, people expect at least this much from glib/gtk+. Regards, -Tristan _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list