Re: gio on win32 (was Re: Announce: gio merged)

[Hans Breuer]

On 04.12.2007 09:30, Alexander Larsson wrote:
> On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
> 
[...]
>> I've started something of this, but not commited yet. (I'm getting too old
>> for all these ifdefs ;)) See attahed patch.
> 
> Looks good to me.
> 
>> Again I alread started a win32 specific implementation, not commited yet
>> but attached for review.
> 
> Looks good. Does it also work for the root dir, or does
> g_path_get_dirname() fail in that case?
> 
Still need to check the root dir case, but it should work given something
like "c:\", the "c:" has the special meaning of the current directory on
the give drive which probably won't work with the API used.

>> At the moment I'm concentrating on getting gio to work at all. At some
>> points there still is working implmentation missing. My current unresolved
>> externals (i.e. some of the stuff that compiles still requires functions
>> not compiled) :
>>
The list of unresolved is now empty meaning gio compiles an links with msvc6.
> 
> All this should be possible to just ifdef out.
> The unix mount stuff is just to set the G_FILE_ATTRIBUTE_FS_READONLY
> attribute, which is not that important and done completely different on
> windows.
> 
> The localtime_r stuff is part of the implementation of the
> freedesktop.org trash spec in g_local_file_trash(). We should have a
> completely different implementation on windows. Just stub it for now.
> 
I've just commited the following:

2007-12-08  Hans Breuer  <[EMAIL PROTECTED]>

[gio compiles and links on win32, not sure how much already works]
* glocaldirectorymonitor.c : ifdefed out inotify emulation for win32
* glocalfile.c : use HAVE_UNISTD_H; implement file system size info
base on win32 API; prefer g_lstat() over lstat(); instead of
localtime_r() use an all GLib implementation on win32;
get_mount_info() still needs a win32 specifc implementation
* glocalfileinfo.c : use HAVE_*_H; start of implementation of
win32_get_file_user_info to get owner/group info without uid/gid
* glocalfileinputstream.c : include  on win32
* glocalfileoutputstream.c : include  on win32 and some S_IS*
definition, use g_win32_ftruncate() for G_OS_WIN32
* gwin32appinfo.c : optionalize a bunch on #ifdef AssocQueryString
it is available with mingw/w32api but a mess with the M$ Platform SDKs
see: 
http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00014.html
* makefile.msc : updated

>>> [...]
>> AssocQueryStringW is not available with the original SDK delivered with
>> msvc6. With more recent SDKs it seems to be part of some "Internet Explorer
>> SDK". I'll try to look into replacing with some less critical API.
> 
> Oh, I wasn't aware of that. I think all these calls do is sniff around
> in the registry anyway, so one can probably implement it using raw
> registry calls.
> 
Still need to take a closer look. Just #ifdefed for the moment.

 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio on win32 (was Re: Announce: gio merged)

[Alexander Larsson]

On Wed, 2007-12-05 at 22:13 +0100, Hans Breuer wrote:
> On 05.12.2007 12:19, Alexander Larsson wrote:
> > On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
> >> On 03.12.2007 10:07, Alexander Larsson wrote:
> > 
> >>> Thats a way it can be made to work with the current use in libgio, but
> >>> it makes the API sort of weird for win32. How exactly is the dynamic
> >>> path calculated? Maybe its possible to make the API work in some
> >>> relative way? That way some other library on could also use
> >>> g_io_modules_ensure_loaded() to load its modules relative to its dll.
> >>>
> >> The thing needed than would be the DLL name or the HANDLE of the DLL to
> >> resolve the relative path against. I'm not sure though how the
> >> responsibilities need to be split for loading some gio-modules.
> >> Is an application supposed to deliver it's own extension modules for gio?
> > 
> > I changed this so that _g_io_modules_ensure_loaded is a private function
> > that only glib uses for its libs. It takes no arguments and could use
> > whatever magic require on win32 to find the module directory.
> > 
> > Instead I exported g_io_modules_load_all_in_directory, which is used in
> > the implementation of _g_io_modules_ensure_loaded. It can be used in
> > other libraries (such as in gvfs) to implement a similar thing.
> > 
> > Is this ok for you?
> > 
> Looks good. So I guess someone needs to write the first gio-module working
> on windoze - maybe around FindFirstChangeNotification() ;)

I don't think that needs to be a module actually. I've made the fam file
monitor a module, so that gio doesn't link to libfam. However, the
inotify monitor is built in, as that has no extra dependencies. (Loading
modules is not free, as it causes an extra private dirty page.)


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio on win32 (was Re: Announce: gio merged)

