Here I am attempting to expand the DDL and select one of the options. I spied and built my BP application on my monitor and when testing on my laptop all the regions are slightly off. All elements spied in Browser mode are fine. In the region editor I have tried changing the Location Method to Image and the Position to Anywhere, which works when the using the monitor and the view has scrolled but unfortunately this does not resolve the region issues on my laptop. I have checked previous threads and I don't think zoom is the issue.
Highlighting the region when using my monitor:
Highlighting when on laptop:
Does anyone have any suggestions?
Thanks
This typically happens for zoom settings on your browsers. Double check your zoom is set to 100% for both browsers.
Can confirm on my machines the zoom settings are different but then align when both set to 100% zoom.
For using region mode we have to check the following things to make sure it works a correctly.
Screen resolution used while spying a region. Set the same screen resolution while running the process.
Use the tolerance property 60%.
If image is not visible on screen, use some static labels and spy them first through html mode. Focus the label, so that the region element gets visible in screen
Region mode elements takes time to identity. make sure to apply appropriate wait time.
Related
I have a multi-monitor config that duplicates the task bar on each monitor. I also have an application with an icon in the taskbar (thus it shows on all monitors), and I'd like this application to behave differently depending on which monitor the click came from.
Is it possible to determine which monitor's taskbar was used to launch that app? I would just need the API function names (rather than actual code).
Thanks!
Whether or not what I asked in my OP is possible, I found a way to do what I want: Immediately upon launch, I obtain the current mouse position in absolute coordinates. This allows me to determine which monitor the mouse is on, which is almost certainly the monitor holding the taskbar icon used to launch the application.
I'm working on a UWP project which uses the MapControl.
After updating to the Creator Update for Windows 10, the mapcontrol behaves in unexpected and undesired ways:
I update the heading and center almost constantly, but this now causes the zoomlevel to change slowly over time.
And when I change the mapstyle, it zooms out by a lot. (But this seemingly only when I update either/both the heading and/or center)
I have no idea why this is happening or how to avoid it.
Any help appreciated.
This is a bug that is currently being investigated.
As a workaround, rather than independently setting zoom and center, try using the SetScene API.
like this:
TrySetSceneAsync(MapScene.CreateFromLocationAndRadius(newCenter, newRadius, heading, pitch), MapAnimationKind.Linear);
https://learn.microsoft.com/en-us/uwp/api/Windows.UI.Xaml.Controls.Maps.MapControl#Windows_UI_Xaml_Controls_Maps_MapControl_TrySetSceneAsync_Windows_UI_Xaml_Controls_Maps_MapScene_
I'm working on an existing React-Native app, and in the iOS version, there's a problem where a portion of the bottom of the screen does not respond. At first it was thought to be on a specific screen, but upon further investigation, it was found to be affecting other screens as well. The control used on the first screen where the problem was noticed is TouchableOpacity, but a rectangular section in the middle at the bottom of the screen does not respond, but in either corner at the bottom of the screen it does respond. Another screen has a ListView, and if you attempt to scroll from that same bottom middle area, it won't, but everywhere else, it will. This is evident in both the simulator and on the physical device. It acts like there's something in the road floating over the top of everything.
I've tried using the Accessibility Inspector to identify the cause, but this hasn't revealed anything.
The highlighted area in the screenshot above is where I'm referring to.
To complicate things further, this problem doesn't exist in the Android version.
Has anyone experienced this before, and if so, what was the cause and how do I fix it?
Edit: I've now determined the cause is an Animated View that's hanging about, it seems not all the child elements within it are having their opacity set to 0. I've attempted to address this using pointerEvents, but this just moves the problem to a different child element.
Anyone have any suggestions?
The issue turned out to be that the parent was having it's height changed during the show and hide events to avoid this same issue in Android, so we need to only change it if the platform is Android.
this.setState({height: (Platform.OS === 'ios') ? 50: 0});
I would like to draw some sort of window on top of all the other windows. For example, to display some debugging infos (like conky) or things like a timer.
The main thing is that I would like to able to continue using the other windows while using it (the events go through transparently).
I've tried doing it with pygtk, pyqt and others but can't find a way to make it a real overlay with no event capture.
Is there some low-level x11 solution?
I think the Composite-extension-approach will not work when a compositing manager is running (and thus Composite's overlay window is already used).
Since you explicitly mention "no event capture":
The SHAPE extension allows to set some different shapes for a window. Version 1.1 of this extension added the "input" shape. Just setting this to an empty region should pretty much do what you want.
Some concrete example of exactly what I think you ask for can be found in Conky's source code: http://sources.debian.net/src/conky/1.10.3-1/src/x11.cc/?hl=769#L764-L781
Edit: Since you said that you didn't find anything in Gtk (well, PyGtk), here is the function that you need in Gtk: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-input-shape-combine-region
You might need Composite extension + GetOverlayWindow request:
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
CompositeGetOverlayWindow returns the XID of the Composite Overlay
Window. If the window has not yet been mapped, it is mapped by this
request. When all clients who have called this request have terminated
their X11 connections the window is unmapped.
Composite managers may render directly to the Composite Overlay
Window, or they may reparent other windows to be children of this
window and render to these. Multiple clients may render to the
Composite Overlay Window, create child windows of it, reshape it, and
redefine its input region, but the specific arbitration rules followed
by these clients is not defined by this specification; these policies
should be defined by the clients themselves.
C api : XCompositeGetOverlayWindow
PyGTK Solution:
I think the composite and shapes X extensions are sufficiently ubiquitous and shall assume here that they are active on your system. Here's PyGtk code for this:
# avoid title bar and standard window minimize, maximize, close buttons
win.set_decorated(False)
# make the window stick above all others (super button will still override it in the z-order, which is fine)
win.set_keep_above(True)
# make events pass through
region = cairo.Region(cairo.RectangleInt(0, 0, 0, 0))
my_window.input_shape_combine_region(region)
win.show_all()
# set the entire window to be semi-transparent, if we like
win.set_opacity(0.2)
Basically what this does is tell Gtk that other than pixel (0,0) the entire window my_window should not be considered part of itself in terms of event propagation. That in turn, according to my current understanding means that when the pointer moves and clicks, the events go to the underlying window under the pointer position, as if my_window was not there.
Caveat:
This does allow your overlay window being the focus window (due to user-solicited window switching or just because it pops up and gets the focus when your application starts). Which means that for example, keyboard events will still undesirably go to it up until the user has clicked through it to make it lose focus in favor of whatever window is under the cursor. I would likely use the approach described here to iron out this aspect.
If there's a different and proper approach for making a portion of the screen "display stuff but not receive events", without building an oddball window like above over it, I'm happy to learn about it.
I assume that one's particular desktop environment (gnome, unity, etc. on linux) may interfere with this solution depending on version and configuration, on some occasions.
I am using xmonad (with minimal configuration, main = xmonad gnomeConfig{ modMask = mod4Mask, terminal = "gnome-terminal" }) and my computer has two monitors and I am using xinerama.
This works, but way too often I am surprised by the mapping of xmonad screens to monitors,
when pushing a window to a screen (shift-mod-N) or moving focus to a screen (mod-N).
Also, mate-panel shows window symbols on virtual screens symbols - but something is not right there (these virtual screen seem to have double width, I guess because it's one X screen)
What is the right mental model for this?
(Is there a magic key that shows the screen number of the current (focused) window?)
NOTE (suggested by answers below): in xmonad lingo, a window is on a workspace, and a workspace is mapped to a (physical) screen.
The XMonad.Actions.PhysicalScreens documentation says the following:
This module allows you name Xinerama screens from XMonad using their
physical location relative to each other (as reported by Xinerama),
rather than their ScreenID s, which are arbitrarily determined by your
X server and graphics hardware.
Screens are ordered by the upper-left-most corner, from top-to-bottom
and then left-to-right.
I believe that "physical location relative to each other" refers to the layout specified by the ServerLayout section of Xinerama's configuration file. I am doing a bit of guesswork here, as I am not very familiar with Xinerama, but it seems that module can help with the issue of unpredictable screen numbers.
Here is a copy of my answer from here. I will preface it by giving a terminology clarification: what you call "screen" is called a "workspace" in xmonad parlance, and what you call "monitor" is called a "screen".
By default, this is what happens:
There are 10 distinct workspaces, numbered 1-10.
Each screen is assigned one of the ten workspaces.
There are two ways to navigate: you can choose to focus a particular screen (via mod+w,e,r) or to focus a particular workspace (mod+1,2,...,0).
If you focus a particular screen, the assignment of screens to workspaces does not change, but the selected screen gets input focus.
If you focus a particular workspace, and that workspace is not currently visible on one of the screens, then the currently focused screen has its mapping changed to that workspace.
If you focus a particular workspace, and that workspace is currently visible on one of the screens, then the currently focused screen and the screen showing that workspace have their mappings swapped.
There's two common ways of tweaking this behavior. One way is to change case (6) to keep the mapping as is, but change input focus to the screen that is showing the workspace you selected. See view. The other way is to change (1) and (3) in tandem: create (10 * number of screens) workspaces, and arrange for the mod+1,2,...,0 keybindings to choose which workspace to jump to based on both which key you pressed and which screen is currently focused. The result of this modification is to create the illusion that each screen has an independent set of workspaces that never interfere with each other -- rendering case (6), the confusing case, impossible. See IndependentScreens.