Re: Announce: gio merged

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-28 at 17:15 -0600, Yevgen Muntyan wrote: 
> Alexander Larsson wrote:
> > On Tue, 2007-11-27 at 10:11 -0600, Yevgen Muntyan wrote:
> >   
> >> Hi there,
> >>
> >> Does GAppInfo make sense on Windows and Mac? It doesn't
> >> build on win32, and it's not quite clear whether the fix is
> >> to provide stubs or to remove the code completely.
> >> What is it for, are normal applications going to use it? Perhaps
> >> it's an X-specific (that is, specific to platforms which use freedesktop.org
> >> specs) functionality needed by Nautilus and friends,
> >> while on win32 and mac all that's needed is some
> >> g_open_file_somehow()? Perhaps applications do need
> >> some information about "what application handles this
> >> file type or this file", but then probably some special API
> >> should be provided exactly for that, while a xdg desktop
> >> wrapper should be left for X, as X-specific API.
> >>
> >>     
> >
> > I haven't built of Win32 in a while, so I can't say anything about the
> > current state. However, GAppInfo is clearly not X-specific in any way,
> > as its an abstract interface. There is even an Win32 implementation
> > gwin32appinfo.c (that at least used to work last time I tried it).
> >   
> 
> Well, here are the functions from the header:
> 
> This is not exactly unix-specific, but is indeed very unixish.
> 
> const char *g_app_info_get_id                       
> (GAppInfo             *appinfo);
> const char *g_app_info_get_name                     
> (GAppInfo             *appinfo);
> const char *g_app_info_get_description              
> (GAppInfo             *appinfo);
> 
> Desktop files here, and stubs on win32.

Installed applications having a name is hardly unixish? What operating
system doesn't have that?

Also, Why do you say they are stubs? 
The id returns the id of the registered app in the win32 registry. 
The name comes from AssocQueryStringW w/ ASSOCSTR_FRIENDLYAPPNAME. 

It is true that win32 has no description for the application, and a
desktop file has, so I added that to the interface. However, I don't
think its a huge deal, not all desktop files have descriptions either.

> const char *g_app_info_get_executable               
> (GAppInfo             *appinfo);
> GIcon *     g_app_info_get_icon                     
> (GAppInfo             *appinfo);
> 
> Desktop file too.

In win32 this is AssocQueryStringW ASSOCSTR_EXECUTABLE

> gboolean    g_app_info_supports_uris                
> (GAppInfo             *appinfo);
> 
> This one, isn't it from desktop file, when you have "foobar %u" line?

It is how you implement it for desktop files yes. I don't understand why
being possible to implement on a desktop file makes it somehow not an
interesting API? (Even if we don't have this info on win32.)

> gboolean    g_app_info_should_show                  
> (GAppInfo             *appinfo,
>                              const char           *desktop_env);
> 
> This one - desktop file, show in the menus or not, right?

Thats the source of info on desktop files, yes. In Win32 we look for
NoOpenWith in the ASSOCKEY_APP key from AssocQueryKeyW.

> gboolean    g_app_info_set_as_default_for_type      
> (GAppInfo             *appinfo,
>                              const char           *content_type,
>                              GError              **error);
> GAppInfo *g_app_info_get_default_for_type        (const char  *content_type,
>                           gboolean     must_support_uris);
> 
> freedesktop.org thing. I guess Internet Explorer will tell about its
> ideas of how to handle different content types, but most interesting
> ones are in f.d.o. own database, will glib have its own mime type
> database on windows? (And on mac)

freedeskop.org is not the only system in the world that can map from
types to applications. Win32 handles this just fine, and gio uses this
just fine.

Also, the content type is an opaque string representing a "file type".
On unix its a mimetype, yes, but on win32 its the native type string as
stored in the registry (which is typically something like ".doc",
although there are also some generic types).

Did you look at the gwin32appinfo.c code?

> Then, GAppLaunchContext is X-specific - display and startup notification.

GAppLauchContext is the connection between the display independent part
of app info and the code that ties into the display system. This
distinction is more obvious in X, since it has a more obvious split
between ui an non ui code. The calls in GAppLaunchContext right now are
obviously needed for X, However, it may well be that e.g. win32 would
want to extend GAppLauncher with some other calls so that it can handle
e.g. launching the new app on the same screen as the app it was launched
from.

> All in all, it *looks* like a glib wrapper around xdg desktop
> files mechanics, which is X-specific. It surely can all be implemented
> on all platforms (partly with stubs), but is it needed?
> Win32 is different (and dumber); Mac has yet a different set of notions
> about applications, starting applications, and opening files (especially
> this one, how it chooses applications for files is total mystery). Why
> have rich f.d.o. API on platforms where it doesn't make sense? After
> all, it's glib, not *gnome*-vfs. This stuff could do well in Gtk maybe.
> Or maybe I am wrong, don't know.

GAppInfo is an abstraction for registered application handlers for file
types. On unix it is backed by freedesktop.org specs, on win32 the
implementation uses the registry. I don't know why you keep calling it X
specific, as the concepts are clearly portable (especially since a Win32
native version is included). Yes, a few (very few) of the calls might be
more usable on xdg backed system than on others, but that is not really
a problem.

The fact that the each OS has different ways to handle these things (as
you list above) is why it is useful to have a common abstraction to let
you handle them. That way any app can have a way to open a file with the
os-registered default application without having to have os-specific
code.

The APIs are in gio because it goes very closely with the content type
abstraction (which is the native OS definition of file types). Both the
APIs and code for these go together by necessity, and the content type
clearly needs to be in gio since we e.g. return type for files.