search

LCA-ActivityBrowser / activity-browser

GUI for brightway2
GNU Lesser General Public License v3.0
134 stars 50 forks source link

Duplicating impact categories without forced additional value in the name tuple #1133

Closed mkvdhulst closed 7 months ago

mkvdhulst commented 7 months ago

Feature request

Dear developers,

I am a great fan of the new feature to duplicate and edit impact categories. It massively simplifies the personalisation of the impact assessment step. Thank you for creating this new feature! I would like to make a minor suggestion for a change in the way this new feature has been implemented that in my opinion would make the tree view of duplicates more intuitive.

At current, when duplicating a method - or a category within a method - one is shown a screen where each position of the tuple containing the name of the method/category is shown in a separate field, with an additional blank field for some unique identifier (default being "copy"). This later field cannot be excluded and thus the tuple with the name of the duplicate is always one value longer than the original. In the tree view, this adds an additional layer that might be unneccesary.

For example, when duplicating the impact category "IPCC 2013", one could add the unique identifier directly to the name of the method in the first field, without needing to fill the second field. By extending the name in the first field with e.g. "duplicate" and leaving the second field blank, one could register a new method with the name tuple ('IPCC 2013 duplicate'). However, due to the forced additional value in the second field, it gets registered as ('IPCC 2013 duplicate', 'copy'). In the tree view, you would find your duplicate as "IPCC 2013 duplicate" above "IPCC 2013 no LT" and "IPCC 2013". When expanding "IPCC 2013 duplicate", you first get the unnecessary category "copy" and within it the original category of "climate change". I think it would be cleaner to be allowed to make a duplicate without forcing the name tuple to be appended with this additional "copy" layer. I'm curious to hear if this is possible.

Kind regards, Mitchell

marc-vdm commented 7 months ago

Thanks for the suggestion, entirely agree that we should make some improvements to this!

For who pikcs this up, also see #1056 for screenshots

Also; I suggest we move the copy addition (where it is relevant) to the name of the last entry in the tuple instead of adding another tuple item, that will move the copy to the same level as the original too.