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".
Related
In my angular application I am tracking filters that users utilize on one of the pages. What I can later see in Logs, is the following (query for last 24 hours)
What I am interested in, is the count of filters groupped by its name. So I created the following query:
However the problem as you can see, is that my y-axis starts from 1 instead of 0. To users this looks like the last two filters don't have any values, where in reality they both have count of 1.
I have tried to use ymin=0 together with render function, however it did not work (chart still starts from 1). Then I have read I need to use make-series() function and so I tried:
customEvents
| where timestamp >= ago(24h)
| where customDimensions.pageName == 'product'
| make-series Count=count(name) default=0 on timestamp from datetime(2019-10-10) to datetime(2019-10-11) step 1d by name
| project name, Count
However the result is some weird matrix instead of a regular table:
I have just started with application insights thus any help in respect to this matter would be more than appreciated. Thank you
in Workbooks in application insights you could do almost this query (see below for a simplification?), then use the chart settings and set the axis min/max explicitly:
but why are you using make-series but then summarizing to just one series?
in this specific case is summarize simpler:
customEvents
| where timestamp between(datetime(2019-10-10) .. datetime(2019-10-11))
| where customDimensions.pageName == 'product'
| summarize Count=count(name) by name
| render barchart
in the logs blade (where you are), you could do this query, and I believe you can use
render barchart title="blah" ymin=0
(at some point workbooks will be able to "see" all the rendeer options like ymin/ymax/xmin/xmax/title/etc, but right now they're all stripped out at service layer)
A bit late to the party, but the correct syntax to pass in ymin and ymax when using a query is this:
| ...
| render barchart with (ymin=0, ymax=100)
See https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/renderoperator?pivots=azuremonitor
So what I currently want to do is pretty much implement rofi in awesome.
The reason I want to do this and I don't just use rofi is because I want to learn how to 'auto-generate' widgets in awesome.
This will come in handy later when I'll implement things like network widgets that when clicked, shows you a panel, shows you the wifi hotspots available as rows, etc etc. So it's just for me to learn how awesome works better. But also, I want a program launcher.
And also, before someone suggests it, I already know that there's a built-in launcher in awesome, and I also know that there's this. This is not what I'm looking for. I want to have the same thing thing rofi and dmenu have: I want to have suggestions pop up when you press keys. and I want to be able to click on the suggestions, etc.
What I want is something like this: uhhhh
So what I'm having problems is this: how do I auto-generate the rows? I want to be able to specify in only one place how many rows I want, and have awesome do the rest.
I've looked through Elv's github and I found radical and even though what he made is a menu system, I thought that I could use some of his code to do what I want. But I can't for the love of god figure out how it works. No offense to him, but it's not all too well docummented, even for users, and for actually explaining how the code works there's no docummentation.
So My question is: How can I make this work? How would I go about making the widgets that act as the rows automatically?
TL;DR:
i want to write a program launcher like rofi in awesome
i want to be able to specify only in one place the number of rows
therefore, (((I think))) I need to automatically generate widgets as rows somehow, how can I do it?
EDIT:
What I want is to be able to create the rows of my launcher automatically. I know I can hardcode the rows myself, have each row have a different id and then I can write a function that on each keypress, will update each widget with the most relevant matches. So it would be something like (not tested at all):
local wibox = require("wibox")
local awful = require("awful")
local num_rows = 10
local row_height = 40
-- set the height of the background in accordance to how many rows there are,
-- and how high each row should be
local prompt_height = row_height * num_rows
local prompt_width = 300
-- make a widget in the middle of the screen
local background = wibox({
x = awful.screen.focused().geometry.width / 2 - prompt_width / 2,
y = awful.screen.focused().geometry.height / 2 - prompt_height / 2,
width = prompt_width,
height = prompt_height,
bg = "#111111",
visible = false,
ontop = false
})
local rofi_launcher = wibox.widget({
widget = background,
{
-- get a flexible layout so the searchbox and the suggestion boxes get
-- scaled to take up all the space of the background
layout = wibox.layout.flex.vertical,
{ -- the prompt you actually type in
-- set id here so we can adjust its ratio later, so the magnifying
-- glass will end up on the right, and the texbox will take up the left side
id = "searchbox_and_mangifying_glass",
layout = wibox.layout.ratio.horizontal,
{
-- set id so we can use it as a prompt later
id = "searchbox",
widget = wibox.widget.textbox,
},
{
widget = wibox.widget.imagebox,
icon = '~/path/to/magnifying_glass_icon.svg',
},
},
{ -- this is where I actually create the rows that will display suggestions
{ -- row number 1
-- make a background for the textbox to sit in, so you can change
-- background color later for the selected widget, etc etc.
widget = wibox.widget.background,
{
-- give it an id so we can change what's displayed in the
-- textbox when we press keys in the prompt
id = "suggestion_1",
widget = wibox.widget.textbox,
},
},
{ -- row number 2
-- background, again
widget = wibox.widget.background,
{
-- id and textbox again
id = "suggestion_2",
widget = wibox.widget.textbox,
},
},
-- and another 8 (according to the `num_rows` variable) of the same two
-- textboxes above. This is exactly my problem. How can I make these
-- textboxes automatically and still be able to interact with them to
-- display suggestions on the fly, as the user types keys into the prompt?
},
},
})
If this is not clear enough please do let me know what you don't understand and I will update my question.
Equally untested as your code, but this creates a tables of textboxes instead of using the declarative layout to create all these textboxes:
[SNIP; For shorter code I removed some stuff at the beginning]
local textboxes = {}
local widgets = {}
for i = 1, num_rows do
local tb = wibox.widget.textbox()
local bg = wibox.widget.background(tb)
bg:set_bg("#ff0000") -- The original code did not set a bg color, but that would make the bg widget useless...?
tb.id = "suggestion_" .. tostring(i) -- This is likely unnecessary, but the original code set these IDs, too
table.insert(textboxes, tb)
table.insert(widgets, bg)
end
local rofi_launcher = wibox.widget({
widget = background,
{
-- get a flexible layout so the searchbox and the suggestion boxes get
-- scaled to take up all the space of the background
layout = wibox.layout.flex.vertical,
{ -- the prompt you actually type in
[SNIP - I did not change anything here; I only removed this part to make the code shorter]
},
widgets
},
})
-- Now make the textboxes display something
textboxes[3].text = "I am the third row"
textboxes[5].text = "I am not"
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 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.
I have a module that automatically outputs (in dot format) functions written in some kind of assembly language (the IR of my compiler). The nodes are the basic blocks printed using the 'record' shape. The problem is that the edges take a strange route, for example:
digraph {
node [shape = record];
n0[label="{<name> entry | <body> store i, 0\nstore sum, 0\ngoto test | {<target> target}}"];
n1[label="{<name> test | <body> t2 = load i\nif t4, body, done | {<true> true | <false> false}}"]
n2[label="{<name> body | <body> t5 = load sum\ngoto test | {<target> target}}"];
n3[color=firebrick3, label="{<name> done | <body> t9 = load sum\nret t9}}"];
n0:target:s -> n1:name:n
n1:true:s -> n2:name:n
n1:false:s -> n3:name:n
n2:target:s -> n1:name:n
}
And an image:
What can I do so that the edge from 'target' to 'test' is placed on the left side?
The simplest non-guru way is force that wayward link to attach on the "west" sides.
n2:target:w -> n1:name:w
This might work okay for this case. A more general way, but takes more thinking and coding, but would allow the edge to attach to the :s and :n if you desire that, is add an invisible node of size zero (color=white, or there might be a visibility attribute) and get from n2 to n1 using two edges. Have the arrowhead on only one of them. The invisible node would have to sit to the left of n1 or n2. Alas, my graphvis-fu is not strong enough to create a working example; maybe someone else can create one.