No, current is the current value setted. Don't need to add a field for that. Instead to only be changed by pulseaudio the field is updated by a set, like you do but without duplicating it. And a timer is launched for the use case we have no update from pulseaudio and sync the volume level. No bouncing and no wrong value (or for a short couple of times).
All case are covered and I don't forget where pulse stay at 40%. 2017-02-24 18:36 GMT+01:00 <marcel-hollerb...@t-online.de>: > I dont see why... > > Lets keep the sample 20% -> 40% -> 60% > > then there are 2 calls, > > first: emix_sink_volume_set(sink, vol) where volume is set to 40% > second: emix_sink_volume_set(sink, vol) where volume is set to 60% > > So at each time the set_value points to the value that got set last > time. And we are always jumping to the correct value back when the drag > ends... > > And "if pulse stays at 40%", then my scenario wont hit ... but i think > we should not search for a scenario where it works :P > > On Fri, Feb 24, 2017 at 06:25:07PM +0100, michael bouchaud wrote: > > Sorry but with your solution the comportment will be the same... > > Or you will save and display wrong value > > > > 2017-02-24 18:23 GMT+01:00 michael bouchaud <michael.bouch...@gmail.com > >: > > > > > Ok and if pulse stay at 40% ? > > > > > > 2017-02-24 17:15 GMT+01:00 <marcel-hollerb...@t-online.de>: > > > > > >> On Fri, Feb 24, 2017 at 01:42:00PM +0100, michael bouchaud wrote: > > >> > 2017-02-24 13:31 GMT+01:00 michael bouchaud < > michael.bouch...@gmail.com > > >> >: > > >> > > > >> > > 2017-02-23 22:13 GMT+01:00 Simon Lees <sfl...@suse.de>: > > >> > > > > >> > >> > > >> > >> > > >> > >> On 02/24/2017 01:03 AM, marcel-hollerb...@t-online.de wrote: > > >> > >> > On Thu, Feb 23, 2017 at 03:13:18PM +0100, michael bouchaud > wrote: > > >> > >> >> 2017-02-23 14:11 GMT+01:00 <marcel-hollerb...@t-online.de>: > > >> > >> >> 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 > > >> > >> enlightenment-devel@lists.sourceforge.net > > >> > >> 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 > > >> > enlightenment-devel@lists.sourceforge.net > > >> > 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 > > >> enlightenment-devel@lists.sourceforge.net > > >> 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
