On 7/30/07, <b class="gmail_sendername">nf2</b> <<a href="mailto:nf2@scheinwelt.at">nf2@scheinwelt.at</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Richard Moore wrote:<br>> On 7/28/07, nf2 <<a href="mailto:nf2@scheinwelt.at">nf2@scheinwelt.at</a>> wrote:<br>><br>>> I see, but there is some kind of relationship between kfile and<br>>> libsolid. I reckon this has to change when plugging GVFS in. In this
<br>>> case, Kfile should probably use the gvfs API for drives and volumes<br>>> instead...<br>>><br>><br>> I'm curious why we would be pluging GVFS in at all? I don't remember<br>> any discussion about us using it.
<br>><br>> Rich.<br>><br><br>I believe a discussion whether the core-engine of file-management (which<br>KIO tries to be - at least for network-resources) can be in the desktop<br>layer, or not, wouldn't be bad. Perhaps the problem is not as obvious
<br>for desktop developers than for everyone else. Generally i think that<br>users don't care about the "K" or "G" in front of application names.<br>They rather expect that everything which is a "linux application" will
<br>run on any desktop in the same quality and hit the install button.<br>Finding out that different applications provide totally different and<br>incompatible file-management models (in file-choosers for instance) will<br>
most likely frustrate them. As long as someone only works with local<br>files, he won't realize. But working with documents on file-servers can<br>be a painful experience. GVFS might be an opportunity to fix those<br>
file-management inconsistencies...</blockquote><div><br>KIO works for non-KDE apps - it automatically copies the file to a temporary location, and monitors the file for changes, uploading it when it changes. Works pretty good. Second, there is KIO-FUSE, which could be used to let non-KDE apps do their thing without knowing they're not working on local files
<br><br>FUSE is meant for a below-desktops system anyway, so that would probably be a better way to go. I'd rather see (for once) work from the other side to work with this, but I guess that's just a dream. At least, you'd have an easier time getting KIO to (optionally) use GVFS, even though that still has to be written, than GVFS use KIO, even through Fuse ;-) So you choose to do the right thing, I guess.
<br><br>I guess the dev's don't want to cripple or de-stabilize the (proven and working) KIOslaves for something which MIGHT [1] exist in the future, and we MIGHT use. GVFS will also introduce a new dependency, and I guess it's not platform independent either, is it? So I guess they're sceptical, and won't turn heaven and earth to get support for this.
<br><br>Of course, I'm no developer, and who codes decides - so as long as the KIO dev's accept your patches, be happy, don't worry.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Norbert<br><br></blockquote></div><br>[1] it's not really like it's ready yet:<br>
<a href="http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00062.html">http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00062.html</a>