I'm using a tiling window manager i3 to run selenium tests. Sometimes I run tests using Chrome & Firefox besides PhantomJS. I realize that one cannot resize an i3 window that's tiled, so I wonder what, if any, workarounds are there to resize window, or detecting if the window is currently tiled and setting it floating?
I realize that one option would be setting chrome and firefox to always run floating in i3 config, but that would impede my regular workflow.
You actually can resize tiled windows, either with the mouse or with the resize command:
resize <grow|shrink> <up|down|left|right|height|width> [<px> px [or <ppt> ppt]]
This grows or shrinks the window in the given direction. With the optional parameters you can specify by what amount the window should be resized. The first argument - <px> px - is used for floating windows and defaults to 10 px. The second argument - <ppt> ppt is for tiled windows and gives the amount in percentage points of the parent container, it defaults to 10 ppt.
In the default configuration there is a resize mode that can be reach with Mod+r (with Mod being either Alt or Super, depending on the choice when first starting i3). While in this mode, windows - floating and tiled - can be grown with Down or Right and shrunken with Up and Left.
For example: Say, you have a container with 3 equally wide windows side-by-side - each taking 33.33 % of the containers width. If you run resize grow width on the middle one, it will be resized to take 43.33 % of the parent container, while the windows to either side will be shrunken to 28.33 %.
As for setting a window to floating, you can always do that with the command floating enable, so there is actually no need to query the current floating state.
If you really want to, you could query this information from i3's IPC interface.
Proof of concept:
Use i3-msg -t get_tree to retrieve the JSON-encoded layout tree (this gets you the whole JSON in one line, so maybe you want to put it through json_xs, json_pp or some similar program for more human-friendliness).
Get the ID of the current window with xdotool getactivewindow
Look in the tree for a node with attribute "window": <WINDOWID>
Check whether the attribute "floating" is set to "user_on" (or possibly "<ANYTHING>_on", I am not sure about that)
Related
We have an application which has a window with a horizontal toolbar at the top. The windows-level handle we pass to Vulkan to create the surface ends up including the area behind the toolbar i.e. Vulkan is completely unaware of the toolbar and the surface includes the space "behind" it.
My question is, can a surface represent only a portion of this window? We obviously need not process data for the pixels that lie behind the toolbar, and so want to avoid creating a frame buffer, depth buffer etc. bigger than necessary.
I fully understand that I can accomplish this visually using a viewport which e.g. has an origin offset and height compensation, however to my understanding the frame buffer actually still contains information for pixels the full size of the surface (e.g. 800x600 for an 800x600 client-area window) even if I am only rendering to a portion of that window. The frame buffer then gets "mapped" and therefore squished to the viewport area.
All of this has sort of left me wondering what the purpose of a viewport is. If it simply defines a mapping from your image buffer to an area in the surface, is that not highly inefficient if your framebuffer contains considerably more pixels than the area it is being mapped to? Would it not make sense to rather section of portions in your application using e.g. different windows HWNDs FIRST, and then create different surfaces from then onwards?
How can I avoid rendering to an area bigger than necessary?
The way this gets handled for pretty much every application is that the client area of a window (ie: the stuff that isn't toolbars and the like) is a child window of the main frame window. When the frame is resized, you resize the client window to match the new client area (taking into account the new sizes of the toolbars/etc).
It is this client window which should have a Vulkan surface created for it.
When screen sharing a specific window on macOS with Zoom or Skype/Teams, they draw a red or green highlight border around that window (which belongs to a different application) to indicate it is being shared. The border is following the target window in real time, with resizing, z-order changes etc.
See example:
What macOS APIs and techniques might be used to achieve this effect?
You can find the location of windows using CGWindowListCopyWindowInfo and related API, which is available to Sandboxed apps.
This is a very fast and efficient API, fast enough to be polled. The SonOfGrab sample code is great platform to try out this stuff.
You can also install a global event tap using +[NSEvent addGlobalMonitorForEventsMatchingMask:handler:] (available in sandbox) to track mouse down, drag and mouse up events and then you can respond immediately whenever the user starts or releases a drag. This way your response will be snappy.
(Drawing a border would be done by creating your own transparent window, slightly larger than, and at the same window layer as, the window you are tracking. And then simply draw a pretty green box into it. I'm not exactly sure about setting the z-order. The details of this part would be best as a separate question.)
Is there a way to increase the width of the Bootstrap 3 grid to beyond 1170? My users often use devices that support 1920 x 1080 resolution. I want to maintain the responsiveness (in case the window is not maximized) but whenever the window is > 1600px in width, I want the grid system to be as wide as 1600px.
Is there a way to add another "step" to the grid system for windows wider than 1600px? Preferably without using LESS, just by adding some Custom CSS to override original Bootstrap rules?
Allow me to answer the question myself. I needed to change my search keywords to find the answer. It was mentioned in this issue on Bootstrap's GitHub issue tracker (last comment). It is a CSS file called BootstrapXL which basically adds a new "x-large" grid level to Bootstrap 3 for devices beyond 1600 px in width (i.e. Full HD monitors with the window maximized).
We ported our application from Qt3 to Qt5. It runs smoothly under Windows but not under Linux (X11). With Qt3 there is no problem with Windows or Linux.
Inside the application there is a canvas of about 1000x800 pixels. A simple vector graphic is drawn onto the canvas. The user clicks into the canvas, holding the mouse button pressed an moves the mouse. Each mouse move results in a repaint.
We registered the milliseconds in each stage:
Start of MouseMove-event handling: 10581
call of update or repaint (makes no difference which one)
Handling of resulting Paint-Event: 10583
Painting finishes: 10584
return from update/repaint: 10687 (!)
I do not find any reason for this lag of 100ms (at each mouse move event!)
I need help!
In Qt4.8 the native graphics backend was deprecated.
Remote X11 is no longer drawn with X11 calls but by painting onto a canvas and transmitting the result (a bitmap) to the client. This may result in larger bandwidth requirements and a slower when running X11 over network.
See also this
I have a tvtk SceneEditor for a mayavi scene in my traitsui application. When defining this editor, I asked it to have size 500x500.
Because of the mayavi toolbar, the scene editor itself understands that it has a smaller size than this under normal circumstances:
>>> self.scene.scene_editor.get_size()
wx.Size(500, 468)
And when the window is enlarged so that the editor takes up much more space, it understands this too
>>> self.scene.scene_editor.get_size()
wx.Size(500, 781)
However, if the editor is made much smaller, it refuses to take up less space (even if the contents could easily be rescaled) because the editor was specified to take up 500x500. It allows the editor to be resized, but just cuts off part of the display until it is enlarged again.
I want to know if there is a way to a) ask how much of the editor is currently displayed on the screen (instead of the minimum size the editor is willing to display) and b) make the editor default to 500x500 but be willing to ask its contents to rescale themselves if it is made smaller.
I am using the wxpython backend.
edit: It is also important that the scene is contained within a layout='split' Group -- after exploring this question and running into the enormous number of sizers that wx generates when adding traitsui widgets, I realized this might matter as well.
After hacking around for a few days, I have an answer to part a) (though it is hacky and not necessarily general purpose and it might be specific to the layout='split' layout).
self.scene.scene_editor.control.Parent.Parent.Size describes the size of the viewport in which the editor is being displayed, at least with layout='split' but I can easily imagine that it would be different for other layout types (which I didn't test).
Armed with this information, I managed to write a wrapper that resizes the editor to be at least this small before making snapshots.
More gory details:
The sizer associated with self.scene.scene_editor.control isn't the right one, probably because that sizer refers to the window containing the editor, whereas the sizer associated with the size of window within the containing splitter widget is allowed to "cover" that window and ignore its size.
I found out that the process of adding traitsui widgets defines so many boxes (assuming a nontrivial number of widgets) that there result is this enormous glut of wx Windows with their associated wx Sizers that all depend on their child widgets to determine the current size, so it is extremely difficult to control things like this. This is probably why enaml exists; so that these constraints can be explicitly specified by the user. Maybe someday I will convert my program to use enaml, but that seems like a lot of effort for something that currently works pretty well.
I still don't have an answer to part b), so I am leaving this question open. It would be nice if there were a way to specify at construction to the mess of wx sizers that resizing this window below its initial size is allowed, but there probably isn't one.