[Hans Breuer]

On 05.12.2007 12:19, Alexander Larsson wrote:
> On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
>> On 03.12.2007 10:07, Alexander Larsson wrote:
> 
>>> Thats a way it can be made to work with the current use in libgio, but
>>> it makes the API sort of weird for win32. How exactly is the dynamic
>>> path calculated? Maybe its possible to make the API work in some
>>> relative way? That way some other library on could also use
>>> g_io_modules_ensure_loaded() to load its modules relative to its dll.
>>>
>> The thing needed than would be the DLL name or the HANDLE of the DLL to
>> resolve the relative path against. I'm not sure though how the
>> responsibilities need to be split for loading some gio-modules.
>> Is an application supposed to deliver it's own extension modules for gio?
> 
> I changed this so that _g_io_modules_ensure_loaded is a private function
> that only glib uses for its libs. It takes no arguments and could use
> whatever magic require on win32 to find the module directory.
> 
> Instead I exported g_io_modules_load_all_in_directory, which is used in
> the implementation of _g_io_modules_ensure_loaded. It can be used in
> other libraries (such as in gvfs) to implement a similar thing.
> 
> Is this ok for you?
> 
Looks good. So I guess someone needs to write the first gio-module working
on windoze - maybe around FindFirstChangeNotification() ;)

Thank you,
Hans

 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio on win32 (was Re: Announce: gio merged)

[Alexander Larsson]

On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:
> On 03.12.2007 10:07, Alexander Larsson wrote:

> > Thats a way it can be made to work with the current use in libgio, but
> > it makes the API sort of weird for win32. How exactly is the dynamic
> > path calculated? Maybe its possible to make the API work in some
> > relative way? That way some other library on could also use
> > g_io_modules_ensure_loaded() to load its modules relative to its dll.
> > 
> The thing needed than would be the DLL name or the HANDLE of the DLL to
> resolve the relative path against. I'm not sure though how the
> responsibilities need to be split for loading some gio-modules.
> Is an application supposed to deliver it's own extension modules for gio?

I changed this so that _g_io_modules_ensure_loaded is a private function
that only glib uses for its libs. It takes no arguments and could use
whatever magic require on win32 to find the module directory.

Instead I exported g_io_modules_load_all_in_directory, which is used in
the implementation of _g_io_modules_ensure_loaded. It can be used in
other libraries (such as in gvfs) to implement a similar thing.

Is this ok for you?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio on win32 (was Re: Announce: gio merged)

[Alexander Larsson]

On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote:

> > Thats a way it can be made to work with the current use in libgio, but
> > it makes the API sort of weird for win32. How exactly is the dynamic
> > path calculated? Maybe its possible to make the API work in some
> > relative way? That way some other library on could also use
> > g_io_modules_ensure_loaded() to load its modules relative to its dll.
> > 
> The thing needed than would be the DLL name or the HANDLE of the DLL to
> resolve the relative path against. I'm not sure though how the
> responsibilities need to be split for loading some gio-modules.
> Is an application supposed to deliver it's own extension modules for gio?

There are two things here. Modules loaded by libgio, which are installed
(atm) in $libdir/gio/modules (or as specified by --with-gio-module-dir).
These are used for things that extend libgio. For instance, gvfs
installs its GVfs implementation there so that gio suddenly supports
uris. We also install e.g. the fam implementation of file monitoring and
the HAL based volume monitor there. 

Secondly GIOModule is an easy way for apps to load modules, which e.g.
gvfs uses to load its modules. You just point it to a directory and it
loads the modules there. 

I'm thinking maybe the second use case isn't that important. We can make
the first case work pretty nice on win32 if the GIOModule loading API is
internal, right? Then for the second case gvfs could just duplicate this
small piece of code.

Opinions?

>  glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test
> >>> g_file_test is pretty lame though. It does a new stat each time you call 
> >>> it and there are no ways to get more than a single piece of info for each 
> >>> call. This will just slaughter i/o performance. 
> >>>
> >>> What exactly is it that you need it to do that g_file_test does? We need 
> >>> to move that into glocalfile.c instead.
> >>>
> >> The first thing is the undefined statfs_buffer for !USE_STATFS and
> >> !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand
> >> the unknown API first to propose how to port it.
> >> On a quick glance the missing definition for S_ISDIR led me to propose
> >> g_file_test(). But of course this can be resolved differntly.
> > 
> > Maybe we should have a full alternative implementation of
> > g_local_file_query_info() using GetFileAttributes and similar calls. 
> > 
> I've started something of this, but not commited yet. (I'm getting too old
> for all these ifdefs ;)) See attahed patch.

