After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 527524 - port to GIO
port to GIO
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-11 12:00 UTC by André Klapper
Modified: 2011-11-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description André Klapper 2008-04-11 12:00:15 UTC
These are the occurences of gnome_vfs calls:

$:andre\> grep -R gnome_vfs .
./src/load-graph.cpp:    used_text = SI_gnome_vfs_format_file_size_for_display(used);
./src/load-graph.cpp:    total_text = SI_gnome_vfs_format_file_size_for_display(total);
./src/load-graph.cpp:   text1 = SI_gnome_vfs_format_file_size_for_display (in);
./src/load-graph.cpp:   text1 = SI_gnome_vfs_format_file_size_for_display (out);
./src/disks.cpp:        monitor = gnome_vfs_get_volume_monitor();
./src/disks.cpp:        volume = gnome_vfs_volume_monitor_get_volume_for_path(monitor, mountpoint);
./src/disks.cpp:                volume = gnome_vfs_volume_monitor_get_volume_for_path(monitor, "/");
./src/disks.cpp:            icon_name = make_string(gnome_vfs_volume_get_icon(volume));
./src/disks.cpp:            gnome_vfs_volume_unref(volume);
./src/disks.cpp:        if (gnome_vfs_url_show(url) != GNOME_VFS_OK)
./src/callbacks.cpp:  if ((res = gnome_vfs_url_show("ghelp:gnome-system-monitor")) != GNOME_VFS_OK)
./src/callbacks.cpp:    g_warning("Could not display help : %s", gnome_vfs_result_to_string(res));
./src/sysinfo.cpp:  markup = SI_gnome_vfs_format_file_size_for_display(data->memory_bytes);
./src/sysinfo.cpp:  markup = SI_gnome_vfs_format_file_size_for_display(data->free_space_bytes);
./src/util.cpp: * SI_gnome_vfs_format_file_size_for_display:
./src/util.cpp:SI_gnome_vfs_format_file_size_for_display (GnomeVFSFileSize size, GnomeVFSFileSize max_size)
./src/util.cpp:    char *str = SI_gnome_vfs_format_file_size_for_display(size);
./src/util.cpp:      char *str = SI_gnome_vfs_format_file_size_for_display(size);
./src/util.cpp:    char* bytes = SI_gnome_vfs_format_file_size_for_display(rate, max_rate);
./src/util.h:SI_gnome_vfs_format_file_size_for_display (GnomeVFSFileSize size, GnomeVFSFileSize max = 0);
./src/procman.cpp:      mon = gnome_vfs_get_volume_monitor();
./src/procman.cpp:      gnome_vfs_init ();
./src/procman.cpp:      gnome_vfs_shutdown ();
Comment 1 Benoît Dejean 2008-04-18 07:00:56 UTC
I will merge my git as soon as i'll have solved a giomm issue. I can't find anything suitable to replace gnome_vfs_url_show .
Comment 2 Cosimo Cecchi 2008-04-18 11:24:55 UTC
(In reply to comment #1)
> I will merge my git as soon as i'll have solved a giomm issue. I can't find
> anything suitable to replace gnome_vfs_url_show .

The most suitable function in GIO to replace that is g_app_info_launch_default_for_uri ().

Comment 3 Benoît Dejean 2008-04-22 22:03:02 UTC
Done in r2400. 

I've been fighting all the night in order to merge my git branches to svn ... where the history has been squashed into a giant patch without any commit message.
svn die die die !

Oh and since the commit messages are gone, the only remaining problem is about the VolumeMonitor. The Gio binding is a bit unstable and nobody seems to understand what are Volume, Mount and UnixMount, why a UnixMount is not a Mount and why gio-unix-2.0 is external. So i've hardcoded the disk icons for now.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 4 A. Walton 2008-04-23 01:55:59 UTC
Andre asked for someone to comment on this in IRC, so here's my attempt at a quick explanation.

GUnixMount is a GMount (inheritance is fun!), and the Unix classes were moved out of the gio base library so that e.g. Windows developers wouldn't have to worry about them. On any *n*x platform, you should be using gio-unix-2.0 instead of gio-2.0 (as the latter includes the former for you in pkg-config) if you want to work with Volumes/Mounts/Drives.

The whole Volume/Mount/Drive is a bit confusing at first, but once you understand it, it somewhat makes sense. Drives are physical disks and other storage devices, which can host multiple volumes. Volumes are partitions/images/etc. and are mountable (and generally, map back to their parent drive). Mounts are mounted file systems, which can be associated with volumes, but aren't necessarily [think virtual file systems which really aren't located on a "volume"]. 

The GUnixMount stuff is a special case on top of the GMount class, with specifics needed for dealing with UNIX mounts (fstab/mtab entries). 

