Feature request #10426
Composer Manager : ideas for improvements
|Pull Request or Patch supplied:||No||Resolution:||invalid|
For my work, I duplicate an old project with a lot of composers. Now, I have to rename some composer's window name (those I want to reuse) and delete others. It's a bit hard to do that.
As the name of the composer is not always really expressive, I need to see if the content suits the best what I want to show, so I can decide if I keep this one or not.
In the composer Manager,
1/ It should be possible to select more than one composer, either to duplicate, delete, display them. Now, you have to do it one by one. Not practical when you have many composers to deal with.
2/ when you select a composer and display it, the composer Manager is automatically closed. Since 2.0, you can directly open other composers through "Composer menu --> Composers" from an opened composer so I think that when the user chooses "Composer Manager" way, he might be the one who decides when to close this dialog. He might be able to rename, duplicate, display, delete in the order he wants and not be interrupted as soon as he displays a composer window.
Indeed, when I display a composer and decide if I must keep or delete it, I've to reopen the Composer Manager to choose the action. Keeping the Composer Manager opened might help.
3/ Then, in a map composer window, we can add in Composer menu the possibility to rename/delete the active composer, near the duplicate button .
4/ When opening Composer Manager from a composer window, i think that a focus might be on that composer name (highlighted?). So that you can identify it directly in the list and perform, if needed, the action you want on it.
Indeed, when you have many composers whose names are almost the same, it can help to find the one you just used.
5/ Can composer Manager dialog not be modal?
#1 Updated by Nyall Dawson over 3 years ago
- Resolution set to invalid
- Status changed from Open to Closed
Some of these issues are already fixed in master. Do you mind testing and then creating separate feature requests for each of your ideas which are still outstanding? (multiple requests in the one issue make things very difficult to track).
#2 Updated by Harrissou Santanna over 3 years ago
You are right! I'm confused; i thought i was using Master but it was 2.2. And nice to see that most of the improvements asked are already done.
I test and will open new topic for each feature that could be improved or added.
Just to be sure! About the point 1, I suppose that the principal development is not on the feature of multiple selection but the action you can do on these composers. So, should I open three tickets (one for each task of displaying, deleting and renaming multiple composers) as each task, I suppose, requires a specific code? Or only one issue about multiple selection is sufficient (the rest deriving from that)?
Thanks in advance...