Nested IControls

[Bindernews]

I've seen several people mention the desire for nested IControls previously (including issue #41 ), so I figured I'd make a larger issue about it for the purpose of discussion. I think these are the major points to consider w.r.t. nesting IControls:

• Can ALL IControls be nested (like HTML, Java Swing, Qt, etc.) or do we have a specific IContainer class which can contain children?
• Are nested controls actually nested, or just managed by the "parent" control? If we go with the nested route (like every other GUI system I've ever seen) then we have a tree structure of controls. If we go with the "manager" route then we don't have to change much of the current IGraphics code. Each control still draws itself, but the "parent" control resizes child controls as part of its own resize event. I would call this the "flat" model.
• How do children work regarding tags? If we use the "tree" model then we have to teach IGraphics about the tree. If we go with the flat model that's not necessary.

Flat Model

Pros

• It's what we currently use, so there shouldn't be any breaking changes

Cons

• It's inconsistent with every other GUI framework I've ever seen, which is confusing for newcomers
• Drawing only one part of a child element (e.g. a tab container or a viewport) requires telling IGraphics to hide the control, then manually drawing the required parts, and passing in modified mouse events. Using the tree method would require similar things, but it definitely feels janky and wrong.
• Because the child controls don't actually draw themselves (unless they do), the parent control basically has to keep calling SetDirty because one of its children might have changed, and there's no real way to know that. This breaks a lot of performance optimizations.

Tree Model

Pros

• It's consistent with other GUI models, so more familiar for new users
• By adding a SetGuiDirty(const IRECT& area) method (or something similar) each child can more easily control which specific parts of the GUI need updating. We could implement this in the flat model as well.
• Logically makes more sense for parents to update/draw/keep track of their children

Cons

• Even with careful planning, it would probably end up being a major breaking change. This is less of an issue b/c iPlug2 is still in alpha, so breaking changes are expected; Still not ideal
• Would require re-writing parts of IGraphics that may be annoying
• In most tree GUI systems, any node may have children, meaning IControl would likely end up having children support, so all controls would have it as well. I'm not sure if this is really a con, but I'm fairly sure it's not a pro.

I'm willing to write the code but I think this is a pretty major feature, and it needs to be addressed.

NOTE: If anyone posts more pros/cons, I'll update this post to include them.

[AlexHarker]

I'm pretty sure that the tree model is preferable, although I'd prefer it not to be breaking and I'm not convinced that it needs to be. For me the issue is that most of what is currently in IGraphics would go into something like a container or viewport and then Graphics would either have a default one (composition) or inherit the features of one - not sure which is better or easier. Then a lot of methods in IGraphics (e.g. mousing/drawing) would simply call into the main containter/viewport, possibly with some coordinate management beforehand. We could then use transforms to have local coordinates and zoom/scale within a viewport, although ensuring these worked correctly would be a challenge due to the way transforms are managed currently.

The recent I haven't done this is simply

• I don't personally need it for anything right now, although I think it would be great to have
• it needs a lot of changes to IGraphics, which are big and in code that is currently stable, and thus needs some caution

If you are willing to take a shot at it, and also willing to discuss it in more detail I'd suggest a longer discussion off list, and possibly with at least an audio conversation to make it easier. There's a lot of detail I could go into there that would be hard to do or extremely tedious in written form.

Obviously, input from @olilarkin would be good to make sure he'd be onboard with a plan.

[Bindernews]

I agree that we can make the changes without breaking the API but I think we may end up deprecating some methods, which would (at a later time) mean breaking changes. I'm willing to take a shot at it but not until mid-August. I just wanted to start the conversation now b/c I know these things take time.

I definitely agree we should start a more in-depth discussion, but I also want to ensure that other users have the opportunity to voice their opinions. I suspect most people will want the tree structure, but maybe I'm wrong. We can figure out a time for an audio call later, once I'm done with my current commitment.

[AlexHarker]

Sounds good.

[olilarkin]

It would be great to solve this, and wouldn't be too upset having to modify my product codebases if necessary to deal with changing to a tree model. I am slightly bothered by the CPU usage of IGraphics that I see in Xcode, with fairly minimal animation at 60 FPS, which is often around 7%. I am not sure if switching to a more sophisticated tree model and changing the way dirty regions are specified can improve this or not, or if this is even something worth worrying about. Whenever I profile it I normally see e.g. a nanovg draw function is the hotspot.

There is a branch here where I have been working on a new multi-touch capable IVKeyboard control that nests individual controls for each key. Seems mad to redraw the entire keyboard if only a single key is pressed.

https://github.com/iPlug2/iPlug2/tree/controls/multitouch_controls

This is kind of a hack though, a bit like the IVNumberBox control, which easily breaks down when you try and move/resize the control programmatically.

@Bindernews I would be very interested to see a proposal for a tree solution, if you have time to work on something.

[Bindernews]

@olilarkin What do you want in a proposal? Do you mean a PR, or more of a proposal of new/removed/changed methods and functionality that we can discuss in a call?

Slightly off topic: why are things named SetDisabled and Hide? It seems weird have a kind of double-negative "No, don't hide this" in order to show it. I'd say change those to SetEnabled and Show respectively each of which can call SetDisabled and Hide for backwards-compatibility.

[olilarkin]

Just if you have any ideas of a better way that it should work, even if quite breaking, you could make a branch for us to try, for discussion, not a PR as such.

Up for renaming methods more sensibly, make an issue if you like

[AlexHarker]

FWIW - I think they are called SetDisabled and Hide because controls default to enabled and shown. So it is an active choice to do the opposite. I see how SetDisabled() is more problematic if you want to enable (I see a big issue with unhiding with a call to Hide(false).

Hide is historical - SetDisabled I think used to be SetGrayed().

For my money doubling methods is not a great idea (worse than having objectionable names) and making the change will reverse the logic in anyone's plug-ins, leading to a breaking change, with a likelihood of introducing bugs.

[asedev]

Since C++14 one is able to use this feature:

[[deprecated("Replaced by SetEnabled, due to ...")]]
void SetDisabled(bool v) {
  SetEnabled(!v);
}

void SetEnabled(bool v) {
  enabled = v;
  ...
}

[olilarkin]

Some IContainer work here:

https://github.com/iPlug2/iPlug2/commit/1de55f385bb6340a038dc29e63d1dd3ef848cd65

[AlexHarker]

Can we close #41 now as this seems more up to date and references #41 should anyone wish to check it?

[olilarkin]

There is also an experiment here I did a while ago: https://github.com/iPlug2/iPlug2/commits/controls/child_controls