Better to just remove these debug lines.

Probably a lot more readable if you just write this as two if statements.

Also, I do not think the i18n() is needed for the first line, I don't think anyone is going to translate "%1 (%2)" differently.

There's https://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics . Would probably work just as well and wouldn't be as verbose. :)

What's this for? If it is to avoid bindings breaking, with Controls 2 that does not happen as much.

Why not use Kirigami.ActionToolBar for this?

Hm, i guess... just never liked to add that style of logic to property assignments ;)

That's what i thought as well, except it turns out that parenthesis is not always parenthesis, depending on context, in certain languages (Japanese comes to mind, but i'm sure there'll be others)... so i've learned to wrap quite literally everything in an i18n call ;)

The semantic markup is partially orthogonal to that verbose description, though... It'd be nice to add those in, i guess, but i'm also weary of this taking a huge amount more time (which me learning a new markup language would require ;) ). It'd certainly be good to get in, but i'd like to postpone that for another patch.

the "not as much" bit is what scares me most about that statement, basically ;) The whole thing where a checkbox reflects the state of something else and isn't state in itself is always a bit fun, so i would quite like to ensure that the value-change logic is kept entirely separate from the visual representation, which... i can accept is a workaround, but it's a fully safe one, at the cost of a bit of verbosity.

In short, because this isn't a toolbar, and toolbuttons want to stay in toolbars :) Long version: Because making use of displayComponent would be quite awkward, given the type of control i'm attempting to produce here (in short, this component is supposed to make it easier, not more work, to produce a message box type thing... and requiring the actions to be given a display component does not make that easier). However, as a thought for some future work, modifying ActionToolBar to expose its default delegate would make it a candidate for a future refactor of this component :) (perhaps at the same time it ends up in Kirigami... because it seems like this type of component is kind of missing, and would be distinctly handy to have in the framework)

Many of these can be shortened when using semantic markup, like the title can just be "@title:window" since the "Remove Account" is already part of the main string. In any case, it's more a "hey you might want to have a look at this for the future" thing.

Hmm, to be honest, if you want to make sure a binding does not break, using an explicit binding object would be more semantically correct.

My main issue with using a MouseArea to override behaviour on a parent control is that it'll cancel out any pre-exising behaviour the parent has. I have seen it break things like hover states for example. But I guess if it works it works.

If you set ActionToolBar's flat property to false you effectively get the same result, since a non-flat ToolButton is basically just a Button. :)

Exposing the default delegate of ActionToolBar is a good idea... I'll ponder that a bit sometime in the future.

Definitely a part of the plan, yup - i'd not been pointed at that page before, so now i have somewhere to look at :)

Hm, you're right though... yeah, switching to a Binding does make sense, i'll do that

Still got that component.close() bit to handle, though, and i'm not really sure how to deal with that in any remotely pleasant fashion... though, again, if the default delegate gets exposed, the same trick from here could be used, so... i'll mark this one down for future work, i think :)

I think this would be more readable if you'd return on error

this could use a text so it has a tooltip. Probably also helpful for a11y

For me, returning early is an absolute no-no; i have run into way too many bugs caused by mistaken assumptions in early returns that you just don't get with a nested approach like this one... It does make the code indentations deeper, but i feel like that's a reasonable cost to pay for less accidentally-buggy code :)

Good call, yes :)