Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Here be Dragons! #3

Open
eylles opened this issue Oct 12, 2022 · 2 comments
Open

Here be Dragons! #3

eylles opened this issue Oct 12, 2022 · 2 comments

Comments

@eylles
Copy link
Owner

eylles commented Oct 12, 2022

to the 2 guys who recently starred this @mcrute and @VentGrey , thanks for the stars but be warned that the audio slider widget (only one available in the repo at the time) causes awesome's memory consumption to ramp up from just adjusting the sound a couple times.

why? you may ask, welp i crudely cobbled it together from what little lua i've learnt from configuring awesomewm.

Can you fix it? God i wish i knew or understood how, see this widget sits on the very sweet spot where lua documentation and tutorials out there are useless (or at least they seem, because i am writing lua that seems correct in respect to them, but clearly isn't), awesomewm documentation and tutorials are also useless (i have not seen a single one that considers the spawning of a daemon with continuous output and parsing the output from another cli program whose execution is triggered by the output of the daemon), analyzing and copying other similar widgets is not a great option either, most audio sliders don't even do half of what this dragon does (reacting to external volume changes on demand with a daemon, changing colors of the bar and handle to show mute status, change icon of the widget on dependence of the audio port used [on the screenshot the sink managing instance shows a headphone icon because bluetooth headphones are used], work with pactl versions lower than v15) or they are in the opposite end of the expectrum, where they do a LOT more but their authors decided to not add comments explaining what any of the non-trivial code does or why it does things a certain way (being honest the code may be "trivial" but i'm just that uneducated).

have you tried to ask for help? yes, and 90% of the time it has been the very same guy who answers me by not looking at the code and suggesting me to fix something on lua that i don't got the knowledge to fix, last time was extra fun, he sent me on a "hunt" for a patch that may or may not exist in the lua mailing list which patches the lua garbage collector, patch lua on my system, then "just patch the awesome awful.spawn library to interact with the garbage collector" to solve this, ah fun indeed and chatting with him is time extraordinarily well spent!.

will you fix it? i'm trying, at this pace of working alone something will eventually work, or i will be able to understand some of the more complex widgets, absorb the esoteric secrets of correctly using the awesomewm lua api, fix my widget, leave all the code uncommented and join the club of "he managed to fix it, but all of his code is uncommented, nothing seems trivial and when asked about it he doesn't answer or just gives the most vague answers possible"

🙃

@VentGrey
Copy link

VentGrey commented Oct 13, 2022

Well, thank you for the long explanation 🤓. I haven't tested the code yet but it's nice to hear about those bugs beforehand 🙏.

For what I can see a patch might not be needed. I have a very basic LUA level so we are on the same boat. However if I get some free time this weekend Ill try to investigate further on this matter 👩‍💻👩‍🔧.

In any case thank you for making this code 😀, regardless of it's "bug" I think it's an awesome project and I think it's worth the effort to understand and debug it's issues.

@eylles
Copy link
Owner Author

eylles commented Oct 13, 2022

welp, i did reduce the agressive memory consumption by adding one thing from jezer's daemon (from the open PR i did in work from a branch) but it still ain't a "real" fix just helped a bit, from that i'm sure that the real problem is the daemon, and looking at this, and from a chat with jezer that his daemon is a singleton, i'm convinced that the way to go is to have a singleton daemon of pactl subscribe that does parsing for both sources and sinks, emits the 3 signals for each (port for the icon, mute for the colors, volume for the value of the slider)

then the slider widget itself (i plan to add a simple popup that subscribes to the same signals as the slider) can have multiple instances for sink or source (idk why would someone want more than one instance of each) getting the signals from a single daemon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants