-
Notifications
You must be signed in to change notification settings - Fork 599
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Very WIP but slowly convert layoutbox to accept template #2955
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2955 +/- ##
=========================================
- Coverage 88.07% 80.8% -7.27%
=========================================
Files 650 494 -156
Lines 44324 28037 -16287
=========================================
- Hits 39037 22655 -16382
- Misses 5287 5382 +95
|
9684475
to
b9f842b
Compare
end | ||
|
||
function w._do_layoutbox_update() | ||
-- Add a delayed callback for the first update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the idea behind it?
as far as i understand it, in case of multiple updates, it will take the first of them, not the last one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still working with it. I've mainly been looking at tasklist
and taglist
as templates. My answer right now: 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the idea behind it?
For stuff like the taglist, calling awful.widget.common
"update" and "label" is very expansive. Usually, more than 1 tag is created in the same event loop iteration. Without batching those calls, it slows down startup a lot. With the new client layout append
API, the layoutbox will have the same problem, so I am happy to see batching being integrated so early! Usually it was the result of my profiling AwesomeWM and trying to address some bottlenecks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Elv13 and what about second part of my question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have one more question : queued_update
is a local table. It means each instance of layoutbox will have its own queued_update
. screen
is also local to the layoutbox instance.
So, why don't we use a basic boolean variable, instead?
OR: the declaration of queued_update
should be moved out of the constructor. (And probably use something else than the screen to identify the layoutbox instance, IMO.)
5e1b4d9
to
8bf6843
Compare
Rebased and took another crack. Mainly getting errors around the reset part. Reading more of the code to understand what is going on.
|
Hi, thanks for this effort. I created a |
Closes #2950
Took a crack at it... still trying to figure out
awful.widget.common
andwibox.widget.base
for the purposes of the template. Commented with my TODOs of where I'm currently tripped up.