617 Beta - Nice Features!

That sounds like a good call!

I’ll play for a little bit and see how it feels over the next couple of days. You’ll always get my honest opinion (whether you want it or not! :slight_smile: ).

I’ll take it. My gut tells me that we probably want to copy the group structure, like the duplicate command, which only leaves the question of whether or not to leave the layers alone or use the current layer.

Personally, I’d probably leave the layers alone since you can hit the L button and them move the current selection onto the current layer, if that’s what you want. That may or may not be what other people find useful though.

2 Likes

I really like the idea of creating a Toolpath Group with the toolpaths from the pasted objects. Then the user can really do anything they want with them - they’re grouped and contained…You could name the group "pasted group 1, pasted group 2, etc.). and it uses the structures you already have. It also is probably easier and cleaner for your code too - as you don’t need to modify the existing toolpaths and handle the exceptions there. It also is logical from a user perspective.

As for layers, again…What’s rational to me is if I’m pasting something, I’m expecting it to go into the active layer - the same place I expect anything that I create. It behaving differently than Duplicate doesn’t bother me, because they are different commands with different user intents.

As for grouping of objects: I would expect the pasted objects to remain grouped - even if nested. I’m thinking that I’m copying EVERYTHING and expect the pasted objects to behave exactly like the ones I copied.

  • G

YES! This is wonderful! Duplicating the toolpaths when the objects are duplicated saves so much time for making repeated parts! The only thing I would add is a keyboard shortcut for Duplicate, like Ctrl+D.

The new copy/paste work exactly how I would expect. I really like the feature about pasting to the original location if the mouse is off of the view. That is a really nice touch! It keeps from having a separate paste command for it.

The new highlight looks really good also. It’s better than I imagined. The only thing is that it still highlights for elements on locked layers.

You guys did a really good job with all of this.

3 Likes

As for the differences between duplicated elements creating their own toolpaths versus adding to the existing toolpaths, I can see it both ways.

Maybe the strategy could be:

  • If all of the elements that make up a toolpath are duplicated, then a new toolpath is created since it will be identical to the original.

  • If only some of the elements of a toolpath are duplicated, the new elements will be part of the existing toolpath.

  • A duplicated toolpath resides in the same group as the original.

  • If all of the toolpaths in a group are duplicated, a new group is created since it will be identical to the original.

As for how this plays out with the difference in behavior, if any, between Duplicate and Copy/Paste, I’m not sure.

If we keep with the philosophy that pasted elements are treated as new in context, which is why they land in the current layer, then pasted elements should always create a new toolpath. Maybe if elements from multiple toolpaths are pasted, then a new group is created for them with the naming that @GJM suggested.

There are a lot of ways to make this very robust. My only concern is that it may become very cryptic and unintuitive for new users until they learn all of the subtle nuances. One way around this would be to keep with basic behavior and add an options dialog that allows the user to specify the behavior. I’m a big fan of options dialogs, but I understand that they are a lot more work for dev.

@ZoltanTheZ My only concern with the ruleset that you’re proposing, is that it demands that the user really understand the relationship between toolpaths and design elements. In reality, there is a very loose connection between the elements and their toolpaths. Some design elements won’t have toolpaths, others may be associated with more than one toolpath, perhaps be in more than one toolpath group. Trying to tie the action of copying and pasting a design to the toolpath is actually pretty complicated.

So, the interface really needs to be as clear as possible and as simple as possible. The rules may be too complex for the average bear.

I think that any objects and toolpaths that result from a paste (not talking duplicate - which does have a different intent IMO) should be contained and clearly differentiated from the original so there is no question what the system did. They should retain all of the properties of the originals (groupings, etc.), but they should be new groups. I personally feel that the newly created toolpaths should be in a toolpath group as well (as I said above).

4 Likes

Honestly, I think @robgrz did a pretty nice job of this. I’m playing with different combinations: elements that are without toolpaths; elements that are members of different toolpaths; elements with toolpaths in different groups - and the behavior is actually quite consistent and predictable…once you understand what’s going on.

I haven’t played much with duplicates yet…but I think I’m OK with the paste toolpath behavior. I think I’d prefer the “new toolpath group” idea better - but I am comfortable with the way Rob did it as is.

I do think pasted objects should retain their DESIGN grouping (even nested), however. Right now, they lose all groupings.

2 Likes

@robgrz Duplicate shares the defect that we reported wrt the Grouping Icon not refreshing when you ungroup items. If you Duplicate a grouped design element, the resulting element is grouped, however, if you click on the ungroup icon, the object ungroups but the mini-icon doesn’t reflect the change. Same is true for nested groupings…the system is doing the ungrouping properly, but not reflecting the icons.

UPDATE: The incorrect behavior is fully mimicked: If you try to group PASTED design elements, the icon is not properly updated to reflect what’s going on in the system.

