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
Related
I am currently building a minesweeper game which has three different game modes. Harder mode has more objects and a bigger window size. When I try to switch back to a simpler mode, the size of the window will not resize to a smaller window, which will make the layout look terrible.
Before it looks like this:
After switching from a harder mode, the layout will be like this(which remains the size of the harder mode):
So what can I do to set those windows to suitable sizes? Or what can I do to set a default window size for each mode? Thanks
There is a few things you should look into:
Size policies. Size policies of the individual widgets dictate how they might shrink or be expanded vertically and horizontally. With the right policies, elements like the icons and scores at the bottom will stay reasonably sized in all geometric configurations. Depending on how you realized the playing field, you can also use size policies there to ensure that elements don't grow too big.
Spacers. A horizontal spacer element in the middle of your bottom bar will help keeping the icons and scores small and in position. It will eat up the additional space.
QWidget's adjustSize() method. You can call it whenever your playing field changes. If your playing field does not work with size hints, but absolute sizes, you can call resize() on the playing field widget, and then. if necessary, adjustSize() on the main window.
Good day! I am using jstree and it works just fine. However, when I restore down the window, its appearance becomes different. Here are the screenshots.
Original window size
After restoring down
Please help me make them not to change appearance. I have to place the tree on the left side of the page and they should retain their original form. The css (with the whole code) is available in jstree.com. Thank you very much!
It's looking like a problem depends on your computer.
Even so, maybe just maybe if you have any window animation when minimizing or maximizing your browser window, css media queries on your site or widget catches that window resize event and behave depends on that changes.
[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.
I have a Direct3D11 scene set up in SlimDX in a window. The rendering is done in a separate thread.
Is there a way to keep the renderer from stretching the image when it draws to the resized control? I've tried ModeDescription.Scaling = DisplayModeScaling.Centered and it doesn't seem to have any effect. Is there something I'm missing?
(I already am updating the render target size. The reason I ask this is that when I resize the control it stretches the image to fill the control for a split second before the render target gets updated with the new size. This has the result that as I resize it, it flickers terribly. If I could reset the render target just slightly faster it might get rid the the flicker. Keeping the image in the corner without scaling it is perfectly fine since ultimately it won't be scaling at all.)
Workaround 1: One can put the render target inside a control. When the window resizes only resize the control though a special method that first stops the rendering, then update the buffers and begins rendering again. It's a bit of hack, though. I have to wait for the render cycle to complete, then block it, then resize, then unblock.
Workaround 2: A similar workaround is to check for a resize flag in the render loop rather than interrupting it. The renderer should be able to draw directly without scaling. This is much more acceptable performancewise. However, a blocking call to the UI thread must be made to execute the actual resize.
Workaround 3: Rather than resizing the control at all, one could make it as large as the maximum size it could be, but clipped (inside the window). No resize is necessary, but a scissor rectangle must be maintained in a similar manner to the workarounds above unless you don't mind rendering a whole lot of offscreen pixels. Rendering twenty or so extra rows and columns of pixels does have the favorable effect of supplying immediate image at the edge when the window is resized back larger.
Ideally the resize should be done directly from the UI thread (no fooling around with delaying it and reentering the UI thread from the render thread). It's not the render thread's responsibility and it slows it down. Likewise, the buffer resize should be done in the render thread for maximum performance (no fooling around with waiting/blocking/resizing/unblocking). The only reason this does not work is that the render thread scales if the resize is done before the buffers are resized.
So my question still stands: Is there a way to render without scaling?
I am going to answer this in terms of the raw Win32 APIs involved, which might require a bit of finesse to translate to a managed .NET environment & SlimDX.
When you are dragging or resizing a window, windows basically hijacks your message pump and creates a new one specifically designed to do the resizing logic efficiently. This operation is more or less modal until it is completed. Many messages you would normally get are quite literally blocked until the resize or drag is completed. In the app terms you get a WM_ENTERSIZEMOVE when this behavior begins, and either WM_EXITSIZEMOVE or WM_CAPTURECHANGED when it ends. You need to check both of these messages, as alt-tabing out when doing a drag will send WM_CAPTURECHANGED and never a WM_EXITSIZEMOVE!
All this means that when you get a WM_ENTERSIZEMOVE you can set a flag and know that all WM_SIZE and WM_MOVE messages that occur afterwards are for the drag operation. Typically resizing rendertargets and tracking down and de-allocating all default pool resources is a very slow operation, and well worth defering until the drag/resize has completed. This has the side effect of making the window stretch which is exactly the same problem you are describing here, and you want to fix that.
It should be possible to add special handlers in WM_SIZE, WM_MOVE, or WM_SIZING, and WM_MOVING that forces a syncronous render and repaint via SendMessage (as opposed to PostMessage) when they occur, but you will need to make sure you only do this when inside the modal loop owned by WM_ENTERSIZEMOVE.
I would recommend either forcing the window to a fixed size (which seems rather common) or not redrawing the D3D control until the changes are done (that or simply clear it black).
There seems to be a way to do what you want, as I have seen games capable of changing size with no flicker, but I've no idea how that's done, unfortunately. Locking the window size and providing a menu was the old solution.
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.