GTK double click handling causes Stepper to skip values.

[thePalindrome]

The Stepper, despite being (currently, see #762 ) exclusively for floats, does not seem to implement clamping against rounding errors.

Given the following compilable example (with warnings):

use druid::{AppLauncher, WindowDesc, Widget, PlatformError, LensWrap, Lens, Data, LensExt};
use druid::widget::{
    Padding, Stepper, Switch, WidgetExt, Flex, Label, TextBox, Parse
};
fn main() {
AppLauncher::with_window(WindowDesc::new(build_ui)).launch(State {
     n_value: 20.0
     });
}
fn build_ui() -> impl Widget<State> {
let mut row = Flex::row();
let n_textbox = LensWrap::new(
        Parse::new(TextBox::new()),
        State::n_value.map(|x| Some(*x), |x, y| *x = y.unwrap_or(0.0)),
    );
    let stepper = LensWrap::new(
        Stepper::new()
            .with_range(0.0, u32::MAX.into())
            .with_step(1.0)
            .with_wraparound(false),
        State::n_value,
    );
row.add_child(Padding::new(5.0, n_textbox));
row.add_child(Padding::new(5.0, stepper));
row.center()
}

#[derive(Lens, Data, Clone)]
struct State {
    n_value: f64,
}

Use the buttons to go up and down a few times, and you'll note that some values will end up being skipped.

As a note, I'm building off of 0.6.0, and would state that building off of master is something that should be discouraged (so if this is fixed in master, I request this not be closed until the release is pushed onto crates.io)

[luleyleo]

This has nothing to do with rounding errors, in fact I've had this issue 'fixed' at one point and that fix caused it to no longer work on macOS and thus was reverted.

I'll take a look if we can solve that properly by now.

The original fix (for GTK): #713
And the revert: #716

---

Also, I don't think building druid from master is discouraged at all, we make sure that master builds and runs at any time and using it allows catching bugs earlier during development. Keeping issues open until their solution is on crates.io sounds interesting, but also annoying (we'll have to close them all once we make a release), and I don't want to spent time on that yet, considering how fast druid is progressing. But once we reach stable 1.0 that might be something to consider.

[luleyleo]

Implementing the ideas from #859 would solve this.

• No extra double or triple click events, it's merely an extra event property for those who care.

[xStrom]

Thanks for reporting this. This is a current issue and not resolved yet.

As a note, I'm building off of 0.6.0, and would state that building off of master is something that should be discouraged (so if this is fixed in master, I request this not be closed until the release is pushed onto crates.io)

Druid is under very active development and we put in a lot of effort to keep the master branch reasonably stable. Changes don't get merged in willy-nilly. Thus right now using master directly is fine (and optional) if your app is also still under development. The master branch is expected to have fewer bugs, with the downside of regular breaking changes. Once we reach 1.0.0 our recommendation will of course change to everyone just using that.

Regarding the issue tracker, this is of course just a tool and every project chooses to use it differently. Druid uses the issue tracker to guide the development of druid itself and not as a notice board for developers using druid to build their own app. Which is not to say that such a notice board isn't useful. Indeed we've spent considerable time recently in setting up practices in building just such a notice board. You can check out the unreleased section of the changelog to see a list of all the bugs that have been fixed in master but are not available in the latest release on crates.io.