Version: 3.1.2 (using KDE KDE 3.1.2) Installed from: SuSE RPMs OS: Linux Tabs should be easily ordered using drag and drop like in Opera 7.1. This includes being able to drag and drop a tab to another Konqueror window's tab area. It also means that if a tab is dragged onto a Konqueror window that tab's contents will be displayed in that window. Of course like in Opera 2 arrows pointing up and down appear when placing a tab in between others.
This should also include "You should be able to drag and drop tabs in the following ways. Draging a tab off of the tab bar should detatch the tab. Dragging a tab onto another tab should nest the tab. Draging a tab onto another window should move that tab to that window. Draging a window onto the tab bar should turn the window into a tab and possibly a few more permutations. " http://bugs.kde.org/show_bug.cgi?id=47574
> Dragging a tab onto another tab should nest the tab. nested tabs? Is that a good idea?
I'm not completely sure if it not be too much trouble to implement nested tabs. but, i think the rest is very good stuff. Well anyway, we will leave that for later, now what do you think of the rest?
The problem with moving tabs between windows is that sometimes that involves a lot more of code than others: the case in which you move tabs between processes. When you move a tab from a window to another window of the same process, all it takes is telling what window something should appear in. The second case is not possible because we don't share data between processes. So, it would be much like a drag-and-drop: the first Konqueror would delete the tab and the second would create a new one at the selected site. Troubles: keeping history, not reloading the site.
Are you sure this is not possible, this would be a great feature to have, and I'm sure many want it. If my tab suggestions could be done, KDE would be the first desktop with full tab support. Anyway, is this possible at least:http://bugs.kde.org/show_bug.cgi?id=59790 This has to be possible, tabs would be twice as useful if this was possible and it already is possible in borwsers like Opera and mozilla. And this is proabbly possible too: http://bugs.kde.org/show_bug.cgi?id=59788 since its possible in mozilla and Opera.
I agree with you. And I'm not saying it's impossible. I'm just saying that some of the things you are asking for are more difficult to implement than they seem, so it might be quite some time before they are fully implemented. For instance, konsole already supports this: you can detach sessions from the main konsole window and reattach them -- but only to the same window.
I guess this wish won't be fully realizable until kwin offers global MDI support to all KDE apps.
Bug 47574 seems to suggest some additional behavior. i'd really like to have the opera behavior in konqi. an additional feature that would be great: shift-click = open link in new tab!
#8: You can already do ctrl+click for opening a link in a new tab. And when you activate "open links in new tab instead of in new window" in "settings" > "configure konqueror..." > "behavior" then you can even use the middle mouse button for that purpose.
*** Bug 47574 has been marked as a duplicate of this bug. ***
*** Bug 56599 has been marked as a duplicate of this bug. ***
I should clear something up. I meant that a tab should be able to be dnd to anoter konqueror window which would create a new tab with the contents of the dragged tab. THe new tab should automatically be activated. and some additional behaviours from duplicates: Draging a tab off of the tab bar should detatch the tab, if the user holds the right mouse button he can move the detached tab to another konqueror window etc. if he lets go it becomes another konqueror window with the tabs' contents.
*** Bug 69232 has been marked as a duplicate of this bug. ***
Sorry for me poor english, i'll try to be understandable. We have drag'n'drop system between windows (for example i can copy/move files from one konq window to another that way). I want the same between tabs (not only in the same window). example of what i want: i'm starting dragging file from konq window #1, drag it to bar vs other opened windows (in the bottom - i forgot its name in english), delay on it, get maximized konq window #2, drag to some tab in konq window #2, delay on it, then i get it displayed, then i finally drop the file
Is it just be, or does this feature work in KDE 3.2?
No, this has been disabled for some reason in KDE 3.2. It doesn't work here either.
*** Bug 94484 has been marked as a duplicate of this bug. ***
*** Bug 94297 has been marked as a duplicate of this bug. ***
As nothing seems to have been done about this and this one is easy to fix just time consuming. First make kparts seriaizable. Then when the drag operation occurs serialise the kpart to the clipboard. Then use standard drag and drop to move the serialised data between windows or to the desktop or wherever. Some shared memory mechanism may be needed if the kpart contains large objects, but that's just a performance optimisation. The main problem would appear to be a lack of support for serialisation and reflection by QT. http://www.cs.queensu.ca/home/dalamb/qt/local/datastreamformat.html
Is this feature planned for the next versions of KDE?
*** Bug 143761 has been marked as a duplicate of this bug. ***
I've voted for this as well. This would be infinitely useful for reasons stated previously. I want to see a developer's view of this, though...
Currently, in 3.5.x, Konqueror tabs are dragable. You can also drag some types of Konqueror content to make a tab. So, if there is an issue is that the only choice is 'Copy'. It appears to me that it would be nice if you could also do a 'Move'. So, do you think that I should revise this bug to ask for the 'Move' option, or should we close it as fixed?
> Currently, in 3.5.x, Konqueror tabs are dragable. In the same window, yes. But not between different windows, either belonging to the same process or to different ones: in this case, "drag" is just creating a normal dragging with the URL of the tab, and then a drop that loads -again- the URL. That means you lose history, and more important the GET/POST metadata of the page. > So, if there is an issue is that the only choice is 'Copy'. No. > So, do you think that I should revise this bug to ask for the 'Move' option, or > should we close it as fixed? I do think you should leave this report as it is now.
I believe dragging right now only handles the URL, and ignores things such as scrolls, form content, POST results, etc.
Qt-4.5 brings us a nicer solution for reordering tabs etc. (this is in trunk right now, will be in KDE-4.3). However comments 25 and 26 are right, additional metadata is not carried over right now. I could work on this, since this wish is so highly-voted (although I guess it wasn't voted for this reason, but for dnd support in the first place...). Do you have a testcase showing the missing POST data?
An alternative could be to shift tab-management from the application to the window-manager, as KWin now supports tabbing, and to use application-tab-management as a fallback when running a non-KWin/non-KDE environment. As all standard tab-management features (including those this bug is for) are supported in KWin, this could, "fix" the bug while also saving vertical space by removing the need for an in-app tab-bar.
I believe this is a really bad idea. I have deactivated Kwin-tabbing. I tried it, but it is not really usefull having the tabs on top. This is like in Chrome and I do not know why anyone thinks this is good idea.