suggestions.md

The more stuff I add to minifb the more I actually want to use it in some other projects (like ProDBG) as I'm almost doing double work/cut'n'pasta now. So I have considered extending minifb somewhat that might break the current API.

Window::new(title, width, heigh...) <- this is all good but i'm thinking off perhaps adding something like

Window::new(title, width, height, Option<Scale>, Option<WindowStyle>) (style is for resize and such)

window::update_with_buffer(&buffer) <- rename of the current update function.

I wouldn't call it API breaking as long as the basic interface is more-or-less the same :)
For Window::new, have you thought maybe about doing something like:
Window::new(title, width, height, Option<WindowParams>
A generic WindowParams struct could hold all future options (so for now it could be window scale, style, mouse enabled/disabled etc.). This way you wouldn't have to worry about breaking code.

Considering update_with_buffer - is it just changing name for the sake of better description or are you planning to add some other type of window update?

I'm not using minifb but I saw this and how to do optional parameters are something I've been thinking about a bit lately. I did notice this pattern emerging in libstd https://doc.rust-lang.org/std/fs/struct.OpenOptions.html, though I'm not sure yet if I'm a fan. Thought you might find it interesting though if you haven't seen it already. API wise, not that it's a huge concern, but it means you can leave the existing Window::new() as is and and use a WindowsParam builder to add new parameter options.

This looks pretty good IMO! My approach is more C-like, but OpenOptions seem more flexible.

Thanks for the feedback! @bitshifter Yeah I can't say that I'm a bit fan of the OpenOptions thing.

I agree with having a WindowsParams struct is likely better also as these can be created inline in Rust the code can look something like

Window::new(..., Some(
   WindowOpts { 
      scale: Scale_1X, 
      resize: Resizeable::Yes, 
      .. WindowOpts::default()
   });

^ that looks really nice to me

also

Considering update_with_buffer - is it just changing name for the sake of better description or are you planning to add some other type of window update?

Yeah I want to support windows where you actually don't display a buffer (like have an OpenGL context or whatever instead)

That one will be called update instead and when you actually want to display a buffer one uses the update_with_buffer instead. I guess I could have made it optional but I think this is cleaner.

Alright, that makes sense then! So if you're talking OpenGL now, I assume shader support will be there as well? ;)

gonna be hard to beat glium in that case :)

No, I'm not going to add OpenGL support at all. The thing is for ProDBG I use bgfx and it pretty much only need a window handle so all that setup can be outside of minifb which is the point.

The idea is here to support widows which isn't "forced" to update with a buffer but can still do so if wanted as it's something I want to do on a regular basis.

Yeah it really doesn't make sense to take on glutin/glium really. All I want is basic window setup which you have a bit more control over :)

Sounds good then! Being able to use a separate OpenGL context will be definitely beneficial for some users.

👍

Thanks! I will go ahead doing this stuff :)