Re: NB 8.2 Issues

Too much text and only a smartphone keyboard for answering...

First. Thanks for your effort and investigation. Can you please add the info to the faq entry! 

Second : Yes. There were some inconveniences introduced as you showed. I was not aware of it. As you see in the commit I simply aligned the behavior of the two image loading methods. The previous behavior was faulty and it made no sense that one method supports dark images and the other not. 
I doubt that are many platform derivates, which use a dark theme with the flag set, are affected. I am also against defining images as public API. That makes it more complicated. With NB82 the dark theming should be quite stable now. /defendmodeoff

Third: Yes, we can improve the handling of splashscreen and the branding dialog. This could be one of the first contributions under the Apache flag. Create issues for that and we can work together. 

Best regards,  BennoDen 5 okt. 2016 7:20 em skrev Steven Yi <[email protected]>:
>
> 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, 
> >> 
> >> Thanks for the reply.  My images are named the same as they have 
> >> always been and for which they worked in previous platforms. If 
> >> something changed that requires new image names I'd consider this a 
> >> regression. 
> >> 
> >> However, my theme, while dark in nature, does not come up as a dark 
> >> look and feel (I don't set "nb.dark.theme").  Setting breakpoints in 
> >> Splash and ImageUtilities confirms that those code paths for dark 
> >> image loading are not used. 
> >> 
> >> An interesting point is that the image I am seeing for the splash and 
> >> about screen is precisely the one shown in that wiki link. 
> >> 
> >> It would be simpler if the problem was that I only saw one image (the 
> >> dev one), but what I'm seeing is the dev one first appear, then my own 
> >> image, on startup.  For the about screen, I only see the dev image. 
> >> 
> >> I do see something interesting: in org.netbeans.core.startup.Splash, there is: 
> >> 
> >>  if (!s.exists("splash.png")) { 
> >>                 s.scheduleSave(this, "splash.png", false); 
> >>             } 
> >> 
> >> Looking in my test user directory, in the cache is indeed a splash.png 
> >> with the dev image. 
> >> 
> >> I looked through the commit 
> >> (http://hg.netbeans.org/main-silver/rev/121baf524946) but nothing 
> >> there seems like it would  cause this behavior. 
> >> 
> >> I also checked that the contents of the core_{BRANDING}.jar contains 
> >> my images and it does, which hints to me that the build process is 
> >> working alright. 
> >> 
> >> 
> >> On Wed, Oct 5, 2016 at 2:11 AM, benno.markiewicz 
> >> <benno.