DOpus has been and is such an incredible and well engineered alternative to the Windows Desktop Explorer.
I would both truly trust and find it invaluable if the DOpus team considered creation of a TaskBar [SideBar] alternative or equivalent tool for launch, notification, and windows management. With DOpus integration it would be awesome.
Just a product suggestion I would happily pay for.
David Simmons
For launching things, Opus can have docked/floating toolbars, which can blend in with the taskbar. I have one on the bottom of my right-hand monitor, which looks like this next to the taskbar on the left-hand monitor:
That won't replace the whole taskbar, though, since it doesn't handle showing and switching to active windows, the clock, notification icons, and so on.
I am not sure it is a good idea to try to replace the taskbar, as it could be a compatibility nightmare. I suppose the real taskbar could be set to auto-hide and something similar shown instead, which would be safer.
What value do you think we could add that the real taskbar and other alternatives do not already provide?
That is really good to know. I actually worked at MSFT as an architect for 10 years on .net, .js, powershell, cloud, etc.
Sidenote: I have been really busy and remiss in not sharing a lot of scripting components and other things I've developed and use with DOpus. I think it is an incredibly great product and one of the (2) or (3) big things that makes me stay on Windows as my prime development and work environment rather than the other systems I regularly use.
My main gripe about the task bar is the way it shuffles icons as windows are opened. I.e., it violates the principle of surprise. As one's motor skills get used to a pattern that an icon for launching or indicators will be in one spatial location, that shifts with the sands of opened windows, and icons can even flow to the hidden area as space is lost due to opening windows. I would also like to be able to script the combo-pop-up menus on those launcher-icons. I make extremely heavy use of sym-links (reparse-points) to manage portable vhdx drives and integrate systems that allow me to create servers or NAS setups that are portable and can be cloned or repaired quickly. Which means that I often want to resolve the location of a file or application path (there is no task-bar mechanism to find the target).
And, quite a few other suggestions. Like, I'd love to take a little time to extend DOpus to have a basic Scintilla/Notepad++ style visualizer since then it would be "darn" close to an IDE for working with Scripts and DevOps activities. Making it even more broadly appealing.
It is also probably worth mentioning that on all my Windows machines I install Araxis-Merge, and Classic Shell. On most of my machines I have at least two monitors (unless in latop road-warrior mode). Multi-monitor (w/DPI scaling) lends its own set of desirable elements to the mix. [and I have most of our engineers, staff (and recommend to clients) using a similar set up and mix on their machines].
Best Regards,
David Simmons
p.p.s., thanks for getting me to revisit toolbars. I had not looked in a couple versions. I just discovered some new great stuff. DOpus is such a rich tool.
Hmmm. Played with a new toolbar for a couple minutes and three items came up:
a) Drag and drop of apps onto toolbar to auto-create launcher buttons. Launcher buttons supporting auto-add of document items in combo menu (like taskbar).
b) Ability to (copy/paste as xml .dcf style file) drag a toolbar to desktop in toolbar-edit mode so that I can save the XML layout for import/sharing with other DOpus users (my team, etc). One can already do that with commands (.dcf) files.
c) Ability to script their visibility so they can be associated with particular lister-views/folder/directories being active or not.
d) Setting the background color of the toolbar seems to be "ignored" when rendering it. Ok, figured this out. Need to not use "glass" or "taskbar" setting in appearance menu setting and it's ugly in rounded corner mode.
Any suggestions welcome and desired.
a) You can drag apps to the toolbar while in Customize mode, same as normal toolbars.
b) Individual buttons/menus can be dragged in/out as .dcf files while in Customize mode. Or you can share the whole toolbar .dop file from /dopusdata/buttons. (Same is also true for normal toolbars, if it's ever needed for them.)
c) Scripts can respond to events and use the Toolbars collection to see which toolbars are currently in use, and run commands to open and close them as needed.
d) Yes, the top-level of Glass, Taskbar and Transparent toolbars will ignore background color settings, by design.
Thank you Leo. DOpus is awesome...
I've been experimenting since I wrote that post and discovered (a);
did not know (b) part about whole-toolbar;
had not explored (c) but that's great to know.
(d) Makes sense. Although I noticed that when I set the toolbar-background the menu items inherit it as a default (which is causing me to manually have to force set each one to white/etc). Wish I could instead have default mean the default-menu item background-color.
You could cheat and use a background image (e.g. solid color .png, set to tile), which then gives you a checkbox for whether or not it's inherited by sub-menus.
(I'm not sure why we don't have the same checkbox for simple colors, but creating a simple background image is quick and saves you the trouble of having to override things in lots of sub-menus, which will be a pain to maintain.)
Great tip/trick... Trying now
Where do I install the solid-color images so they will show up in the background-image list choices?
Ahh, ok. Got it. I just need to manually build a png/image file. [be great if I could use css ;-)]
I cheated and used my TechSmith Snagit screen grabber to clip a small section of the existing toolbar, saved as a PNG into the "../Directory Opus/Images" directory. Won't quite make sense when I share to colleagues, but we will figure it out.
Excellent, now menu items look much better.
This may be useful:
(Please excuse the broken image in there. We're running a very slow process to repair all of those on the new forum.)
Last question as I have no gotten quite fancy with building a whole DevOps toolbar/menubar for managing a server.
If I want to add a field to a toolbar that I can script when data is entered into it, how might I go about it.
I.e., I started with adding a "Label", then setting the Field Type of the label to "Search Field". But what I really want is to have a script take control of any text-entry "Enter/Return/Typing" action in that "Search Field". So that I can then compose a:
https://{bakedpath}?query={label-search-field-contents} URL action to be invoked on "Enter/Return/Typing".
Lol, bonus-points for ideas on how to maintain a "event-driven" icon-update that blinks, or displays notification changes within the toolbar (effectively supporting all that the TaskBar notification area does).
You can't currently have script input fields directly on toolbars, but you could have a button on the toolbar which prompts you for input that a script then acts on.
You could either call a script-command using {dlgstring} to pass it arguments.
Or you could call a script (with the script directly in the button, or calling it via a script-command, whichever is most convenient), and the script could create any UI it wants from simple Dlg.Request (similar to using {dlgstring} but you have more control) all the way to completely custom UIs made with the integrated dialog editor.
What about a reliable ("naming") approach to finding the label of that toolbar (search-field) HWND and superclassing it so I can intercept events to insert my own control/behavior onto the toolbar?
Slightly less aggressive than trying to jam my own control onto the toolbar [which might really screw-up/confuse DOpus].
Which I could presumably get installed and uninstalled (as a event filter/listener injected DLL within the DOpus process) using the toolbar scripting API you mentioned in a previous part of this thread.
I guess you could try something like that. (It's obviously not something we officially support.)
There won't usually be any child controls on a toolbar that just has normal buttons, at least as they are currently implemented, so if you find a child HWND of the expected class (e.g. Edit if it's a pathfield) then you've probably got the control you want, as none of the normal buttons create child windows. (The whole toolbar is usually one big control, effectively, unless there is a field on top of it.) Of course, this is subject to change.
You might find it easier to hide the field HWND and create your own rather than try to subclass ours, which may confuse a lot of things.
