Although my implementation is not fully complete, I have decided to share my progress: https://github.com/v6ak/qubes-i3status-dir
It is available under a WTFPL-like license. Regards, Vít Šesták 'v6ak' On Monday, January 18, 2021 at 2:39:09 PM UTC+1 Vít Šesták wrote: > BTW, I've started the reimplementation of qubes-i3status as a Python > wrapper around i3status. I am trying to be quite conservative – in the > default settings, there should be no visible difference except CPU load, > periodic freezes and bug fixes (battery status). > > * Some indicators (battery, load and time) are already present, they just > need some adjustments of the format in order to be a drop-in replacement. > * Disk status was easy to implement. I just need to verify that it can > properly handle the change of default pool. > * Running qubes: I need to study the events deeper… > * NetVM status – currently, it is disabled and discouraged. I might decide > to reimplement this, but I am not 100% sure right now. > > Regards, > Vít Šesták 'v6ak' > > On Friday, January 15, 2021 at 5:40:38 PM UTC+1 David Hobach wrote: > >> Hi Vit, >> >> > * I have many VMs in my computer. >> > * I use i3 with qubes-i3status >> > * The script qubes-i3status calls command qvm-ls --no-spinner >> --raw-data >> > --fields NAME,FLAGS quite frequently. >> > * The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems >> to >> > cause high CPU load. Unfortunately, the process that shows the high CPU >> > usage is qubesd, not qvm-ls. >> > >> > What can be improved: >> > >> > a. Don't use qubes-i3status. Problem solved. >> > b. Optimize qvm-ls. Not sure how hard it is. >> >> This issue is really old (back from at least 3.2) and caused by each >> qvm-ls line relating to one request to qubesd. Actually it was even worse >> with 3.2. >> >> It should improve with 4.1 though, see [1]. >> >> [1] https://github.com/QubesOS/qubes-issues/issues/3293 >> >> > c. Optimize qubes-i3status. I am not sure about the ideal way of doing >> > that, but clearly running qvm-ls --no-spinner --raw-data --fields >> > NAME,FLAGS just to compute the number of running qubes is far from >> optimal. >> > One could add --running. And maybe it could have been written without >> > flags. The script just ignores VMs with the first flag being “0” (maybe >> in >> > order to ignore dom0) and the second flag being “r” (probably not >> needed >> > with --running). >> >> Filtering might work in the meantime, yes. >> >> BR >> David >> >> -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b98004f9-01be-447c-9388-65944f948a14n%40googlegroups.com.
