I’ve added a null container inside a clone. I’ve checked the clone immune flag. descended inside it and dropped a table, but the table still has the look of a clone, even though is sitting inside a clone immune container.
Is this right?
d
In fact, refreshing the Clone field (i.e. I have another address that results in the same master, so the clone is basically refreshed) leaves the clone immune container but deletes all of its contents. I strongly think that if a container is clone immune, all of its contents should be ignored!
d
If you don’t want the COMP to be a clone, then you need to clear the Clone parameter.
Making a node clone immune only makes that node’s parameters immune from cloning (and the node is safe from renames/moves/deletes etc.). Since the clone parameter is still filled in, then that COMP is still a clone and all of it’s contents will behave as such.
We’d be reducing functionality if we made a Clone Immune COMP no longer behave as a clone.
I can understand the expectation though, but I think that’s more of a learning/UI issue.
The component I’m talking about doesn’t have any clone parm.
ie.
CLONE1 (some clone)
CLONE1/NOCLONE (a container, with clone immune flag on to have whatever is updateing CLONE1 leave it alone, and with it, I’m thinking, leave alone its contents too)
CLONE1/NOCLONE/SOMETHING (some op inside NOCLONE)
when CLONE1 gets updated, SOMETHING gets deleted
Ah I see. Ya I think we need both behaviors. I can envision instances where people just want the COMP immune but they want the the contents to remain cloned.
Boils down to a UI issue mostly, maybe the Clone Immune flag has 3 stages, not clone immune, clone immune and clone immune recursive (or something).
I actually added the -R option to the opset command specifically for this case (if that helps you out for now). -R will recursively set flags for all of the nodes children.
I’m all for this third stage, as long as it will not result in
CLONE1/NOCLONE/SOMETHING*
to visually have the immune flag set.
In my case
CLONE1/NOCLONE/
would act as a “spare network” of
CLONE1
i.e. it’s content is not part of the definition of CLONE1. Inside a user works like in a normal network, and having the orange immune flag toggled for all nodes in there would be very disturbing. See also this topic viewtopic.php?f=17&t=118&hilit=+clone
I agree with Achim.
We’re having a conceptual conflict here. Containers are intended to hold other containers and so on, as is especially the case with User Interfaces models.
The Cloning mechanism easily fights against whatever is inside a clone that’s not in the master, either by tending to delete it or delete its connections, and yet it would seem an imperative for anyone creating UIs to have standardized (ie cloned) UI widgets.
Therefore I think this is not a “band aid” that’s needed - although that may work, but it is a serious look by Derivative at the needs for developers to use cloned containers in a hierarchy (ie a PANEL_CLONE) which in turn contains lots of other cloned containers in them as well as clone immune parameters.
The approach of creating a clone immune container to hold whatever you don’t want the parent clone to modify should work, but I still find it a work around. Within a UI hierarchy, you don’t want to have extra panels just for the purpose of defeating cloning (and the size/positioning mantainance that goes with them, as well as the extra confusion added when navigating the hierarchy).
Nonetheless, workarounds are still possible if for example the bug that deletes connections (see separate thread) is fixed. For example I create a MASTER_PANEL with, inside it, a SETTINGS component. When I create another panel, I copy the MASTER PANEL, and make SETTINGS a clone of the master SETTINGS (settings also contains any bg that goes in the panel). That way I can create a hierarchy where the clones are “sitting on the side” of each component together with the main functionalities. But I’m still getting connections deleted inside of SETTINGS, and other weird behavior that’s driving me nuts.
Like a famous master says: “If you get a goat, you’ll have the problem of a goat”!
to paraphrase: “If you implement cloning, you’ll have the problem of proper cloning to deal with!”
d
Hey Dani, there is no conceptual conflict here, we are just trying to find the time to do all the fixes and RFEsthat we have to do. We understand the need for these features, and we are thankful that you guys are testing them and reporting bugs and asking for RFEs.
Please do not take the lack of a feature as meaning we do not think it is required, we are working on multiple issues all the time. We will address this one as soon as possible as well.
yeah, I’m not inferring that you’re not fixing things, I’m just suggesting to look at fixes to do in the broader perspective of how developers will want to use clones within a hierarchical UI context, which is where I believe both Achim and I are having problems, because it still feels (regardless of bugs) that there is some higher level design missing that would make clones easier to deal with. It basically has to do with how one would work in a mixed clone/clone immune hierarchy in a more natural and flowing way.
For example now I’m having to struggle with a Master that has a clone immune network inside it, the reason being that the network needs to be changed/added to (ie. a series of buttons). The creation of that network is triggered by an input DAT which contains button names. In the master, in order to test functionality, I have some test DAT feeding in some button names. In the clone, meaning a container within my UI, I feed in other buttons, and it all works. The problem is that when I reload the file, or the clone gets updated, all the Master “test” buttons within the clone immune network are copied over, in addition to what’s already there, and the recreation of the network (at the clone level) is not triggered because officially the button input DAT is not triggered (no names change). I end up with a bunch more buttons all coming from the master test. If I disconnect and reconnect the button name DAT from the clone, the recreation of that network is triggered and everything goes back to normal. The solution is not to have test buttons in my master that would end up getting duplicated, but it’s a “mental note” (clear the network before saving) that is not right to impose on the developer (as well as any change in the master during development would re-trigger copying the clone immunes to all the clones).
Maybe a third clone immune state would solve that - in the master I should basically flag my buttons container as “to be ignored” so its contents are left alone in the clones.
The Clone immunity is cloned. If you make a node clone immune in the master the nodes in the clone will be clone immune also (that is, once they are created they will be clone immune from then on).
Or maybe I’m not understanding what you want exactly.