Looks good to me.

> > I think we can make the posix version mostly work for win32, but a
> > native implementation can get more information, like fat attributes
> > (hidden, archive, system) and NT ACLs.
> > 
> > I think the interesting parts for a native win32 implementation is (for
> > local files, i.e. in glocalfile.c):
> > 
> > g_file_query_info() - This returns information about a file, like size,
> > type, icon, last changed, etc. The return type is a GFileInfo which is a
> > key-value container where the keys are namespaced strings like
> > "std:type" or "unix:uid". 
> > 
> This sounds like the application again must be unix/win32 specific. Or who
> is supposed to interpret the unix:uid key? Could some of this be abstracted
> away?

Some keys are unix specific, some are specific to other types of
storage. This isn't a "glib is build on unix" type of thing either. Some
filesystems store a unix uid, some don't. For instance, on a unix
machine you don't get a unix:uid when you get file info for a file on a
smb share. You might get a dos:is_archive though, as smb can hand you
that.

There are also common keys, including some that are more abstracted. For
instance, "owner:user" gets you the username of the user owning the file
and "owner:user_real" the full name. These are calculated from the uid
on unix backends, but can be calculated in other ways on other backends.
Similarily things like "access:can_read" is an abstraction of the
results of the permissions, which can be unix permissions or some other
form.

However, you can't really abstract away e.g. the unix permissions
totally. If you want to modify the permissions you can't work on the
abstracted fields, but must handle the specific details of the storage
format.

> > g_file_query_filesystem_info() - Similar to the above, but gets
> > information about the filesystem the file is on. i.e. total diskspace,
> > diskspace left, type of filesystem.
> > 
> Again I alread started a win32 specific implementation, not commited yet
> but attached for review.

Looks good. Does it also work for the root dir, or does
g_path_get_dirname() fail in that case?

> > g_file_enumerate_children() - This is readdir() + stat of each file
> > combined into one. I think Win32 has a better fit to this, where
> > FindNextFile actually returns stat info. On posix you need to make a
> > separate stat call for each filename readdir() returns. So, a native
> > win32 impl

gio on win32 (was Re: Announce: gio merged)

[Hans Breuer]

On 03.12.2007 10:07, Alexander Larsson wrote:
> On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: 
[...]

 g_io_modules_ensure_loaded (GIO_MODULE_DIR);
 It would be nice if this function would take no parameter to allow
 implementation of dynamic DLL placement resolvement in one place.
>>> Hmm. This is also used by gvfs to load its modules. It then passes a
>>> different location to the function ($(libdir)/gvfs/modules). Can you
>>> describe in more detail what you want it to do?
>>>
>> On windows the location of DLLs is deduce at runtime. It depends on where a
>> setup installed the DLLs, rather than fixed at compiled time.
>> Thus we have established a pattern to resolve module placement from the DLL
>> loading them. See for example gtk/gtkmodules.c.
>> My first idea was taht the parameter to g_io_modules_ensure_loaded() was
>> always the same. Thus it would have been possible to do the dynamic path
>> calcualtion in just this one function. Of course GIO_MODULE_DIR can be
>> defined to a function call on win32, to keep the other code like it is.
>> _gio_win32_module_dir() will have to return a static string than.
> 
> Thats a way it can be made to work with the current use in libgio, but
> it makes the API sort of weird for win32. How exactly is the dynamic
> path calculated? Maybe its possible to make the API work in some
> relative way? That way some other library on could also use
> g_io_modules_ensure_loaded() to load its modules relative to its dll.
> 
The thing needed than would be the DLL name or the HANDLE of the DLL to
resolve the relative path against. I'm not sure though how the
responsibilities need to be split for loading some gio-modules.
Is an application supposed to deliver it's own extension modules for gio?

 glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test
>>> g_file_test is pretty lame though. It does a new stat each time you call it 
>>> and there are no ways to get more than a single piece of info for each 
>>> call. This will just slaughter i/o performance. 
>>>
>>> What exactly is it that you need it to do that g_file_test does? We need to 
>>> move that into glocalfile.c instead.
>>>
>> The first thing is the undefined statfs_buffer for !USE_STATFS and
>> !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand
>> the unknown API first to propose how to port it.
>> On a quick glance the missing definition for S_ISDIR led me to propose
>> g_file_test(). But of course this can be resolved differntly.
> 
> Maybe we should have a full alternative implementation of
> g_local_file_query_info() using GetFileAttributes and similar calls. 
> 
I've started something of this, but not commited yet. (I'm getting too old
for all these ifdefs ;)) See attahed patch.

