The GNOME Journal, September Edition

gnome-vfs support is already easy. The question that has to be asked is why aren't developers using it?

Lack of will to read the docs / api? only wanting to write to what they already know?

Incompatible? e.g. file roller just calls command line apps so it would require more work in copying archive files around to decompress and after compressing.

e.g. file roller just calls command line apps so it would require more work in copying archive files around to decompress and after compressing.

For some reason, KDE's equivalent to file-roller has no problems accessing remote files. I'm pretty sure that, just like file-roller, it is pretty much a frontend to command line utilities, too.

So, the issue must be soluble. Still, after having filed an according bug against file-roller some 6 month or more ago, all the feedback I got was that it was impossible for the above mentioned reason.

I begin to suspect that GNOME makes it infinitely harder for developers to integrate with GNOME-VFS than KDE for its KIO-slaves. Further, the lack of complete, usable and up-to-date documentation appears to be a major factor.

> gnome-vfs support is already easy. The question that has
> to be asked is why aren't developers using it?

That's the theory. I don't know about you, but I am doing most of the file access through third party libraries like libxml though. How can you make this interact with gnome-vfs?

load and feed the resulting buffer to libxml, either in one whole chunk, or a bit at a time as libxml should support streaming data in.

I was wondering about this. It seems a little goofy compared to fopen. With a normal file operation, the application can pretty reasonably expect that the resource will always always be there and that it can access it very quickly.

For network files things get tricky. For one, should file interactions be asynchronous in another thread? Or should the app just block whenever it is trying to access the file? That could be very annoying for a user if the network connection is slow.

Does gnome-vfs maybe cache a local copy of the file? If so, how then does it handle the file changing while it is being used? I guess most apps don't handle this anyway unless they are smart about it. For example Totem will play a file I deleted no problem until it gets to the end of the movie but gvim will instantly tell me if the file has been modified outside the editor.

Caching locally seems like a bad idea on really big files also where you might want to do incremental reads.

I guess I can see it being easy for developers depending on how it was implemented. If there are options that make it behave differently depending on the use model then I can see it being pretty slick and easy for people doing simple apps like video players, web browsers, etc where file open/close isn't a big part of what is going on. Probably just go through and replace all the fopen with a differnt call, maybe some new options and viola!

It would only be incrementally harder for the developer and much nicer for the user if instead of blocking during file operations, the gnome-vfs library had some sort of callback that could be used so the app could lock out the gui (not freeze it which amounts to the same thing but looks 10x worse) and provide a "update file from network" dialog or something.

Seriously for most apps you are right this should be pretty easy. There should be a howto or something. If one doesn't exist, that sucks. If one does exist, then that really sucks and developers should get their shit together.

Hopefully now that the fuse file system is making its way in to the kernel gnome-vfs can go away

Hopefully now that the fuse file system is making its way in to the kernel gnome-vfs can go away

Nope! Kernel level code requires privileges. FUSE, even though it is called "userland file system" does not and cannot change the simple fact that on monolithic kernels mounting file systems is a privileged action.

The good thing about Gnome-VFS, KIO-Slaves and eventually HURD translators is that no mounting in the traditional sense takes place, thus no privileges requires.

This substantially increases the user's freedom without compromising system security.

Therefore GNOME-VFS cannot go away, unless you either set the SUID bit on /sbin/mount or you decide that your users should not have the right to transparently access e.g. SMB shares or other remote file systems.
Both choices are IMHO unacceptable. Well, there is a third choice: Wait for the HURD to become ready...

OK if this is true (I'm not a kernel hacker) something needs fixing.
UNIX was once the king of NOS's but is falling behind. eg. how do you have a $HOME directory mapped to a server using my username/password and not IP based like NFS does? it must be possable OS X does it.

All I'm saying is that it can't be done at the kernel level the operation should be pushed down to freedesktop level so that session-management systems (eg gome, kde and others) do the work and apps do not have to know about it.

my 2 cents worth:)

what kernel? bsd? solaris? aix? gnome is not just linux, therefore anything added to the linux kernel is irrelevant on this front.

