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