simple bars 
I'm not sure that clarifies anything...
Can you look at where this conversation has gone and confirm or deny if it's in line with what you were looking for with this request? I.e. what part of the ribbon UI style do you think could be added to Opus and to what benefit / use-case?
I just want to point out that this screenshot (right half) is just what I was talking about with a TabToolbar idea. Still a toolbar, just a different kind. And not a full blown Ribbon. You can still place it anywhere you want along with other toolbars. 
+1
You can already do something very similar to that using the toolbar commands earlier in the thread.
...yeah - I'm mostly with Leo here if we're debating between being able to use a series of commands VS this specific new kind of "TabToolbar" idea. I just don't see it being necessary at all - given the customization capabilities in Opus. It'd be even more work for GPSoft to implement, and not provide any of the other tangential benefits that would be useful in other scenarios. I'm still going to call out my feeling though that the main shortcoming I see with Opus current toolbar design is the rigid separation between global and local toolbar states.
Here's a brief video example of what you can do NOW... with the drawback being that you can't actually swap the local toolbars into a global toolbars space. I'm "faking" it by having my normally 'globally' enabled Operations toolbar turned on only 'locally' for the purpose of the demo. Which is NOT what I would normally want to do... but which perhaps others might not have a similar aversion to. The buttons that I add to the 'Menu' bar all run variations on this command:
toolbar local close name="my.comictools"
toolbar local close name="my.difftools"
toolbar local close name="my.ebooktools"
toolbar local close name="my.movietools"
toolbar local close name="my.musictools"
toolbar local close name="my.operations"
toolbar local close name="my.pictools"
toolbar local close name="v10.drives"
toolbar local toggle name="my.operations"
Note: I thought I had posted a follow-up to this last message, but it appears that it didn't "make" it...
I had noted that - while not really trying to play devils advocate against my own belief that we don't need a specially designed new type of "TabToolbar" to do this sort of thing, so much as the ability to locally turn off global toolbars - the fact remains that using my suggested method (which I've modified below) also has the disadvantage that you don't get the visual indicator that real ribbon UI's generally provide to show which of the toolbar buttons are active. I guess that's really a distinguishing visual ~feature of an actual "TabToolbar" that you don't get by using a series of commands like I had said.
I'm using this now and I like it, where - for the RARE occasions - when I want to turn on more than one of my local toolbars (most usually one of the project based toolbars PLUS either the drives or difftools toollbars) at the same time, I cased that off using the @keydown modifier. Basically, normal button clicks turn off ALL the possible local toolbars I use in this fashion - where again - that I'd also like to be able to do with global toolbars; and Shift+Clicking the button just "adds" the toolbar to the lister.
I had also tried putting ALL of the close toolbar commands into a separate user command like Leo had suggested. But the problem with that approach is that calling that user command to always turn off ALL toolbars resulted in clicking any button like that to NOT be able to toggle the toolbar OFF on the second click. Because the user command was turning it off FIRST, the :common toggle command toggled it back I have other means like the close *this button I keep on the far right of each of these toolbars, but I really still wanted to also be able to toggle off in the same button that toggles on as well. So I put all of the close commands except the one I'm toggling on back into each button. Going back and forth between the two methods was quite a PITA because of the number of places I've got copies of these buttons (not just on my main Operations toolbar, but also copies of these toggle buttons on each of the toolbars themselves). So that "maintenance hassle" was apparent 
... but I don't expect to have to mess with that ever again .
[code]@keydown:none
toolbar local close name="my.comictools"
toolbar local close name="my.ebooktools"
toolbar local close name="my.movietools"
toolbar local close name="my.musictools"
toolbar local close name="my.pictools"
toolbar local close name="v10.drives"
@keydown:shift
@keydown:common
toolbar toggle local name="my.difftools"[/code]
...and a side benefit is that when I have one of my locals turned ON using this method, simply holding the key causes the button whose toolbar is being toggled ON to light up / highlight. So it's not a persistent highlight of the button - but it does light up when you hold down because of whats happening in the button between the Shift and Common keydown cases. I thought that was a fairly decent upshot for otherwise not havign any visual queue of which button you've got 'active'.
If you put the command to turn on the toolbar you want on the first line, the button should appear pushed-in when that toolbar is on, and normal when that toolbar is off.
Ah - thanks for that. That helps... I started a new thread to specifically debate the global / local thing... will shut up here now about it.
That makes my preferred code for these sort of buttons look like:
[code]@keydown:common
toolbar toggle local name="my.difftools"
@keydown:shift
@keydown:none
toolbar local close name="my.comictools"
toolbar local close name="my.ebooktools"
toolbar local close name="my.movietools"
toolbar local close name="my.musictools"
toolbar local close name="my.pictools"
toolbar local close name="v10.drives"[/code]
You don't need the @keydown:common at the top of the function, it's only needed if it comes after other @keydown directives .
Thanks Jon - but I've edited and re-edited these buttons so many times now I'll leave it the way it is unless it seems to cause a problem. Point well taken though!