Announcement

Collapse
No announcement yet.

xterm + kde + gtk focus glitch

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [SOLVED] xterm + kde + gtk focus glitch

    I used to be a gnome-terminal fan, with Kubuntu, because konsole's cursor blink rate is far too slow.
    But, I've just upgraded to Oneiric from Lucid, and gnome-terminal and kwin don't get on, and the gnome-settings-daemon (required to tell gnome-terminal the blink rate) runs only fitfully if at all.

    So, since Kubuntu kindly gave me the hint to use xterm by putting it on the system menu, I've checked out xterm. It's pretty good, with
    Code:
    xterm -bc -bcf 200 -bcn 200 -sb -geometry 80x60 -bg black -fg cyan
    but it has a very annoying problem: when starting gtk based gui programs like gvim or gedit or firefox, the focus usually stays with the xterm window, sometimes even with the new window going behind the xterm. Not a problem for k apps, and only happens with xterm under KDE.

    Anyone shed light on this?

    Is there a way to tell kwin which window should have focus? I imagine that this is kwin's responsibility.

    Maybe I'll just have to try konsole again, with the ancient hack of blink.c (see /usr/share/vim/vim73/tools/blink.c if you've got gvim installed).
    Regards, John Little

    #2
    Try
    Code:
    [i]command[/i] &disown

    Comment


      #3
      Originally posted by steveriley View Post
      Try
      Code:
      [i]command[/i] &disown
      No, that didn't work; the xterm still has the focus; disown is a bash builtin and works on bash, but my problem is at the window manager level.

      (Incidentally, my approach using konsole with a blink programme is holding up, and I use disown in my .bashrc to hide it from bash job control.)
      Regards, John Little

      Comment


        #4
        My simple test involved nothing more than opening a terminal and running a GUI program. In Konsole, starting GUI programs hands control to the program, as you mentioned. Then I installed xterm and ran a GUI program -- kcalc -- and noticed the behavior you described. When I tried kcalc &disown, control handed off to the calculator. I wonder why we're observing dissimilar behavior?

        Comment


          #5
          Originally posted by SteveRiley View Post
          Then I installed xterm and ran a GUI program -- kcalc -- and noticed the behavior you described. When I tried kcalc &disown, control handed off to the calculator. I wonder why we're observing dissimilar behavior?
          I don't get the behaviour with kcalc, only with gtk apps. Adding & disown makes no difference, either to kcalc or gvim. gvim "disown"s itself anyway (close the terminal, fork, set process group and so on).
          Regards, John Little

          Comment


            #6
            Originally posted by jlittle View Post
            I don't get the behaviour with kcalc, only with gtk apps.
            Ah, there's the difference, and yes, I see now you even mentioned that in your original post.

            Comment


              #7
              Well, in case anyone finds the thread, I've just stumbled on a workaround.

              I noticed that if I start xterm from konsole, the focus glitch did not occur. Investigating, I ran env | sort in an xterm started from konsole and diffed the results with xterm started from the K menu, and found:

              DESKTOP_STARTUP_ID=solomon;1334389409;810229;1617_ TIME2396976

              if I unset it, and start gvim, gvim gets and keeps the input focus.

              This is part of the Desktop Entry Specification's startup notification protocol,
              at http://www.freedesktop.org/wiki/Spec...ification-spec. It says

              It is suggested to unset this environment variable in the launchee as soon as it's read, to avoid possible reuse by some process started later by launchee.
              Maybe this is what happens. If it is, it's not vim code that does it, but presumably gtk. Disabling launch feedback in the KDE menu editor has no effect.

              Maybe xterm should follow the suggestion, though xterm has to work at a lower level than desktops so maybe not. I might have a look around the xterm project, or mention it in the vim dev mailing list (the xterm maintainer has been seen there).
              Regards, John Little

              Comment

              Working...
              X