For the icon that represents a volume, use g_volume_get_icon(), for a specific mount, use g_mount_get_icon(), and you guessed it, g_drive_get_icon() for drives. It's as simple as that. Keep in mind that "drive"/"mount" can mean "camera" or "music player" or "NFS share" and you might get those icons if the device/mount is of that type, and so on.

If I've missed anything, please let me know.
Comment 5 Benoît Dejean 2008-04-25 21:11:52 UTC
Thanks for the explanation. But there's something i don't get : why GUnixMount is not part of the common API as a GUnixMount isa GMount ? i mean why does g_unix_mounts_get() is not a subset of g_volume_monitor_get_mounts() ?
Comment 6 A. Walton 2008-04-25 22:53:53 UTC
(In reply to comment #5)
> why GUnixMount is not part of the common API as a GUnixMount is a GMount ?

#GVolumeMonitor should return #GUnixMounts on a UNIX platform; If the #GVolumeMonitor isn't returning any #GUnixMounts at all on a UNIX platform after using the gio-unix package, then it's probably a bug. It could be the case that the HAL volume monitor module in GVFS is simply overriding the #GUnixVolumeMonitor, and you're never seeing any #GUnixMounts. I don't know if this is the case though, you'll have to talk to David Zeuthen about that. I don't think it is though. 

The idea is that you get a #GVolumeMonitor, and with it you can monitor all volumes, not just Unix ones.

> i mean why does g_unix_mounts_get() is not a subset of g_volume_monitor_get_mounts() ?

Because g_unix_mounts_get() gets a list of strings from e.g. /etc/mtab. g_volume_monitor_get_mounts() gets a list of #GMounts, which should include #GHalMounts, #GUnixMounts, and #BobsFrobMounts if your application load bobs-frobs-inc-volume-monitor.so. It's probably poorly named, and definitely underdocumented as I did a lot of that work in a rush to get something in for GNOME 2.22 (and to have something to look at other than source code when I'm scratching my head wondering how it works ;).

If you need to filter through the list that the volume monitor gives you, I'm not sure if there's a better way than just checking the type of the object it gives you (e.g. G_IS_UNIX_MOUNT).

The GUnixMountPoints/GUnixMountPaths API is very low-level, just abstracting the various differences between UNIXes. GIO then layers on top of that. GLib probably could have kept most of that stuff as a hidden abstraction, but someone somewhere probably would have wanted it public at some point, as it seems to me like it would be often duplicated code for anyone wanting to write e.g. a system management tools like this one, which like to know the gritty details about the underlying system. And then GVFS needs it too, for the HAL volume monitor.

Hope that helps.
Comment 7 Benoît Dejean 2008-04-25 23:39:15 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > why GUnixMount is not part of the common API as a GUnixMount is a GMount ?
> 
> #GVolumeMonitor should return #GUnixMounts on a UNIX platform; If the
> #GVolumeMonitor isn't returning any #GUnixMounts at all on a UNIX platform
> after using the gio-unix package, then it's probably a bug. It could be the
> case that the HAL volume monitor module in GVFS is simply overriding the
> #GUnixVolumeMonitor, and you're never seeing any #GUnixMounts. I don't know if
> this is the case though, you'll have to talk to David Zeuthen about that. I
> don't think it is though. 

benoit@ibook >>> cat mounts.cpp 
#include <iostream>
#include <ostream>

#include <gio/gio.h>
#include <gio/gunixmounts.h>

int main()
{

    g_type_init();
    GVolumeMonitor *monitor = g_volume_monitor_get();
    GList *mounts = g_volume_monitor_get_mounts(monitor);

    std::cout << "Mounts " << g_list_length(mounts) << '\n';

    std::cout << "UnixMounts " << g_list_length(g_unix_mounts_get(0)) << '\n';
}
 
benoit@ibook >>> g++ -Wall $(pkg-config --cflags --libs gio-unix-2.0) mounts.cpp -o mounts && ./mounts
Mounts 0
UnixMounts 10

benoit@ibook >>> uname -s
Linux

benoit@ibook >>> pkg-config --modversion gio-unix-2.0
2.16.1

Then it's a bug.

> 
> The idea is that you get a #GVolumeMonitor, and with it you can monitor all
> volumes, not just Unix ones.
> 
> > i mean why does g_unix_mounts_get() is not a subset of g_volume_monitor_get_mounts() ?
> 
> Because g_unix_mounts_get() gets a list of strings from e.g. /etc/mtab.
> g_volume_monitor_get_mounts() gets a list of #GMounts, which should include
> #GHalMounts, #GUnixMounts, and #BobsFrobMounts if your application load
> bobs-frobs-inc-volume-monitor.so. It's probably poorly named, and definitely
> underdocumented as I did a lot of that work in a rush to get something in for
> GNOME 2.22 (and to have something to look at other than source code when I'm
> scratching my head wondering how it works ;).

OK, i've been mislead by the fact that the current implementation is buggy.

Thank you very much.