2 Likes

It is true that the relationship between elements and toolpaths is complicated and opaque to the user in the Design Environment.

The one-to-many and many-to-one cases of elements and toolpaths would still adhere to the rules:

  • Elements without toolpaths will duplicate as before.

  • If an element is part of more than one toolpath, the duplicated element will be part of all toolpath of which the original was a part.

  • If an element is the only part of more than one toolpath, each of those toolpaths will be duplicated.

  • The above applies to mixed cases.

As for toolpath groups, the rules would also still apply. I cannot think of any edge cases where things would get weird.

You do make a good point that all of this should be clear to the user. I did say that I was also concerned about the complexity, but you highlight the importance of legibility and transparency. The user should be aware of the consequences to the underlying toolpaths that actions on the design elements will have.

One solution could be to prompt the user with a dialog whenever an action is taken on a design element that has associated toolpaths:

  • If a user deletes an element that is part of a toolpath, a warning could appear to warn the user that the toolpath will be modified.

  • If a user deletes an element that is the only element of a toolpath, a warning could appear to warn the user that the toolpath will get deleted.

  • If a user duplicates an element that is entirely or partly associated with a toolpath, the user could get a prompt to choose to create a new toolpath or to associate the new elements with the existing toolpath.

All of these dialogs could have a “Don’t Show This Again” option so as not to annoy advanced users.

These are for the Duplicate command only. I do agree that elements pasted from the clipboard should create new toolpaths and toolpath groups always.

I’m glad we are having an in-depth discussion about this because getting this right (and I’m not saying that what I have proposed is the right way) will make the software very powerful and usable. Getting it wrong can make the software cumbersome and annoying.

And I do think that Rob and his team have done a great job with this feature so far.

3 Likes

We’ll get that in the next release.

Yeah, the more I think about it, I’m more sure that we should keep the groupings for paste.

I could envision the Duplicate becoming a “Duplicate Selected” command that brings brings up a quick window to ask:

Keep items groups
Retain items on existing layers
Add to existing toolpaths

Basically, the paste command would be a shortcut to what we believe is the most common usage, and the Duplicate command would give you the flexibility if you have a different need, at the expense of a dialog on the left pane.

The side benefit is that “Duplicate Selected” becomes the framework for arrays so that all of the logic is in one place.

8 Likes

LOVE IT! More control in the hands of the user. Thanks!

We just uploaded 618 to https://carbide3d.com/carbidecreate/beta/

It hasn’t been thoroughly tested yet but if you’d like to try the duplicate command, give it a shot.

  • (NEW) Duplicate Selected command is better fleshed-out. Connected to CTRL-D.
  • (NEW) Paste now keeps grouping structure of pasted items.
  • (FIX) Group/ungroup icons were not properly updated in all cases.
  • (FIX) Items on locked layers no longer react to hover events.
  • (FIX) Better handle Fit View commands to make them more reliable with 3D views.
  • (FIX) Fit window was ignoring single vertical/horizontal lines.
  • (FIX) Deleting an object and then undoing now retains toolpath connections.
  • (FIX) Simulating ball mill toolpaths should work correctly now.
10 Likes

@robgrz First glance: Copy/Paste looks great. Group / Ungroup for both pasted and imports looks to work as well.

Wow, great enhancements! Just keeps getting better!

(a cut/paste from one CC project to another would be fantastic)

Thanks for your efforts…

As a newbie, 617 is great, so far. I have been able to learn a few things through just trying. Basic issues are near easy, near.

Can’t wait to get more experience to do more

Thank you so much for implementing the duplicate feature. This is amazing. I still need to test more but love what I see so far. This is exactly what I wanted in the feature request at Import designs from another CC file. If you can get it to duplicate into another file that will be excellent. I can’t wait to play with the other feature enhancements too. Keep up the great work.

We are planning to add the ability to import another C2D file once we get a few other things stabilized. (Which is different than cut and paste but I’m not sure which will be more straightforward.)

2 Likes

@robgrz If you go the “Import a C2D File” route, you’ll likely be asked (maybe by me) to also implement an “Export to C2D” option as well, with the same kind of selective capabilities as the SVG export.

I can see where that can become complex, since exported items may have toolpaths associated with them that also have other non-selected objects associated with them. Not sure if you’d need to solve that one.

You might solve the cut/paste problem with a JSON file sidecar. Just put all the necessary info in a sidecar and clipboard the full path of the sidecar. Your solution would only work for CC, but it would give you the freedom to do whatever you want in the format of that file. Just a thought. Photoshop has been using file-based sidecars for years…no worries about partying like it’s 1999!

  • Gary
2 Likes

That sounds like a logical progression, I like it.

That was the fallback idea, but it’s looking better and better as we go on.

3 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.