Hi
A simple question:
Can we have tabs in more than one row? And if yes how can we do that?
Sorry, no you can't.
And is it in the future features list?
Not currently. Personally I don't think multiple rows of tabs makes for good UI (see homepage.mac.com/bradster/iarchitect/tabs.htm for some examples of this) so it would take quite some convincing for us to consider this 
I see the point and that's true but the way Dopus handles tabs they eventually are not all visible in the lister due to the number and size what is not very handy.
There are other file managers that have this (p.ex: Total Commander).
Anyway it is not a very important feature.
[quote="jon"]Not currently. Personally I don't think multiple rows of tabs makes for good UI (see homepage.mac.com/bradster/iarchitect/tabs.htm for some examples of this) so it would take quite some convincing for us to consider this [/quote]That's a fascinating reference you have provided, Jon. Thank you.
Unfortunately, they heap even greater ignominy on your chosen alternative of scrolling arrow controls, as follows:
[i]"Since the SourceSafe properties dialog provides more tabs than can be displayed in a single row, the developers elected to use a scrolling tab control. The arrow controls on the right edge of the tabs allow the user to scroll through the tab captions. Interestingly, scrolling through the tab captions does not change the current tab, it just allows the user to see those tabs that are otherwise hidden.
The notion of hiding tabs from the user has to be among the most ill-advised design strategies one could possibly conceive. The strategy forces the user to take actions (four mouse-clicks in the above illustration) just to determine which types of properties are available, and moreover, requires another four mouse-clicks to get back to the beginning after exploring the dialog. Hopefully, modifying the options on the last tab in the dialog will be a very infrequent process.
Microsoft employs this strategy in a number of its development tools, and has built methods into those tools for developers to add it to their own applications. This will undoubtedly cause the proliferation of this truly shameful design strategy, one which would never have survived even the most casual usability testing."[/i]
(My emphasis...)
I have to say, that on those occasions when I have inadvertently created too long a tab group, the need to manipulate those scrolling arrows quickly drove me back to the drawing board to re-desing my tab group. In my experience, the multiple row paradigm, while undesirable, is the lesser of two evils.
I agree, the arrows aren't perfect. There's a suggestion in the database to replace the arrows with a drop-down list, which I think would be better, so this idea may see the light of day. [Edit, much later: That's implemented now.]
Personally I think the best solution is to not open so many tabs that it becomes an issue
[Edit: Also note, that when they are talking about "hiding tabs from the user", it is in the context of a configuration dialog where the user was not responsible for adding the tabs and, quite understandably, has no idea what other tabs are present. I do think this is quite different to the situation in Opus where any tabs, even if they are hidden, were actually created by the user - I think the user can reasonably be expected to keep track of what tabs they have open. If you can't keep track of the tabs you have opened I'd have to ask why you are opening so many in the first place]
[quote="jon"]I agree, the arrows aren't perfect. There's a suggestion in the database to replace the arrows with a drop-down list, which I think would be better, so this idea may see the light of day.
Personally I think the best solution is to not open so many tabs that it becomes an issue [/quote]
I agree wholeheartedly with both of these points.
A drop-down list would be a much better idea. 
However, as soon as I see the scroll arrows, I start closing tabs, and would do so even if you did implement the drop-down list.
PS: I hasten to add that housekeeping of tabs has been greatly enhanced by your implementation of the Locked Tab (allow folder changes) feature.
THE best imo would be to implement multirow tabs, but operating logically, not like MS implementation (no row swapping, no auto-rearranging rows, equal-size tabs in some cases etc.).
Neither drop-down list nor arrows provide overview of what's in tabs.
X.
Without row swapping you end up with the situation that the active tab isn't adjacent to the object that it affects (ie, in that case you may as well use buttons, since the tab metaphor breaks down.)
And I'm sure somewhere I've seen flat buttons used instead as tabs.
Anyway, so maybe keep moving row with selected tab next to display area, but prevent 'wild' auto-reorganisation of tabs, so as to keep row contents and tab order when moving rows.
X.
In this situation (tabs "outside" the view) I usually define a shorter size to make room.
Another distinction is that Opus windows are resizeable while the Properties dialogs in the examples are not.
I like the list/menu idea, too.
Another thought: There could be a "list of tabs", for lack of a better name, that is where the tree is but lists tabs. I think that would work well for people who want lots of tabs open, but I'm not sure if that case is common enough to be worth the effort of coding up the UI.
Like Leo's idea - I keep a short tree so would have plenty of space under the tree for a Tab list...
I am also currently with bspeight as soon as the tab scroll arrows appear I start closing tabs (I don't find the tab arrows useful for managing tabs).
i'd like to chime in a vote for mouse wheel tab scrolling >.>
I have to say that I think what Leo suggested might just be a good idea, though I don't think it would be of much use if you're not using a widescreen display. I find that having two columns really is more than enough even at 1680x1050.
I do have a suggestion of my own, but it's not really related to what have been discussed so far but it does involve the tabs. What I really would like to see is the ability to prefix all folder tabs with the drive letter. The reason for this is that when I have many tabs open, I can have as many as 3-4 tabs labeled "Downloads" but they are all located on separate drives. This in addition to a tab drop-down menu (or something similar) would really make my day
It seems to me that to make that idea logically complete the tab would need to contain the entire path of what is displayed for the tab which is probably out of the question due to space considerations.
What you have suggested might help you with your particular set of folders, but what if I happened to have C:\Old\Downloads and C:\New\Downloads? Just using C: and Downloads would be just as "confusing" as the present method.
what about mouse near either end of the tabbar to initiate a scrolling action toward that direction? or maybe slide out arrows that one can hold down...
Personally I don't like tabs in a preferences or options dialog - I prefer the current DOpus style. When it comes to tabs, I think it comes down to understanding when tabs are useful and where they aren't - you just can't throw them away because of a programmer and user's implementation.
Tabs in a lister are great but when you start having so many open that they get hidden then I think it's time to stand back and ask yourself if there is a better way you, as a user, could be doing things.
It's like a tabbed web browser. Do you only use one window with tabs for every page and topic you are looking at - or do you open a new window for each topic? Personally I have a window per topic.
On a side note, as far as GUIs go, I miss the days of the automatic GUI layout engine (MUI as an example sasg.com/mui). I think there's a lot in this that is missing from modern UIs. As a programmer, I used to find it rather liberating.