Trash, Delete, Shred - BrowserExtension problems?
David Hugh-Jones
hughjonesd at yahoo.co.uk
Tue Jul 1 06:50:08 BST 2003
On Mon, 2003-06-30 at 21:29, David Faure wrote:
> On Monday 30 June 2003 16:44, David Hugh-Jones wrote:
> >
> > OK, so I have written some code and removed all references to "shred",
> > and added some actions "forcedel" and "forcetrash".
>
> I thought I had followed the thread, but those 2 new actions surprise me.
> Do you really want to define new actions, or to change the meaning
> of the existing ones? Can you summarize for me what those actions will do?
No problem. This was just the way I decided to implement it, but I could
be completely off base:
Make the "delete" action use a new KonqOperations constant
KonqOperations::DEFAULT
Make a "forcedel" action which does KonqOperations::DEL
and a "forcetrash" action which does KonqOperations::TRASH
[ remove the shred action entirely]
The KonqOperations module figures out what DEFAULT means, and act
accordingly.
I did consider doing it differently, by keeping the "del" and "trash"
actions, and dynamically choosing which gets displayed and linked with
the main delete shortcut. My reasons against this were: it seemed rather
complex to do this for all the different views; and on a philosophical
level, it seemed better not to just have a facade over two separate
actions, but accept that there really is a "default delete action" which
the user defines to work in a particular way. One action, with two
possible underlying operations. (On the subject of naming, I have a
compromise whereby the name is always shown as "delete", but the icon is
dynamically chosen to be "trash" or "delete". I figured that having the
action name constantly changing e.g. for users who have "delete remote,
trash local" would be confusing.)
>
> > My problem is that the old actions are still defined, and the new ones
> > undefined, in KParts::BrowserExtension, which is used by konqueror
> > directly. I could edit the browserextension to understand the new
> > actions... but is that not going to break kdelibs binary compatibility?
>
> As you can see the existing actions are only comments in that file....
> You can add the slots with the correct names directly to the iconview's
> and the listview's BrowserExtensions.
>
OK, now I've found the browserextensions, I can probably override this
stuff by redefining createActionSlotMap in some appropriate subclass
(konq_dirpart I think). Actually, if I am clever, I will try and make
the kdelibs BrowserExtension more agnostic about what slots it expects
to have, without breaking binary compat.
Thanks for your help.
Dave
More information about the kfm-devel
mailing list