resizable and layoutable guis

[elgiano]

Before this PR FluidWaveform and FluidPlotter can instantiate Views as "standalone" windows, or by directly placing them in an external window with parent and bounds and in none of these cases plots resize when their parent window is resized. This PR makes the "standalone" mode resizable, and introduces a third mode, which creates a view without parent nor bounds, so that it can be used with SC's Layout Management. This new mode is activated by setting the standalone argument to false.

There shouldn't be any breaking change, but GUIs have now three modes:

1. parent=nil, standalone=true (default): create a new (resizable) window
2. parent.notNil, bounds: a Rect: create a view and place it in parent at bounds
3. parent=nil, standalone = false: create a View without parent or Bounds

Example usage with Layout Management:

var win, fW, fpL, fpR;
win = Window("waveform and two plotters");
fW = FluidWaveform(...);
fpL = FluidPlotter(...);
fpR = FluidPlotter(...);
win.layout = VLayout(fW.parent, HLayout(fpL.win, fpR.win);
win.front;

TODO:
[] add Layout Management example?

Notes:

1. I've been replacing ^super.new.init(...args) with super.newCopyArgs(...args).init everywhere I could in these two files. It saves a lot of unnecessary code duplication, and some init functions were even removed altogether as they were only there to copy those args.
2. I tried to simplify some of the nested forking in FluidWaveform. Layers don't return anymore something that needs to by synced, as all asynchronous server operation and GUI drawing are now done in the same forkIfNeeded. If a Function needs to wait for the gui to be ready (such as refresh, which needs to wait for layers to refresh the view), it will run all layer.draw calls as part of its own thread (like processBlocking). Draw is called only internally (and I think it's meant to be private, right?). External functions will need to defer { fluidWaveform.refresh } , but not front, which forks automatically.
3. I perceive as an inconsistency the fact that FluidWaveform returns its parent with .win, while FluidPlotter does is with .parent. Is there any good reason they shouldn't both do it with the same method name (I prefer parent)?

[tedmoore]

Hi @elgiano,

Sorry, just seeing this now! (in the future, feel free to request or @ me) Thank you for this! I'm looking forward to checking it all out. The resizing is definitely something that these objects need. I'm heading off tomorrow for another trip of workshops, so it may be a couple weeks, but I assure you I'll get to it.

3. I perceive as an inconsistency the fact that FluidWaveform returns its parent with .win, while FluidPlotter does is with .parent. Is there any good reason they shouldn't both do it with the same method name (I prefer parent)?

There is no good reason, I also prefer parent! (and yet it was I who called it win...)

Cheers. T

[elgiano]

Hi @tedmoore, thanks!!!
Glad you like the idea, I'm already using it and I find it kind of fundamental for my flow!

Now main branch was updated, and there are conflicts... you have workshops, I have a piece coming... so let's definitely take it easy, I'll solve the conflicts after the piece, in a couple of weeks, as I don't feel like updating flucoma right now :)

Looking forward for what's coming!

EDIT: I see, you made FluidPlotter zoomable <3 I'll definitely look into it in a couple of weeks then :D, but for sure resizing and zooming have to be compatible.

[jamesb93]

This looks great. I wish we had the composability of views in Max. I think that to complete the PR some additional documentation would be really good @elgiano. Then it would have my approval for sure. I think that we could also aim to merge this for the next major release!

[jamesb93]

With documentation that shows how to use the three modes, this is good to go (from my non-SC specialist perspective). I'm sure @tedmoore will have more concise and important feedback.

[elgiano]

Thanks @jamesb93 I'll do the docs in a couple of weeks!
I updated my local branch, I'll test it these days but it looks fine so far. Just one note for later:

FluidPlotter's mouseMoveAction gets the FluidPlotter as first argument, not the UserView. I totally support it (you can always get plotter.userView), but I haven't noticed it before and since it's written view everywhere, I'm not sure this is intended.

EDIT: let's make it clearly intended :)

[elgiano]

@tedmoore
Hey Ted! I've updated the help files and made some final changes (and resolved some conflicts). It's ready for review now, whenever you have the time!

[tedmoore]

Thanks @elgiano, I'll take a look this week!

[tedmoore]

Thanks @elgiano! I love this. Thanks for doing the implementing and thanks for your patience while we were busy for a couple weeks there.