Default paste color opacity

Indeed, the RGBA field in the F&S dialog should be fully opaque when you type a RGB value with no alpha.

Finaly I've decided to work on this feature.

I've found that there was already this feature for colors beginings by '#' following by 6 digits, and in this case it take the current Alpha (not full opacity).

My patch use this feature but with or without '#' char. First I remove the '#' if it exists and then if we have 6 digits I add the Alpha.

Because it was simply a rearrangement task (+ a little comment), I don't put my name in authors field.

Patch tested successfully on Windows XP, Inkscape trunk revision 10760.
I'm going to test it on Ubuntu with a slight modification (IMHO, the active code should still be inside the !empty condition).

Oh yes, you're right, sorry.

The !empty condition shall enclose '#' condition (and so '#' remove) and text.size condition (and so alpha adding).

I can submit a second patch tonight if necessary.

Fix committed revision 10761.
Thanks for the patch!

AFAICT r10761 seems to have introduced a slightly annoying regression (in the 'Background Color' widget called from 'File > Document Properties > Page > Background', but also in 'Fill & Stroke'): manually entering hex values (including Alpha > 0) by typing (not pasting) now make one feel like Sisyphus:
- It is not possible to overwrite the automatically added '00' for alpha with e.g. 'ff'
- Backspacing feels odd (from the end, or when placing the cursor somewhere in the middle of the hex string) because when a character has been deleted, the entry is auto-completed with '0' at the end, and the color changes unexpectedly (at least sometimes - I could really figure out what triggers that auto-completion).

Proposing to revert the commit.

(tested with r10760 and r10761 on Mac OS X 10.5.8 (32bit))

Regression confirmed.

Fix reverted revision 10893. Thanks for your test, ~suv.
Keeping it in progress. I'll try to find where it fails a bit later.

It seems a bit difficult to keep the old alpha value when typing because the widget is live updating. Validating with Enter or by leaving the field would be easier.

Another easiest solution would be to default alpha to FF whatever the value is as far as it's length is <=6.
Would such a behavior be acceptable?

Patch attached.

Hi JazzyNico,

Thanks for your help!

This feature would be very usefull. Maybe we should have to differentiate pasting and editing (and if not create a new type of widget dedicated to type colors). I will try to submit another patch this week-end now I've some time.

Please find attached a better patch.

I've recoded the whole process. For me, the entry is just an input. When the user wants to modify it, he just not want that Inkscape modify it in the same time. Now what you type is what you want. It's no longer the color notebook that understand the RGB string but the color selector. This one takes an order (the color string) and try to update himself the best he can.

I've found no regression.

- The alpha will be kept but not appended as soon as the user don't want to change it (by typing it or move the alpha slider).
- The GtkEntry is now an Inkscape::UI::Widget::ColorEntry that is linked to a ColorSelector. This way we can reuse this widget anywhere we want.
- Now a SPColor can be created/setted with a RRGGBB string and ColorSelector accepts also this input for setColor.
- The entry will now keep the begining # when the user type it, I hope this will not be an issue as soon as lot of others IDE keep it and as soon as it will have no impact on the way Inkscape handles colors (and for future we should keep it to differenciate with names).

If this patch is accepted, two enhancements for the future that are not linked with this bug :
- We can propose other standards input formats (ie RGBA, RGB, color names, rgb(int, int, int)...), even if finally Inkscape convert them to RGBA hex values.
- It would be also possible for the parser to warn the user (by coloring the field in red?) that the entry cannot be used.

Enjoy :o) .

Ok, after some thinking, I've found that I've been a little bit too fast...

I've written the following proposal: http://wiki.inkscape.org/wiki/index.php/Color_Entry_Widget

This speak about this bug discussion but also about the whole idea I have. I thought it was important to share it with you before going ahead on this patch. I don't know whether it's a good idea to implement the whole thing in this single bug request.

I point there the fact that Inkscape is dealing with colors differently than the SVG specification, and I explain my proposal.

Please note that for the moment my patch is not compliant with the alpha proposal you will find in the wiki page (ie appending the default alpha). But in order to not submit a patch per day, I would like first to be sure that this behaviour is wanted before proposing a new one.

Sorry for this issue and thanks for your comments.

Thanks, Romain!
I've added a blueprint linked to your proposal: https://blueprints.launchpad.net/inkscape/+spec/color-entry-widget