I have a Big monitor which I would like to simulate more than one monitor.
i.e:
------------
| |
| M1 |
------------
should be treated as:
-------------
| M1 | M2 |
| | |
-------------
I'm running AwesomeWM version 3.5.9 on X11 1.18.3. I don't care if I can achieve this behaviour by changing the settings of my window manager or the xserver. Whichever way is the easiest.
Cheers
Edit: June 2019. A new feature currently under review for AwesomeWM v4.4 will add a :split() method to the screen API. It does what is done below, but better.
I just answered this question here:
Let awesome wm use only a part of the screen
This is the code:
local wdh = screen[1].geometry.width/2
local x, y = screen[1].geometry.x, screen[1].geometry.y
screen[1]:fake_resize(x, y, wdh, screen[1].geometry.height)
screen.fake_add(x+wdh+1, y, wdh, screen[1].geometry.height)
I will add this to the documentation soon.
Related
StackOverflow is denoted as a place for AwesomeWM community support.
I would like to have a dedicated Tag in my AwesomeWM config where only three particular application will be running all the time. I managed to create new tag using sample config, and I managed to filer the applications using awful.rules.rules and place them into the tag.
I am experiencing troubles in understanding how AwesomeWM layout engine really works. I would like to achieve the following: three static columns of fixed widths, each application is located at its own column, when focus changes then no rearrangement happens, when any application is not running, then its reserved place is remain empty.
___________________
| | | |
| | | |
| A | B | C |
| | | |
| | | |
___________________
How do I specify layout in such case? Should I write my own one? Can I use flexible layout and specify position for client? What is the recommended correct way to achieve my goal?
I am experiencing troubles in understanding how AwesomeWM layout engine really works
A layout is a table with two entries:
name is a string containing, well, the name of the layout
arrange is a function that is called to arrange the visible clients
So you really only need to write an arrange function that arranges clients in the way you want. The argument to this function is the result of awful.layout.parameters, but you really need to care about
.clients is a list of clients that should be arranged.
.workarea is the available space for the clients.
.geometries is where your layout writes back the assigned geometries of clients
I would recommend to read some of the existing layouts to see how they work. For example, the max layout is as simple as:
function(p)
for _, c in pairs(p.clients) do
p.geometries[c] = {
x = p.workarea.x,
y = p.workarea.y,
width = p.workarea.width,
height = p.workarea.height
}
end
end
Should I write my own one? Can I use flexible layout and specify position for client?
Well, the above is the write-own-layout approach. Alternatively, you could also make your clients floating and assign them a geometry via awful.rules. Just have properties = { floating = true, geometry = { x = 42, y = 42, width = 42, height = 42 } }. However, with this you could e.g. accidentally move one of your clients.
What is the recommended correct way to achieve my goal?
Pick one. there is no "just one correct answer".
I come from a php/mysql background, and json data and firebase queries are still pretty new to me. Now I am working in React Native and I have a collection of data, and one of the keys stores a integer. I want to get the average of all the integers. Where do I even start?
I have used Firebases snapshot.numChildren function before so I am getting a little more familiar in this json world, but any sort of help would be appreciated. Thanks!
So, you know that you can return all of the data and determine the average. I'm guessing this is for a large set of data where it would be ideal not to return the entire node every time you would like to retrieve and average.
It depends on what this data is and how it's being updated, but I think one option is to simply have a separate node that is updated every time the collection is added to or is changed.
Here is some really rough pseudo code. For example, if your database looks like this:
database
|
+--collection
| |
| +--item_one (probably a uid like -k2jduwi5j5j5)
| | |
| | +--number: 90
| |
| +--item_two
| | |
| | +--number: 70
|
+--collection_metadata
| |
| +--average: 80
| |
| +--number_of_items: 2
Then when a new item is added, you run a metadata calculation:
var numerator = average * number_of_items + newItem.number;
number_of_items++; <-- this is your new number of items
numerator / number_of_items; <-- this is your new average
Then when an item is updated, you run a metadata calculation:
var numerator = average * number_of_items - changedItem.oldNumber + changedItem.newNumber;
numerator / number_of_items; <-- this is your new average
Now when you want this data, you always have this data on hand.
I'm working on a patch that plays samples from a piano, which works in xcode to build an piano app for ipad. I'm trying to add an adsr to create sustain, but I can't seem to get it working. Could someone point me in the right direction? Thanks!
Patch:
https://docs.google.com/file/d/0B4-qHDgzbDB3VUlwM09FSEowZWM/edit
The ADSR is just an evelope which you are using to multiply the sound output with. However it is meant to be on a temporal axis together with the trigger of the sound. When I look at your patch I notice another thing: Why are you reloading the samples into the arrays every time you trigger them? The arrays should be filled on startup of the app, like this:
[loadbang]
|
[read -resize c1.wav c1Array(
|
[soundfiler]
Later, when you actually just want to play back, you do
[r c1]
|
[t b]
|
[tabplay~ c1Array]
|
[throw~]
and at one central point in your patch you can have
[catch~]
|
[dac~]
(add the main voulme there). Notice there are no connections between the three parts!
I've been putting some thought lately into networking for real time, fast paced games. It seems that if you interpolate correctly then the hit calculation is done on the state that happened more than (p1.interp+p2.interp+p1.ping/2+p2.ping/2) ago from player2(p2)s points of view when the shooter is player1(p1).
The packet first goes to the server which takes p1.ping/2, then the server calculates it on the game state that has happened p1.interp + p1.ping/2 ago. The result of that calculation is send to the player2 which only sees it p2.interp later. It adds up even further because of the time it takes for all three sides to process things.
player1 server player2
| | |
.------|_1.............actual.....|.....game state......|
| | | ^ |
|intrp |_2 | | |
| | | | |
`----->|_3----ping/2 | | |
`------|_4----ping/2 |
`------5_|-------.
| |
6_| intrp|
| |
7_|<------‘
Excuse my poor ASCII art skills but I couldn't resist.
(I got home where I have Windows installed and I see how shit it looks here but hope you guys get the idea)
Assuming 50ms ping, 100ms interpolation it gives us more than 250ms summed up. This means that a player2 is seen approximately 250ms in the past by player1 but, assuming client prediciton, he sees himself in realtime. Is my logic flawed or is this just not a big deal?
I found this as an answer to a related question. Not sure if this is appropriate as an answer but I can't comment.
I have a widget to insert that looks like this
+--------------------+
| +-------++-------+ |
| | || | |
| | || | |
| | || Label | |
| | Label || Label | |
| | || | |
| | || | |
| +-------++-------+ |
+--------------------+
A QWidget element containing two QVBoxLayouts, each containing one or more QLabels.This Widget is going to be inserted in a Vertical Layout that has a stretch cell, so all the widgets of this kind will go to the top and shrink to the smaller height possible.
Resulting in something like this.
______________________ ← Layout boundary
+--------------------+
| +-------++-------+ |
| | || Label | |
| | Label || Label | | ← Widget shrunk to the smallest
| +-------++-------+ |
+--------------------+
______________________ ← Layout boundary
↑
|
| ← Spacer
|
↓
______________________ ← Layout boundary
But before doing this insert, I want to know the size that the widget would have in the inserted layout. Maybe the minimum size allowed by its internal layout. Not sure how to call it.
I have tried already many approaches like inserting the widget in an alternate invisible layout so I can retrieve its height when inserted, which should be the same that the widget would take when inserted in my definitive layout.
But for some reason I always get 480 or 478 when the widget is at most 50px height when pressed vertically. So I am totally lost.
I have to do this because I need the widget to animate when inserting, and I need to know the height it will take for me to animate from height 1 to it.
How can I do this?
Without having the exact code, it's hard to say for sure, but having just attempted to reproduce your example, from the description above, I'd suggest looking at the following things:
It sounds like you're actually calling widget->height() before the widget has been displayed. Instead, try calling widget->sizeHint().height() instead. The QWidget::sizeHint() method tells you what size the widget would like to be, if the parent geometry doesn't place any other constraints on it.
If you're obtaining the sizeHint() and still getting the wrong answer, have a look at the documentation for QWidget::ensurePolished(). I believe that it's important to call this, to get more accurate geometries for widgets that have not yet been displayed:
QWidget calls this function after it has been fully constructed but before it is shown the very first time. You can call this function if you want to ensure that the widget is polished before doing an operation, e.g., the correct font size might be needed in the widget's sizeHint() reimplementation.
And if you're still having problems, then have a look at the documentation for QWidget::sizePolicy(), and the class QSizePolicy Class Reference. I must admit that however many times I read the docs on enum QSizePolicy::Policy, they never all sink in. It's really easy to have one incorrect size policy value mess up your layouts.
It can be worth experimenting with the different size policies in Qt Designer, before actually applying a size policy.