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 <[email protected]>:
> 
> > 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
> >
> 
> 
> 
> -- 
> 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

Reply via email to