[PATCH] remove UDSEntry from the public KIO API?

Jos Poortvliet jos at mijnkamer.nl
Tue Jul 31 10:39:01 BST 2007


On 7/30/07, nf2 <nf2 at scheinwelt.at> wrote:
>
> Richard Moore wrote:
> > On 7/28/07, nf2 <nf2 at scheinwelt.at> wrote:
> >
> >> I see, but there is some kind of relationship between kfile and
> >> libsolid. I reckon this has to change when plugging GVFS in. In this
> >> case, Kfile should probably use the gvfs API for drives and volumes
> >> instead...
> >>
> >
> > I'm curious why we would be pluging GVFS in at all? I don't remember
> > any discussion about us using it.
> >
> > Rich.
> >
>
> I believe a discussion whether the core-engine of file-management (which
> KIO tries to be - at least for network-resources) can be in the desktop
> layer, or not, wouldn't be bad. Perhaps the problem is not as obvious
> for desktop developers than for everyone else. Generally i think that
> users don't care about the "K" or "G" in front of application names.
> They rather expect that everything which is a "linux application" will
> run on any desktop in the same quality and hit the install button.
> Finding out that different applications provide totally different and
> incompatible file-management models (in file-choosers for instance) will
> most likely frustrate them. As long as someone only works with local
> files, he won't realize. But working with documents on file-servers can
> be a painful experience. GVFS might be an opportunity to fix those
> file-management inconsistencies...


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

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.

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.

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.

Norbert
>
>
[1] it's not really like it's ready yet:
http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00062.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070731/b1eeb35c/attachment.htm>


More information about the kde-core-devel mailing list