> I think we can make the posix version mostly work for win32, but a
> native implementation can get more information, like fat attributes
> (hidden, archive, system) and NT ACLs.
> 
> I think the interesting parts for a native win32 implementation is (for
> local files, i.e. in glocalfile.c):
> 
> g_file_query_info() - This returns information about a file, like size,
> type, icon, last changed, etc. The return type is a GFileInfo which is a
> key-value container where the keys are namespaced strings like
> "std:type" or "unix:uid". 
> 
This sounds like the application again must be unix/win32 specific. Or who
is supposed to interpret the unix:uid key? Could some of this be abstracted
away?

> g_file_query_filesystem_info() - Similar to the above, but gets
> information about the filesystem the file is on. i.e. total diskspace,
> diskspace left, type of filesystem.
> 
Again I alread started a win32 specific implementation, not commited yet
but attached for review.

> g_file_enumerate_children() - This is readdir() + stat of each file
> combined into one. I think Win32 has a better fit to this, where
> FindNextFile actually returns stat info. On posix you need to make a
> separate stat call for each filename readdir() returns. So, a native
> win32 implementation of GFileEnumerator would be more efficient.
> 
> None of this is strictly necessary of course, so it all depends on how
> much time the win32 developers want to spend on it.
> 
At the moment I'm concentrating on getting gio to work at all. At some
points there still is working implmentation missing. My current unresolved
externals (i.e. some of the stuff that compiles still requires functions
not compiled) :

glocalfile.obj : error LNK2001: unresolved external symbol _g_unix_mount_free
glocalfile.obj : error LNK2001: unresolved external symbol
_g_unix_mount_is_readonly
glocalfile.obj : error LNK2001: unresolved external symbol _g_get_unix_mount_at
glocalfile.obj : error LNK2001: unresolved external symbol
_g_unix_mounts_changed_since
glocalfile.obj : error LNK2001: unresolved external symbol _localtime_r
glocalfile.obj : error LNK2001: unresolved external symbol
__g_local_directory_monitor_new
glocalfileinfo.obj : error 

Re: Announce: gio merged

[Alexander Larsson]

On Fri, 2007-11-30 at 15:01 +0100, Hans Breuer wrote: 
> >>
> >>* gio/gcontenttype.c : use GDir instead of using 
> > 
> > Hmm? Why is that building on Win32? It should be picking the #ifdef
> > G_OS_WIN32 part of that file.
> > 
> You are right. I was just fooled by the unconditional #include 
> and mechanically translating to GDir (without testing if it compiles).
> But - given that there are two completely independent implementations in
> this file - wouldn't it be better to split it into gcontenttype-win32.c and
> gcontenttype-unix.c ?

Probably. I'm not sure why they ended up in the same file while e.g. the
appinfo stuff got split. Just happened I guess.

> >> gsocketinputstream.c gsocketoutputstream.c
> >> needs some reimplementation/porting to use winsock specific API.
> > 
> > This has been made Unix only. We'll probably need a winsock version of
> > this later though.
> > 
> >> g_io_modules_ensure_loaded (GIO_MODULE_DIR);
> >> It would be nice if this function would take no parameter to allow
> >> implementation of dynamic DLL placement resolvement in one place.
> > 
> > Hmm. This is also used by gvfs to load its modules. It then passes a
> > different location to the function ($(libdir)/gvfs/modules). Can you
> > describe in more detail what you want it to do?
> >
> On windows the location of DLLs is deduce at runtime. It depends on where a
> setup installed the DLLs, rather than fixed at compiled time.
> Thus we have established a pattern to resolve module placement from the DLL
> loading them. See for example gtk/gtkmodules.c.
> My first idea was taht the parameter to g_io_modules_ensure_loaded() was
> always the same. Thus it would have been possible to do the dynamic path
> calcualtion in just this one function. Of course GIO_MODULE_DIR can be
> defined to a function call on win32, to keep the other code like it is.
> _gio_win32_module_dir() will have to return a static string than.

Thats a way it can be made to work with the current use in libgio, but
it makes the API sort of weird for win32. How exactly is the dynamic
path calculated? Maybe its possible to make the API work in some
relative way? That way some other library on could also use
g_io_modules_ensure_loaded() to load its modules relative to its dll.

