Dolphin plugin for ownCloud

Frank Reininghaus frank78ac at googlemail.com
Tue Nov 6 06:21:05 GMT 2012


Hi Dominik,

2012/11/5 Dominik Schmidt:
> On 05.11.2012 16:23, Frank Reininghaus wrote:
>> I haven't worked on any plugins myself either yet, but I'm afraid that
>> two different plugins will be necessary indeed.
>
> urgh, that's pretty shitty UX wise :-\

well, yes, it seems that the current plugin architecture has not
exactly been designed for your use case :-(

>>> Bummer once again. If I go for implementing it myself, would there be any
>>> interest to take it upstream? (good code assumed ofc) :)
>>
>>
>> I don't know if it's actually up to me to decide this because
>> KVersionControlPlugin2 isn't even part of Dolphin...
>>
>> Do you mean that you would add a way to replace the currently used
>> icons for the different ItemVersions? Or rather add new ItemVersions?
>
>
> I mean to create a new interface, which is more powerful: allows setting
> icon overlays everywhere, allow context menu creation everywhere like
> KAbstractFileItemActionPlugin.. (and the KVersionControlPlugin could be made
> a subclass maybe) dunno how performant that can be done.. it would be part
> of libkonq, no? Then this is still the right list to discuss, isn't it?

You cannot make KVersionControlPlugin a subclass of anything else in
KDE 4.x, that's probably not binary compatible.

lib/konq might be a good place for any kind of new plugin base class,
that would also enable Plasma's FolderView to use it. Not the
"Open/Save File" dialogs though - for them, it might be required to
have the plugin in kdelibs, just like KAbstractFileItemPlugin. OTOH,
kdelibs is in some kind of feature-frozen state AFAIK.

This mailing list is probably the right place to discuss this, but I
would prefer not to be the only one giving advice and taking
decisions. I never had anything to do with plugins, so I don't have
much knowledge in that area at the moment.

Best regards,
Frank




More information about the kfm-devel mailing list