Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Tristan Van Berkom <tristanvb openismus com>]

On Mon, 2011-03-07 at 16:08 -0500, Matthias Clasen wrote:
> On Mon, Mar 7, 2011 at 1:22 AM, Tristan Van Berkom
> <tristanvb 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