I have a 2-monitor setup and when I spawn a QInputDialog it always spawns in the left monitor, ie the one I generally dont use that much. Is there a way to indicate to appear in the monitor I have focus without incurring in any (x,y) positioning stuff.
Basically I dont care where it appears as long as it the monitor with focus.
You can use QDesktopWidget (http://doc.qt.io/qt-5/qdesktopwidget.html) to find out which screen your MainWindow is being displayed on. This is going to be the screen with "the focus", I assume.
You then use the screen number to find out the geometry of the screen and place place the QInputDialog in the screen's center - either before the dialog is shown or right afterwards.
I'm afraid this solution is using "(x,y) positioning stuff", but if you find a way to place the dialog without it, let me know.
Related
I resize a floating window, let's say to some size WxH pixels. Then I change to tiling mode, so the window gets resized automatically to some new size, let's say W'xH' pixels. Now suppose I switch the window back to floating mode.
What I Want: The window automatically resizes to the last size, i.e., WxH.
Current Situation: The window just becomes floating, but still has the size W'xH'.
Is there any way of making this happen? Like some way we can save the dimenisons of a window everytime it's resized, and whenever a window enters floating mode, apply the last known size from that application?
I know it probably sounds very dumb, I'm so sorry.
There is multiple ways. The "simple" way is to use client.connect("property::floating", function(c) if c.floating then restore(c) else save(c) end) where you implement both save and restore yourself by calling c:geometry().
The more advanced way would be to use request::geometry and awful.placement built-in geometry memento support. That's preferred since it allows to prevent the client from flickering between 2 sizes. However it is much more complicated to pull off.
You can use awesome-remember-geometry from berlam.
https://github.com/berlam/awesome-remember-geometry
The basic idea is: I would like to draw over everything on the screen.
One way I can imagine this is creating a transparent full-screen window without window controls (minimise, maximise, etc.) or borders. Then drawing into that window which is transparent. The problem I can think of is that I will be unable to control windows which are behind our transparent window.
How could I do something similar to this, without the mentioned problem? I would also like it to work on multiple operating systems if possible.
Edit:
The user will not be drawing with the mouse or other means on the screen, but will be able to continue use his desktop like normal, without that my program interferes in any way (other than the drawing on the screen). My program will only display something on the screen, which the user will be unable to interact with (at least that's the plan).
Qt 5 implements it:
QWidget w;
w.setWindowFlags(Qt::WindowTransparentForInput);
Qt 4 didn't support this functionality yet - see QTBUG-13559. The bug report had a hint on what needed to be done for Windows.
The method you describe is the one to use; a transparent full-screen window.
If you're using the left mouse button to draw, you'll need a mechanism of switching modes to be able to select items through the window and send events to the operating system.
[qt 4.8]
To get correct window dimensions including its frame, I do the following (as described e.g. here, see comment from Daniel Hedberg).
mainWindow.move(-50000, -50000);
mainWindow.show();
// do something with the window dimensions
mainWindow.move(0, 0);
mainWindow.show()
This works fine, however, I have a problem with the move(0,0) call: It makes the window always appear at position (0,0), while I would like to have the default behaviour, this is, the application only suggests to the window manager that (0,0) is a good place to position the window, and the WM might decide to shift it if necessary to avoid overlapping. In other words, I would like to switch back to Qt's default behaviour as if there weren't a call to move at all.
How can I do that?
One solution is to store Windows original position and use that. For extra safety (in case screen resolution changes), check that entire window still fits on screen and move and even resize if it does not.
A hacky alternative would be to create and open empty, possibly transparent dummy window of the same size and see where it gets positioned. Then move the original there and close the dummy one. Reading your question carefully, I think this would do what you are after.
I don't know of a Qt way to ask Window Manager to reposition the window, so if you really need that, specify the OS etc details.
Looking into the source code of Qt, I can now partially answer my own question: To convert a call to move into a suggestion for positioning instead of a request, do this:
mainWindow.move(100, 100);
mainWindow.setAttribute(Qt::WA_Moved, false);
mainWindow.show();
I've tested the code under X11 using Qt 4.8.4, and hopefully it works with on other platforms too.
Unfortunately, this doesn't solve the very problem I have, namely to use show to get the (decorated) dimensions of an off-screen window which then gets moved to the screen, calling show again. It seems that the first call to show directly sets platform-specific window manager flags which aren't completely reset and reevaluated in the second call. Actually, I'm going to think that this is a bug in Qt, so I'll report it accordingly.
is it possible to use the startMove Method in AS3 and limit the movement only to the y-axis?
I want my window only to be dragable vertically.
Thank you for your tips.
I don't think that is possible, given that the actual movement of the window is done by the operating system alone (and I can't think of any application right now that restricts such a movement).
But maybe you can emulate such behaviour by encapsulating your actual application into a different window. You could then change the actual application size to the full screen and make it transparent and use startDrag to emulate the dragging of the inner window. Because with that function you can specify boundaries in which the movement is allowed.
I don't know if that will work as you would like it to, however.
I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.