[PATCH] remove UDSEntry from the public KIO API?
nf2
nf2 at scheinwelt.at
Mon Jul 23 11:41:51 BST 2007
Thiago Macieira wrote:
> nf2 wrote:
>
>> are you going to remove UDSEntry completely from the public KIO API? I
>> have seen that it isn't used in kdirlister.h. What about StatJob?
>>
>> I think getting rid of UDSEntry would make it easier to switch to GVFS
>> as backend lateron... GVFS seems to be a good candidate for a common
>> file-management library - it only depends on GLib and DBUS and it's
>> design is quite elegant...
>>
>> norbert
>>
>
> Here's a new patch, based on Norbert's work. I changed a bit from his code
> by adjusting the indention style on the new file (udsentry.cpp/h) and
> simplifying a bit.
>
> This hides the details of UDSEntry and UDSField from the public. The
> question is now? Should we commit? Norbert, does it help towards your
> goal?
>
>
Cool. I have seen you have also fixed the KioSlaveTest (which i have
just commented out). And udsentry.cpp looks a lot nicer now.
I think the patch should be commited - everything which makes the
KIO-API more generic and extensible (without having to break the API)
will help you in the future. No matter if the future is GVFS or not.
I think the next step (as soon as possible) should be to write an
experimental GVFS-slave to learn out about other compatibility issues.
This slave could in the future handle all protocols intended for
file-management: file:, ftp:, sftp:, smb:,.... Having the "engine" for
file-management in the desktop-layer just never worked well.
File-management "naturally" belongs to the platform (a layer shared by
all applications - like X, cups, HAL,...) and not to certain desktops.
But slaves which primarily exist to support certain applications (http
for Konqueror for instance) could stay in KIO.
As GVFS is not finished yet, i think it would be great for KIO and SOLID
developers to check out the sources from Alexander Larssons GIT and have
a close look how it works. And maybe participate by subscribing
gnome-vfs-list at gnome.org. :-)
cheers,
norbert
More information about the kde-core-devel
mailing list