On Fri, Feb 24, 2017 at 01:42:00PM +0100, michael bouchaud wrote: > 2017-02-24 13:31 GMT+01:00 michael bouchaud <[email protected]>: > > > 2017-02-23 22:13 GMT+01:00 Simon Lees <[email protected]>: > > > >> > >> > >> On 02/24/2017 01:03 AM, [email protected] wrote: > >> > On Thu, Feb 23, 2017 at 03:13:18PM +0100, michael bouchaud wrote: > >> >> 2017-02-23 14:11 GMT+01:00 <[email protected]>: > >> >> The "current" is the current value of pulseaudio, and if pulseaudio > >> change > >> >> this > >> >> value we will got an event who update the value and the slider. > >> > > >> >> The user don't complain about bouncing slider, but because he got wrong > >> >> value displayed by the slider. > >> > > >> > The video obviously shows how the slider bounces back and forth ... > >> > so the user complained about the bouncing slider. Just read the commit > >> > message you reverted, and you get to the video where you see the bug. > >> > > >> > >> While in most cases i'd agree that showing the actual volume is better, > >> i've experienced the bouncing around and it basically makes the slider > >> unusable so unfortunately in this case I don't think we can show the > >> actual volume, pulse will catch up soon enough. > >> > >> > > I understand boucing slider could be annoying for users, we need to take > > this into account, I agreed. Marcel I don't think adding a field is the > > best way to resolve > > this. If we do like that we need to add a field for sinks, sink_inputs and > > main volume. > > And now the problem go to e_client_volume too, so we need to do the same > > with these > > sliders (I really dislike it). This only grow the memory usage in my point > > of view without > > really fixing it. We just moving the problem, as I say before, in other > > place (here higher > > level). > > > > Ok I see your commit you don't move the problem in higher level, but memory > still grow.
I dont think thats too bad. Thats a few bytes per sink and channel. The reason i dont like the timeout mechanic is that pulse could update to a "old" value. Lets say you rise from 20% to 40% to 60%. Now you wait for pulse to update. Pulse first updates to 40 (you display it) and then pulse updates to 60%. And you have a jumping slider again. I think that saving our own volume somewhere is here the easiest solution, with the smallest number of corner cases. > > > > > > Why not adding a timeout mechanics when a volume set is done. We set the > > volume > > and update current volume field. If pulse don't change it in a delay of > > time (maybe 1 s), > > we go to read the current volume. > > If the volume isn't changed current field differ from the readed value, so > > we could send > > the volume change event. > > > > This fix all places without more memory allocated. What do you think ? > > > > > >> -- > >> > >> Simon Lees (Simotek) http://simotek.net > >> > >> Emergency Update Team keybase.io/simotek > >> SUSE Linux Adelaide Australia, UTC+10:30 > >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > >> > >> > >> ------------------------------------------------------------ > >> ------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> enlightenment-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > >> > > > > > > -- > > Michaël Bouchaud > > > > > > -- > Michaël Bouchaud > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
