You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The library uses its own variable for settings storage, at least in fvignoredversions.cpp (autoupdate branch). When an application uses the library, it might end up storing settings in two different places: one for application settings (if it stores them, for example, in IniFormat), one for Fervor.
I believe this is harder to understand, to maintain and to configure after deploy, than in case where application provides Fervor library with settings variable. The application author would then be free to decide how he wants to store settings, he wouldn't have to comply with library requirements.
I propose to roll back the commit c76d4bc ("reinstate access to QSettings to store ignored version").
The text was updated successfully, but these errors were encountered:
The library uses its own variable for settings storage, at least in fvignoredversions.cpp (autoupdate branch). When an application uses the library, it might end up storing settings in two different places: one for application settings (if it stores them, for example, in IniFormat), one for Fervor.
I believe this is harder to understand, to maintain and to configure after deploy, than in case where application provides Fervor library with settings variable. The application author would then be free to decide how he wants to store settings, he wouldn't have to comply with library requirements.
I propose to roll back the commit c76d4bc ("reinstate access to QSettings to store ignored version").
The text was updated successfully, but these errors were encountered: