On Wed, 26 Oct 2016 06:57:53 +0000 "Alexis BRENON @Wayland" <brenon.alexis +wayl...@gmail.com> said:
> Just to be sure that I understand clearly, what you call 'Toolkit' is > libraries like GTK, Qt, and co. that are used by developers to build their > apps, isn't it ? yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit), FLTK, ... chromium/blink is basically a toolkit of its own etc. at least looking at gtk3 here it doesn't do momentum with wheel/axis scrolling (out of the box). maybe it needs enabling? qt - same story. (not in standard scrollable regions like in the file selector) but efl's scrollable regions do silky smooth scrolling with momentum out of the box when you scroll your wheel around - also as long as thumbsrcoll is enabled (it is on mobile profile) click and drag to do the same like on mobile devices - with momentum when releasing. my point here is - if you go mess with the input events as they actually come from a device, it will totally mess with this kind of code that is doing all the smoothing, interpolation and animated momentum already. it isn't the job of a low level input event to go and try and pretend to have events it does not to try and produce these kinds of effects which are already done at the toolkit level by at least 1 toolkit, and the input device doesn't have the context information a toolkit has to know when to stop, bounce back, or just do this in steps rather than with momentum (eg with a slider widget). > Finally, do you know some tiling DE/WM Wayland compliant ? yes. enlightenment with tiling module enabled will do this. tiling module is a bit rough, but people do use it. > Kind, > Alexis. > > Le mer. 26 oct. 2016 à 02:17, Carsten Haitzler <ras...@rasterman.com> a > écrit : > > > On Mon, 24 Oct 2016 18:42:31 +0000 "Alexis BRENON @Wayland" <brenon.alexis > > +wayl...@gmail.com> said: > > > > > Hello everyone, > > > > > > I would like to implement kinetic scroll in the libinput driver for Xorg. > > > > > > I know that it's probably not the intended use of libinput ; as explained > > > in the documentation, it's the client that have to manage that. > > > > > > However, as an Xorg user not happy with the synaptics driver, I would > > like > > > to add a similar feature (fixing small disagreements encountered with > > > synaptics) to libinput, allowing Xorg users to easily move to libinput > > > without losing this feature. > > > > > > My first idea is to implement the kinetic scroll using a thread that > > sends > > > axis events as long as there is no button event, key event or motion > > event > > > higher than a threshold. > > > > > > It makes some time since the last time I developed in C, and maybe it's > > not > > > the better way to do it. I would be happy to hear your advices. > > > > > > One thing I'm thinking of is then to add some options in the Xorg > > > configuration file to enable/disable this feature, choose the events > > > stopping the kinetic scroll and change some thresholds. This will allow > > to > > > easily disable this feature in the future in case the clients manage the > > > kinetic scroll on their own. > > > > > > What do you think of this? Is there someone already working on it? Is my > > > proposition a good way to implement it? > > > > > > Thanks for your attention. > > > > > > Kind regards, > > > Alexis BRENON. > > > > we already do kinetic scrolling higher up in the toolkit. we do > > acceleration > > using these events and we do smooth animated scrolling in our scroller and > > not > > just stepping, as well as momentum as we slid with bouncing at the ends. > > it's > > already done in toolkit out of the box. if you try and hack this in at the > > input layer this simply doubles the amount of this and likely makes the > > user > > experience worse. this would have to be off by default and if it's off by > > default... you need ways of turning it on client by client ... and even > > then > > there are a pile of other problems you'll hit. so my suggestion is - > > don't. add > > to your favorite toolkits instead if they don't have it. they have far more > > information about the context at the time and the use cases needed etc. > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