> >> glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test
> > 
> > g_file_test is pretty lame though. It does a new stat each time you call it 
> > and there are no ways to get more than a single piece of info for each 
> > call. This will just slaughter i/o performance. 
> > 
> > What exactly is it that you need it to do that g_file_test does? We need to 
> > move that into glocalfile.c instead.
> > 
> The first thing is the undefined statfs_buffer for !USE_STATFS and
> !USE_STATVFS in g_local_file_query_filesystem_info. I need to understand
> the unknown API first to propose how to port it.
> On a quick glance the missing definition for S_ISDIR led me to propose
> g_file_test(). But of course this can be resolved differntly.

Maybe we should have a full alternative implementation of
g_local_file_query_info() using GetFileAttributes and similar calls. 

I think we can make the posix version mostly work for win32, but a
native implementation can get more information, like fat attributes
(hidden, archive, system) and NT ACLs.

I think the interesting parts for a native win32 implementation is (for
local files, i.e. in glocalfile.c):

g_file_query_info() - This returns information about a file, like size,
type, icon, last changed, etc. The return type is a GFileInfo which is a
key-value container where the keys are namespaced strings like
"std:type" or "unix:uid". 

g_file_query_filesystem_info() - Similar to the above, but gets
information about the filesystem the file is on. i.e. total diskspace,
diskspace left, type of filesystem.

g_file_enumerate_children() - This is readdir() + stat of each file
combined into one. I think Win32 has a better fit to this, where
FindNextFile actually returns stat info. On posix you need to make a
separate stat call for each filename readdir() returns. So, a native
win32 implementation of GFileEnumerator would be more efficient.

None of this is strictly necessary of course, so it all depends on how
much time the win32 developers want to spend on it.

> >> Finally gio.symbols should be added to make exporting of symbols (and what
> >> not;) as easy as for glib/gobject and gtk+
> > 
> > It also needs to set up the aliases work for unix... I'll take a look at it.
> > 
> >> Do you want me to commit the uncritical pieces?
> > 
> > Everything but the gcontenttype.c part (that should not build on win32)
> > looks good to me.
> > 
> Ok, revert that thing and just moved the #include  stuff into the
> !G_OS_WIN32 #else.

Did you commit your stuff? 

> In the first chunck I was also completely missing the gwin32appinfo.c
> thing. Now it is giving me a hard time by using somewhat unusual API - not
> available in my current Platform SDK insta

Re: Announce: gio merged

[Hans Breuer]

On 28.11.2007 09:24, Alexander Larsson wrote:
> On Tue, 2007-11-27 at 22:34 +0100, Hans Breuer wrote:
>> On 26.11.2007 17:25, Alexander Larsson wrote:
>>> I just commited gio to the glib svn module. As this is a sort of large
>>> chunk of work I expect there to be some temporary issues to work out.
>>>
>>> For instance, its likely that there are some build issues for platforms
>>> I haven't tested. I got a bunch of solaris fixes for gio-standalone,
>>> which hopefully survived the merge, but there might still be issues.
>>>
>>> I'd also like some help from the win32 folks to make sure this builds in
>>> all the right ways.
>>>
>> Here comes the first chunk ;-)
>>
>>  * gio/gcontenttype.c : use GDir instead of using 
> 
> Hmm? Why is that building on Win32? It should be picking the #ifdef
> G_OS_WIN32 part of that file.
> 
You are right. I was just fooled by the unconditional #include 
and mechanically translating to GDir (without testing if it compiles).
But - given that there are two completely independent implementations in
this file - wouldn't it be better to split it into gcontenttype-win32.c and
gcontenttype-unix.c ?

>> gsocketinputstream.c gsocketoutputstream.c
>> needs some reimplementation/porting to use winsock specific API.
> 
> This has been made Unix only. We'll probably need a winsock version of
> this later though.
> 
>> g_io_modules_ensure_loaded (GIO_MODULE_DIR);
>> It would be nice if this function would take no parameter to allow
>> implementation of dynamic DLL placement resolvement in one place.
> 
> Hmm. This is also used by gvfs to load its modules. It then passes a
> different location to the function ($(libdir)/gvfs/modules). Can you
> describe in more detail what you want it to do?
>
On windows the location of DLLs is deduce at runtime. It depends on where a
setup installed the DLLs, rather than fixed at compiled time.
Thus we have established a pattern to resolve module placement from the DLL
loading them. See for example gtk/gtkmodules.c.
My first idea was taht the parameter to g_io_modules_ensure_loaded() was
always the same. Thus it would have been possible to do the dynamic path
calcualtion in just this one function. Of course GIO_MODULE_DIR can be
defined to a function call on win32, to keep the other code like it is.
_gio_win32_module_dir() will have to return a static string than.

>> glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test
> 
> g_file_test is pretty lame though. It does a new stat each time you call it 
> and there are no ways to get more than a single piece of info for each call. 
> This will just slaughter i/o performance. 
> 
> What exactly is it that you need it to do that g_file_test does? We need to 
> move that into glocalfile.c instead.
> 
The first thing is the undefined statfs_buffer for !USE_STATFS and
!USE_STATVFS in g_local_file_query_filesystem_info. I need to understand
the unknown API first to propose how to port it.
On a quick glance the missing definition for S_ISDIR led me to propose
g_file_test(). But of course this can be resolved differntly.

>> Finally gio.symbols should be added to make exporting of symbols (and what
>> not;) as easy as for glib/gobject and gtk+
> 
> It also needs to set up the aliases work for unix... I'll take a look at it.
> 
>> Do you want me to commit the uncritical pieces?
> 
> Everything but the gcontenttype.c part (that should not build on win32)
> looks good to me.
> 
Ok, revert that thing and just moved the #include  stuff into the
!G_OS_WIN32 #else.

In the first chunck I was also completely missing the gwin32appinfo.c
thing. Now it is giving me a hard time by using somewhat unusual API - not
available in my current Platform SDK installation. There are people
claiming shlwapi.h to be "one of the worst designed libraries to come out
of the Windows team"
[http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=203814&SiteID=1]
So at least now I know why it was not installed on my computer :-)

To be continued ...
Hans

 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Alexander Larsson]

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

> gbooleang_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.)

> gbooleang_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.

> gbooleang_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

Re: Announce: gio merged

[Yevgen Muntyan]

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.

const char *g_app_info_get_executable   
(GAppInfo *appinfo);
GIcon * g_app_info_get_icon 
(GAppInfo *appinfo);

Desktop file too.

gbooleang_app_info_supports_uris
(GAppInfo *appinfo);

This one, isn't it from desktop file, when you have "foobar %u" line?

gbooleang_app_info_should_show  
(GAppInfo *appinfo,
 const char   *desktop_env);

This one - desktop file, show in the menus or not, right?

gbooleang_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)

gbooleang_app_info_set_as_default_for_extension 
(GAppInfo *appinfo,
 const char   *extension,
 GError  **error);
gbooleang_app_info_add_supports_type
(GAppInfo *appinfo,
 const char   *content_type,
 GError  **error);

Same thing - applications do or do not support certain mime types,
but only on xdg you can know that.

Then, GAppLaunchContext is X-specific - display and startup notification.
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.

Best regards,
Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Alexander Larsson]

On Tue, 2007-11-27 at 22:34 +0100, Hans Breuer wrote:
> On 26.11.2007 17:25, Alexander Larsson wrote:
> > I just commited gio to the glib svn module. As this is a sort of large
> > chunk of work I expect there to be some temporary issues to work out.
> > 
> > For instance, its likely that there are some build issues for platforms
> > I haven't tested. I got a bunch of solaris fixes for gio-standalone,
> > which hopefully survived the merge, but there might still be issues.
> > 
> > I'd also like some help from the win32 folks to make sure this builds in
> > all the right ways.
> > 
> Here comes the first chunk ;-)
> 
>   * gio/gcontenttype.c : use GDir instead of using 

Hmm? Why is that building on Win32? It should be picking the #ifdef
G_OS_WIN32 part of that file.

> gsocketinputstream.c gsocketoutputstream.c
> needs some reimplementation/porting to use winsock specific API.

This has been made Unix only. We'll probably need a winsock version of
this later though.

> g_io_modules_ensure_loaded (GIO_MODULE_DIR);
> It would be nice if this function would take no parameter to allow
> implementation of dynamic DLL placement resolvement in one place.

Hmm. This is also used by gvfs to load its modules. It then passes a
different location to the function ($(libdir)/gvfs/modules). Can you
describe in more detail what you want it to do?

> glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test

g_file_test is pretty lame though. It does a new stat each time you call it and 
there are no ways to get more than a single piece of info for each call. This 
will just slaughter i/o performance. 

What exactly is it that you need it to do that g_file_test does? We need to 
move that into glocalfile.c instead.

> Finally gio.symbols should be added to make exporting of symbols (and what
> not;) as easy as for glib/gobject and gtk+

It also needs to set up the aliases work for unix... I'll take a look at it.

