Trash, Delete, Shred - BrowserExtension problems?

[David Faure]

On Tuesday 01 July 2003 07:50, David Hugh-Jones wrote:
> 
> 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

Why not do the least intrusive change, which would be to let del and trash
do what they do right now, and to add a "defaultdel" or whatever, which
calls the right one?
Besides you can't call a slot "delete", it's a C++ keyword - been there, done that :)

> [ remove the shred action entirely]
I'd suggest to at least inform pour at kde.org about it... I don't want to be 
yelled at for removing the feature he added...

> 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.
Yes that's fine.

> (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.)
Hmm, we currently send to trash even remote files? This sounds a bit useless
and broken.... We are really talking about remote == over SMB or FTP, right?
(Not like "other partition"...)

What will you do with the del and trash actions? Some people (including me)
still want to have them in the RMB, to delete some files and trash some others.
I suppose you'll add a config option (since there's no full-fledged menu editing
for the popupmenu yet). Just make sure that one can't have both the "del"
and the "defaultdel" actions at the same time, since they'll both appear
with a "Delete" label.

> > > 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. 

Huh - keep it simple. Just add a defaultdel slot in the browserextensions,
that's all you need. 

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Qtella users - stability patches at http://blackie.dk/~dfaure/qtella.html