There's been some controversial discussion in bug #127930 <http://bugzilla.gnome.org/show_bug.cgi?id=127930>. Raphaël proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not. I couldn't agree more that the content of totally transparent pixels is undefined. However I hardly see how "reviving" fully transparent pixels could confuse users. The manual should just state clearly in big bold letters that the RGB value of a fully transparent pixel is undefined, and so one can expect anything arising from the exposition of previously transparent areas. This approach was even taken by the PNG specification, which specifies to maintain the full RGB data even for pixels with zero alpha value (there's even an entry in the Rationale section aimed to explain the reasons). The manual could also mention that in the current version the RGB value in fully transparent pixels is kept intact with whatever was there before assuming that it was initialized, that if it is not initialized at all then the pixel could contain anything, that some filters could silently alter the RGB data of the pixel, and that this behaviour could change in future versions. The proposal given by Raphaël in bug #128118 <http://bugzilla.gnome.org/show_bug.cgi?id=128118> does not allow the possibility of increasing the opacity, so it's not valid as a way to edit the alpha channel, which was the intention in bug #127930. The only solution that I could perhaps admit discussing is the same applied in bug #127930 but instead of just setting all the pixels in the alpha channel to alpha 255, do the equivalent of applying the "threshold alpha" filter with a value of zero, i.e. keep zeros as zeros and set all the nonzero values to 255, which sounds more in accordance with Raphaël's ideas. There's another problem that Raphaël mentions in bug #127930: >There are other problems related to the consistency of the user >interface: in the menu for creating the mask, the new option to >"transfer" the alpha channel is the only one that has a side effect >and this is not obvious to the user. Putting this option in a >separate group may solve this problem, but in any case I don't like >the fact that it mixes different concepts. I agree with him here; leaving this option just as it is results confusing because that option is the only one which modifies the alpha channel. My initial proposal aimed at solving this issue by using a different wording for the options, but it was rejected: to use "Copy Alpha to Mask" (or "Copy from Alpha channel") instead of the previous "Layer's Alpha Channel", and call the new one "Move Alpha to Mask" (or "Move from Alpha channel"). The rationale was that the strong opposition between the words Copy and Move, the only word that changes between the two sentences, would make it evident that the latter could have destructive side effects. OTOH most users are familiar with the fact that if they *move* a file from A to B and then delete it from B, they lose the file. This was also mentioned by Raphaël as a drawback (what if the user discards the mask?, he argued), but I don't see a problem here. Pedro Gimeno
