Archived Beta Discussions > SlickEdit 2013 v18 beta

MDI buffers and windows and tab groups, oh my

<< < (2/2)

I've added next_tab_group and prev_tab_group commands which is similar to your window_next command. Currently they only switch groups in the current mdi window. When I have more time, I'll have them cycle through other all MDI windows.

I'm trying to figure out if I can use one-file-per-window with tab groups. I would like to, since it is nice having a tab for each open file, but there is still one fly in the ointment: There is no way using the keyboard to switch between tab groups while preserving the active tab in each group.

I like to have one pane visible for each file I am actively working on at the moment (e.g. source & header, or caller/callee), but I have other files open that I have visited recently and might want to refer to again. In v17 and before, I used multiple-files-share-window, with one MDI window per active file (always tiled), and I could use next-window and prev-window to easily switch between the panes, allowing me to jump quickly between files I'm actively working on. If I needed to visit one of the other files not currently visible, I used the "List open files..." dialog (bound to a key) to select and show it in the current pane.

What I would like to do in v18 is have one pane/tab group for each file I'm actively working on, and have other recently visited files in tabs that are not currently active/visible. Then I can easily find, move and activate them using the tabs. However, there does not currently appear to be a way to quickly switch between the tab groups from the keyboard while preserving the active tab in each group. As described by Clark in another thread (,9130.msg39345.html#msg39345) :

--- Quote ---next_tab_group doesn't maintain the active tab of the tab group it switches to. It switches to the first tab (left most tab) in the next group. prev_tab_group switches to the last tab (right most tab).

--- End quote ---

I find that using next-tab-group does not always activate the first tab in the group, sometimes it activates the last one, but either way it is annoying, because what I always want to do when switching between groups is switch to the previously active tab in the next/previous group. I do this switching between panes constantly, and it drives me nuts when the file I've been working on is hidden because it activates a tab that I don't need right now. So I would really like to see the idea that Clark proposed in that other thread implemented:

--- Quote ---Maybe there should be two sets of commands. Maybe we need additional commands maybe called next_tab_group_active_tab and prev_tab_group_active_tab which do what you want. I don't think there is a way to do this from Slick-C right now but the C++ code has the functionality.

--- End quote ---

Until this functionality is provided, I'll have to go back to multiple-files-share-window mode and miss out on the convenience of using the tabs.


--- Quote from: Matthew on May 22, 2013, 04:18:18 pm ---If you really like using the "files share one window" mode (and a lot of folks do, including 50% of our dev team :-) ), then continue using it and dock the File Tabs tool window.

--- End quote ---

The big problem I have with this is that the file tabs toolbar is dog ugly when compared to the MDI tab groups. Any chance you can fix this?

For 18.0.1, I changed next_tab_group and prev_tab_group to preserve the active tab. I don't think it makes sense for them to do anything else. The previous implementation wasn't inconsistent with which tab was activated.

Thanks for doing this, I look forward to trying it out.

It's moot now, but I did see a case where the last (right-most) tab was activated in one group when I used next-tab-group to switch focus. Maybe it is affected by the tab ordering preference (I had mine set to alphabetical). I just using next-tab-group to cycle repeatedly through three groups with the tab sort order set to "most recently viewed" and in one group with three tabs I got a different one activated each time I landed on that group - a bit mysterious, but not worth pursuing.


[0] Message Index

[*] Previous page

Go to full version