Re: NB 8.2 Issues

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,
>>>>
>>>> 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
>>>> <[email protected]> wrote:
>>>>> Steven, check http://wiki.netbeans.org/DevFaqImagesForDarkLaf
>>>>>
>>>>> 1)I contributed a change regarding image loading for dark lafs in 8.2. Perhaps your icons are not properly named...
>>>>> 2) Check the sources of NB. There won't be so much splashscreen images. In worst case, brand the unwanted one also. Den 5 okt. 2016 1:19 fm skrev Steven Yi <[email protected]>:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I updated to NB 8.2 just now and gave my Ant-based platform
>>>>>> application a try on it. I'm seeing two issues at the moment:
>>>>>>
>>>>>> 1. The icons for my application (visible in Branding dialog, also
>>>>>> located within branding folder) do not seem to get applied in the
>>>>>> build. (Cleaning and rebuilding with 8.1 does work fine.)
>>>>>>
>>>>>> 2. When I go to run the application within the IDE, for the splash
>>>>>> screen, I first see a Netbeans IDE image that says "Netbeans Platform
>>>>>> Development Version" appear, then as the progress occurs on load, my
>>>>>> own splash screen image appears with the progress bar.
>>>>>>
>>>>>> Both issues exhibit themselves when I generate a release build and
>>>>>> execute the release version of the application.
>>>>>>
>>>>>> Are others seeing these behaviors too?
>>>>>>
>>>>>> steven
>
>
>
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org