On 11 Jan 2012, at 17:21, Riccardo Mottola wrote: > Hi, > On 01/10/2012 08:47 PM, Gregory Casamento wrote: >> I'm wondering how this change will effect the WinUXTheme and the >> GnomeTheme. Has anyone tested those? >> >> They rely on activate as the place where all of the images are >> rendered in memory from the native widgets. I haven't tested this >> yet, but I'm willing to bet that it's broken the dynamic themes. >> > Actually, you are right.. during a dynamic switch interface images (radio > buttons, checkboxes and such which are emulated with images) do not get > switched.
OK ... yes there are some problems that need ironing out. 1. The contract with theme developers (ie documented behavior) is that the standard theme setup must have been done at the point when the GSThemeWillActivateNotification is posted ... so the theme subclass and any related classes in the theme bundle can do extra changes there, and the gui won't redraw itsself until after they have been done (when GSThemeDidActivateNotification is posted). So the NSImage code needs to do its work before this notification, rather than *at* the GSThemeDidActivateNotification. This could be fixed simply by having GSTheme call a private method of NSImage before posting the GSThemeWillActivateNotification, rather than having NSImage observe GSThemeDidActivateNotification. 2. The documented behavior is that images will be saved on theme activation and restored on deactivation ... so we should honor that, rather than reloading images on every activation. Save and restore ought to be easy to implement in NSImage if it isn't already there. 3. The documented behavior is that the theme may set a replacement class to be used instead of NSImage to load in the new images ... so we need to continue to honor that. Unless ... we want to change these rules ... they were designed to make it safe/reliable for people to develop themes and know they wouldn't be broken by changes in gui, but there aren't many themes yet ... so we could try to develop a better set. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
