Embedding Dolphin's KPart

[Andreas Pakulat]

On 03.06.08 12:36:10, Alexander Dymo wrote:
> On Tue, Jun 3, 2008 at 12:08 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > starting a new thread as this is about the technical problems when we
> > embed that kpart.
> 
> To make it short, I think it's a totally wrong approach.
> Reasons:
> - file manager have to be as simple as possible

Sure, but it should also be a file-manager, else we shouldn't call it a
file-manager. That means you can use it to:

- navigate the filesystem
- manipulate the filesystem (copy/move/rename at least)
- open files in kdevelop or external apps.

Currently only 1 and 3 are supported and frankly I don't see how you can
integrate 2 into the current few (but maybe I'm just not visionary
enough ;)

> - file manager have to be as fast as possible (load a kpart just for
> filemanager?)

Do you have any data backing that up? So far loading that kpart is by
far not the worst problem in kdevelops startup time.

> - it's wrong to have dependency on kdebase application, we already
> have konsole plugin that doesn't work without kdebase and that sucks

Which is not a problem, if you want to maintain the code in
kdevplatform/plugins/filemanager it can serve as a fallback if dolphin
is not installed.

Besides: All kde apps have a dependency on kdebase, namely
kdebase-runtime. So we add to that an optional runtime dependency on
konsole and dolphin. And we can easily control those two, as opposed to
all the external deps we have which give me a much larger headache.

> If we want to reuse code, let's just copy filemanager from kate like
> we did for KDevelop3.

That doesn't solve anything, we still have to maintain that. The reason
for using something that already exists is not having to maintain it
ourselves. We're already too few people trying to work on too much code,
so lets reduce the amount of code we have to work on if we can.

Andreas

-- 
You're being followed.  Cut out the hanky-panky for a few days.