Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Delete grouping concept without contained concepts #1070

Open
HansBosma opened this issue Sep 5, 2024 · 17 comments
Open

Comments

@HansBosma
Copy link

Description

In a view I have Archimate elements that contain other archimate elements. I'd like to delete the grouping concept from the view but not the contained elements. E.g. I have a visual group that contains several applications; I'd like to delete the visual group from the view but not the applications within the group. I think it is not possible to do this, except for dragging the contained elements out of the grouping concept and then delete the group. But that is quite a hassle...

@romualdrichard
Copy link

Pretty sure that jArchi should be your friend for this.

@RaimondB
Copy link

RaimondB commented Oct 9, 2024

Agree that it is quite a hassle. A jArchi should be able to solve it, but I would think it should be a standard feature to delete an object in general while keeping the nested objects in the view. It should then work for all types of elements.

@jbsarrodie
Copy link
Member

Hi,

I agree that this should, one day, become a built-in feature (I've needed it more than one time).

But because a jArchi implementation is possible,
and there's only Phil working on code (I now seldom find time to code), this won't be implemented anytime soon.

Regards

@HansBosma
Copy link
Author

ok, appreciate your support. I will do without it... and hope for this feature to be built in, remaining a happy Archi user.

@Phillipus
Copy link
Member

Phillipus commented Oct 16, 2024

I've written some POC code to do this in a generic way - delete a diagram object and move all of its child objects to the parent object/view. Needs more work but it's a start.

@romualdrichard
Copy link

I tried a jArchi script but it's just a try :( not working

@Phillipus
Copy link
Member

I tried a jArchi script but it's just a try :( not working

Because re-parenting is not implemented in jArchi.

I'm working on a native implementation. When I get it working I'll update here.

@Phillipus Phillipus pinned this issue Oct 18, 2024
@Phillipus
Copy link
Member

I've implemented this now. It's a generic implementation that will delete the selected container object from the View and re-parent the object's child objects to its immediate parent, which might be another container object or the View (diagram).

All that's left to do is to decide what to name the function in the menu. At the moment we have "Delete from View" and "Delete from Model". The new feature could be something like:

  • "Delete from View keeping children"
  • "Delete Container from View"
  • Something else

Suggestions for a short yet descriptive menu item name are welcome...

@RaimondB
Copy link

RaimondB commented Oct 18, 2024

Maybe "delete and keep nested"? Or "Delete from view (keep nested)"

@romualdrichard
Copy link

"Remove container"
"Delete and ungroup"

I asked Ckaude :
"Remove parent keep child"
"Delete parent save nested"
"Erase parent keep content"
"Remove box keep contents"
"Delete group keep items"
"Ungroup keep inner objects"
"Remove parent free child"
"Delete shell keep inside"
"Remove wrapper keep inner"
"Erase parent free nested"

@RaimondB
Copy link

Btw, will it also work with multi select and do we have the function in jarchi as well for enabling automated cleanup scenario's in diagrams

@Phillipus
Copy link
Member

Btw, will it also work with multi select and do we have the function in jarchi as well for enabling automated cleanup scenario's in diagrams

Yes, multi-select is supported. A jArchi implementation will come later once this has proved to be OK.

@Phillipus
Copy link
Member

I still can't decide what to call it. The important words are "delete" and "from View". I tried "Delete Container from View" but not everyone will understand "Container". Perhaps "Delete from View (keep children)"?

@HansBosma
Copy link
Author

My first idea is to retain the current menu functions but in case it is a container object, ask the user: 'do you want to keep the contained objects in the view?' This question can also be asked whenever one wants to delete a container from the model.

Otherwise, I agree, 'Delete from View (keep children)' or 'Delete from View (keep contained objects'). And also? 'Delete from Model (keep contained objects in the view).

@Phillipus
Copy link
Member

Phillipus commented Oct 21, 2024

My first idea is to retain the current menu functions but in case it is a container object, ask the user: 'do you want to keep the contained objects in the view?' This question can also be asked whenever one wants to delete a container from the model.

I agree that would have been one way to do it, but because of the way things work internally with the Eclipse framework the regular "Delete" command can't be over-ridden to ask that question. That's why we also have a separate "Delete from Model" command. One advantage of having separate commands is that you can assign different shortcut keys.

And also? 'Delete from Model (keep contained objects in the view).

That would require yet another menu item and (complicated) implementation. If it were part of the Delete from View (keep children) implementation but then it gets ugly with confirmation dialogs. Selecting Delete (keep children) "One or more of the elements you have selected is referenced elsewehere in a View. Are you sure you want to delete the selected element(s)?" These dialogs can be intrusive when all you want to do is quickly delete something.

@HansBosma
Copy link
Author

ok yes, I agree "Delete from View (keep children)" looks best

@Phillipus
Copy link
Member

This is in the Archi 5.5 Early Access builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants