[IDEAS] list on features & thoughts for nannou from a beginner perspective

[lewislepton]

howdy folks,

well im looking at nannou & have been for the past few weeks. really like it. though im no rust person [but have been interested in using it for a while]. just need to get used too it more than anything.

but I do have questions & thoughts on nannou. this is purely coming from a beginner of it & also as someone who has been doing coding with openFrameworks for a while. also [& more importantly] from a realm of making things understandable to new users that may come across this platform. how it can be made easier to understand etc.

so some of these questions may seem pedestrian at first & can easily be looked down upon by others for the simplicity of them, or even the misunderstanding of how something works. but its purely to make things not only easier to understand but maybe to open minds in ways that could help the platform become more user friendly for utter beginners & people shopping around for a new coding playground to delve into ;)

[lewislepton]

one thing that pops out at me when creating a project is the rendering of it. making the project is fine to a degree after looking at what things do. I know there has been talk of a project generator, which would be fantastic. so im not touching on project starting.

but one catch I think is a bit head scratching & wondering if anything could be done to lessen it or make it part of the backbone code is how it renders, or gets the drawn frame on screen. with frame right at the end of the view function. this is a weird little catch & im trying to think of ways that this little sucker could be put into the background of nannous code.

fn view(app: &App, model: &Model, frame: Frame)->Frame {
  let draw = app.draw();
  let time = app.time;
  draw.background().color(Rgb::new(0.13, 0.13, 0.13));
  draw.ellipse().x_y(app.mouse.x * time.cos(), app.mouse.y * time.sin());
  draw.to_frame(app, &frame).unwrap();
  frame ///<---- this wee mofo right here
}

because whilst 'yes' it is to show the drawn frame. but it feels & looks like we are already doing it with draw_to_frame(app, &frame).unwrap();. maybe even doing that twice if we bring in UI to draw to the frame. so it feels as if we are saying it twice, just to make sure it's listened & clean its room.

in some ways this feels more understandable in my head on if frame is still in

frame.begin();
/// all the other code that has circles & cack
frame.end();

but rather than going the path of having a begin() or end(), I was thinking if its possible to even have frame in the background of the source code of nannou? if not, that is fine. but its one catch that really baffled me [maybe others] & did not stick out until I sat back, then saw that little sucker winking at me.

[mitchmindtree]

Thanks a lot for the feedback @lewislepton! I think you're onto something here.

---

Some history!

The reason that the Frame type is returned is as you guessed it - to make it clear that this is the Frame that will be displayed for the window. Now that you mention it, this is an artifact of nannou's original API which used to have a more "purely functional" feel to it. E.g. update used to look like this:

fn update(app: &App, model: Model, update: Update) -> Model

This kind of API is more useful in other imperative languages to make it clear that the returned Model is now the new state of the application, and to make sure that the user can't magically store a reference to it somewhere on another thread and mysteriously break nannou's app API by mistake.

We switched to what is the current API a few months back after realising that this kind of bug isn't possible in Rust anyway due to Rust's ownership model. We switched all the update and event function signatures to take &mut Model rather than Model -> Model, but for some reason I omitted the view function from this and I can't think of a good reason as to why!

---

TL;DR A simple fix for this would be to take the Frame by reference instead of taking it by value and returning it - I think there should be no need for begin()s or end()s at all!

Thanks again for sharing :) The first-steps feedback is often the most valuable!

[lewislepton]

cheers for that man. this is the first thing that popped in my head. I do have others. but im just thinking on best ways to say about them first, like this first suggestion. rather than have a list ;)

[lewislepton]

the one thing I know for sure that would be a great addition to nannou & have said this prior when asking questions, is HTML output & even to extend on that, able to build native applications from nannou/vscode, say creates a Xcode/visual studio project to then build in the IDE.

im not 100% sure how rust works, im still looking at all these things. but maybe ive been spoilt for choice with using kha/haxe [since that can export to pretty much anything & runs very well]

but HTML output/builds would be a fantastic addition. I do think emscription is good, but its that overload of extra stuff that brings it down. ive found on several things its slow & sluggish. not a good thing if you want to share stuff. though if emscription is the path needed, then that's the way it needs to be.

but to extend on this, a capability to create native applications on the system you are on would be such a big welcome. either that or creates a project for your IDE & you build it from that, or even a way to do a build right away.

HTML makes sense so you can post stuff online easily & show off works. native application building is super useful for installations & things that would need to run for long periods of time

[JoshuaBatty]

Hi @lewislepton, rust is already creating native applications each time you build. You can find these by going to your project folder, then depending on if you built-in release or debug mode, navigating to target/release/ or target/build/ directory. Inside that folder will be an executable that is the native application :)

As for compiling to the web, there has been a lot of requests along this line and essentially we would need to target WASM. The main reason this can't move ahead anytime soon is lack of support for Vulkan on the web. We would need to change the graphics backend to target WebGL in this scenario. I think this will become something we can start to discuss when we move from using vulkano to rendy and gfx-hal down the line.

[lewislepton]

fantastic @JoshuaBatty , that does clear up a lot ;)