DonationCoder.com Software > LaunchBar Commander

Terribly slow and buggy

(1/2) > >>

smilejack1:
I love LaunchBar Commander - it's exactly what I was looking for - except it's running far too slowly.  I created folders with shortcuts to all my different types of software, and made a node on my only dock to each of those folders, and did likewise to all my most used data folders.  Then I minimized the dock to the tray, and created key commands to show the menus for all those nodes. Works perfectly for how I use my machine, except that sometimes it takes more than 20 seconds or more for the appropriate menus to open - far too long to be useful. 

How can I speed things up?  Some configuration notes - Dell Dimension 8100, XP Home SP3, P4 1.3 Ghz (old & slow, I realize), 768 Mb RAM.  Got my data (including almost all the folders to which my nodes connect) on a second drive.  Tried installing LBC to that drive and to my C drive - no appreciable difference in performance.

I'd be glad to provide other system data - HijackThis, running processes, etc. - if anyone can help.  Can't find a similar program I like half as much...

mouser:
can you confirm that when you experience it being slow to open and browse inside those directories, if you then click away from the launchbar, and go back, its fast.  once i know that i can better diagnose the problem.

smilejack1:
Yes, that's more or less what happens.

mayabelle:
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:


* 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)!  :)

smilejack1:
Amazing timing. I was going to make a post today detailing further developments regarding this issue.

Unable to find a satisfactory workaround for LBC, I tried a few other applications which offer similar functionality - MenuApp (http://www.desktopapps.co.uk/menuApp.html) and PowerPro (http://powerpro.webeddie.com/) - and experienced the same difficulty.  I found a setting in Power Pro which allows one to exclude icons, and the speed of menu display increased drastically.

It seems safe to conclude, then, that the displaying of icons is likely at the heart of this issue.  I should add that, to the best of my knowledge, there were no unresolved links in the folders I was attempting to display (although my test of LBC was a month ago, and I have made some changes to the folders in question since then), so I don't think that was a factor in my case.  Most of the folders involved, though, did contain a large number of links, so that was likely was a factor in my case.

I should also add that I do miss seeing the icons - they help me to navigate to the application I'm looking for - and that PowerPro contains a huge number of functions I don't need, and is more difficult to configure than LBC.  But the workarounds suggested in the post above look too burdensome to me, so I'll probably stick with PowerPro for the time being.

I'm not smart enough to suggest any workarounds, but I will say that I'd prefer LBC to PowerPro if this issue is resolved, icons displayed or not, and that I appreciate the DonationCoder site and the people who run it...

Navigation

[0] Message Index

[#] Next page