Show Posts
1
LaunchBar Commander / Re: Terribly slow and buggy
« on: February 07, 2009, 03:17 AM »
I had this problem as well (with 1.5GB RAM!) but also liked the program too much to substitute anything else, so finally I figured it out (at least for my case).
The major speed problem seemed to occur whenever the menu/dock contains any unresolved shortcuts (pointing to a file or path that does not exist, has been moved, that particular external drive is not inserted, etc.) OR just very many .lnk shortcuts (standard Windows shortcuts). In such a case, Windows insists on spending a ridiculously long time searching for those missing shortcuts, including the paths to the actual menu items AND paths to their icons - and the dock/menu does not display until Windows is done searching (and this occurs for each submenu seperately.) But even just ONE unresolved shortcut somewhere in the menu/dock slows down the ENTIRE menu/dock dramatically.
My (mediocre) workaround, for now, is to avoid putting items in the menu/dock that are:
For the most part this is tolerable, except that manually configuring each individual program shortcut in a LaunchBarCommander submenu is much more time-consuming than simply creating a bunch of .lnk shortcuts (via Windows "copy" and "paste shortcut"), putting them in the Shortcuts folder, and configuring just one LaunchBarCommander menu item to show the contents of that folder.
I have some ideas of ways that the developer could solve this issue (but would not know how to implement them or if they are possible):
Hopefully this can give the developer some ideas in finding solutions to some of the speed issues. If not, at least it narrows down the source of the issue.
Thank you for all your hard work and I look forward to future releases with speed fixes (and the awesome-looking new features that are not yet enabled in current version)!
The major speed problem seemed to occur whenever the menu/dock contains any unresolved shortcuts (pointing to a file or path that does not exist, has been moved, that particular external drive is not inserted, etc.) OR just very many .lnk shortcuts (standard Windows shortcuts). In such a case, Windows insists on spending a ridiculously long time searching for those missing shortcuts, including the paths to the actual menu items AND paths to their icons - and the dock/menu does not display until Windows is done searching (and this occurs for each submenu seperately.) But even just ONE unresolved shortcut somewhere in the menu/dock slows down the ENTIRE menu/dock dramatically.
My (mediocre) workaround, for now, is to avoid putting items in the menu/dock that are:
- located on drives other than the one from which LaunchBar Commander is run (when those drives are unavailable, those shortcuts will be unresolved)
- links to Windows folders that show the folder's contents as a submenu AND contain .lnk shortcuts (a few lnk shortcuts seems to work at reasonable speed, but for now I'm avoiding the possibility of that issue altogether)
- make sure that I adjust LaunchBarCommander shortcuts whenever any files/folders that are moved/deleted, to avoid unresolved shortcuts
For the most part this is tolerable, except that manually configuring each individual program shortcut in a LaunchBarCommander submenu is much more time-consuming than simply creating a bunch of .lnk shortcuts (via Windows "copy" and "paste shortcut"), putting them in the Shortcuts folder, and configuring just one LaunchBarCommander menu item to show the contents of that folder.
I have some ideas of ways that the developer could solve this issue (but would not know how to implement them or if they are possible):
- limit the amount of time that Windows spends looking for shortcuts that it does not find immediately
- add an option to automatically import all .lnk shortcuts from a Windows folder into LBC and convert the .lnk shortcuts to LBC command items. This would at least eliminate the .lnk issue. Also, launching a program via an LBC shortcut to a Windows .lnk shortcut is slower than just pointing the LBC shortcut directly to the real destination file/app. Importing .lnk files from a folder (or even importing all files in a folder with filters by extension or filename) and converting them to LBC command items would make the app much FASTER without much extra configuration time for the user.
- optionally cache all menu icons in a subfolder LBC, to save time on searching for them each time the dock/menu/submenu is opened
Hopefully this can give the developer some ideas in finding solutions to some of the speed issues. If not, at least it narrows down the source of the issue.
Thank you for all your hard work and I look forward to future releases with speed fixes (and the awesome-looking new features that are not yet enabled in current version)!