Re: What is hijacking Konsole?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Mon, Oct 31, 2011 at 02:18, Duncan <1i5t5.duncan@xxxxxxx> wrote:
> Tut, tut! As a reasonably regular poster you should know by now that
> some hint as to kde/app version should be included, just in case the
> behavior changed between versions. =:^) (By the same token of being a
> regular poster, however, I know that you're on at least a semi-recent
> kde4, tho it's unlike to be current upstream 4.7. But one really
> shouldn't have to look at the from header and recall that name's posting
> history to deduce that, as among other things, it reduces the
> transparency of the list for newbies. Not that the version is likely to
> matter here, but by the very token that you're posting a question about
> it, you can't know that for sure or you'd not be posting. And perhaps
> it /will/ turn out to be version dependent in some way, tho I doubt it,
> but I don't know either at this point.)
Ah, yes, sorry. In fact this is KDE 4.7.2. I'm usually more careful
about mentioning that.
> But addressing the question...
> You indicate Ctrl-F, upper-case F. Since for obvious reasons (conflict
> with whatever's running inside without it) konsole's default shortcuts
> (almost) all have the shift modifier and indeed, Ctrl-Shift-F is the
> default "Find" shortcut, in context, there's some doubt as to whether you
> mean Ctrl-Shift-F or simply ctrl-f.
You bring up a good point. I do mean lower-case F, I use the
upper-case letter when mentioning the shortcut because א) it is easier
to discern an upper-case letter by itself, ב) that is what the Konsole
shortcuts menu shows, and ג) that is what is written on the keyboard!
In my opinion using upper-case F would be a triple whammy and
deserving of the full Ctrl-Shift-F name!
> I'm assuming ctrl-f, since presumably you'd have found the find shortcut
> listed in konsole's menus and/or in the shortcut dialog and thus wouldn't
> have posted to ask about it. With that assumption and further assuming
> that you /have/ checked the shortcut dialog, just in case...
Correct assumption,... sorry for making you go through it though!
> If ctrl-f isn't listed in konsole's shortcut dialog, then it's a
> reasonably safe deduction that it must be being grabbed either above
> konsole, before konsole sees it, or below, in whatever app is running in
> konsole. I'll assume (yes, the assumptions ARE beginning to stack up at
> this point, but...) that you've tested in enough in-konsole apps to know
> that it's not that, which by exclusion leaves only the above-konsole/
> global grab possibility.
Yes, I did get this far. I checked in a new Konsole with nothing
running in it. That much I did not see fit to share but maybe I should
> That means... check global and custom shortcuts in kde settings, plus
> anything else (media players, etc, often have global-grab shortcuts) that
> you might have set a global shortcut in.
Right. Done that. Again, I should have been explicit.
> I can make a few observations that might help narrow down the search.
> 1) Ctrl-f is a default kde "standard shortcut" (common to most kde apps
> where it would apply, with exceptions like konsole for the above noted
> conflict reasons, so it uses the shifted variant) for "Find...". As
> noted, konsole is an exception, but what we're interested in here is that
> since ctrl-f is a standard kde shortcut already, it's quite unlikely to
> be a default for anything else kde related, especially as a global
> By exclusion, that means it's probably either a non-default setting, or a
> non-kde app that is doing the grab.
That is what I was afraid of. However, being a new install I did not
see what it could be.
> 2) The fact that it's an xterm that opens ALSO strongly suggests that
> whatever's doing the grab either isn't KDE related, or is a non-default
> setting of something kde. Because if it was kde, it whould be a konsole
> window opening by default, not xterm.
> 3) As a followup on #2, what do you have set as your default terminal
> emulator (kde settings, workspace appearance and behavior, default
> applications, terminal emulator)? Presumably it's konsole or we'd not be
> having this discussion, but that xterm's coming from somewhere, and this
> is one more kde angle to check.
It is in fact Konsole.
> 4) Similarly, consider file associations (kde settings, common appearance
> and behavior, file associations). It's quite possible that whatever's
> getting triggered is from a broken file association, possibly of a mis-
> parsed longer command that would normally be launching something /in/
> xterm, but being broken... Again, this wouldn't be a kde default
> association as that would be konsole instead of xterm, but consider libre
> office / OOo associations, for instance, as well as (again) non-kde media
> players, etc.
That is one that I did not think to check. Thanks.
> 5) Does ctrl-f behave as expected in non-konsole X-based apps? In kwrite,
> for instance, and konqueror, ctrl-f should trigger a find, by default.
Actually, only after I posted did I even think to check of Ctrl-F's
behaviour in other apps! For me it is a given that Ctrl-F is Find,so
ingrained that I wouldn't even need to check it universally. I was
naive and young then!
> Normally a global shortcut would apply everywhere and you'd get an xterm
> instead in those cases as well, but it's also possible to confine an
> otherwise global shortcut to only a specific app/window. KDE custom
> shortcuts (under kde settings common appearance and behavior, shortcuts
> and gestures, custom shortcuts), for instance, can be set to only trigger
> if a particular window is active, thus allowing them to be used as macro
> triggers (a shortcut to insert a boilerplate fileheader in source files,
> for instance, but that will only trigger if you're running your customary
> source editor). If the trigger only works in konsole, perhaps it's
> something like this.
> 6) As you obviously have xterm installed... it might be worth seeing if
> ctrl-f is doing strange things in it, as well. #5 covers this to some
> degree already, but it's an easy test that will give you another
> datapoint, so...
> 7) This should have been covered under the assumptions above, but just in
> case... What happens if you run whatever app in a text-mode VT instead
> of a terminal emulator under X? The assumption would be that ctrl-f
> works fine in that case, but it's worth checking, if you haven't.
> 8) If all else fails, try the bisect method. Of course the first step is
> checking with a different user or with all the config files normally
> found in ~/ temporarily moved out of the way for testing. If it's
> happening in an all-defaults user, you /really/ have a head-scratcher...
> I'd post to the distro list in that case, but if a clean user config
> kills the strange behavior as well, then you at least know it's for sure
> in your user config, and can bisect it down from there.
> Hopefully these will help you find the culprit. As the above makes
> clear, evidence points to it NOT being konsole or even kde related, at
> least as a default setting, but that doesn't mean I can't try to help.
> Please post a followup with the culprit, once you find it, as you've
> gotten me curious as well, now. =:^)
The truth is, I would have never found it if Zorael had not mentioned
it. I had set up and used xbindkeys so long ago and stopped using it
in my previous install. For some reason (I think that I know why,
actually) it got reenabled in the new install but with this default
config that had never popped up before. I would have never located
Thank you for the insightful troubleshooting methodology! We have
similar style, but you are without a doubt more thorough and careful!
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
[Red Hat Install]
[GIMP for Windows]
[Red Hat Development]