in-place-editing patch for konqueror bookmarks

Oelewapperke oelewapperke at
Fri Jan 17 17:38:00 GMT 2003

Hash: SHA1

On Friday 17 January 2003 11:02, David Faure wrote:
> On Thursday 16 January 2003 23:02, Oelewapperke wrote:
> > On Thursday 16 January 2003 18:07, David Faure wrote:
> > > Please reconsider this. You rewrote a complete bookmarkbar
> > > implementation just to change the menus! There is much duplicated code
> > > in your patch, which I'm strongly against. This will become a
> > > maintainance hell.
> >
> > This is not true, check the code, I changed both the buttons and the
> > menus (and as far as I can see I need to do that)
> Ok, the KIPEToolBarButton indeed adds MMB/RMB to the buttons.
> But why a brand new KIPEBookmarkBar? Why not integrate this with
> the original bookmarkbar? We don't need to have two of them...

because the class delivers events, something which can not be done with only a 
KBookmarkOwner, I need a KIPEBookmarkOwner for that.

> > > All you need is to pass KBookmarkMenu your own popupmenu class,
> > > and this will work both for the bookmarkbar and for the toplevel
> > > bookmarks menu. I can do the KActionMenu part of the work if you agree
> > > to rework the rest around it.
> > > Thanks.
> >
> > it will not provide the same options on the buttons if I do it like this.
> To implement MMB and RMB on buttons I suggest adding a new signal to
> KToolbarButton. An _integrated_ solution is much better than one which
> reimplements many things. This will allow other applications or other
> toolbar buttons in Konqueror to react upon MMB (like "MMB on Back opens
> previous URL in new window", "MMB on Home opens Home in a new window" etc.)

It would hardly save any code in that class, but I could move it upstream 
anyway. I only fear that would break bc, and I would like this to go into kde 
3.2 (3.1 even, but I guess it's too late)

Version: GnuPG v1.2.1 (GNU/Linux)


More information about the kde-core-devel mailing list