https://bugs.kde.org/show_bug.cgi?id=458573
--- Comment #2 from Dawid Wróbel <m...@dawidwrobel.com> --- I actually realized after posting this that disabling that action in this case was on purpose. I think that it goes against the user intuition, though, that they can't clean-up that field in that case. But before I get to the point, let me digress as I think this fundamentally touches a bigger issue, i.e. the way we differentiate between categories and splits. The way I see it, the category field should work like this: 1) I can assign a category, once pressing enter, it is represented like a tag in a bubble. This experience is basically akin to any website where you can add tags to your post, e.g. on stackexchange. 2) In the same field, if I want to add another category, I simply can, without having to open a split edit window. The splits are automatically added in the background *and* the amount divided evenly between them (while arbitrary rounding if total amount is not an even number). 3) Furthermore, I can continue to add *more* categories, again in the same category, without having to pull up split editor. The split get added in the background and adjusted accordingly. 4) If needed, user can open the split editor windo and re-adjust the split amounts arbitrarily 5) After any arbitrary adjustment of splits, any further category addition/deletion from the main view would *not* recalculate anything and simply mark the transaction as invalid. Now, with that UI/UX in place, that single delete button would be redundant, as each tag would have its own 'x' to remove it. It does sound like a bit of work, but in general I think it would make the whole process potentially faster and more up-to-date with what users are accustomed to. In the meanwhile, however, I would suggest that it still makes sense to allow the existing "clear" button remove +1 categories, in which case a modal confirmation would pop-up to confirm that corresponding splits would be removed, too. Although personally I think it's a bit extra, given that we do have Undo/Redo functionality in place, so it's not like that action is unrecoverable. -- You are receiving this mail because: You are watching all bug changes.
