Version: 4.0 (using KDE 3.1.9) Compiler: gcc version 3.3.2 20030831 (Debian prerelease) OS: Linux (i686) release 2.4.21 It seems with my lates update of kde (orths debs cvs20030901) that on the menu that opens when you right click on a link, the "open in background tab" item has gone. That feature was really really cool and I'd really love to see it back. Thanks
Stephan Binner removed it. Konqi now checks your tab settings to see it should open tab in background.
CC'ing Stephan Binner.
Stephan Binner doesn't need to be CCed and doesn't see this as bug because it was done intentional to reduce context menu bloat.
Sorry for spam Stephan. I knew this was intentional just thought you would be the one to tell the reason for this change. /cartman
Well, You say "it was done intentional [sic] to reduce context bloat".. That doesn't really make much sense to me. I see 'context bloat' as stuff thats anoying, dirty and doesn't make much sense.. Like all the 'copy link location', 'save link as', 'copy to' etc. And then you also have all the normal document context menu items on a link context menu (up, back, view docu source, view docu info etc). Really, if you want the link context menu to be cleaned, remove that stuff - don't remove really functional stuff from it! (And as an aside, I don't think the config option is adaquate, I often use both 'open in background tab' and 'open in new tab' - I find it one of the absolutely killer features that konq has over mozilla). David
Stephan and Konq developers, please bring this feature back! I agree with Dave that this is an absolutely killer feature, because you don't always just want one setting. I don't agree with ripping it out: there are far better things to go for (e.g, K3b, CDBakeOven, whatever), than this. To quote David Woodhouse: "I do wonder just how far we should be taking the usability crusade though. What's next? People turning up on my doorstep, observing that the lack of doorbell is likely to confuse people and hence removing my front door?" Please, I urge you to return this feature!
"Copy To" ,"Open With" entries are very useless too and "Actions" entry on CVS HEAD.
*** Bug 71337 has been marked as a duplicate of this bug. ***
*** Bug 72961 has been marked as a duplicate of this bug. ***
I find the disappearance of that feature from 3.2.0 so annoying that I'm seriously considering downgrading back to 3.1.4... Please, bring it back!!!
Please, please bring it back, or make 'open in new tab' open in a background tab like FireFox does. Its annoying as hell not being able to open in background!
> or make 'open in new tab' open in a background tab like FireFox does. It's configurable.
> It's configurable. Thats already known and fine. But whats wanted by many is an on-the-fly option like in kde-3.1.x. Users should not have to pull up the entire kde control center/module and change configuration to just to open a tab one way or the other. 7 clicks is worse than 2 clicks. It gets even worse when users used to 2 clicks have to switch to 7 clicks.
I understand the point about kontext menu bloat. Still, I was rather shocked to find out this feature got removed. As others have pointed out, the cool thing about it was that you could select either behavior (background or foreground) on the fly. Sometimes I want the new tab in the foreground, sometimes (esp. if I suspect it will be a slow-loading page) I want it in the background. It may not be the world, but it's not one of those "nobody needs that anyway" features, either. Now, as an attempt to make everybody happy: Would it be possible to have configurable context-menus much like toolbars already are configurable? This way everybody could add/remove the stuff they (don't) need and get just the level of "bloat" they like. Of course since the whole point of context menus is to be context sensitive, this would be somewhat more tricky than configuring toolbars. Still I think it might be worth a try. Should I try to elaborate this idea?
*** Bug 77160 has been marked as a duplicate of this bug. ***
I think this is the biggest usability mistake of 3.2. New users don't grasp the power of tab browsing by themselves anymore because of this feature removal. We have lost a lot of intuitivity here.
with 3.0/3.1 there was the possibility to open links in a new (tab) window - middle mouse button: new window in the foreground - shift (or was it ctrl?) + middle mouse button: new window in the background with 3.2 the second possibility is gone ;-(( it is just always in the foreground or always in the background - but no selection via modifier key why isn't there a "configure mouse actions" like it is possible for keyboard shortcuts?
> New users don't grasp the power of tab browsing by themselves anymore because of this feature removal. What are you talking about? Opening tabs in background? That's default in KDE 3.2.
> What are you talking about? Opening tabs in background? That's default in KDE 3.2. I think you should read comment 17. Its the "on-the-fly" choice between opening in background or foreground tab that is the core of this bug report.
Comment 17 is bogus, it talks about windows and not tabs. And the as broken mentioned Shift+middle click for background window works with KDE 3.2[.1].
ok, maybe #17 was not clearly expressed (actually it was another bug which was marked as a duplicate of this one): it works for open in new windows, but it doesn't work for tabs - with tabs there is no on the fly choice between foregrund/background and there are reasons to switch between these do...
Comment 17 said "...there was the possibility to open links in a new (tab) window" so I thought it mentioned "tab". In any case, this bug is about opening tabs in background/foreground on-the-fly.
CVS commit by binner: Pressing Shift when selecting "Open in New Tab" in context menu now reverses "Open new tabs in background" setting. Please drop your votes *NOW*! :-) CCMAIL: 63706@bugs.kde.org M +3 -0 konq_mainwindow.cc 1.1274.2.16 --- kdebase/konqueror/konq_mainwindow.cc #1.1274.2.15:1.1274.2.16 @@ -2350,4 +2350,7 @@ void KonqMainWindow::slotPopupNewTab() bool newTabsInFront = config->readBoolEntry( "NewTabsInFront", false ); + if (KApplication::keyboardModifiers() & KApplication::ShiftModifier) + newTabsInFront = !newTabsInFront; + popupNewTab(newTabsInFront, openAfterCurrentPage); }
On Wed, Mar 31, 2004 at 09:42:18AM -0000, Stephan Binner wrote: > Pressing Shift when selecting "Open in New Tab" in context menu now reverses > "Open new tabs in background" setting. Please drop your votes *NOW*! :-) Dropped.
Pressing Shift for inversing the "Open new tab in background" setting now also works when opening a new tab with Ctrl+left mouse button (in general a context menu entry is far too slow for opening tabs IMO).
Comment #25 is good if this is documented somewhere. I was very disappointed when I saw "Open new tab in background" disappeared. Other possibility : use a cascaded menu Open in new tab ->In foreground ->In background
For the sake of one line in one menu, this is a really stupid reduction in Konqui's usability. Despite others' suggestions here, I cannot find any combination of shift or control clicking on any button to let me choose foreground or background tab at opening time. Now there is no way at all to choose whether to open a tab in the foreground or background, except by changing kcontrol. My vote is added.
So the option gets added back, but not as a choice in the menu. What is the obsession with removing useful entries? How about dropping 'burn with k3b' from html pages' context menu? Keyboard modifier is better than no option at all (thanks for it, really), but I'd still rather see a seperate menu option. I don't like having to reach over to the keyboard while idly browsing. Might as well drop copy and paste from right click menu as well since ctl-c and ctl-z work just as well..
playing with 3.2 some more, one more comment Having only one (menu) choice leads to inconsistency. I usually want tabs to open in the background, so I set them to do so. The problem arises then when I LEFT click on a javascript open new window link. For example at http://kde-apps.org/content/show.php?content=9715 click on the thumbnail. If "Open links in new tab instead of new window" is not clicked, it opens in a new *foreground* window. If "Open links in new tab ..." is checked, it opens in a new *background* tab. Surely this is not consistent. When I LEFT click a link I want to be taken there, not have it open in the background somewhere. Again, you succeeded in removing one entry from the konqueror right click menu. The Gnome people must be laughing though because it forced you to add another option in the configuration screen. Why must Konqueror be the only tabbed browser without the ability to choose between background and foreground with the click of the mouse? (shift button helps, but still forces keyboard usage and doesn't fix the inconsistency mentioned above)
> Pressing Shift when selecting "Open in New Tab" in context menu now reverses "Open new tabs in background" setting. Well this might "fix" one problem/bug, but another one arrises :( Before this commit I could open a link with Shift-Enter (now that konqueror supports type-ahead find, browsing with the keyboard is really fun :), in a background tab (as I set this preference in the control center). Now, I get a new tab, but in _foreground_. Therefore I would vote, for _one_ of these modifiers from control to shift, so that I can open links in a background tabs with the keyboard only. Is this the right place to mention this bug, or should I add a new bug entry (someone from kopete told me, that CVS bugs should not go in bugzilla)?
Please add a new bug report.
Implementing user configurable context-menus (Wish #66119) could resolve this issue ... giving the user choice without the bloat ...
I think implementing that report: https://bugs.kde.org/show_bug.cgi?id=133718 would solve this one too, in much nicer manner then suggested here (however, I didn't read all comments thoroughly).