> Do you want me to commit the uncritical pieces?

Everything but the gcontenttype.c part (that should not build on win32)
looks good to me.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Alexander Larsson]

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).





___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Matthias Clasen]

On Nov 27, 2007 4:34 PM, Hans Breuer <[EMAIL PROTECTED]> wrote:

> Here comes the first chunk ;-)

Thanks for jumping in.

> * gio/gcontenttype.c : use GDir instead of using 
> * gio/gcancellable.c gio/gdummyfile.c
>   gio/glocalfile.c gio/gsimpleasyncresult.c : use HAVE_UNISTD_H
> * gio/glocalfile.c : use HAVE_PWD_H
>
> gsocketinputstream.c gsocketoutputstream.c
> needs some reimplementation/porting to use winsock specific API.

Following th eio channel example, gsocket*stream has been made unix-specific
and renamed to gunix*stream. I guess we should have a winsock-based
gwin32*stream, too.

> Finally gio.symbols should be added to make exporting of symbols (and what
> not;) as easy as for glib/gobject and gtk+

Certainly.

> Do you want me to commit the uncritical pieces?

Yes, please.


Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Hans Breuer]

On 26.11.2007 17:25, Alexander Larsson wrote:
> I just commited gio to the glib svn module. As this is a sort of large
> chunk of work I expect there to be some temporary issues to work out.
> 
> For instance, its likely that there are some build issues for platforms
> I haven't tested. I got a bunch of solaris fixes for gio-standalone,
> which hopefully survived the merge, but there might still be issues.
> 
> I'd also like some help from the win32 folks to make sure this builds in
> all the right ways.
> 
Here comes the first chunk ;-)

* gio/gcontenttype.c : use GDir instead of using 
* gio/gcancellable.c gio/gdummyfile.c
  gio/glocalfile.c gio/gsimpleasyncresult.c : use HAVE_UNISTD_H
* gio/glocalfile.c : use HAVE_PWD_H

gsocketinputstream.c gsocketoutputstream.c
needs some reimplementation/porting to use winsock specific API.

g_io_modules_ensure_loaded (GIO_MODULE_DIR);
It would be nice if this function would take no parameter to allow
implementation of dynamic DLL placement resolvement in one place.

glocalfile.c needs some more porting to GLib APIs, e.g. g_file_test

Finally gio.symbols should be added to make exporting of symbols (and what
not;) as easy as for glib/gobject and gtk+

Do you want me to commit the uncritical pieces?

Thanks,
Hans


 Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
Index: gcancellable.c
===
--- gcancellable.c  (revision 5943)
+++ gcancellable.c  (working copy)
@@ -21,9 +21,14 @@
  */
 
 #include 
+#ifdef HAVE_UNISTD_H
 #include 
+#endif
 #include 
 #include 
+#ifdef G_OS_WIN32
+#include 
+#endif
 #include "gcancellable.h"
 
 #include "glibintl.h"
