Re: ANN: New version of PikoPixel, pixel-art editor

[Josh Freeman]

On Oct 15, 2018, at 12:09 PM, Bertrand Dekoninck wrote:

> Pikopixel doesn't seem to deal well with other themes on GNUstep,  
> now that it has its own and overrides GNUstep defaults..
>
> The theme changing dialog in the Info panel is now buggy : when I  
> switch to the default GNUstep theme, Pikopixel sets its own theme,  
> instead of the default one. Which is sensible but a little tough.  
> But the real problem is that if I want to change again to another  
> theme, all my themes are listed with the same name "Pikostep" in the  
> Info panel and I can't change to another. I can only "revert to  
> default theme", which sets my Rik theme as it is the default one.

   Thanks for the bug report - I didn't know the Info panel allowed  
you to change themes, so I'll look into this.
(For anyone else who didn't know, the standard GNUstep app Info panel  
has a hidden button: If you click on the bottom line of the Info text  
("Current theme: ..."), it will display a theme-selection panel that  
lets you switch to a different installed theme).

   PikoPixel's custom theme is installed when the app starts, and  
only if you're using GNUstep's standard (built-in) theme. The custom  
theme currently doesn't support on-the-fly theme-switching while the  
app is running.

   If you want to change themes on-the-fly while PP runs, or if you  
prefer GNUstep's built-in theme, you can disable PP's custom theme by  
setting 'PPDisableGSThemeCustomizations' in PikoPixel's defaults:

defaults write PikoPixel PPDisableGSThemeCustomizations YES


> Which is more annoying is an incompatibility with PikoPixel and the  
> Rik. theme for me : it crashes at startup.
>
> Since revision beta9a, Pikopixel segfaults on dry launch, right  
> after that I push the OK button of the first dialog (creating an  
> empty window). It doesn't occur when I open an image with it (using  
> the context menu of GWorkspace).

   Thanks for this info. I can reproduce the crash, and it appears to  
be a bug in Rik.theme (I used the fork at https://github.com/BertrandDekoninck/rik.theme 
 ):

   Rik.theme replaces the implementation of -[NSWindow  
setDefaultButtonCell:] in order to set up an animation that pulses the  
window's default button. Rik.theme's animation controller retains the  
default button cell that was passed, and the animation will  
continuously call [[defaultbuttoncell controlview] setNeedsDisplay:  
YES] to update the button.

   However, the animation is never stopped, so it will continue  
sending setNeedsDisplay: messages even after the window is ordered  
out, up until the app exits (for every default button that's been  
displayed).

   If a window is unloaded (several of PikoPixel's sheets are  
released once they're dismissed, including its initial size sheet),  
the default button cell will stick around, since the animation  
controller retained it, but the cell will contain a pointer to a now- 
deallocated control view (NSActionCells don't retain their control  
views, presumably to prevent retain loops), and sending it a  
setNeedsDisplay: message will crash.

   To show this is the cause of the issue, you can prevent the  
control view from deallocating by retaining it as well - change  
rik.theme's NSWindow+Rik.m, line 35:

        [[defaultbuttoncell controlview] setNeedsDisplay: YES];
->
        [[[defaultbuttoncell controlview] retain] setNeedsDisplay:  
YES];

   (Note that this is just for demonstration, and not a fix, since it  
will leak the control view & run up its retain count. A fix would  
probably involve registering for NSWindowDidResignKey notifications  
and stopping animation when the notification was received).

Cheers,

Josh