Unfortunately, it seems that the Spell Catcher X input method causes BBEdit to slow down quite a bit. Even disabling all interactive features for that application doesn't help; only shutting off the input method from the input menu fixes it.
However, the SCX input method is all-or-nothing; if it's on, it's on for all apps, and if it's off, it's off. So, when switching to BBEdit, I go and disable it, and then I forget to re-enable it when I go do something else.
Would it be possible to have the input method activation excluded on a per-application basis? I don't even know if this is something within the realm of SCX's control, but it sure would be nice.
0
Input method, per-application
Started by jeremy, Feb 13 2004 09:32 PM
3 replies to this topic
#2
-
- Admin
-
- 2,986 posts
Administrator
- Gender:Male
- Location:Toronto, Canada
- Interests:This Place!
Posted 13 February 2004 - 10:44 PM
jeremy, on Feb 13 2004, 09:32 PM, said:
Unfortunately, it seems that the Spell Catcher X input method causes BBEdit to slow down quite a bit. Even disabling all interactive features for that application doesn't help; only shutting off the input method from the input menu fixes it.
However, the SCX input method is all-or-nothing; if it's on, it's on for all apps, and if it's off, it's off. So, when switching to BBEdit, I go and disable it, and then I forget to re-enable it when I go do something else.
Would it be possible to have the input method activation excluded on a per-application basis? I don't even know if this is something within the realm of SCX's control, but it sure would be nice.
However, the SCX input method is all-or-nothing; if it's on, it's on for all apps, and if it's off, it's off. So, when switching to BBEdit, I go and disable it, and then I forget to re-enable it when I go do something else.
Would it be possible to have the input method activation excluded on a per-application basis? I don't even know if this is something within the realm of SCX's control, but it sure would be nice.
The Spell Catcher app *could* theoretically detect the change in active application and toggle the input method on or off - that is IF there was a way to actually reliably do this. I say reliably because there IS a way to do it, but it just plain out doesn't work right. Works better on Panther, works really poorly on Jaguar.
As for the BBEdit thing, I've used it there quite a bit and never noticed a performance issue. What kind of hardware are you using? There may be a little tweak that can be made with the input method tuner to make this better - but I think it would be a trade off of sorts. You'd get between speed at the expense of slightly incorrect behavior in certain situations (not crashing, just missed or doubled characters or something like that).
Use the Send Feedback command if you want to explore this. If you know how to use PropertyListEditor, I can give you something simple to do yourself.
#3
-
- Members
-
- 42 posts
Member
Posted 13 February 2004 - 11:07 PM
(Yikes, this forum posting page seems to have some Javascript or something that catches keystrokes that Cocoa programs like Safari use for text editing... I kept getting weird tags in my text that I didn't ask for, and it finally crashed Safari completely, so I'll retype my post...)
I'm using two different machines, a 500Mhz G4 Powerbook, and a dual-1Ghz-G4 Powermac. The slowdown in BBEdit is not significant on the desktop machine, but on the laptop it makes editing downright annoying. Disabling the SCX input method clears it right up.
If your machines are all faster you would probably have to do a side-by-side taste-test to notice the slowdown, now that I've looked at the effect on my faster desktop machine. It manifests most annoyingly when moving the cursor using keyboard commands. It's only BBEdit, so I figured it must be unique to that application. I prefer using Cocoa apps anyway, for the text editing features and because I prefer to have my spellchecker stick in those way-cool red underlines for mistakes. (I really, really wish I could have that in MS Word with SCX rather than just with the built-in checker.)
I'll drop you an email tonight or tomorrow, I'd be happy to try a tweak and I'm not afraid of property lists.
I'm using two different machines, a 500Mhz G4 Powerbook, and a dual-1Ghz-G4 Powermac. The slowdown in BBEdit is not significant on the desktop machine, but on the laptop it makes editing downright annoying. Disabling the SCX input method clears it right up.
If your machines are all faster you would probably have to do a side-by-side taste-test to notice the slowdown, now that I've looked at the effect on my faster desktop machine. It manifests most annoyingly when moving the cursor using keyboard commands. It's only BBEdit, so I figured it must be unique to that application. I prefer using Cocoa apps anyway, for the text editing features and because I prefer to have my spellchecker stick in those way-cool red underlines for mistakes. (I really, really wish I could have that in MS Word with SCX rather than just with the built-in checker.)
I'll drop you an email tonight or tomorrow, I'd be happy to try a tweak and I'm not afraid of property lists.
#4
-
- Admin
-
- 2,986 posts
Administrator
- Gender:Male
- Location:Toronto, Canada
- Interests:This Place!
Posted 13 February 2004 - 11:21 PM
jeremy, on Feb 13 2004, 11:07 PM, said:
(Yikes, this forum posting page seems to have some Javascript or something that catches keystrokes that Cocoa programs like Safari use for text editing... I kept getting weird tags in my text that I didn't ask for, and it finally crashed Safari completely, so I'll retype my post...)
I'm using two different machines, a 500Mhz G4 Powerbook, and a dual-1Ghz-G4 Powermac. The slowdown in BBEdit is not significant on the desktop machine, but on the laptop it makes editing downright annoying. Disabling the SCX input method clears it right up.
If your machines are all faster you would probably have to do a side-by-side taste-test to notice the slowdown, now that I've looked at the effect on my faster desktop machine. It manifests most annoyingly when moving the cursor using keyboard commands. It's only BBEdit, so I figured it must be unique to that application. I prefer using Cocoa apps anyway, for the text editing features and because I prefer to have my spellchecker stick in those way-cool red underlines for mistakes. (I really, really wish I could have that in MS Word with SCX rather than just with the built-in checker.)
I'll drop you an email tonight or tomorrow, I'd be happy to try a tweak and I'm not afraid of property lists.
I'm using two different machines, a 500Mhz G4 Powerbook, and a dual-1Ghz-G4 Powermac. The slowdown in BBEdit is not significant on the desktop machine, but on the laptop it makes editing downright annoying. Disabling the SCX input method clears it right up.
If your machines are all faster you would probably have to do a side-by-side taste-test to notice the slowdown, now that I've looked at the effect on my faster desktop machine. It manifests most annoyingly when moving the cursor using keyboard commands. It's only BBEdit, so I figured it must be unique to that application. I prefer using Cocoa apps anyway, for the text editing features and because I prefer to have my spellchecker stick in those way-cool red underlines for mistakes. (I really, really wish I could have that in MS Word with SCX rather than just with the built-in checker.)
I'll drop you an email tonight or tomorrow, I'd be happy to try a tweak and I'm not afraid of property lists.
This same special case is also made for Internet Explorer, and AOL for the same basic reasons. But the performance impact all depends on the application's implementation of their TSM input-from-an-input-method routine (UpdateActiveInputArea if you care to know). BBEdit does it via AppleEvent, not CarbonEvent, so that's probably the main reason for the slowdown. TSM has to convert the UAIA CarbonEvent into an AppleEvent every keystroke.
Still, SCX and BBEdit will get along (for the most part - there are a couple of little things) if you turn that special handling off. Your mileage may vary. We have to opt for compatible vs. fastest most of the time...
(And this forum software is written almost entirely in PHP. Probably has some JavaScript, but I've NEVER heard of it crashing Safari! If you can reproduce that, let me know).
