New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type selection in browser takes too long stopping early #4170
Comments
As of 15e5373 the implementation has been changed to the built-in type ahead selection available in Mac OS X v10.5 (and later). This mostly happens with big listings. The Console log says
Need to dig further into this. |
Is there any chance that this gets fixed soon, or reverted back to use the previous code? It's really a big step back in usability. And it's not just big listings - sometimes even with just dozens of files in a directory. And it happens on OS X 10.5 as well. |
Or maybe the number of seconds until timeout could be made a preference setting, so that users who deal with lengthy listings are once again able to use this feature. |
This should be resolved as of 9610923. Please reopen if still an issue in the latest nightly build. |
This is very disappointing. From the initial comment I gather that code is (or was) available to fix this; but it is not being applied for some unknown reason. As someone who registered CyberDuck, seeing 18 months old bugs not getting fixed despite the appearance of a fix being readily available just sucks. |
Replying to [comment:9 udittmer]:
The issue is not as trivial as it might seem. With the patches referenced above performance was improved but apparently not enough for some configurations. |
Replying to [comment:10 dkocher]:
The first comment implies that the code that was working correctly was replaced by code that has problems. Would there be more to fixing the issue than reinstating the old code? |
It's been a few months without a reply, so I thought I'd ask again: Is there any prospect of the original code being reinstated, maybe as a user-selectable option? |
No, nothing has changed - it doesn't work. Still getting the following error in the system.log:
How would you like me to provide you with a test case? I'd be happy to run a debug version that produces whatever output you need to track this down. |
Nothing has changed as far as I can tell:
Selection does work sometimes, but more often than not, it doesn't. I can only state again that I'd be happy to run a debug version that produces whatever output might help you debug this. This was using Cyberduck 4.4 build 12661. |
Replying to [comment:18 udittmer]:
Is this still on OS X 10.6? |
Yes |
Please (again) test the latest snapshot build which has a generic regression fix to optimize table cell rendering. Sorry this issue is dragging on, but as this is not reproducible on later OS X versions (because the table view widgets have seen performance optimizations) I have little motivation to further optimize. Also, there is little I could do as the performance constraint depends on the number of method call the underlying OS X framework that implements type selection issues to our delegate. |
No, that doesn't work either - but thanks for trying. I understand the issue about not being able to support old OS X versions. The thing that irked me -and which gave me hope that a fix might be easy- was the very first comment in this thread, where you said that the old, fast matching code had been replaced by some Apple API that was slower. So I had a hope that the old code could simply be restored. I guess the time for that has passed by now. But once I upgrade to a newer OS X version and find that the matching still doesn't work I'll be back complaining some more :-) |
I'm seeing this exact problem using Cyberduck 4.4.3 (14140) and Mac OSX Mavericks 10.9.2. I get the same error in the console log. The hardware is a 2013 2.6GHz MBP Retina laptop. I'm about as maxed out as it's going to get for performance and latest updates, yet I still see this issue, which happens at the most maddening time, when you need to jump down a loooooong list of files. The directory that I reliably encounter this problem with contains 1800 files and folders. I would be glad to put together a test case for you to reproduce this issue. |
To reproduce:
What I expect to happen: I jump to a file starting with Z. What really happens: I stay at the originally selected line. An error message appears in the OS Console. |
Same here on 10.9.2 and 4.4.4. |
I used to be able to just start typing the name of the file or directory, but since upgrading to 3.4.1 (5780)/5780, sometimes it works and sometimes it just plays an error sound. I haven't figured out exact steps to reproduce, but it seems to happen more than half the time for me.
Attachments
Screen Shot 2014-04-15 at 1.09.00 PM.png
(2000.5 KiB)t.zip
(331.4 KiB)The text was updated successfully, but these errors were encountered: