Konqueror delete unification

David Hugh-Jones hughjonesd at yahoo.co.uk
Mon Jul 14 11:36:45 BST 2003


On Sun, 2003-07-13 at 18:17, Leo Savernik wrote:
> I mostly delete local files, but sometimes decide to trash them, all 
> accessible by rmb. Is it possible to retain that behaviour with the new 
> implementation, i. e. local files default to delete in the contextmenu? As 
> far as I interpret your description, the answer is yes. However, will there 
> still appear a confirmation dialog showing the files to be deleted?

The context menu will do the default delete action. You can override it
- well, will be able to override it once the code works :-) - with a
keyboard shortcut.

There will be a confirmation dialog if you want one (and by default). If
you set your default action to trash, and then do a forced delete, there
will always be a confirmation dialog. This is to prevent people
accidentally doing an unconfirmed delete when they thought they were
doing an unconfirmed trash. (The alternative would be to make the "force
delete" shortcut hard to do accidentally - e.g. Ctrl+Shift+Delete. This
might be preferable, actually.)

> >
> > konq_dirpart. BUT: this never seems to get called. The functions are
> > static: am I misunderstanding how C++ inheritance works?
> 
> Only virtual functions are called. But static functions cannot be virtual. So 
> it won't work out for you.
> >
> [...]
> > (There is also one other thing the patch does - removes the "go to weird
> > ass places" options from the Go menu. See the XML usability report for
> > why. This just sort of got bundled.)
> Erm, I use these occasionally. By which equivalent functionality are they to 
> be replaced?


Well, for the moment, just delete the relevant chunk of the
konq_mainwindow.cc patch - like I said, these were bundled by accident.

But, I think these Go menu items are completely useless and indeed
incomprehensible to 99% of users, and I hereby give you full warning
that I am going to do my damnedest to get rid of them! See the konqueror
usability report for more details.

Dave







More information about the kfm-devel mailing list