[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KFilePlacesModel/View question
From:       nf2 <nf2.email () gmail ! com>
Date:       2009-10-20 0:03:43
Message-ID: aaed7a190910191703g7064375fr9d69337c19ae4832 () mail ! gmail ! com
[Download RAW message or body]

On Mon, Oct 19, 2009 at 11:48 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On October 18, 2009, nf2 wrote:
>> I'm wondering whether the device related code in KFilePlacesModel
>> could be internalized a bit. So that the classes using it don't have
>> to deal with devices directly (like kfilplacesview.cpp,
>> systemmodel.cpp, placesengine.cpp, placesrunner.cpp). That way we
>> could more easily plug a different model, for instance when running
>> KDE apps outside KDE.
>
> parse error. you mean "outside of the KDE Workspace".

Yes.

>
> as for the original issue, why couldn't all the models provide Solid::Devices?
> or even better, why wouldn't this simply rely on different Solid backends?
>

My first attempt (last year) actually was adding network mounts to
Solid. But that was rejected by Kevin, because he said that Solid was
focussing at hardware (as the name suggests). He convinced me. I don't
think it's good to push everything which is a kind of "item for
something" into Solid.

My second attempt was to propose a new "KStorage" API - a "to the
point" API for managing filesystem volumes and mounts inside KIO. I
still think this would be a good solution, because IMHO the
filemanagement library (KIO) should provide everything what's needed
to write a file-chooser or file-manager. GUIs shouldn't need to bother
about picking the right things out of a generic hardware abstraction
layer. From the perspective of a file-chooser, Solid would be an
implementation thing behind the scenes, and hiding the implementation
is good for portability in general. For instance when porting a KDE
application to another platform or OS, it might not be necessary to
carry a fully fledged hardware abstraction library across - just for
displaying some "filesystem roots" in a file-dialog.

But actually such a "filesystem roots" API already exists:
KFilePlacesModel. It isn't in KIO, and it has the advantage that it
provides everything (standard items, storage, bookmarks) that you need
to define the left side panel of a file-dialog/manager. This seems to
be the ideal point to plug a different implementation. What i would
like to change, is that storage items appearing in KFilePlacesModel
not necessarily have to be Solid::Devices (by internalizing some
device.is<> and device.as<> code, which is now scattered across UI
code).

Regards,
Norbert
[prev in list] [next in list] [prev in thread] [next in thread]