Version: 3.0.0a5 (using KDE 3.1.3) Installed from: Gentoo Compiler: gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice) OS: Linux (i686) release 2.4.20-gentoo-r6 A feature to reorder editor tabs would be of great help. Thanks Nachiketa
hmm, that is no kate problem ;)
Implementing this wish from a5 would be still appreciated in b2 !
I'm writing a patch to enable drag & drop of the tabs, I'll post it when it's tested.
Created attachment 3785 [details] Patch that allows drag & drop of editor tabs
The patch works, however after reordering the tabs the shortcuts Alt+Left/Right does no longer follow the order of the tabs, I guess the pages themselves must be reordered in some internal list (or the shortcuts should use the ordering of the tabs). The patch uses the function movePage() (which I didn't make), so it's good in it self, but the function might be missing something.
If the Alt+Left/Right problem could be fixed, and the patch added to official kdevelop this would be very useful...
I think KDevelop is in feature freeze for the time being. That's probably why the patch havn't been included.
Will this be included in future releases?
This really should be implemented in kdelibs to allow tab reordering in every app that uses tabs. This would be very useful in konqueror, too. At the moment when trying to reorder tabs in konqueror, the tab is duplicated (the second tab to which the first one is dragged opens the same URL as the first one), which is not the behaviour that I expected. If you drag a tab in konqueror to an empty space in the tab widget, then a duplicated tab is created, which is sufficient I think. So the reordering could be done when one tab is dragged to another.
Ack, I hope my patch havn't been in vain :-/
Do you know that you can reorder the tabs in Konqueror, Konsole, Quanta (and maybe others) by dragging the tabs with the middle mouse? The functionality is already present, just that it's not enabled in KDevelop... It's a simple "tabWidget()->setTabReorderingEnabled(true)" call in the main window inheriting from KMdiMainFrm. Of course, check that tabWidget() is not NULL (might happen in some MDI modes I think).
Mantias Andras: Thanks for the info ! Anyway, I think that as Thorben does: tab reordering feature should be available by default in every app tat use tabs =). The actual way that konqueror, konsole, quanta... is not that obvious - for example, I didn't know it's existance till you mentioned it, and I feel that many others are in the same situation. IMHO, usual drag and drop as Simon implemented with his patch is more natural.
Maybe it was not clear, but the current implementation makes it possible to every application using KTabWidget (which is in kdelibs) to enable tab reordering. It just isn't enabled by default. The problem with the patch is that it's KDevelop dependent, while the implementation in KTabWidget works for every other application. I also see a possibility to drag by accident if the dragging is done with the left mouse button. Here is a quote from the API documentation: "void KTabWidget::setTabReorderingEnabled(bool enable) [slot] If enable is true, tab reordering with middle button will be enabled."
Don't forget this important part: " Note that once enabled you shouldn't rely on previously queried currentPageIndex() or indexOf( QWidget * ) values anymore. You can connect to signal movedTab(int, int) which will notify you from which index to which index a tab has been moved."
Mantia Andras: > I also see a possibility to drag by accident if the dragging is done with the left mouse button Actually, this wouldn't be a problem but a way to discover the feature! if someone unintentionally moves one tab to another no side effect would occur. He/She simply would realise how to reorder tabs :-). Moreover, I don't think that someone could execute that action unintentionally: it's not very normal to right click in one tab, and keep the mouse button pressed while moving the cursor. The only problem I can see appears in konqueror. And it's that such action is already being used for drag&drop tabs with a different behaviour: - If you drop the tab into another, then the URI of the tab you dragged would be shown in the tab where you dropped it. - If you drop it in a blank space, a new background tab will appear there with the URI of the tab you dragged. - If you keep the mouse while dragging in another tab, that tab will be shown. Personally I think that reordering should work dragging with the left mouse, because the behaviour described is the same as dragging the URI directly from the URI toolbar =). What's more, the problem appears only in konqueror. The konqueror's drag&drop instead of reordering would just not fit all the uses of tabs: in kopete or konsole or even kdevelop the reordering behaviour would be the best and probably the only comprehensible option. I think that it should be activated by default ;-).
CVS commit by dymo: Ok, ok, it's really simple ;) Implemented tab reordering feature. CCMAIL: 63328-done@bugs.kde.org M +9 -0 newmainwindow.cpp 1.18 M +1 -0 newmainwindow.h 1.5 --- kdevelop/src/newmainwindow.cpp #1.17:1.18 @@ -207,4 +207,6 @@ void NewMainWindow::init() { tabWidget()->setCornerWidget(but, TopRight); } + tabWidget()->setTabReorderingEnabled(true); + connect(tabWidget(), SIGNAL(movedTab(int, int)), this, SLOT(tabMoved(int, int))); } } @@ -667,3 +669,10 @@ void NewMainWindow::documentChangedState } +void NewMainWindow::tabMoved( int from, int to ) +{ + KMdiChildView *view = m_pDocumentViews->at(from); + m_pDocumentViews->remove(from); + m_pDocumentViews->insert(to, view); +} + #include "newmainwindow.moc" --- kdevelop/src/newmainwindow.h #1.4:1.5 @@ -94,4 +94,5 @@ private slots: void fillWindowMenu(); void openURL( int ); + void tabMoved(int from, int to); // void loadMDISettings();
What of FIXED is this status? It is 2.5 years later than the last post and I cannot still reorder tabs (3.9.93, IDEAL simpl.). Could someone please reopen this report -- it is unfortunately still valid.
On Wednesday 13 December 2006 10:42, Maciej Pilichowski wrote: [bugs.kde.org quoted mail] because at that time there was not simple IDEAL mode and the reordering works for IDEAL... BTW, you can reopen it as well, if you want. Andras
> because at that time there was not simple IDEAL mode and the reordering > works for IDEAL... It would be good to stick to only one mode after all and to maintain it. Now I am told that IDEAL simpl. is the "standard" so I switch from IDEAL to simplified, but again that was not "standard" before... > BTW, you can reopen it as well, if you want. I can't. This is not my report.
> because at that time there was not simple IDEAL mode and the reordering > works for IDEAL... It would be good to stick to only one mode after all and to maintain it. Now I am told that IDEAL simpl. is the "standard" so I switch from IDEAL to simplified, but again that was not "standard" before... Well, time changes things. IDEAl is still there, you can use it if you want, however there are bugs that we can't fix. Simple IDEAl has none of those bugs, however it does have a couple of features missing in comparison to KMDI-IDEAl. Luckily Repositioning of toolviews between the 3 docking areas will soon become reality, the patch for that exists already it just need to be reviewed. If thats what your after: It'll hopefully make it into rc2 to be tagged this friday at the latest. Andreas
Ok, I don't understand the last few comments. Editor tab reordering has been working for ages in SimpleIdeal with the same 3rd button mouse drag as with KMDI Ideal.
Alexander, drag&drop with 3rd mouse button? a) it is not standard -- LMB is b) not everybody has three buttons and emulation does not solve this
It's not drag and drop but just drag and you can use the keyboard with (in my case) alt+shift+left or alt+shift+right