OK, so this is pretty cool. I recently learned how to do animations in Java, and I began to wonder if this could be done with the icon in FXTrayIcon ... so I did some experimenting, and sure enough ... not only can it be done, but it works REALLY well! SO, I added it as a feature in the library.
I created a package private class (Animation) that manages the core of the animation process where the setup and controlling of the animation is done through the main class. Both in the Builder and of course post instantiation.
Everything is well documented, and I created a test program with three example animations in there. It ran fine for me in Idea... I didn't try it as a Maven Lifecycle.
I didn't document the Animation class since it is package private and it cannot be seen by users of the library. So there's nothing in there for them anyways. I figured the docs in the main class would be sufficient, but if you prefer, I will document it, just let me know.
I bumped the version number and set it to a SNAPSHOT ... you should be able to pull it and just do a mvn clean install and then use it in whatever - which is how I tested it on one of my apps.
All of those private loadImage methods that returned based on the OS would then leverage different size values for the icons ... I got rid of those if statements using an immutable size class that is created and defined at instantiation based on the OS and it cannot be changed.
I can see where you've struggled with these icon sizes ... and I have decided that at least where the animation is concerned, It is going to default to the final icon sizes that you defined by leveraging a small class that stores those sizes. Same class I just mentioned only this one can be changed by the programmer if they desire to do that leveraging the setIconSize() method. The Animation code simply uses that class object to get the icon sizes so if the user changes it then it will just use those automatically.
We might want to consider deprecating all places where the icon sizes are passed in by argument and defaulting everything to the operating system sizes you defined while allowing the programmer to change the size ONCE and no need to keep typing in the size when you do anything with different icons. Should make working with the library easier as well as making the library simpler because where icon sizes are concerned they will only ever be taken from one object... and simplification is a beautiful thing! There are a lot of overloaded methods in the program for that reason alone so dialing it back to leaving it default with the option to make the default whatever they want (except for those methods that you defined, those defaults are immutable), would simplify a lot and it would make a final stand on the issue while allowing flexibility for those who need it.
I re-structured the Builder and deprecated all code that requires icon sizes and we can fade those out whenever ... certainly no hurry because it will definitely break people's programs after an upgrade so we will want to present this as deprecated for some time I think...
had to be done because my test program was leveraging a dependency that isn't modular compliant so that section tells Maven to not test compile the code in the test folder.
OK, so this is pretty cool. I recently learned how to do animations in Java, and I began to wonder if this could be done with the icon in FXTrayIcon ... so I did some experimenting, and sure enough ... not only can it be done, but it works REALLY well! SO, I added it as a feature in the library.
I created a package private class (Animation) that manages the core of the animation process where the setup and controlling of the animation is done through the main class. Both in the Builder and of course post instantiation.
Everything is well documented, and I created a test program with three example animations in there. It ran fine for me in Idea... I didn't try it as a Maven Lifecycle.
I didn't document the Animation class since it is package private and it cannot be seen by users of the library. So there's nothing in there for them anyways. I figured the docs in the main class would be sufficient, but if you prefer, I will document it, just let me know.
I bumped the version number and set it to a SNAPSHOT ... you should be able to pull it and just do a
mvn clean installand then use it in whatever - which is how I tested it on one of my apps.All of those private loadImage methods that returned based on the OS would then leverage different size values for the icons ... I got rid of those if statements using an immutable size class that is created and defined at instantiation based on the OS and it cannot be changed.
I can see where you've struggled with these icon sizes ... and I have decided that at least where the animation is concerned, It is going to default to the final icon sizes that you defined by leveraging a small class that stores those sizes. Same class I just mentioned only this one can be changed by the programmer if they desire to do that leveraging the
setIconSize()method. The Animation code simply uses that class object to get the icon sizes so if the user changes it then it will just use those automatically.We might want to consider deprecating all places where the icon sizes are passed in by argument and defaulting everything to the operating system sizes you defined while allowing the programmer to change the size ONCE and no need to keep typing in the size when you do anything with different icons. Should make working with the library easier as well as making the library simpler because where icon sizes are concerned they will only ever be taken from one object... and simplification is a beautiful thing! There are a lot of overloaded methods in the program for that reason alone so dialing it back to leaving it default with the option to make the default whatever they want (except for those methods that you defined, those defaults are immutable), would simplify a lot and it would make a final stand on the issue while allowing flexibility for those who need it.
I re-structured the Builder and deprecated all code that requires icon sizes and we can fade those out whenever ... certainly no hurry because it will definitely break people's programs after an upgrade so we will want to present this as deprecated for some time I think...
I put a discussion about it in the README
Also, this section that I added to your pom file:
had to be done because my test program was leveraging a dependency that isn't modular compliant so that section tells Maven to not test compile the code in the test folder.