I'm very happy with the new toolbar handling in DO11 but I don't like new Toolbars popping up like the automatic Images toolbar for thumbnail view. The disturbing change of the appearance is too much for me. I'd suggest two or three things to make this less disturbing and more useful. The second idea came up when I decided to remove the location fields from the display border toolbar and place more icons there. I prefer to have a location toolbar like in DO10 because the fields were too small in dual mode for me. The problem with the location toolbar is that the location fields will not always scale according to the file displays. It only works fine as long as the ratio of the display width is 50:50 and both fields are configured to scale to the whole width. Moving a divider between the file diplays/tree doesn't also change the width of the location fields.
My ideas/suggestions:
Add an option to save the position of a toolbar in one line with another toolbar like discussed in this thread: Idea: Content type based buttons/button-groups. With this you could show a short toolbar with a few image related buttons as a "conditional button group" without changing the height of the file display.
Add an option to add a divider to toolbars that has a fixed position dependend to the position of a display/tree divider. With this you could divide a toolbar into parts that always scale synchronous with left/right/tree. It should be possible to position a "conditional button group" toolbar next to this divider so they can be configured to always show up above the file display that triggered the condition. For single display mode/no tree this toolbar would simply ignore the dividers and revert to the default behaviour.
Alternatively/additionally to suggestion 2) you could make it possible to position toolbars above tree and left/right file display with the same width which only appears if the tree or correspondend display is shown but I think this would be more complex to configure for what happens when switching to single mode/no tree because several buttons will appear/disappear with their correspondend element.
You should be able to do 1 already by using Toolbar Sets. Create a set with the default toolbars + the extra one, then specify that set be used in the same place you were previously specifying the extra toolbar.
2 & 3 make sense, but may be beyond the scope of what we're planning for the current release.
I'm not sure what you mean. The toolbar set itself is conditional, so everything in it (that isn't also in the default toolbar set) is also conditional.
Yes, but e.g you create a toolbar "media". In "media" you have buttons for images AND audio. Condition would be "images" and "audiofiles" to let the toolbar appear. But for each condition toolbar would show all buttons.
Conditional buttons would mean, that on images in toolbar "media" only e.g. "picture-convert" and "turn left/right" would be shown, and on audiofiles e.g. "MP3 convert" and "Play".
Other example: On default operation-toolbar the extract-buttons could appear only when archives are shown in lister. With conditional buttons you could create powerful toolbars without having lots of toolbars/sets.
Right, but I'm not talking about conditional buttons (we are not considering that for Opus 11.0, but it may come later), just what point 1 talked about where a conditional toolbar is desired on the same line as another toolbar instead of taking up an extra row. Toolbar sets can be used to get that.
@leo:
I tried your suggestion to save a "conditional button group" toolbar set. I configured it to appear in my wildcard path format for folders containing audio files and it's working fine. Thanks for the hint. @Sasa: What's the problem? A toolbar beside a toolbar can be as small as a button. For "conditional buttons" you could create toolbars containing only one button, place them in one line with another toolbar and save that as icon group. With this you would end up with a large number of toolbars and icon groups but it should work. The only limitation would be that you can't position your buttons inside a toolbar but only at the right or left end of it.
I discovered a little issue with saving a toolbar set to a path format. When I open another toolbar it vanishes when I change the directory. Would be nice to have something like the format lock for toolbars (maybe in it's context menu) to lock/unlock a toolbar to be always shown until it's unlocked.
@kundal: You really think creating a toolbar for each button is comfortable? Btw. such buttons alreasy exists, like pic slider. The combination of conditional toolbars and buttons would be perfect, but I think it is a feature only for major releases, so we should close this topic until DO 12!
[quote]You really think creating a toolbar for each button is comfortable?[/quote]I didn't say it's comfortable but only that it would work.
What you requested goes far beyond the "conditional Toolbar groups" especially if you think of conditions like "select an image file and the button appears".
Thinking about what's possible at the moment it's not really useful for me as long as other toolbars are closed when a toolbar set was applied to a path. I often open an additional toolbar that I never want to be closed when navigating through various folders. So it's really nice to have my "player buttons" popping up in the main toolbar when I'm in my music collection but when I open my extended "Audio Toolbar" to work with files it's really annoying to have it closed every time I change the directory.
I'd prefer if manually opened toolbars (by a button or the toolbar context menu) would survive in the current lister until they are manually closed as the standard behaviour. Otherwise I'd completely avoid to apply this sort of toolbar sets to paths because it makes "special task toolbars" unusable for me.
Another issue: I tried to call my toolbar set from a button. Now the "Audiobuttons" doesn't show up next to my standard topmost toolbar where I saved it but next to the second toolbar "Location". It's not possible to get the "button group" at the position where I saved it even with Arguments STATE=top LINE=0. Going to a folder matching the path wildcard brings up the toolbar set with correctly positioned "Audiobuttons". I used all variations I could think of (and read in the manual) of this command:Toolbar LOADSET=toggle NAME=Audiobuttons
I'm not sure that the current features let you go all the way with what you want to do in the way you want to do it...
Maybe Kundal's recent comments are a good example why... Seems like we might do well to have some additional controls beyond just turning a toolbar or set ON. Maybe some additional options similar to what we have in layouts or folder tab groups, where we could control whether or not turning ON a toolbar or toolbar set in a folder format should also turn OFF existing toolbars or leave them alone. Perhaps also some sort of control at the toolbar function level as well, so that when ad-hoc toolbars are turned on you could possibly specify an option in the raw command to 'preserve' it against being turned off by a format change or something.
I think the most flexible method to make all this work a bit smoother though, would be to get rid of the toolbar drop-down in the folder format settings all-together and instead just give us a free-form 'command' window where we could run whatever functions or scripts we want. For some of what Kundal is asking for, he could then do what he wants with a series of toolbar commands...
@Kundal, I'm going to start another topic about some of the toolbar position commands not seeming to work right; but for your case, it would probably help more if you posted a screenshot with what the command is resulting in vs what you want it to be doing...
With conditional buttons or button-groups we would only need one toolbar and not need its exact positioning. We also wouldn't need too much toolbar-sets or wouldn't have the "jumping" when activating a conditional toolbar. Don't misunderstand, for some people different sets, layouts, jumping and floating toolbars are perfect, but other people - like me - get used to one layout with a few toolbars (in fact with conditional buttons I only would need one toolbar for all operations).
I feel your pain . The "jumping around" you're talking about is driving me a bit mad... I know Leo is tired of seeing me mention anything about Navlock, but I may make a video to show how crazy my lister looks when I'm in dual-horizontal display mode, copying several large files that also are configured to show in the folder tree, and changing folders that trigger the Images toolbar .
It's great and useful functionality thats being added, but the visual jerkiness of all these things in combination is so jarring to me I'm turning it all off...
Amusing how you've all been asking for dynamic toolbars for literally years without apparently giving any thought at all to how it would work in practice.
The post you link to from a few days ago (and 10 days after the first Opus 11 beta release) has some useful ideas, and we may implement them in the future, but Jon's point was that, for years, people have been asking for what we've delivered in the Opus 11 betas, and now suddenly some people want something quite different which nobody had ever mentioned until now.
Which is all fine and normal, but it'll take time to work on completely new ideas.
I changed my Audiobuttons command not to load the saved Toolbar Set but the toolbar itself defining it's position with this command:Toolbar NAME=Audio-test LINE=0,1080 TOGGLEIt turns out that the Line=0 argument doesn't work any longer when the position is added.
The line number is completely ignored and the toolbar will always open above the file display in the last line with this command. Defining only LINE=0 works but obviously doesn't position the toolbar in one line with the topmost toolbar but moves it to line 1. I'd say this is definitely a bug.
@steje: I don't think it's necessary to post screenshots for this because it should be easy to reproduce.
@leo: I think with toolbars popping up under certain conditions like view modes or path formats you delivered much more than people have ever asked for. The ability to save toolbars with layouts and styles was all I can remember that was requested several times. The way you implemented this now naturally leads to new ideas and needs.
The general agreement between Sasa, steje and me seems to be that too much "visual jerkiness" isn't good for a file manager so we need solutions to to take advantage from the new features with minimal "jumping around" effects.
Another idea how to solve the above mentioned issue with additional toolbars being closed when a Toolbar Set is defined for a path and the directory changes: When applying a Toolbar Set to a folder format it should be possible in the dialog to choose to add (Toolbar LOADSET=add) the Set instead of always replace it.
For "conditional buttons" you could create toolbars containing only one button, place them in one line with another toolbar and save that as icon group. With this you would end up with a large number of toolbars and icon groups but it should work. The only limitation would be that you can't position your buttons inside a toolbar but only at the right or left end of it.
. The "jumping around" you're talking about is driving me a bit mad... I know Leo is tired of seeing me mention anything about Navlock, but I may make a video to show how crazy my lister looks when I'm in dual-horizontal display mode, copying several large files that also are configured to show in the folder tree, and changing folders that trigger the Images toolbar 
... I myself am quite happy just with toolbar states being saved into Layouts. So thanks for that!