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

Popup "Change component class" could have "don't show again" checkbox? #483

Open
eugeneloza opened this issue May 11, 2023 · 3 comments
Open

Comments

@eugeneloza
Copy link
Member

Currently every time when we change a component class, we show a popup. Well, if someone needs to change a lot of components then it's getting quite tedious always closing this popup, I've just had to change 10 - and it's already annoying. Often it's done by a checkbox "never show again", but that might be not as straightforward to implement (then we'll need some Settings like "reset all warning poups"). Maybe "don't ask again in this session" could work better?

@michaliskambi
Copy link
Member

I think "don't ask again in this session" is a nice idea.

But an even better idea, that maybe would work even better (depending on how you did these 10 changes) would be to support "Change Class..." operation when multiple components have been selected. While I hesitate about the "don't ask again" / "don't ask again in this session" UX, I am 100% confident that we want to have all possible editor operations support multi-selection.

So if you changed 10 components to the same class, by clicking 10 times "Change Class..." -- I would like to address it by instead having "Change Class..." available when you have multiple components selected. As long as components have the same "category" (only TCastleTransform descendants, only TCastleUserInterface descendants), and no component is a child of another, then we could change the class of 10 components in one go.

Of course support for multi-selection in "Change Class..." would not mean we cannot also add "don't ask again" / "don't ask again in this session" checkbox.

@eugeneloza
Copy link
Member Author

having "Change Class..." available when you have multiple components selected

Well, in my usecase it was changing 4 buttons from TCastleButton into TCastleBigButton, then changing 2 more in another design, and then realizing that the previous 4 didn't save (due to the issue reported and you've fixed already :D) and doing that again. So, having ability "not to ask for the rest of the session" seems beneficial. And multi-select might be dangerous, as the user might accidentally have something selected (e.g. parent and child UIs) and then replace both TCastleUserInterface and TCastleImageControl for TCastleButton, maybe will require another warning popup ("You are trying to change class of multiple selected components, but they don't have the same class").

So, e.g. when I'll want to replace (all) my buttons for some TCastleCompositeButton then I'll have to go through multiple views, replacing, maybe 30-40 buttons :)

@michaliskambi
Copy link
Member

michaliskambi commented May 12, 2023

As for operating on multi-selection being dangerous: agreed, it changes more. But then, it is also comfortable and idea of working on entire selection is understood by users. That's why we have undo (which now works OK for "change class..." too) :) In this case, I would not make another warning, but I would extend existing dialog, like adding there paragraph "Note that the operation will change XXX selected components."

Anyhow, having checkbox "don't ask again in this session" is also a good idea, I guess both are. I would welcome PR for both of these :) Where "this session" would simply imply the simplest, global Boolean in EditorUtils unit that always starts at false when you run the application.

Note that if you want to change all buttons really fast, nothing will really beat a search+replace on all .castle-user-interface files, like "$$ClassName" : "TCastleButton" -> "$$ClassName" : "TCastleMyButton" . In general for most cases I wouldn't recommend people editing these JSON files directly... but it is undeniable that in this case it is the most efficient solution, if you would have multiple such replacements over multiple designs.

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

2 participants