After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 792615 - Combo box bug with Remote Desktop
Combo box bug with Remote Desktop
Status: RESOLVED DUPLICATE of bug 777527
Product: gtk+
Classification: Platform
Component: Backend: Win32
3.22.x
Other Windows
: Normal critical
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2018-01-17 18:01 UTC by Dean
Modified: 2018-01-17 20:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dean 2018-01-17 18:01:16 UTC
With 3.22.26 built for python 3.6 on a Windows 7 environment, the screen/monitor location seems to be messed up when using the GUI through a Windows Remote Desktop Connection.  This is seen with comboboxes specifically that the dropdown windows only show up at the top left corner of the view with a very small, empty box.  Pixman is complaining that negative height/widths are being reported for the size.  Also, if I trying to get the height/width of the monitor using

displayGeometry = self.get_toplevel().get_display().get_monitor_at_point(dropDownXCoord, dropDownYCoord).get_geometry()

it returns 0 for height and width.  On the local destop, the reported height and width are correct.
Comment 1 Dean 2018-01-17 18:05:10 UTC
My accessing of the screen height from the monitor geometry get above is used for a custom entry box I created with history items and auto completion.  The height is checked to determine if the dropdown should be displayed above or below the entry box.  It is only displayed above the entry box if the bottom of the dropdown would exceed the bottom of the screen/monitor.  This was working fine locally but I found that it was always displaying above the entry box when viewing remotely which lead me to print out the height/width.
Comment 2 LRN 2018-01-17 18:12:51 UTC
How many monitors are attached to that Windows 7 system?
Comment 3 Dean 2018-01-17 18:14:44 UTC
2
Comment 4 LRN 2018-01-17 19:07:49 UTC
There was a bug in monitor pruning code that affected systems with more than 1 monitor. It was fixed, but the fix was after 3.22.26 (specifically, commit 30ddb3e1a4233ecd6e37c3c26a56f2d413f5d8d7).
There's some steps you can do to investigate this:
1) Try disconnecting one monitor, and see if anything changes (you might need to restart the program; i'm not sure how well monitor re-enumeration is currently supported)
2) Try re-compiling 3.22.26 after applying the comment i mentioned earlier and see if it fixes your issue.
Comment 5 Dean 2018-01-17 19:49:49 UTC
That patch fixes the issue.  Thank you very much!  I would hope this would be applied to the next 3.22 release, but in the meantime, it will continue to apply the patch.  Do you want me to mark this as a duplicate or will you?
Comment 6 LRN 2018-01-17 20:43:13 UTC

*** This bug has been marked as a duplicate of bug 777527 ***
Comment 7 Daniel Boles 2018-01-17 20:45:04 UTC
(In reply to Dean from comment #5)
> I would hope this would be applied to the next 3.22 release

It was applied to the gtk-3-22 branch, so it's in the next release by definition.