#2957 Tk and dual/multihead on windows

obsolete: 8.6b2


As already posted to the mailinglist
(see: https://sourceforge.net/mailarchive/message.php?msg_id=29056120\)

Tk on windows appears to have a problem with screen dimensions on dual/multihead
system. This is the bug report as suggested by Jan Nijtmans.




  • Roland Schwingel

    Patch suggestment to fix dual/multihead issue on windows.

  • Roland Schwingel

    • assigned_to: chengyemao --> nijtmans
  • Roland Schwingel

    Assigned as wished to Jan Nijtmans.

  • Jan Nijtmans

    Jan Nijtmans - 2012-04-06

    Ronald, do you have some test code, to demonstrate this?

    Your proposal is committed to a new branch
    "bug-3512824", for anyone interested to be

    What I would like to know before merging this:
    - Does the same problem occur on UNIX as well?
    (Cygwin has a tk 8.5 port, which can be used
    as well to demonstrate this)
    - What possible unintended effect could this have
    on other applications which depend on the
    screen dimensions?

    So, test code would be handy here, even
    though it cannot be added to the test-suite,
    just a minimal script which can be
    executed manually, and which shows
    the difference before and after the patch.


  • Roland Schwingel

    testscript to be executed in wish to show screen coordinates.

  • Roland Schwingel

    Attached you find a small test script that hopefully helps to illustrate what the problem is.
    I used a native (mingw 64bit and 32bit) wish 8.6 to execute the script.

    It shows the current screen dimensions plus the current window geometry plus the current mouse coordinates.

    On my system I am having 2 monitors having fullhd resolution (1920x1080) each. I use them rotated by 90 degrees.
    So one screen has 1080x1920 resolution. My desktop size is therefore 2160x1920.

    With an unpatched native tcl/tk 8.6 the script shows a screen res of 1080x1920. When I move the window to the 2nd screen I see the mouse coordinates and the window geometry going > 1080 in x which is over the maximum screen width.

    With my patch it shows the correct desktop size and mouse/window coordinates are always below the maximum size.

    I hope this was what you were asking for.

    I also made the cygwin test using the vanilla wish/tk 8.5.11 from cygwin.
    Here my script reports the correct (full dualhead) screen resolution. No patch is needed here. Cygwin tk queries the screen size from the XOrg server which works correct here. The patch is only needed for native (mingw/MSVC) builds of tk.

  • Koen Danckaert

    Koen Danckaert - 2012-04-13

    Note that there are already a number of tickets about multiple monitor issues: #533519, #2257424, #2768586.
    The main reason why these were never solved is that coordinates may be negative on these systems (when the secondary monitor is to the left or top of the primary monitor), and Tk can't handle that. So when applying this patch, be careful that the situation doesn't get worse in these cases.

  • Jan Nijtmans

    Jan Nijtmans - 2012-04-13

    Thanks, danckart! I'll have a look at those first.

  • Jan Nijtmans

    Jan Nijtmans - 2012-04-13

    Koen, Roland,

    After having looked at #533519, proposing two
    possible fixes for that in branch bug-533519(-alt),
    I wonder if this patch is still necessary. An application
    can use [winfo vrootwidth] and [winfo vrootheight],
    to do proper clipping. Agreed?

    Yes, this example was exactly what I wanted. It shows that
    the behavior on UNIX is different from Windows, which
    shows that this is a portability bug.

  • Jan Nijtmans

    Jan Nijtmans - 2012-04-21

    Roland, could you please re-test branch bug-533519,
    now it's based on trunk again? It corrects
    the [winfo vroot??] function on Windows,
    and adapts the various coordinate clipping
    places to use the vroot limits in stead
    of the screen limits.

    I think that solves your problem too.

    Jan Nijtmans

  • Jan Nijtmans

    Jan Nijtmans - 2012-05-04

    With #533519 and #2768586 fixed,
    the remaining problem described here
    is a duplicate of #2257424.

    So closing this one.

  • Jan Nijtmans

    Jan Nijtmans - 2012-05-04
    • status: open --> closed-duplicate