Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1 Applet pops windows on wrong display

closed-accepted
Grant McLean
None
5
2007-11-02
2007-09-07
Michael Kellen
No

I'm running sshmenu (3.14-1 package) on Ubuntu (Feisty Fawn). I have two monitors, running in a MergedFB configuration (shared mouse and keyboard, but separate DISPLAYs -- :0.0 & :0.1).

Regardless of which DISPLAY's gnome-panel contains the SSH Menu applet, all windows (including the menu, the alerts, the dialogs and the gnome-terms) are displayed on the :0.0 screen.

This is not the only app where I have seen this, but it was the only one where I cared ;-)

I did some digging and found this thread which suggests that this is a bonobo problem:

http://lists.freedesktop.org/archives/dbus/2004-January/000675.html

I was able to confirm that the applet was (incorrectly) always reporting :0.0 as the DISPLAY when it was run from the panel. The app works just fine stand-alone. I would have just used gnome-swallow, but it has the same problem.

Having absolutely no Ruby experience, I'm afraid I kludged together an icky hack using a global variable to correct the setting everywhere it was needed. It forces the windows to appear on the screen where the event that created them originated.

Discussion

  • Michael Kellen
    Michael Kellen
    2007-09-07

    Corrects DISPLAY using global variable

     
    Attachments
  • Grant McLean
    Grant McLean
    2007-09-12

    Logged In: YES
    user_id=242694
    Originator: NO

    Looks like you're a natural at this Ruby coding - all you need to do is kick the habit of putting $ in front of variable names :-)

     
  • Grant McLean
    Grant McLean
    2007-09-12

    • assigned_to: nobody --> grantm
     
  • Michael Kellen
    Michael Kellen
    2007-09-12

    Logged In: YES
    user_id=214056
    Originator: YES

    Hey, I am coming from the Perl universe ... $ is a way of life.

    Seriously though, is there an elegant way to share this value across the several classes that need to know it? I *did* say it was an ugly hack ... but not so ugly that I'm willing to debug bonobo. ;-)

    Anyway, at some point I'll figure out how to load a DISPLAY specific config file so that I can stop having to write a second subclass to specify a different "default" config for the other screen (I currently subclass gnome-sshmenu.rb to have a different default config file so that I can have separate menus on each display ... this lets me segregate the workside connections to the CRT on my desk and keep my home network on the laptop screen).

     
  • Grant McLean
    Grant McLean
    2007-10-18

    Logged In: YES
    user_id=242694
    Originator: NO

    Hi Michael

    I have tried unsuccessfully to reproduce the problem you had with
    SSHMenu popping up on the wrong diaplay. In the end, I integrated
    your patch anyway as it didn't seem to cause any harm. I omitted
    to mention this in the Changes file when I built the release, but
    it is in release 3.15. Let me know if it works for you.

    Cheers
    Grant

     
  • Grant McLean
    Grant McLean
    2007-10-18

    • status: open --> pending-accepted
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
    • status: pending-accepted --> closed-accepted