gnome-vfs is also more flexible than fuse, which requires you mount the locations you want to access, you can't just load a random url, unless I'm missing something, or something has changed recently.

My bad I was talking about the Linux.
To me the whole gnome-vfs thing seems unworkable, like the grandparent mentions all the apps need to support it, you don't have a mount point where for instance you can dd an image to a hard drive eg: boot from a live CD use the gui to mount a smb share and then dd an image on that share to the local hard drive.
I'm not sure how OS X does it but you do get a mounted filesystem that any application can see.
which in the long run make appilcation development easier and non gnome appilcactions can see the mounted drive.

I say bugger the other kernels they will catch up. Currently there is only 2 that matter Linux and BSD and I'm sure BSD will catch up real quick if OS X can do it.

I say bugger the others because Solaris, AIX and friends are not used on the desktop much these days and if they are it wouldn't mater because the gnome-fs doesn't work now anyway, so they lose nothing.

Yes of course. Because we all know those are trivial and easy fixes that an *intern* can do in less than 10 weeks. I mean come on, making gnome-vfs not suck should be just as simple as fixing all of the bugs in Samba. How hard can that be?

Seriously. Just look at the last entry. One intern with help from Owen Taylor spent an entire summer figuring out how to make Gnome startup faster (not respond faster, or use less resources, just get from login to desktop faster). And then he wasn't even able to write a working patch. Everybody would like to see your list come true, but they are not easy things to do. In the meantime, I welcome patches to any application that make it better, including Rhythmbox.

The topic has been beaten to death already over at OSNews. Really. And your posting (complain, arguments, whatever) won't change anything!

Face it: Java might be nice but it doesn't matter without application developers and end-user applications that looks'n'feels like a GNOME application (and delivers some utility: there's no need for another editor.)

If you feel Java is needed as a competitor to Mono, write a review about a Java end-user application for the next edition (submission deadline: Nov., the 1st)!

A nice one would be Azureus: Does it run flawlessly on GCJ? Does it look GNOME'ish? Does it appear to react fast enought? What about HIG complience, for example: Instant Apply? Button order? Proper lists and tree views? Of course, you'll also need to write about the background stuff: What is Bittorrent? What's its benefit? How does one use it?

You get the idea.

This, in fact, is much more promising than writing useless comments about a beaten-to-death topic.

You shouldn't make assumptions about persons you don't know. But anyway, here are my answers and my opinion:
1.) I don't defend Mono because I'm not happy about the legal situation either. I can't comment on Mono's technical merits.
2.) I'm honstely don't mind about any Mono application. I run none of of them, and I don't need any of the existing ones.
3.) As long as Mono won't get part of the core desktop enviroment, I really don't care about any of Novell's mistakes.

Finally, I don't tell you to shut up. I'm suggesting a more effective way to reach our goal. But if you prefer to believe that your comment is indeed read by someone, well, have fun.

Everybody concerned has read the arguments over and over, again. Your post adds nothing new, and it is additionally off-topic because there's no article in the edition that says: "Use Mono!"

Most importantly: It won't make useful Java, C++, or Python apps appear magically. If C# developers deliver useful applications, people will use them, and thus Mono. If the functionality of the application is important enought, they will find a way around RedHat's No-Support policy; probably by simply switching the distribution.

For a user, your arguments are irrelevant, too, because if Mono dies one day due to legal reasons, a user will simply switch to Python, C++ or C applications. Not a big deal.

Mono has gtk#. Java has...swing? That is about as good as Firefox's Gnome integration.
Java has java-gnome which in fact is a whole lot better than XUL (which Firefox uses). It's an official part of the GNOME Platform Bindings, even.

Check out www.nrpms.net

We have so many cool new ideas bubbling away it's hard to know what to work on next. Besides GOCollab all the following would be fun

Mozilla plugins

cairo integration
Math GUI
a presentaion program
svg integration
More WP features:
comments, repeated headings on different pages for tables.
Sort rows/columns
embedded frames
More text wrapping options
Better import/export filters
Embeddable Spreadsheets
Document previews on open
Document thumb nails for nautilus (like the current pdf's)
drag and drop text to nautilus
Improved grammar checking

Cheers

Martin