Index: gcontenttype.c
===
--- gcontenttype.c  (revision 5943)
+++ gcontenttype.c  (working copy)
@@ -23,7 +23,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 
@@ -787,49 +786,49 @@
 static void
 enumerate_mimetypes_subdir (const char *dir, const char *prefix, GHashTable 
*mimetypes)
 {
-  DIR *d;
-  struct dirent *ent;
+  GDir *d;
+  const char *ent;
   char *mimetype;
 
-  d = opendir (dir);
+  d = g_dir_open (dir);
   if (d)
 {
-  while ((ent = readdir (d)) != NULL)
+  while ((ent = g_dir_read_name (d)) != NULL)
{
- if (g_str_has_suffix (ent->d_name, ".xml"))
+ if (g_str_has_suffix (ent, ".xml"))
{
- mimetype = g_strdup_printf ("%s/%.*s", prefix, (int) strlen 
(ent->d_name) - 4, ent->d_name);
+ mimetype = g_strdup_printf ("%s/%.*s", prefix, (int) strlen (ent) 
- 4, ent);
  g_hash_table_insert (mimetypes, mimetype, NULL);
}
}
-  closedir (d);
+  g_dir_close (d);
 }
 }
 
 static void
 enumerate_mimetypes_dir (const char *dir, GHashTable *mimetypes)
 {
-  DIR *d;
-  struct dirent *ent;
+  GDir *d;
+  const char *ent;
   char *mimedir;
   char *name;
 
   mimedir = g_build_filename (dir, "mime", NULL);
   
-  d = opendir (mimedir);
+  d = g_dir_open (mimedir);
   if (d)
 {
-  while ((ent = readdir (d)) != NULL)
+  while ((ent = g_dir_read_name (d)) != NULL)
{
- if (strcmp (ent->d_name, "packages") != 0)
+ if (strcmp (ent, "packages") != 0)
{
- name = g_build_filename (mimedir, ent->d_name, NULL);
+ name = g_build_filename (mimedir, ent, NULL);
  if (g_file_test (name, G_FILE_TEST_IS_DIR))
-   enumerate_mimetypes_subdir (name, ent->d_name, mimetypes);
+   enumerate_mimetypes_subdir (name, ent, mimetypes);
  g_free (name);
}
}
-  closedir (d);
+  g_dir_close (d);
 }
   
   g_free (mimedir);
Index: gdummyfile.c
===
--- gdummyfile.c(revision 5943)
+++ gdummyfile.c(working copy)
@@ -27,7 +27,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_UNISTD_H
 #include 
+#endif
 #include 
 
 #include "gdummyfile.h"
Index: glocalfile.c
===
--- glocalfile.c(revision 5943)
+++ glocalfile.c(working copy)
@@ -27,7 +27,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_UNISTD_H
 #include 
+#endif
 
 #if HAVE_SYS_STATFS_H
 #include 
@@ -678,7 +680,7 @@
   GUnixMount *mount;
   guint64 cache_time;
 
-  if (lstat (path, &buf) != 0)
+  if (g_lstat (path, &buf) != 0)
 return;
 
   G_LOCK (mount_info_hash);
Index: glocalvfs.c
===
--- glocalvfs.c (revision 5943)
+++ glocalvfs.c (working copy)
@@ -25,7 +25,9 @@
 #include "glocalfile.h"
 #include 
 #include 
+#ifdef HAVE_PWD_H
 #include 
+#endif
 
 struct _GLocalVfs
 {
@@ -130,6 +132,7 @@
user_prefix = g_strdup (g_get_hom

Re: Announce: gio merged

[Yevgen Muntyan]

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.

Thanks,
Yevgen

Alexander Larsson wrote:
> I just commited gio to the glib svn module. As this is a sort of large
> chunk of work I expect there to be some temporary issues to work out.
>
> For instance, its likely that there are some build issues for platforms
> I haven't tested. I got a bunch of solaris fixes for gio-standalone,
> which hopefully survived the merge, but there might still be issues.
>
> I'd also like some help from the win32 folks to make sure this builds in
> all the right ways.
>
> As a general update to the status I would say the API is pretty good and
> shouldn't need much changes (I consider it API slushy atm, only serious
> problems will cause changes). There are a few spots in the
> implementation that are stubbed and marked TODO. We plan to fix all
> these before Gnome 2.22 though. 
>
> Also, the docs are mostly the function templates right now. These need
> to be fully fleshed out.
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>   

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Announce: gio merged

[Alexander Larsson]

On Mon, 2007-11-26 at 17:25 +0100, Alexander Larsson wrote:

> As a general update to the status I would say the API is pretty good and
> shouldn't need much changes (I consider it API slushy atm, only serious
> problems will cause changes). There are a few spots in the
> implementation that are stubbed and marked TODO. We plan to fix all
> these before Gnome 2.22 though. 

There was a vew API changes today:
* gurifuncs.c moved to glib
* g_format_file_size_for_display moved to glib
* GSocketInput/OutputStream was renamed to GUnixInput/OutputStream and
  moved to the unix-only gio-unix-2.0.pc file
* a  main include-everything header was added

> Also, the docs are mostly the function templates right now. These need
> to be fully fleshed out.

A bunch of docs was commited, written by Andrew Walton. I need to review
this for details, but it looks quite good and bumps up much further up
in the docs completion stats.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Announce: gio merged

[Alexander Larsson]

I just commited gio to the glib svn module. As this is a sort of large
chunk of work I expect there to be some temporary issues to work out.

For instance, its likely that there are some build issues for platforms
I haven't tested. I got a bunch of solaris fixes for gio-standalone,
which hopefully survived the merge, but there might still be issues.

I'd also like some help from the win32 folks to make sure this builds in
all the right ways.

As a general update to the status I would say the API is pretty good and
shouldn't need much changes (I consider it API slushy atm, only serious
problems will cause changes). There are a few spots in the
implementation that are stubbed and marked TODO. We plan to fix all
these before Gnome 2.22 though. 

Also, the docs are mostly the function templates right now. These need
to be fully fleshed out.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list