#162 ✓hold

Window#bring_to_front doesn't work in linux

Reported by Roger | February 18th, 2010 @ 12:46 AM

Haven't figured out how to get this working right in Linux yet--currently it just flashes the bar in the taskbar.
This is more of a note to myself :)

Comments and changes to this ticket

  • Daniel Lucraft

    Daniel Lucraft February 18th, 2010 @ 12:48 PM

    • State changed from “new” to “open”
  • Roger

    Roger February 23rd, 2010 @ 02:59 AM

    • Tag changed from linux to linux, windows

    seems that force_active...doesn't really even try to work on Linux.

    Opening a new window does work, though, to bring a window to the foreground.


    always open a new window (might be our only option in linux)

    open a new window, when it opens (in the foreground), leverage it to open the "real" shell we want.

    create a window that is "always on top" and invisible and leverage that somehow to open the "real" shell we want.

    temporarily make the shell we want "always on top" (+- setFocus, etc.) then set it to be "not always on top" and see if that causes it to stay forward.

    Report a bug upstream to swt.

    Window appears to also have a similar problem


    Which I might try to combat with ffi [1] (and/or submitting a patch upstream) sometime.


    [1] http://wiki.github.com/ffi/ffi/windows-examples and http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=[o]%20Open-Sou... (forceForegroundWindow)

  • Daniel Lucraft

    Daniel Lucraft March 14th, 2010 @ 11:32 AM

    I suspect this is not a bug in SWT so much as one of the things that window managers get to choose behaviour for. Flashing the taskbar on linux and windows may be the 'correct' behaviour for that platform.

    Whether we want to go with that or do something similar to the FFI thing on linux as well is the question.

  • Roger

    Roger March 15th, 2010 @ 02:09 PM

    Yeah I'm not sure how to work around it in gnome...not even minimizing
    the window then unminimizing it seems to work (which works in doze).
    I might be able to get
    some traction from making the window "always on top" temporarily or
    what not--I just don't use Linux enough for it to annoy me enough to
    attempt [yet].

    The only other option is for Linux to "always re-use the open window" for opening things. That actually might work ok, but then it wouldn't be exercising Redcar's cool "able to have multiple open windows" ability, so I'm a bit torn...


  • tim.felgentreff (at student.hpi.uni-potsdam)

    tim.felgentreff (at student.hpi.uni-potsdam) February 19th, 2011 @ 12:24 PM

    • State changed from “open” to “hold”
    • Milestone order changed from “0” to “0”

    Are we going to fix this? I think the current behaviour is simply "correct" for DMs - according to the freedesktop specifications, it's up to the window manager to ultimately decide if a window requesting activation should be brought to front or if another means of getting user attention should be used. IF we work around this, we break that expected behaviour.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

A programmer's text editor for Gnome.