Ok and if pulse stay at 40% ? 2017-02-24 17:15 GMT+01:00 <[email protected]>:
> 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 > -- 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
