Re: NB 8.2 Issues

IIRC localisation of icons/images is supported. Weeks ago I was first confused while debugging to see generated resource names like image_dark_en or image_dark_de_de, but in this l10n context it makes sense nowDen 5 okt. 2016 8:54 em skrev Steven Yi <[email protected]>:
>
> Hi Neil, 
>
> Glad to help!  :) 
>
> I don't know about whether this is totally broken; I think the issue 
> Benno's commit solves is just a bit complicated and there was just an 
> unseen impact as a result.  The behavior of the code is pretty much 
> the same as it was prior to the commit, and the change adds an 
> additional case to process with an RGBFilter.  It's really the new 
> images that threw things off (i.e., if the code changes were all that 
> were done, I don't think I'd have seen  any issues come up.) 
>
> I don't know if modifying ImageUtilities.getIcon() would do much from 
> what the dark-handling code does.  We'd still need to iterate through 
> all of the locale/branding variations for both dark and non-dark 
> images, which is what the code does.  (At least that's my 
> interpretation.) 
>
> Cheers! 
> steven 
>
>
>
> On Wed, Oct 5, 2016 at 1:02 PM, Neil C Smith 
> <[email protected]> wrote: 
> > Hi Steven, 
> > 
> > Thanks for taking this one for the team! :-)  This looks like it'll be 
> > fun to work with. 
> > 
> > The way this has been added seems to be totally broken.  Out of 
> > interest, I wonder how ImageUtilities handles localization suffixes? 
> > Does that suffer from the same problem, or could the dark theme tag on 
> > to that? 
> > 
> > Best wishes, 
> > 
> > Neil 
> > 
> > On 5 October 2016 at 17:20, Steven Yi <[email protected]> wrote: 
> >> Hi All, 
> >> 
> >> I have determined the root cause for my issues.  It goes like this: 
> >> 
> >> 1. With dark themes, using "nb.dark.theme" = true in the UIManager 
> >> flags ImageUtilities to attempt to load "image_dark.ext" before 
> >> loading "image.ext".  This behavior did not change with commit 
> >> 121baf524946. 
> >> 2. With commit 121baf524946, what did change was that new dark 
> >> versions of images were added (frame_dark.gif, frame32_dark.gif, 
> >> frame48_dark.gif, spash_dark.gif).  Prior to the commit, if you had 
> >> just the normal versions of these images in your branding, it would 
> >> override the versions provided by Netbeans.  After the commit, the 
> >> Netbeans dark versions now have precedence in loading.  This means 
> >> that end users using dark themes are now *required* to rename their 
> >> branding images as _dark. 
> >> 3. For the splash screen, two different images are used. First is a 
> >> static image that is cached from a previous run (splash1) that is 
> >> displayed using AWT splashscreen. Second is the Splash.java code 
> >> (splash2).  The reason I saw two images --- the Netbeans one and my 
> >> own --- is that the splash1 is generated and cached.  The generation 
> >> of that image was done at a later time in the loading process once my 
> >> LAF code set "nb.dark.theme".  That would load "splash_dark.gif". 
> >> However, for splash2, that gets called earlier in the loading process, 
> >> prior to when "nb.dark.theme" was set.  splash2 would then attempt to 
> >> load "splash.gif", which would use my own splash and not the Netbeans 
> >> splash.gif. 
> >> 
> >> To work around these issues, I did the following: 
> >> 
> >> 1. Renamed my frame branding images to use the _dark suffix to fix the 
> >> setting of the icon for my application. 
> >> 2. For the splash screen, I now have to have duplicates of the splash 
> >> image, one as splash.gif and the other as splash_dark.gif.  This 
> >> ensured that both splash1 and splash2 present the same image content. 
> >> 
> >> A few questions/comments: 
> >> 
> >> 1. Is there a way to set nb.dark.theme in UIManager early enough such 
> >> that I don't have to package duplicates of the splash image? 
> >> 2. It seems that any time now a dark version of an image is added to 
> >> Netbeans platform, end users may will need to update their images to 
> >> override it if they were previously relying on overriding the non-dark 
> >> version. It might be nice if image additions could be advertised as 
> >> part of the ChangeLog as a heads-up. 
> >> 3.  The branding dialog within Netbeans does not account for _dark 
> >> images for frame icons or splash, and only presents users the non-dark 
> >> versions (or defaults).  This dialog should probably be updated to 
> >> work with dark themes.  Until then, users should manually deal with 
> >> dark versions of images within 
> >> branding/core/core.jar/org/netbeans/core/startup.  (At least, for 
> >> ant-based projects; I am not sure if anything is necessary for 
> >> maven-based projects.) 
> >> 
> >> That took a while to sort out, but I think it explains the situation 
> >> and things are now working here as I expected. 
> >> 
> >> Thanks! 
> >> steven 
> >> 
> >> 
> >> 
> >> On Wed, Oct 5, 2016 at 9:29 AM, Steven Yi <[email protected]> wrote: 
> >>> Hi Benno, 
> >>> 
> >>> My apologies, I *do* set nb.dark.theme to true. (UGH)  The breakpoint 
> >>> for isDarkLaf() didn't hit during the initial splash though as my LAF 
> >>> doesn't seem to get to set the value before that shows. It did hit 
> >>> once I went to show the About screen.  I need to run but I will try 
> >>> out creating image_dark_branding.gif for the frame icons and splash. 
> >>> I'll report back results shortly. 
> >>> 
> >>> Thanks! 
> >>> steven 
> >>> 
> >>> On Wed, Oct 5, 2016 at 9:04 AM, Steven Yi <[email protected]> wrote: 
> >>>> Hi Benno, 
> >