Directory Opus Pro v12: Bugs and Feature Requests

Directory Opus Pro v12: Bugs and Feature Requests

Please be aware that I am a new user and still don't grasp some aspects of using Directory Opus, however I have lots of experience voluntarily testing various commercial and open-source software and hope that at least some of my observations are accurate and help push DOpus to greater heights.

Also, these points are merely being posted with the intention to help improve the software and introduce some potentially new ideas. No reply is expected, but with any luck, it'll at least be read!

Bugs

  • Resetting the Columns tab/page to factory defaults for Folders > Folder Formats > User Default causes the Width fields to become blank:

    Expected: All fields should have a Width value shown after resetting the page options, I believe Auto the default.

  • Dragging a MTP folder into DOpus's Folder Tabs bar causes all its sub-folders to be added to the bar also:

    A local folder from File Explorer dropped onto DOpus' Folder Tabs bar adds only the one folder. However, when dragging a folder from File Explorer which has navigated to an Android device connected via MTP, the folder dropped will be opened as well as all of its subfolders. The closer the dragged-in folder is to the root of the Android's filesystem, typically the bigger the issue as many tens of sub-folders may end up opening. At the time, I was also testing DOpus Light, and I can't recall if this bug was limited only to Pro, or both DOpus variants.

    Expected: Only the one folder should be added to the Folder Tabs bar, unless customised to do otherwise via a Preferences setting, or unless a modifier key is held during the drag-and-drop.

  • The right File Display allows for pasting up to 261 characters into the Location bar, whereas the source's correctly caps this at 260:

    Expected: Both Location bars should support the same length of path to be pasted.

  • File Displays > Mouse > Single click to open an item (...) does not respect either of the Allow file selection when clicking to ... options above:

    Accidental clicks that would be prevented by these two options are possible in single-click mode, i.e. items can be deselected/opened before the Lister / destination File Display is active (has focus).

  • Folder aliases can be named with a pipe | in their name, but the pipe character cannot be typed into the "Go:" field (a backslash \ is produced instead).

  • Close PROGRAM=onlast,confirm does not exit the program when only 1 Lister is open if a toolbar button's function points to a user-defined command containing this close command:

    If instead the toolbar button's function is set directly to the mentioned Close command, then DOpus correctly identifies that there is only one Lister left, and quits completely. The ,confirm part is only for the convenience of testing.

    Another example below is a command created via the Command Editor and dragged to the toolbar as a button: the view changes, but the button icon changing is ignored. If the same code is added to a toolbar's Right-click > New > New Button instead, it works just fine.

    @icon:smallicons,Set VIEW=smallicons
    @icon:largeicons,Set VIEW=largeicons
    
    Set VIEW=smallicons,largeicons
    

    I assume I'm just misunderstanding the workflow of customising the toolbar and should instead create buttons directly, not as a command first, which I have now been doing. At the very least, it's not clear what will and what won't work on a button if using the method I've just described. Perhaps the documentation covers this?

  • Toolbars' Always Enable Drop-down is broken:

    1. Enter Customize mode.
    2. Right-click Copy Files and enable Always Enable Drop-down.

    My expectation is that the Menu Button should never launch the command via the left side (main portion) of the button with this option enabled, but instead display the list of toolbar items no matter where clicked. This would essentially make this Menu Button behave identically if converted to a Menu (Convert to Menu), the only difference being that one shows the black drop-down arrow, and the other does not. At the very least, I cannot detect what the option is doing, if anything.

  • When a toolbar item has been Convert to Menu, a label bug is possible (which may potentially be present in the other button modes):

    1. Perform the steps from the last bug above, but as a step 1.5, Edit the button and make sure it has Show label set to Right.
    2. Right-click > Edit the top most item (i.e. on the toolbar, not within the drop-down list of buttons).
    3. Change the Label to AAA > OK.
    4. Click the Menu button and notice the menu itself has been renamed, but not the first item that it lists.
    5. Right-click AAA Menu button > Convert to Menu Button.
    6. Right-click AAA Menu button > Convert to Menu.
    7. Clicking the Menu button will now show the first item in the list has been renamed to AAA.
  • Certain toolbar buttons should display Convert to Menu, rather than Three Buttons by default:

    The Drive Buttons button for example: enabling Three Button renders the button inoperable (displays no drives, clicking does nothing). However, adding a another button to the Three Buttons list, and then disabling Three Buttons to turn it into a Menu brings back the expected functionality. Converting to a Menu Button also works.

  • Pressing OK on the Customize popup window closes the Command Editor without saving changes:

    1. Open the toolbar Customize popup window and from it the Command Editor via editing a button.
    2. Make changes in the function/code area, .e.g write a comment.
    3. Now press OK on the Customize popup window behind.
    4. Navigate back to the Command Editor and notice the written comment was discarded.

    Expected: A warning for unsaved changes should pop up, or at minimum, do not discard the changes.

  • The Command Editor is always on top of all other windows on the system:

    Expected: It likely should only be the top-most window in relation to the DOpus window and its children, not the entire windowing system. But perhaps there's a good reason for this beyond my current understanding of DOpus.

  • A lister in Dual Horizontal mode does not precisely retain its split proportions upon toggling the feature on and off (F6):

    For example, split a Single File Display perfectly into two (horizontally) so that the top and bottom File Displays precisely fit all 10 test files whilst in Details view mode (when selected, the last file item from each display should have a single pixel of white background border along its left and bottom edge at this point, with no vertical scroll bar present). The issue occurs after toggling the Dual Display off and then back on, as the bottom display now has a vertical scrollbar when it previously didn't. Splits should be created equal in size to remedy this.

    The same issue with more details:

    Dual Horizontal displays do not split equally on Set DUALSIZE 50:

    1. Dual Horizontal display mode enabled.
    2. Folder Tabs > Options > Display folder tabs: Always.
    3. Folder Tabs > Options > Tab position: Below.

    Dual display position::

    • Normal: File Display area (inc. column headers) + Folder tabs + Status bar

    • Together: File Display Border (blue bar) + File Display area (inc. column headers) + Status bar

    • Apart: File Display area (inc. column headers) + Folder tabs + Status bar

      Each of the three Dual display position modes above show the various UI elements of the bottom File Display that add up to the same height of the top File Display's column header and file area alone.

      Thus, using Set DUALSIZE 50 produces two halves of differing sizes (top display is larger than the bottom). Ideally, the area where files are displayed should always be identical on both displays when a File Display split occurs, or when specifically split in half via DUALSIZE 50.

  • %T%G as a custom string to show Target in the Lister title bar only shows when the left file display is a junction/softlink, and regardless if it is the active file display or not:

    If the left side is A, a softlink, and active, and the right side is B (a normal folder), the title bar will read A [-> P:\ath\to\A_target ]. Great. But clicking on the right file display will change the title to B [-> P:\ath\to\A_target ] (notice it still points to A's Target too), instead of simply displaying B. If the Swap file displays button is pressed, now regardless of which file display is the active one, the [-> ...] is never shown, even though the A softlink is still open (in now the right file display).

    Expected: The [-> ...] should only show when a file display is active and when its folder is a junction/softlink.

  • Relative graphs do not increase in height thickness when File Display Modes > Details / Power Mode > Extra line spacing is increased:

    Expected: The graphs should match the height of the Name column items, i.e. match the Extra line spacing set.

  • Setting the File Display Modes > Details > Extra line spacing to 1 to rid of the 1px overlap of the file/folder name selection colours (as mentioned in one of your videos), is not mirrored by labels:

    1. Make sure the above setting is set to 1.
    2. Make sure File Display Modes > Details > Grid lines > Horizontal are on and noticeable.
    3. Set the grid line type to the thick black bar at the bottom.
    4. Create a label assignment with a different colour that affects all files and folders (regex .*) for easier testing.
    5. View a File Display with multiple files, and notice that there is (by default) an alternating white and grey pixel gap between each file display item, which is actually an illusion due to the labels not respecting this 1px increase to Extra line spacing.
    6. Increasing spacing to 20 makes the effect obvious.

    I believe this is neither intentional or practical in use, and so labels honouring the spacing, for both Details and Power Mode, makes most sense.

  • Sort-field specific key scrolling does not match column content:

    With Sort-field specific key scrolling enabled for Power Mode, FAYT (Find As You Type) does not search the Type column when the file display is sorted by it (unlike as is explained in the documentation index.html#!Documents/Prefs/Power_Mode.htm).

    Expected: Perhaps I've misunderstood, but I expect simply typing into the File Display to start matching the sorted column, not Name any longer (unless it is the sorted column).

  • Labels with the same foreground and background colour cannot always be read:

    Sometimes you may want a defined label's Unselected text colour to be identical to its background (e.g. #ff0000 for both). A good example of this is when setting Display > Options > Blend file background colors with background to a low value, say 15. This produces a pleasant effect of the foreground colour upon the same background colour, but semi-transparent to let grid lines show through (specifically in my case, the thick black bar grid "line").

    The problems:

    • Both in Favorites and Recent > Labels / Label Assignments, the entries listed are unreadable.
    • Arguably more importantly, the File Display's right-click context menu's Set Label menu is again unreadable.
    • The List, Small, Large, and Thumbnail views also have this issue: a solid block of colour, no readable label name (unlike List, Details, Details + Thumbnails, Power, or Tiles, which display well).

    For the views, Blend file background colors with background should be honoured regardless which view mode is set. And for the appearances of labels in context menus and other places, maybe they can follow the same setting too? Or perhaps a special case can be made when colours are identical to display the foreground as something different to the background, for legibility's sake?

  • Resizing the DOpus window is quite laggy:

    Resizing the windows is nowhere as smooth as seen in a YouTube video of yours. I'm not sure which feature may be responsible (if any) that could be turned off to improve this. In fact, the only slight improvement I've noticed is when using only one File Display instead of two (but it's still not ideal). Interestingly, File Explorer is about as choppy whilst resizing as DOpus.

    Expected: The DOpus window resizing should be similar in performance to other applications, for example the Firefox browser, or Chrome.

  • After performing a search in the Preferences window, dragging the popup window around the desktop is sluggish:

    After searching for select then clicking Display > Options, moving the window around the desktop seems delayed, as if the movements are being smoothed out. Clearing the search to remove the red highlight boxes does not return the popup to a performant state. However, closing the popup and opening it again does.

  • Clicking a sub-menu in a context menu should not re-show itself when the sub-menu is already open:

    A small test of right-clicking the Windows 10 desktop shows that a sub-menu will open when the cursor hovers over one. Re-clicking that now open sub-menu does not hide, then re-show the sub-menu. It remains open. DOpus behaves differently and what it is doing I've found to be a poor experience. In my case, the delay time for a sub-menu to show when I hover over it is long enough for me to then decide to click it, but as I do, the sub-menu begins to show, thus the sub-menu hides and the delay to re-show it tricks me into clicking it again as now it looks closed, yet all that does it re-trigger it again, causing frustration just trying to get the menu open. Disabling the menu from being animated doesn't help the issue.

    Expected: The menus should behave like menus found in most other software on Windows.

  • The tooltip for the Help menu item accessed via the Operations toolbar says that it opens the "online help", which I don't believe is true:

    Both the local HTTP server and CHM methods to view help use a bundled local copy if I'm not mistaken. The tooltip should therefore be more accurate/generic. Perhaps an options for the Help function to define whether the local/online version is opened when accessing the HTTP Help view would be nice? The CHM Help would always be local I presume.

  • When searching for Check-Box Mode via the Help, no results are returned:

    One must instead search for Checkbox Mode (no hyphen). Perhaps the Help can be improved to return the same results for both Checkbox and Check-box`?

  • Some UI strings are both in American and International English (British, etc):

    See Preferences' Viewer > Behavior and Folders > Folder Behaviour.

Feature Requests

Do note, some of these requests may be possible to implement via the scripting and UI building I've seen glimpses of, however I'm too naive to determine what is and isn't possible yet, so please forgive any requests that make more sense to be built by a user rather than implemented into the core of the software.

  • The File Display Border toolbar buttons, e.g. the ones displayed via Enable file display copy and swap border buttons, aren't affected by the setting Click on destination's toolbar only changes state:

    It should not be possible to click anywhere within the Border, not just the added toolbars, so that accidental clicks on e.g. the Close button, could not occur when attempting to just switch the focus to the destination display.

  • A way to set the opacity of selected background colours found at Display > Colors and Fonts:

    Ideally, all colours could have opacity defined but background colours are the most important to me at this moment. For example, making the Selected background: red for Files and folders, shows that the selection background is already slightly transparent by default (label backgrounds and grid lines partially show through), so the ability to customise how transparent shouldn't be much of an issue. Display > Options > Blend file background colors with background already exists, but has no effect on this (which judging by its name, is expected). A separate Blend file selection colors file backgrounds option would give me control over the mentioned default transparency, but should all the colours end up supporting transparency, maybe all their definitions should be grouped with the Display > Colors and Fonts section.

    For now, I will keep Visual styles override file selection colors enabled as it is more transparent (letting me see various file background colours easily), however the sacrifice in my case means no custom selection colours. Perhaps themes are the solution to this, however I have no experience with them.

  • Display the luminosity value in the colour picker:

    Currently there is no easy way to match different colours based on luminosity. One must guess where abouts the slider should be (the slider above the glasses) to be similarly bright to another colour.

  • A way to create your own palette of colours that can be sourced when customising Display > Colors and Fonts:

    With something assigned to a colour which exists in your palette, changing the source palette colour should update the colours for all items assigned to it. This could be expanded so that label colours (and any other colour assignment in the program) could make use of these global colours, making broad colour changes (e.g. from my understanding, theming) much more convenient. Suggested implementation: a Preferences entry for Color Palette that allows for their naming, definition, and deletion, in a list format. These colours would then appear at the bottom of the colour picker popup that is used for colour-picking tasks.

  • Support for pasting in paths longer than 260 characters in the Location bar and elsewhere path lengths are limited.

  • A file display column that shows the Label assignments (Wildcard Filters, Label Filters, ...) name an item is affected by, not the Label name:

    For example, it's much more useful to see "Important files"—the name of a label assignment—than "Red", the name of the label. One could argue to just change the name of Red, but then one would need to maintain the same red across multiple labels (e.g. Important, >260chars, Corrupted, ...) instead of just leveraging a single Red label and using label assignment via regex etc.

  • An Open in Directory Opus for files in File Explorer:

    Similar to Open in Directory Opus on folders via File Explorer's context menu, but a way to do so for files so that the parent folder is opened in DOpus and the item highlighted. Also, right-clicking in a blank area could also display this Open ... option (meaning one needn't first go up/back in File Explorer to perform an open on the current directory).

  • A way to have a button always highlighted when a view corresponds to it:

    I'd like to be able to do this:

    // Attempt 1:
    @toggle:if Set VIEW=smallicons;Set VIEW=largeicons
    @icon:smallicons,Set VIEW=smallicons
    @icon:largeicons,Set VIEW=largeicons
    
    @if:Set VIEW=smallicons
    Set VIEW=largeicons
    @if:else
    Set VIEW=smallicons
    
    // Attempt 2:
    @icon:smallicons,Set VIEW=smallicons
    @icon:largeicons,Set VIEW=largeicons
    Set VIEW=smallicons*,largeicons*
    
    // Attempt 3:
    @icon:smallicons,Set VIEW=smallicons
    @icon:largeicons,Set VIEW=largeicons
    @icon:detailsmode,Set VIEW=details
    Set VIEW=largeicons*,smallicons*,details*,cycle
    

    Ideally no matter which view, the button should indicate that a specified view is in use. The default Flat View toolbar button seems to be able to do this, but only because it has several sub flat view modes I believe.

  • By default, A Refresh option in the right-click context menu of the File Display:

    This can be added manually via the Customize menu, but I think it'd make sense to be present by default as it is something I believe is used quite commonly in File Explorer. I have it set up as a Three Buttons button, Refresh, Refresh Both, and Refresh All, in the same group as View, Sort By, and Group By.

  • All context menu items to have an icon assigned by default:

    Currently, the context menu items don't have an icon assigned, and so setting Image State: to on doesn't force them to show one. If an item, for example New Folder... had an image assigned to its 1 icon, but Show image disabled for it, then the menu would continue to look like it does now. The benefit would be that users could now enable icons simply by switching Image State: to on for the specific context menu, or even all of them, and they'd now have a visual context menu experience. By DOpus doing this, it'd save users from having to go through every context menu item and assigning icons themselves.

  • Allow a drag down motion in addition to the Hold or Right-Click to Drop Down option:

    As found in some applications, for example Firefox, it is possible to click and drag down on the Back and Forward buttons to reveal the list of menu items, which is often faster than holding. Granted, DOpus already supports right-clicking which is quick too, but dragging down can beat it only requiring one click (like when holding): click, drag down to expose the menu, and release on the item you'd like to select. It is also faster than waiting for the Hold timer to trigger.

  • An option to define what happens on Close (X), i.e. minimise to taskbar:

    Other than being a fairly common option in applications, this would allow for one's current Folder Tabs to never be lost when pressing the Close button (not losing tabs is my main concern). It is possible to use Launching Opus > Default Lister > Update Default Lister automatically when closing lister to achieve such behaviour, but whether this option is on/off, DOpus must always re-load a Lister when none are open, which is somewhat slow compared to if the window were to never actually close and to just be restored from a minimised state. File > Close Lister should always close the Lister.

    An argument could be made, "just use the Minimise button", and yes, I agree, that is the simplest solution, however the suggested feature would also act as a fail-safe mechanism when the auto-update Lister option is off, and it'd be a convenience for those of us accustomed to pressing a Close button expecting a session to be "saved" i.e. not discarded as Close would do in this scenario.

  • An additional option Layouts and Styles > Layouts > Merge Listers when loading this layout:

    Any open Listers would be automatically merged into the one being loaded. I can merge them via a button after loading a layout, but it seems like an option that could be part of the DOpus feature itself. Or perhaps there could be a way to use a Lister Layout as a Lister Style, which would remove the need to merge.

  • Explicit icons to indicate between Folder Tabs exceeding the available space, and when tabs are just reduced:

    When Folder Tabs > Options > Use Popup menu when tabs exceed available space > Show menu when tabs are reduced is enabled, display, for example, a "hamburger" (a capital E with no vertical line) icon/character instead of the double-arrow (>>), unless there are indeed items that exceed the available space. Currently, the double-arrow is misleading because there may not be extra folder tabs out of view (which >> kind of implies), leading to erroneous openings of the popup list to find a folder that is in fact only reduced size, but still in view. An icon to differentiate between when the tabs are just reduced and when they are exceeding the available space is a better user experience than having to check potentially both sides of the folder tab bar to spot any "cut-off" tabs to glean the same understanding.

  • A definable Min width for the Folders > Folder Formats > User Default > Columns:

    This would allow for a column to have Collapse for the width, but then 100 for the minimum it'll shrink to (in the case of decreasing the window width, or Fill filling to the available space).

  • When the Folder Tree is locked, still expand navigated folders, just don't scroll to them:

  • With the Folder Tree's option Lock the Folder Tree to prevent it from changing to follow the source folder enabled (locked), the Folder Tree stops both behaviours: it doesn't scroll to, or expand to, folders opened via file displays. I'd like an option to make it so that locking the Folder Tree, only stops it from scrolling vertically, just like there is a way to stop it from scrolling horizontally. This way, when you want to manually scroll up/down, the folders are already expanded to the correct locations, rather than having to do this manually. The current behaviour could be the default, and then like for Horizontal scrolling style:, present an alternate option to only prevent scrolling.

  • A way to pin the Favorites item to the top of the Folder Tree, configurable on a per-Folder Tree basis:

    It should be pinnable so that Favorites remains at the top of the Folder Tree as you scroll up/down. It should also remain collapsible/expandable, so that if you wish for it to be pinned but take up minimal space, just collapse it.

  • Open a favourite bookmark in a new tab via middle-click when choosing a favourite from the Border (blue bar) in a File Display:

    This is already possible via the Folder Tree, just not the Favorites button drop-down found on the Border.

  • Display a dividing line just like in the Favorites button's drop-down (Folder Display Border) between normal Favorites and SmartFavorites, but for the favourites listed in the Folder Tree:

    Currently, there is no separation and it is not possible to tell which ones have been added automatically, and which have not.

  • A Drag over tabs brings them to the front after Xms feature but for the folders listed in the Folder Tree:

    Currently there is no way to override the default delay time one must wait for a folder in the Folder Tree to expand.

  • Option when renaming files to override Windows' behaviour of skipping over underscores:

    For a file named a_b_c.txt, navigating the filename via Ctrl + Left/Right will skip from the file extension, to the dividing ., to the start of the filename, nowhere in between (which is what I'd like). Essentially, the same behaviour as if the file was using hyphens (a-b-c.txt) instead. Microsoft's VS Code has a setting "editor.wordSeparators": "`~!@#$%^&*()-=+[{]}\\|;:'\",.<>/?" to which I've appended _ to achieve this. Maybe something similar could be implemented into DOpus?

  • Better match File Explorer's up/down scroll amount when in Large Icons, Thumbnails, and Tiles view:

    It'd be nice if DOpus better matched how much distance File Explorer scrolls in the equivalent modes. It feels like a tiresome experience covering too little ground with each rotation of the mouse wheel. I could improve this via Windows' number of lines to scroll setting, however that would affect all software, when it's only DOpus I am having issue with. Looking at File Explorer, it appears to use the number defined by the Windows setting as the number of lines to scroll items up/down in the single line height modes, e.g. List and Details, but uses higher amounts of lines to scroll depending of the size of the view items. Just compare Large Icons view in File Explorer to speed at which Large Icons in DOpus scrolls up and down.

  • Tooltips for any and all columns that are being cropped:

    For example, the Description column often contains a lot of text, however when it is set to Collapse its width, this information can be cut off to the point of being useless, something hovering over what remains of the string to produce a tooltip could remedy. I understand the Info Tip produced when hovering over a Name column's item could be edited to include this, however, I think that's more of a workaround to behaviour that most programs implement.

  • Tooltips for truncated column strings in the Utility Panel, e.g. for the File Log.

  • Improve Gif viewing and loading:

    "Not all frames of the animation were loaded due to memory requirements." when viewing an 8MiB Gif file.

  • Support for international English:

    An option for British English strings used in the UI. This would largely benefit multiple regions, such as Britain, Canada, Australia, Ireland, New Zealand, Malta, and South Africa, that mostly prefer international English spellings. DOpus seems to already provide some international strings under-the-hood, for example when typing "customise" into the Preferences search, it'll match the American "z"-variant. A note could also be appended to the Select Language: text at the bottom to remind users that all DOpus' commands use American English, so take care when spelling (I assume this is true). Alternatively/additionally the help documentation could mention that documentation is written in international english but all commands are in American.

Suggestions

  • This PC when grouped by Type shows the group name Hard Disk Drives (HDDs) when it should likely be the more generic Disk Drives, since Solid State Disks (SSDs) are common now.

  • The SmartFavorites feature doesn't update when one would expect:

    For example, set Folder Activity Point threshold to 10, and the Double-click configuration also to 10. With this configuration, one would expect a single double-click of a folder via the Folder Tree / Folder Display to immediately populate the SmartFavorties with the clicked-on folder, but it does not. It's not clear when the folder will appear in the Favorites list, but at some point, it does (maybe this is a bug?). I have tried exiting DOpus and re-launching it, but that didn't cause the list to update either. Perhaps the documentation on this feature could have more detail.

  • Favorites not shown under Folder Tree's Favorites tree item:

  • In the case when Folder Tree > Contents has Smart Favorites (but not Favorites) enabled, perhaps rename the displayed tree item to Smart Favorites as to reduce the poor UX of adding an item to your Favorites but the tree item not displaying it (because despite still being named Favorites, it is now set up to only display the smart variant). Nothing other than remembering that the program has been configured in this way indicates that your normal favourites won't be appearing in that list any more.

  • In the Command Editor, the Name:, Label: and other text entry fields should expand as the window dimensions increase: just like the Function text area.

  • In multiple places in the documentation (and the software I believe), the names given to things assume a left/right Dual Vertical display lister layout:

    A left/right dual display layout was the original and only orientation for dual display mode I believe, but new users may not know this. For example, the folder aliases defaultright and lastright do not make sense when in a horizontal layout. Perhaps their names should be genericised to something like default2? At the very least, hopefully it is noted in the documentation that left/right refers to top/bottom when horizontal.

System information

- Directory Opus v12.23.1 Beta x64 Build 7710
- Microsoft Windows 10 v20H2 OS Build 19042.804

Thanks

I've attached my .ocb configuration file should it be useful.

Thanks for reading and have a great day!

2 Likes

Thanks for the feedback! You might need to give us some time to digest it :slight_smile:

1 Like

Employ this person :slight_smile:

I wish I had a tester on my team that was so thorough... Good job.

1 Like

We'll work through these but may not reply to them all individually.

The effort that has gone into this is much appreciated.

As a general note, please post issues as you find them rather than saving them up for one huge thread. Individual threads make responding to and keeping track of requests much easier, and also makes it possible for people with the same question or idea to find existing threads on the forum.

1 Like

Not a problem. I'll just be happy if any fixes/features make their way into the software.

You're right. Normally I would have, however in this case I had been evaluating the program as a whole. I'll keep it in mind for any future feedback that I have.

I can't seem to edit my post, so I thought I'd let you know that there are at least two incorrectly formatted bullet points, in case that were to lead to any confusion.

As much as I was critical, there's a lot to love about Directory Opus; Thank you for maintaining the best file management software out there :slightly_smiling_face:

Seems I missed the advanced preferences wordbreak_char_names and wordbreak_char_paths when requesting this feature.

I found some issues with them and created a separate post.

We have finished going through your bug reports - thanks again for your detailed report! Feedback on the individual items is below. Please note your feature requests will go onto the list and all get looked at but we don't normally provide feedback on these unless we need clarification about something.

Fixed in the next update.

Fixed in the next update.

Could not reproduce this - the behavior seems the same in left / right.

Fixed in the next update.

Fixed in the next update.

Fixed in the next update.

This is not a bug. Modifiers like @icon affect the button, not the command. They're meaningless in a User-defined command.

This is by design. The Always enable drop-down option means that the drop-down part of a drop-down button is always enabled (available), even if the parent button itself is disabled. It doesn't change the behaviour of the button itself or affect which part is the main button and which is the drop-down.

I don't think this as a bug either, although I understand where the confusion comes from. The parent button of a menu button is separate from the items within it. The default toolbar buttons like Copy Files have a duplicate of the parent within them to try to reduce confusion but they aren't linked in anyway - editing the parent doesn't affect the duplicate within it. When you convert a menu button to a menu, the parent button has nowhere to go but into the menu as the first item, which is why it looks like the first item has been renamed - but actually this is the parent button that's been shifted into the menu.

The UI doesn't look at or know anything about the functions inside the buttons when presenting the functions like 'Convert to Menu' or 'Three Buttons'. I think it would be too complicated for this to be reliable. Those commands are there as conveniences but it's up to you to use them in a way that produces usable buttons.

Fixed in the next update.

This is by design, to work around various z-order issues while editing toolbars, but we agree it's not ideal and we are planning to change this in the future.

The layout code considers the border, toolbars, tabs, scrollbars, status bars, etc. as part of the file display area when dividing the area between the two file displays; it's not specifically intended to result in an even split of the actual file list itself.

Fixed in the next update.

Not a bug. Spacing shouldn't affect the size of anything; it's only meant to increase the gap between lines and nothing else.

It's not really supposed to, and people might want a line between each label background, which it would prevent. We are planning changes in the future which will give more control over this, however.

Fixed in the next update.

Fixed in the next update.

It can be, at times, we're not quite sure why either. It's on the list to hopefully be improved in the future.

This is a known issue, but is actually a bug in Windows, and will affect any programs that create a large number of child windows (which is what happens in Preferences when you use the search) - you can see the same effect in Photoshop, for example. We have a workaround for it which we will hopefully roll out in the next update, but fundamentally it's up to Microsoft to fix it.

Fixed in the next update.

"Online Help" here means help on the screen, as opposed to in a printed manual. It doesn't necessarily mean it's on the web.

This seems to be a limitation of the help engine - it doesn't seem to allow index topics containing a hyphen (or at least, won't find them in a search).

The mentioned string is fixed in the next update; please point out any others you notice.

3 Likes

Glad to see some of the reports resulting in fixes :slightly_smiling_face:

I'm curious however what "the next update" means exactly; will the changes be present in an upcoming 12.23.x beta, or some other version?

I had another look and I couldn't find any other instances of non-American English.

I couldn't reproduce this either. Perhaps I was mistaken.

I'd like to help track down why window resizing is as laggy as it is for me (~4 FPS). I've opened another topic on the matter to describe some further details.

In the meantime, I'll be looking forward to the fixes and potential improvements.

Thank you for your efforts!

I really can't speak for Jon and Leo, but long time reading here makes me confident that it means "upcoming 12.23.x beta".

1 Like

Impressive list!

Didn't realise the Location bar has 260 character limitation, until I just tried to paste a 320 character path into it, and came across this topic after searching to see if this had been reported before.

Given that it's supposed to support up to 32767 chars internally, can the Location bar limit be increased to 32767 ?