Unresponsiveness, odd behavior in many dropdown boxes

[GoogleCodeExporter]

In the new table creation sheet, SP is very slow to update the view if you 
select a non-default 
table encoding or type by keyboard.  Make a new table, tab down to Encoding, 
and hit "u" to 
select the first non-default in the list.  On my system it takes two to three 
seconds before the 
dropdown is updated with UCS-2 - for something with only a dozen or so options, 
that seems 
exceedingly slow.  Moreover, I can't hit "u" again to pick the next option in 
the list (UTF-8, which 
in my opinion should be the first non-default on the list anyways).

The same behavior exists in table type in the same dialog. I've also found it 
in the "Field must be 
indexed to support auto_increment. Which index do you want to add for this 
field?" dialog, as 
well as the New Foreign Key dialog.

These fields should be as responsive as dropdowns on websites, and behave the 
same way.  A 
"state" dropdown is a good example (M and N are good choices as they each have 
several states).  
Selecting by using the arrow keys and hitting enter is as responsive as 
expected, just not by 
hitting the first letter of the dropdown box option.

Using r1480 on 10.6.1 (running on an 8-core 10GB tower with an SSD, so I think 
my machine 
isn't at fault here ;)

Original issue reported on code.google.com by firehed on 6 Nov 2009 at 4:12

[GoogleCodeExporter]

Curious - many of the fields and dialogs you describe are plain Cocoa elements 
- I can't replicate in the New 
Table dialog with 10.6.1 on a MBP 2.16GHz, rather slower than your machine ;)

I wonder if anything else is causing an issue - is anything logged in 
Console.app when this occurs?

Original comment by rowanb@gmail.com on 6 Nov 2009 at 4:32

[GoogleCodeExporter]

I don't see anything in the Console, but I'm not exactly sure where I should be
looking either. The default "console messages" screen doesn't show anything 
relevant,
at least. Filtering for SP only shows a few "auto discovered registration 
ticket"
lines, which I assume is about that keychain thing that was recently fixed.

For what it's worth, I also get the same behavior on my MBP as well (2.26Ghz 
C2D)

Original comment by firehed on 6 Nov 2009 at 4:41

[GoogleCodeExporter]

Longshot, but I have "Enable access for assistive devices" enabled in the 
Universal
Access prefpane to allow TextExpander to work. Maybe that's interfering? 
Turning it
off didn't appear to have an effect but I can't think of any other non-standard 
settings.

Original comment by firehed on 6 Nov 2009 at 4:45

[GoogleCodeExporter]

Aye, you're looking in the right place in Console.app - the reg ticket lines 
are from Growl, and are logged every 
launch… if there's nothing else listed, it's not something like that.

Good thought on the assistive devices - but I have that enabled too.  Hmm.  
Will keep prodding...

Original comment by rowanb@gmail.com on 6 Nov 2009 at 5:03

[GoogleCodeExporter]

I can’t replicate this behaviour either. As Rowan mentioned they are all 
standard Cocoa controls and apart from 
the possible causes mentioned I’m out of ideas of what could be causing it.

Original comment by stuart02 on 8 Nov 2009 at 10:45

[GoogleCodeExporter]

Yeah it's really strange and I've never seen anything like it before. For all I 
know,
it could be something weird only with nightlies because I don't have a dev 
machine.
Don't lose any sleep over it; it's probably a weird setting at my end and rarely
affects my day-to-day work anyways.

Original comment by firehed on 9 Nov 2009 at 12:19

[GoogleCodeExporter]

Is it possible for you to maybe create a dummy user account and try it out in 
that?
Just wondering if there could be any possible plugins/add-ons that may be 
interfering.

Also can you try download the latest nightly (http://nightly.sequelpro.com/) 
and see if the issue is still present?

Original comment by avenja...@gmail.com on 9 Nov 2009 at 11:02

[GoogleCodeExporter]

Posting this from a new test user account (standard, not admin, if it's 
relevant) with r1487 which is the latest 
nightly as of now - same issue.  Maybe I'll try from a clean install in a VM 
when I finally get a chance to set that 
up.

The only other thing I can think of is that my MySQL install is through MAMP so 
I'm connecting through a socket 
rather than host/port.  I can't see why or how that would affect things, but my 
development skills are firmly 
planted in the web realm rather than desktop apps so that doesn't mean much.

Original comment by firehed on 9 Nov 2009 at 11:32

[GoogleCodeExporter]

Thanks for the feedback. The encoding list and the majority of the others are 
hard coded as opposed to being 
dynamically populated using data from the server, so the connection should have 
no effect whatsoever.

Original comment by stuart02 on 9 Nov 2009 at 11:58

[GoogleCodeExporter]

Thanks for that. I have another test for you if at all possible. If you have 
another machine on the network with 
Sequel Pro running, can you can try connect to the MAMP server running on your 
MacPro? This should help 
determine if its machine related or MAMP related.

Many thanks again for putting your time into this. Very much appreciated.

Original comment by avenja...@gmail.com on 10 Nov 2009 at 12:13

[GoogleCodeExporter]

Using my laptop to connect to the desktop with SP has the same issue. I'm 
trying to
also test with a linux vm but the darn thing refuses to allow non-localhost
connections even after making the right changes my my.cnf. Ugh.

The machines are pretty much identical from a software perspective - 10.6.1, 
MAMP Pro
1.8.x (MySQL 5.1.37) and current nightlies of SP.

Original comment by firehed on 10 Nov 2009 at 3:36

[GoogleCodeExporter]

So logging into ur Mac Pro from ur laptop with Sequel Pro still shows the same 
issue?

Mmm ok I've just tried it as well on my MBP (10.5.8) MySQL server and i'm sorta 
getting something similar. 
However its not 2-3 seconds more like 1-1.5 seconds before selected. Definitely 
a noticable lag.

Will do more detective work and get back to you. Thanks again

Original comment by avenja...@gmail.com on 10 Nov 2009 at 6:45

[GoogleCodeExporter]

Ok. so I just checked something in Safari and iChat Prefs.

In Safari in the General settings if I tab to say the "Remove history items:" 
popup and press "m" to select 
Manually I'm seeing the same delay. Pressing "a" to select "After one day" 
results in the same thing.
In iChat prefs tabbing to a popup such as the Buddy Alert popups I also see the 
delay.

Soooo....can I get you to please try the above and see if you're getting delays 
in other programs as well and 
not just Sequel Pro.

Regards

Ben

Original comment by avenja...@gmail.com on 10 Nov 2009 at 6:50

[GoogleCodeExporter]

Indeed I am! Never noticed as the ones *in* the browser don't do it, but Safari 
prefs
exhibits the same behavior (interestingly, Firefox prefs doesn't)

Original comment by firehed on 10 Nov 2009 at 7:14

[GoogleCodeExporter]

I'm seeing it all over the place. System Preferences etc.

I haven't got firefox installed, but I imagine the prefs may not be a standard 
cocoa GUI but I could be wrong.
Similarly iTunes prefs don't even let you select an item in a popup using the 
first letter. You can use arrows 
though.

Looks like this isn't an Sequel Pro issue after all.
Are you happy if we mark this Won't Fix and close it?

Regards

Original comment by avenja...@gmail.com on 10 Nov 2009 at 7:27

[GoogleCodeExporter]

Go for it - I'll file a bug report with Apple. Hopefully they'll figure 
something out :)

Original comment by firehed on 10 Nov 2009 at 2:26

[GoogleCodeExporter]

Marking as “Won’t Fix” as this does not seem to be specific to Sequel Pro.

Original comment by stuart02 on 10 Nov 2009 at 10:15

• Changed state: WontFix