Some file managers have this new interface,
It seems to me a better, more intuitive way to run a software,
Do you think?
If this mode replaces the current UI in DOpus, that will be the last update for me. I left Office behind and will never look back.
The ribbon is a very controversial UI, which has alienated many users.
Ribbon UIs are not customizable. Story ends here.
Even though I do believe that an all Ribbon, tab interface, would turn me away. Having another kind of Toolbar that handles tabs, would be kind of cool.
We would still have are normal Toolbars. The new TabToolbar would work like a normal Toolbar, except you have tabs, and each tab has it's own set of standard/normal Toolbars. Now, each tab can have it's own set of buttons, which could be great for projects. Like a tab for all video buttons, or one for all image buttons or project folder shortcuts, etc, etc. With a TabToolbar, you could cram in 10 normal Toolbars into the vertical space of only 2. And still do your everyday, normal Toolbars on top or below this TabToolbar.
Yes, there are other ways to do the same thing. I'm just say, adding a new TabToolbar, that works along side the normal Toolbars, wouldn't be all that bad of an idea. It would be a Toolbar that you can leave behind, ignore and never use, while others can still get the same kind of affect as the Ribbon.
My 2 cents 
The OP didn't really specifically state what aspects to the ribbon style UI that he liked - and though I was at first a bit confused by ktbcrash's use of the word "tabs" in what he was describing - I like the way he characterized his take on how such a thing could be a benefit in Opus... so, hoping that his description captures the main point of attraction that the OP was thinking of in his request, I'll continue down that path with my own few cents:
Opus currently has two high level toolbar "states" under which toolbars are enabled or disabled... those being GLOBAL and LOCAL (maybe FLOATING is a third, but I'll disregard that for now).
- 'Globally' enabled toolbars will be turned on/off in ALL open listers, as well as any new listers you open after enabling a toolbar in this way. Most of your obvious ways of turning on a toolbar do so ~globally. I.e. - via the Settings->Toolbars menu, or right clicking on any other toolbar and using the Toolbars menu displayed there.
- 'Locally' enabled toolbars will only be turned on/off in the currently active lister, and won't have any effect on any subsequently opened listers. Don't think there are any default buttons that do this in Opus, but you can create buttons, etc that use the LOCAL option for the Toolbar command to do so.
...the thing I actually like about the ribbon design, is that you can toggle through different toolbars without ADDING those toolbars to the current display, consuming more and more screen / lister real estate unless you toggle some off before you turn others on. With the current toolbar implementation in Opus though, it'd be a bit cumbersome to achieve a similar sort of one-click SWAPPING of toolbars; though it could ~sort of be done - it could be a PITA to maintain. Example:
toolbar close ANY_GLOBAL_TOOLBAR_YOU_WANT_TO_DISABLE
toolbar close local ANY_AND_ALL
toolbar close local OTHER
toolbar close local LOCALLY
toolbar close local ENABLED
toolbar close local TOOLBARS
toolbar local TOOLBAR_I_WANT_TO_ENABLE_LOCALLY
...clearly, a potential maintenance hassle - though moreso only if you frequently play with and create new toolbars - which most people probably don't do often after their initial honeymoon period of getting to know Opus. But the main disadvantage is that if you want a special purpose toolbar to 'locally' SWAP space with an already open GLOBAL toolbar, turning off that global toolbar turns it off in all other listers.
I've asked in the past for a way to only 'locally' turn off an otherwise 'globally' enabled toolbar, and this is another example where I think being able to do so would be useful. But I think a few more tweaks would be needed to make doing this seem less of a kludgey looking proposition. If you assume that the 'default' Opus toolbars like Location, Menu, and Operations are the currently enabled GLOBAL toolbars, then I could envision something like this being considered:
toolbar close local Operations
toolbar close local *local
toolbar local DESIRED_TOOLBAR
...this sort of idea would allow you to:
- switch off the default 'globally' enabled Operations toolbar only in the current lister (and maybe it's already turned off, maybe not)
- use a single toolbar command to turn off all potentially locally enabled toolbars that might be open - so as to cutout any potential maintenance hassles where you'd have to update every button ~like this when you potentially ADD new toolbars to your config
- finally - just turning on a particular toolbar you want to enable locally, which we can already do.
...so, similar to ktbcrash - this is one aspect of the ribbon UI style that I think would be useful in Opus. I'd use it!
I think most folks who have railed against the general ribbon UI style probably have 1 or 2 real gripes (and maybe both, equally):
a.) most apps that have implemented a ribbon style UI have STACKED several actions/buttons vertically, causing most ribbon style toolbars to take up a fairly large amount of vertical screen/UI real estate - probably unilaterally HATED by fans of a ~minimalist UI, and NOT an aspect of most implementations of the ribbon UI style that I feel any need for in Opus!
b.) an unfortunate side effect of various apps adopting the ribbon style but not really anything to do with the style itself - is that at the same time the app vendors also re-organized (sometimes SIGNIFICANTLY so) where various actions are in relation to other actions. I know that's part of what I found to be a real turn off when Office 2007 came out. It's easy to blame the changeover to the ribbon style for the "OMG, where did all of my frequently used actions GO" effect many of us felt in kneejerk response. But that aspect of change wasn't really specific to the general style so much as some groups in these companies feeling the need to reorganize crap based on some perceived notion of moving stuff around in a way that was supposed to be more intuitive and user-friendly to ~new users - but essentially giving longtime users a big middle finger along with a mission to go re-learn where things are now. But that's just baggage we can cut loose in an app like Opus, where things are customizable. Let's instead home in on aspects of this general shift in UI design that would be broadly useful to all as an 'optional' capability...?
I definitely agree this should be part of dopus.
I also like the value of *local,
referring to any and all locally enabled toolbars that might be open.
The above could also be used to create a kind of ad-hoc 'full-screen' mode for when you want to temporarily hide all (or most) toolbars for maximum view of the file display.
Yes, I definitely like the idea posted above by ktbcash and Steje. 
What I would like to have is a 'TabToolbar': a toolbar with tabs where I could add current toolbars as a tab (maybe Opus could add current Toolbars to this TabToolbar automatically). Clicking a tab would automatically open the toolbar below the TabToolbar and clicking another tab would replace the open toolbar by another one (Steje called this: 'one-click SWAPPING of toolbars'):
If you really want it you can make it already using the method Steje described.
FWIW (I'm not constantly changing my toolbars ): It might be an idea to add this command to Opus?
toolbar CLOSE ALLThis would make things easier to set up and one can avoid the hassle posted above by Steje:
toolbar close ANY_GLOBAL_TOOLBAR_YOU_WANT_TO_DISABLE
toolbar close local ANY_AND_ALL
toolbar close local OTHER
toolbar close local LOCALLY
toolbar close local ENABLED
toolbar close local TOOLBARS
toolbar local TOOLBAR_I_WANT_TO_ENABLE_LOCALLY
How many tooobars do you have? What's filling them up with so much stuff, that's used so often it's a pain to toggle toolbars individually? Something like that is possible but I'm trying to understand where it would be useful to lots of people.
You could have a user command that closes your list of toolbars so you only have to update one thing when you add a new toolbar.
My solution is to put a button on those toolbars which closes them, so I can click them away as soon as I'm done with them, although the only local toolbar I use often is toggled by a hotkey so I rarely use the button.
Hi Leo, I'm not using that many toolbars myself. 
I don't even need this command for myself, but I thought it could be useful to make it easier for people who want to make a Ribbon like interface with Tabs. I know / agree it can be done already, but it's quite a hassle. BTW: It might, for example, also be useful to have a Tab-toolbar to make it easier to create toolbars with short-cuts to program's / documents / favourites and to organize them in categories. For example, I still use the quite old application LaunchKaos as a program / short-cut launcher because it has a nice (skinnable) tabbed interface:
@Cris:
Checking the manual and following the pattern with regards to the TOOLBAR command,
*all would be a more appropriate value for the NAME argument, instead of ALL. We already have the value *this and hopefully *local as well.
In summary, here are the possibilites based on the above:
turn off the specified global toolbar in the current lister only
toolbar close local AGLOBALTOOLBARturn off all locally enabled toolbars in the current lister only
toolbar close local *localturn off ALL toolbars (global or otherwise) in the current lister only
toolbar close local *allThe above would simplify everything.
I have one toolbar dedicated to searching and filtering, with all three filterboxes etc.
Another dedicated to apps
Another with renaming presets
Another with collections, aliases etc.
And SEVERAL others, each with project-specific buttons
etc.
I also use a graphics tablet, many times including with dopus as well. And it is preferable to use toolbars with related functions instead of menus if I can.
- it also allows for toggling a dopus 'fullscreen' mode as described earlier, for when I want to have max view of the file display dedicated for searching/browsing directories.
General global dopus point:
All-inclusive/Dynamic arguments and values like *all, *local, BACKLIST, DRIVEBUTTONS, TABLIST etc. are welcome additions for ANY command and alwas preferable, not least because they simplify maintenance. They are adaptable, if you know what i mean.
I suspected there was some of that going on in this thread.
It's better if feature requests are left to people who actually want the feature, who can explain why they want it so we can understand their needs and evaluate possible solutions (which would include the ribbon but also many other possibilities). It also saves us from assuming that more people want something than actually do.
(arkon900's post has some good examples which make sense.)
[quote="Cris"]BTW: It might, for example, also be useful to have a Tab-toolbar to make it easier to create toolbars with short-cuts to program's / documents / favourites and to organize them in categories. For example, I still use the quite old application LaunchKaos as a program / short-cut launcher because it has a nice (skinnable) tabbed interface:
[attachment=0]LaunchKaos.jpg[/attachment][/quote]
IMO, ribbons do not make a lot of sense for that situation.
Ribbons are good when you want to use commands from a particular category repeatedly. (You select the category once and then those commands stay on screen as long as you need them.)
Ribbons are bad when you want to use just one command from a category, with the next command likely to be from another category or unlikely to be needed at all for a long time.
I mean, if I've just launched RegEdit, I probably don't want to launch it a second time or launch any of the other things in its category, so why would I want those icons taking up space on my screen? I might want to launch RegEdit a lot but none of the other System tools, while I also want to launch Photoshop a lot, so I'd rather have RegEdit and Photoshop buttons on screen all the time, and the less common things tucked away in a menu. (For example.)
When configured well, toolbars and menus can handle both cases. The ribbon is, after all, just a combination of the two, rotated 90 degrees. (Ignoring obnoxious stuff in most current ribbon implementations, like drawing into the main window titlebar & forcing the window caption to jump around depending on the active tab; completely changes the size, layout and visibility of controls when you resize the window, so you're never quite sure where anything will be or what to look for; and the lack of customisation that we previously took for granted. Those aren't inherent to the concept of a ribbon and we could avoid them.)
I forgot to add this layout would be useful when working on a small screened laptop during travel.
Wow... a fair amount of feedback, but without a recent chime-in from the OP. Along with Leo wondering if there's some bandwagon posting going on here without real desire or need ( ) I also wonder if we've gone off on a tangent NOT in line with what the OP was really asking for. Apologies if I sort of hijacked the thread... I assure you that if I did, it was only based on seeing an opportunity to suggest a method that would get the OP the kind of capability he seemed to be asking for, while bringing other side benefits for things I have LONG wanted to be able to do as well. Being able to kill several birds with one stone in my view is always a big win - and often worth some potentially tangential discussion.
What I'd say to the most recent comments is this... I ALSO don't often ADD new toolbars. Semi-constantly tweaking buttons on some existing toolbars, sure - but I think I've only actually ADDED one toolbar to my Opus config since v10 came out... MAYBE two. So, I'll admit to NOT being one of the people who might be affected by a maintenance hassle I otherwise chimed in on as being a possible detriment. Leo made a GREAT point about centralizing the potentially numerous LOCAL toolbars you'd want to accommodate in each button you'd devise like I suggested via a USER command, reducing the potential maintenance hassle I mentioned to being pretty trivial. Good call...
But the crack about maintainability was really (in my head) just an anecdotal observation along my way towards what I said I felt was the main disadvantage in current Opus toolbar design for wanting to do stuff 'like' this - that being the inability to 'locally' turn off a 'globally' enabled toolbar... arkon900 then went on to more succinctly summarize that several additional capabilities to how we can just CLOSE toolbars would open the door for most of what some of us here seem to want to be able to do - including what I "think" the OP was after. If we could JUST get the ability to locally turn off global toolbars, I think that would get most of us by. But certainly, I could appreciate being able to use wildcard-like controls like we already have with *this... such as *local, then Cris's idea for *all, and hell... why not *global as well for that additional layer of granularity in control. For my purposes, and again towards what I think would serve the OP's request - I think being able to simply 'locally' turn off an explicitly named 'global' toolbar would fit the bill here.
Leo - we've hashed this out a time or two I think over the years... (hope you're feeling better by the way)
...for me, it's not the number of toolbars - so much that for certain workflows I'll want to switch between 1, 2, or 3 toolbars fairly frequently in a session. I've got all of those toolbars in a menu button that flips them on locally, and a 'toolbar local close *this' button at the right end of each of them. While not a BIG deal - it's enough of a PITA to constantly open and close each of them as my need to access one or another of them changes during a session that I usually just leave several of them open... but that equally sucks because of the screen real estate that takes up. In some cases where I definitely feel the need to see more file display real estate - I do go ahead and just turn off the local toolbars. Perhaps trivial sounding but:
a.) how many features have been requested over the years that really only serve to eliminate ONE extra mouse click
b.) I've got about 7 toolbars that I frequently toggle on/off locally... and I have good reasons to continue to have the separation that I have between those toolbars. Some of them are in fact pretty full, so wouldn't be practical to combine buttons from them more than I already have.
c.) I selfishly saw an oppty to ask for something I thought would help with this specific request - that would also bring ~other benefits (i.e. purpose built ~layouts where the entire toolbar set could be changed when launching new listers with the embedded commands feature)
FWIW - I simply don't think it's necessary to tackle this ~problem with some type of new specifically devised "TabToolbar". All that thing is in a ribbon UI app is a regular toolbar with buttons without icons. If we have the commands that let us locally turn off global toolbars, then we're all set... and people can customize how they want. For MOST of my needs I would do something like this:
toolbar close my.Operations
toolbar close local ANY_AND_ALL
toolbar close local OTHER
toolbar close local LOCALLY
toolbar close local ENABLED
toolbar close local TOOLBARS
toolbar local TOOLBAR_I_WANT_TO_ENABLE_LOCALLY
...90% of the time - I would only turn OFF my customized "Operations" toolbar, which is globally enabled. My customized "Menu" and "Location" toolbars I'd leave alone MOST of the time. Then wanting whatever local toolbar I want to enable with this sort of button to take the space of the disabled global "my.Operations" toolbar. And I suspect that most folks who would chime in about wanting a ribbon UI style option would have a similar need - to just disable the one global toolbar locally (excluding the idea of disabling everything for a sort of full-screen lister mode) without affecting ~other open listers.
For rare cases where I might actually WANT several of my local toolbars turned on concurrently, I'd probably just use some @keydown controls - maybe have SHIFT do things the way I'm currently doing things, and use NONE to do things the way we're exploring here - which is how I'd prefer to work MOST of the time.
Just jumping in to say I would really like the option of adding ribbon-style toolbars to DOpus.
Leo has a point, these interfaces make the most sense when you want to repeatedly use several commands from a particular category. That's often how I work. I have several different toolbars filled with different types of tasks that I toggle on and off as needed. Image editing, renaming scripts for different kinds of tasks, metadata, etc. I really do think that the option of a ribbon interface would be a great addition to the world's best file manager!
There's also the fact that ribbons can save space on your screen if you use the "hover over tab to display icons" method. One main tab menu is all you'd need until it's time to grab the next command!
That's what I had in mind too..
- On my second monitor I would like to quickly open a few directories (each with numerous files) in their own separate listers - listers however with minimal or zero [panels, buttons AND TOOLBARS].
Or I could instantly and temporarily create a new window based on a single collection, with the maximum possible file display. All whilst knowing my standard lister toolbar configuration is preserved.
I used a similar feature in the file manager xplorer2, called 'scrap' panes. Which can be thought of as non-standard 'barebones' listers.
- would be very simple to achieve with the suggestions in the 13th post above, in combination with the 'Embedded functions for new Listers'.
I could set a r-click button for folders with:
Go {filepath} NEW
[
Toolbar CLOSE LOCAL *all
Toolbar compact LOCAL
Set VIEW=list
]
whereby 'compact' is a toolbar I activate specifically for 'compact' listers