Follow-up Comment #2, bug #46410 (project gnustep):
When reverse engineering the nib files I noticed there were a lot of errors
which Apple had made in encoding. The nib in question is, I believe from
10.4. Examples of such errors are name mispellings and etc some of which are
compensated for in the nib decoding Logic. I believe this is such a case
where the cell is never coded in IB as a secure cell and during deciding it
should just be assumed that it is. Thus this is not a perfect solution in
the general case as it means that the developer can’t explicitly set a class
which is different than the one which is assumed to go with the field type.
I believe the solution here is to make the assumption that if we are decoding
a secure text field that a secure cell should be provided. Why this was not
done by Apple is beyond me, but it nevertheless was not. Riccardo and I have
dug deeply into this issue in the past.
I will create a pull request for this and you guys can review it and decide
whether it is good or not. The challenge has been making this change function
in the general case. I believe I might have a solution that will address
this.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46410>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gnustep
