[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: popup menus
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-04-11 19:33:46
[Download RAW message or body]


Ok, well, we already discussed this on #kde, but here I can reply a little
more detailed about what I think about the popup menus.

On Sun, 11 Apr 1999, David Faure wrote:

> I'm thinking a lot about the popup menus right now.
> 
> First, I was wrong about the "it's object-oriented, let's handle them in Konq*View."
> It's wrong, because we want the same popup menus if we are in a tree view,
> an icon view, and on the desktop.
> 
> This last point, the fact that kdesktop needs them too, would make me put
> them in libkio. Not only the menus (this is quote nothing), but the
> functionalities that come with it :
> 
> * open with, properties, open with a service (all this is already in libkio)
> * cut, copy, delete, send to trash (to be put there too)
> * paste (is already there and not used, kio_paste)
> * 'New' submenu (moving and renaming kfmpopup.*)

Ok, these four entries should be easy with libkio's capabilites.

> * New view (already there)

Perhaps "New view" makes only sense in a Konqueror View/Window, I'm not
sure about this. (new view in kdesktop?)

> * empty trash (todo ?)

I think this is also a libkio thing. Maybe it's sufficient to compare the
related url with UserPaths::trashPath() and the create an KIOJob for this.

> * up, back, forward : this is konqy specific. Will remain in konqy (adding
> items to the popup menu after it has been created by libkio)
> * add bookmark (should be easy, create KBookmark, or konqy-only as well)
> * save local properties (konqy specific as well)
> 
> ok, I think I got it all :)

Perhaps one additional entry:
In case of http/ftp/other_protocols?perhaps_smb? I'd like to see a "save
document/url/or_whatever_it_is" ("save as...") entry.

But when this is in libkio it requires that either
a) the data is available via the ioslaves
or
b) the popupmenu-caller handles this (the transfer)

I like b) more. Perhaps we could just "tell" the caller "Hey, there will
be a save-as entry in the menu, make sure you can handle this" and the
caller can accept/reject the creation of the menu entry?

( b) would also enable us to use Caitoo for the transfer in Konqueror)

> This looks really nice, BUT (there is always a "but") :
> 
> For konqueror views to be embedded somewhere else (e.g. in kohtml)
> doesn't the popup menu need to be an OPMenu ???
> In that case, all the functionalities above can go in libkio, but NOT the
> popup menu creation itself !
> 
> Or is it ok if we use normal (Qt) popup menus ?
> I'm not sure if/why we need OPMenus for that.

as already discussed on irc:

Let the caller create (allocate) the menu, then pass it over to
libkio. If we make libkio only handle QPopupMenu's we solve two problems
in one:

a) libkio does not depend on libkparts
b) the caller can decide what he/she wants to do. He/She can for example
create an OPMenu (->derived from QPopupMenu) , use the CORBA interface to
give other CORBA objects the capability to modify the menu, and then pass
it over to libkio.


Ciao,
 Simon
 
> Thanks for fast answer !
> I implement this as soon as I know about it :)
> 
> -- 
> David FAURE
> david.faure@insa-lyon.fr, faure@kde.org
> http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
> KDE, Making The Future of Computing Available Today
> 

[prev in list] [next in list] [prev in thread] [next in thread]