PulseAudio Volume Meter. Would like to add VU ticks.

[Nominal Animal]

No, I meant 8 (and not 5).

3 and 8 are between the two monitors.  3 is the right edge of the bottom left monitor, and 8 is the left edge of the top right monitor.

[Ed.Kloonk]

No, I meant 8 (and not 5).

3 and 8 are between the two monitors.  3 is the right edge of the bottom left monitor, and 8 is the left edge of the top right monitor.

Roger.

A window straddled across both monitors gets shoved to the left all the way to the right hand side of the left monitor when running strut.

A Window on the hard left of the right hand monitor gets bumped out of the way of the strut, when ran.

Looks OK.

[Nominal Animal]

Ok.  I'll refactor the code, and post a fixed version of the volume meter later (today or tomorrow).

[Ed.Kloonk]

Ok.  I'll refactor the code, and post a fixed version of the volume meter later (today or tomorrow).

 

I threw them all in a script so I could whiz through them and found out that the first one of number 7   (    ./strut  left    1920 1350   2687 1365) places the bar on the bottom of the right-hand monitor and works ok pushing the windows up, but it also severely interferes with the windows on the left monitor.

The remaining two in (7) are fine.

[Nominal Animal]

That makes sense, because the ./strut left 1920 1350 2687 1365 case, pulling (1920,1350)-(2687,1365) left makes it into (0,1350)-(2687,1365), which intersects with the first monitor, (0,653)-(1919,1732), and therefore should not have been included in the list of tests!

That is, you caught another of my bugs.   

Good thing is, I think I have a sound logic now.

Basically, we use the selected monitor and desired edge to find the rectangle where the VU meter should be displayed.  Then, we try extending it to the edge of the desktop in the direction of the selected edge.  If the extended rectangle does not intersect with any of the other monitors, we're golden.  Otherwise, we try extending in the two directions perpendicular to the previous direction, and if one does not intersect with any of the other monitors, we use that; otherwise, we fail.  (For example, if someone has a 3×3 grid of displays, we cannot really put it anywhere in the center display.)

[Nominal Animal]

Oh my, PulseAudio is annoyingly bad.  (Before you label me, just look at some example documentation, for example stream.h:pa_stream_peek(), and try to find out if the buffer contains a full number of samples for all channels, or whether it is just a byte stream the reader must synchronize itself; i.e., whether each callback starts at a sample for the first channel or not.  All the documentation says is "it can be less or more than a complete fragment", a fragment being the basic self-contained block of samples on the server side.)

You see, to make this "worthwhile", I want to add run-time source selection (by right-clicking on the bar) and some other goodies.  To do that, I need to switch from the "simple" interface to the asynchronous interface.  No problem; I'm very familiar and comfy with async interfaces.  Except this one is 1) designed by a baboon using crayons, and 2) with even worse documentation.  Sure, it is *easy* to get something to seemingly work, and that's fine for proof of concept and quick crappy stuff, but my OCD just don't let me keep doing that with this thing, knowing Ed.Kloonk has been using it for a year already.  Besides, if I do it right, I could add Debian packaging in the sources, maybe visual plugin support (if one wants to write their own peak visualizer), and be happy with the result.  It might be useful for others, too.

Ed.Kloonk, do you mind if I use GPL-3.0+ for the rewritten version, and publish the sources somewhere, maybe GitHub?  (I think it'd be the most appropriate license for this kind of application on Linux.  But, if you or anyone else has a reasonable argument for some other license, I'm open.)

[Ed.Kloonk]

Ed.Kloonk, do you mind if I use GPL-3.0+ for the rewritten version, and publish the sources somewhere, maybe GitHub?  (I think it'd be the most appropriate license for this kind of application on Linux.  But, if you or anyone else has a reasonable argument for some other license, I'm open.)

I don't care. I'm just here to learn. 

[Ed.Kloonk]

Having had a moment to dwell on this more, I feel the Beer-ware licence is more my speed...

Code: [Select]

/*
 * ----------------------------------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
 * can do whatever you want with this stuff. If we meet some day, and you think
 * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
 * ----------------------------------------------------------------------------
 */

https://fedoraproject.org/wiki/Licensing/Beerware




    

 

[Nominal Animal]

Just a progress report:  I'm still trying to decide whether threaded operation (having the audio code run in its own thread, completely separate from the UI; except for reporting changes in available sources using gdk_threads_add_timeout_full() with the single-shot callee (that returns FALSE) function sending a custom 'audio-sources' signal to the GtkApplication or GtkWindow or GtkWidget that uses the sources), or a unified main loop in a single thread, is the way to go.  Both have their benefits and downsides.

It is funny how easy it is to write the code, compared to how difficult it is to select a robust, reliable approach.
I know other developers often pooh-pooh this, and just implement whatever comes to mind first, and then move on; but I don't like that, because it leads to inferior tools.
Sure, it does make much more commercial sense, because then your output and product portfolio gets bigger.  But, I'm after quality, not quantity here.

Apologies if it annoys anyone, but me being me, this is the way for me.