@cameronwhite I tried to address your concerns in the last three commits.

As for your question about the color picker dialog, I haven't checked in detail (it's a very long piece of code and haven't found the time), but the palette service gets passed to the constructor, and events get hooked to it, and that makes me think the dialog is tightly coupled to the palette. I might be wrong, though.

Part of the longer-term vision of my cumulative refactorings is to make it obvious if some component is safe to use or not.

As for using ColorDialogButton to open our dialog, I think it's possible. If no ColorDialog has been assigned, it won't open it, and then we could hook to the Click signal/event

Thanks, I think my only additional suggestion would be putting the ColorBgra -> Gdk.RGBA conversion functions as methods on those types, so that we don't reinvent the code if it's needed elsewhere in the future.

Re: color picker dialog, I'm pretty sure those event handlers are only set up when the live palette mode is being used, so I suspect it wouldn't be a large project to make that more clear with some refactoring.
I really think we should be using the same color picker dialog here - being inconsistent and using a different color picker UI in the effect dialog isn't something I want to introduce

Thanks @cameronwhite. I just moved the conversions to extension methods. I will look into using our color picker dialog as soon as I can find the time.

Thanks!
For the extension methods, how about shifting them to GdkExtensions.cs (or a sub-file) since they're specific to converting to Gdk types?

Yeah, GdkExtensions looks like an appropriate place for them :)

I just checked, and I think it's unlikely that we can use the GTK ColorDialogButton for this (since it appears not to have a Click signal/event), so I created a custom button.

The methods that convert to Gdk.RGBA are no longer needed, so I removed them.

An issue (that should go away with time and refactoring) is that PintaCore was re-introduced in SimpleEffectDialog

I tried to address each of your points in their own commit @cameronwhite. I haven't had a lot of time to check, but isn't considerable precision lost when doing this conversion?

ColorBgra newColorBgra =
	newColorCairo
	.ToColorBgra ()
	.ToPremultipliedAlpha ();

Thanks! Will do some more testing later

Re: premultiplied alpha, that's correct that less precision is available for the channels when alpha goes toward zero

Thinking about this more, perhaps we should only support Cairo.Color here for simplicity, and avoiding any confusion from users about why transparent colors can be different when you close and then re-open the effect dialog

It's pretty easy for an effect to convert to ColorBgra, and isn't any different from how e.g. the palette colors are stored

I just removed the handling of ColorBgra properties @cameronwhite.

I'm thinking that, longer-term, we would probably be able to re-add it if no conversions need to take place, but for that to happen lots of refactoring still need to take place, of course

Thanks!

I think the conversion is inevitable though - since we want the user to select a color using straight alpha in the color dialog, the setting should also be stored in straight alpha and only converted to premultiplied alpha when going into the Cairo surface