So, maybe this other thread went a bit off the rails from being purely about what the OP had requested in it. I sort of hijacked it to advocate a way of doing what they wanted that also brought benefits towards being able to do what I'll describe here...
For some time now, every once in awhile - somebody will ask about creating purpose-built lister layouts that, besides potentially different view settings for the file display, they'd also like OTHER elements to be saved in a specific layout. Those "other" elements may vary slightly depending on the users ideas... I think I've even seen requests for different status bar setups, and other things. But more often than not - I think people have looked for toolbar state control.
The recently added 'embedded commands' feature that lets you send commands specifically to a new lister you open up instead of the 'current' lister is a nice step in that direction. I'd like to also advocate for the idea of Opus allowing us to turn off 'globally' enabled toolbars, only 'locall'y in the current lister. I would use this to:
modify the 'current' lister global toolbar state without affecting other listers already open, or any subsequently opened listers
launch 'new' lister windows with the embedded commands feature to let me 'choose' which combinations of both global and local toolbars to either leave enabled or enable on demand when launching the lister
Along with the handling of toolbars I'm raising here - it would also be nice to see the 'embedded commands' feature as an item that could be saved in layouts themselves. I.e, just as we have check-boxes right now to control various settings for each layout, perhaps an additional button could be used in the Prefs->Layouts config screen that lets us call up a button command editor like dialog to insert the same sort of embedded commands that will then be saved directly with/in the layout. This could be useful to allow people to call up layouts using traditional means OUTSIDE of Opus (like the desktop context menu, or dbl-clicks on desktop, tray icon, etc) where they wouldn't otherwise be able to take advantage of the 'embedded command' system since those external interfaces aren't customizable.
Note: I realized after posting that my example of launching Opus on desktop dbl-click or tray icon IS in fact customizable where you can run a user command rather than call up a named layout. Still think it'd be useful to save embedded commands into lister layout definitions though .
Yeah, all depends on whether or not you've got a use case where you want otherwise 'global' toolbars "out of the way" for some reason... which I sometimes do ...
open a lot of smaller windows, all of them showing a single lister with no toolbars at all (DOpus5-Style - to quickly sort/move/rename masses of images in a mass of listers, tabs don't always do it for me, because I cannot look quickly whats "in" there)
open a dedicated find window with no "fuzz" (I have no problem using the find tool, having a dedicated window is nice though.. o)
as I have a dual/tripple monitor setup, I would open listers with different layouts/toolbars on these to be able to switch more quickly between handling images and handling source (programming) and web-server (html etc.) related files and locations (i often enhance/develop a mass-storage filesystem-based photo-website in my spare time with a lot of files to be touched/looked simultaneously at times - viewing source, website, original images, cached/resized versions and so on).
Writing that, it is even worth thinking about binding/excluding toolbars to layouts without using the need of embedded commands ?! Well, just a "draft" idea.. o)
I think GPsoft are possibly weighing the benefits of potential enhancement here... but who knows what they really think of it. Having something in the Layout config pages in Prefs to specify toolbars would be more elegant, but the related use-cases might probably be viewed as more of a niche power user feature on the whole. So I for one would be content for allowing the embedded command set to be what is stored inside a layout as opposed to ~just toolbar state. If we got the ability to close global toolbars locally - we'd get the sort of control we want re: toolobars in specific layouts as well as all the other sort of interesting things one might only be able to do with the embedded commands...
Thanks for that "Seperate Find Window" thread, I've been through all of them.. o) As I said, I have no problems with how the find tool works, I just don't like my layout squeezed, whenever the find panel pops out, because I use a horizontal dual-lister (with viewer pane to the right), and lister space then is quite reduced when find panel is open.
But isn't DO that tool for exactly these kind of niche power user features ?!.. o)) Fiddling with "embedded commands" to switch toolbars off/on could feel like a hack or workaround in the long term, and might be hard to "get" for DO starters, don't you think ?!You would always need to edit several command sets, in case you add a new global toolbar e.g. (in case there is no command like "toolbar CLOSEALL LOCAL").
I think that the current LOCAL toolbar feature does not seem to work well with positioning of the toolbar if you have more than one lister open. Been trying to get this to work with no joy.
I guess everyone has a different idea of what is efficient and what suits their respective workflows. It would be great if you could have local listers that had a completely diff toolbar set to the standard one IMO, as ppl could configure it as suits them.
That's not really related to the LOCAL argument. The issue there is that you want toolbars in different positions depending on other factors, which isn't easily done at the moment (though you can get some of the way using @ifset).
We have plans to improve all of this, but we're not ready to talk about them yet.
Particularly considering the excellent feature upgrades we get for FREE from release to relesae within the same major versions of Opus - I would happily pay my upgrade fee for some enhancements in these areas of layout control.
@tbone: yeah, you're right - you said building the toolbar state controls into the Prefs->Layout system would be easier. I also ack'd that it'd be alot more "elegant" that way... but I'd hardly consider the inclusion of embedded commands in a layout to be "hackish"... any more so than other pseudo-scriptable interfaces.
seriously though, i like dopus a lot and I think this kind of customisation want is the only real conspicuous failing. other issues are pretty minor & can be forgotten relatively easy. tbh, dopus is one of the main reasons i don't abandon windows altogether.
personally, i think this dialogue is quite interesting as IMO, a lot of it seems to be triggered by the loss of the old find window, but this may be in my head. what do you think?
I think the relevance of the find window is just as a recent and obvious oppty to explore the usefulness of these sort of layout control enhancements. There have been others over the years, and I myself only used the 'separate find window' thing as a good excuse to play around with what we could do with other recently added features like the embedded commands and ifpath/iftitle stuff. Sort of a science project if you will - to help me better get a feel for what else would be beneficial to change in the current feature set in order to get to a 'purpose built lister' layout capability.
.
