Usability with too many Deprecation Warnings dialogs (Settings framework)

> I'm using latest Pharo-Core with OmniBrowser and it's unusable with so
> many warning dialogs raising all the time in every operation : Opening
> an OB browser for example requires 6 Proceed clicks from an user with
> messages like this one:
>
> "The method Preferences class standardButtonFont has been deprecated.
> now accessible via the new setting framework "
>
> To modify this setting you could change the default to false in
> Deprecation initialize:
>
> Preferences
> addBooleanPreference: #raiseDeprecatedWarnings
> category: #general "programming?"
> default: false
> balloonHelp: 'If enabled, use of a deprecated API raises a
> Deprecated warning.'.
>
> but this would modify the Deprecation behavior for all deprecations
> (not just those related with the Preferences-Settings migration).
>
> To me it sounds like one should to consider two kinds of deprecations:
> -Those which need to raise a dialogs
> -Those which doesn't want to because it would affect usability (like
> right now in Pharo with OB).
>
> I've just attached a specific message for deprecations requiring
> active interaction for the user (#deprecatedWithPopUp). This addition
> doesn't require to modify all the current #deprecated: senders, but
> you should explicit modify with the #deprecatedWithPopUp variant in
> those places you consider of enough importance to keep the user
> informed. The Transcript notification behavior keeps intact. Feel free
> to change it anyway you want :)
> Cheers,
>
> Hernán
> <Deprecation.st><Object-deprecatedWithPopUp.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I'm using latest Pharo-Core with OmniBrowser and it's unusable with so
> many warning dialogs raising all the time in every operation : Opening
> an OB browser for example requires 6 Proceed clicks from an user with
> messages like this one:
>
> "The method Preferences class standardButtonFont has been deprecated.
> now accessible via the new setting framework "
>
> To modify this setting you could change the default to false in
> Deprecation initialize:
>
> Preferences
> addBooleanPreference: #raiseDeprecatedWarnings
> category: #general "programming?"
> default: false
> balloonHelp: 'If enabled, use of a deprecated API raises a
> Deprecated warning.'.
>
> but this would modify the Deprecation behavior for all deprecations
> (not just those related with the Preferences-Settings migration).
>
> To me it sounds like one should to consider two kinds of deprecations:
> -Those which need to raise a dialogs
> -Those which doesn't want to because it would affect usability (like
> right now in Pharo with OB).
>
> I've just attached a specific message for deprecations requiring
> active interaction for the user (#deprecatedWithPopUp). This addition
> doesn't require to modify all the current #deprecated: senders, but
> you should explicit modify with the #deprecatedWithPopUp variant in
> those places you consider of enough importance to keep the user
> informed. The Transcript notification behavior keeps intact. Feel free
> to change it anyway you want :)
> Cheers,
>
> Hernán
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Stéphane Ducasse a écrit :
>> Hi hernan
>>
>> 1.1 is under work. Alain told me that he will kill all the call to deprecated methods soon
>>
> yes but only inside the core.
> I will also change deprecation messages. They have to give the new
> equivalent method if any (current message is stupid)
> but, i will not check external packages...
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project