Closed EasyG0ing1 closed 3 years ago
@EasyG0ing1 If you're done with changes, I'd like to merge this. It looks great. Please confirm before I do. Thank you!
@dustinkredmond - Yeah, I'm done .. I was just working through those external tests you have set up ... it was failing them for little things ... dotting I's .. .crossing T's ... etc.
Glad to hear you like the changes ... I absolutely love it! So much more convenient especially for adding menus.
:-)
@dustinkredmond - I added one blurb to the README at the top... that will be my last change ... for real this time. :-)
Perfect, looks good. I'll go ahead and merge and shoot for a release by week's end. As always, thanks for your contributions!
So I've been reading this book about Java best practices and have been really digging the discussion on Builder classes. Very powerful. However, a full-blown Builder class has certain characteristics that would cause of lot of change depending on the class. But with FXTrayIcon, I was able to implement a Builder class without losing any original functionality. The class constructors have the same mandatory parameters as FXTrayIcon. The only difference is that in the second constructor, I add detection for Mac and then instantiate with a 26,26 icon as those are much better on macs than the 16,16.
Once the Builder class is instantiated, it creates a new instance of FXTrayIcon then basically continues to build on that instance until the build call is made at which point it only passes that instance of FXT back to the application.
Besides being convenient, there are some benefits to having this class. For example, addTitleItem and addExitItem are booleans that only affect future change, whereas, in Builder style, it will exist in FXT by the end of the sentence.
Here is an example of using the Builder class in an program I was working with yesterday (testing a really nice Java Email library that is quite powerful and stupid simple).
The current way of doing the exact same thing would be like this:
With the Builder class, it is technically two lines of code, including the show() method whereas the current way, it. is close to 30 lines of code.
You don't have to create MenuItems and then pass them into FXTI, all you need to do is use the menuItem Build option and pass in a string for the label or a String and an Event Handler., you can also call show from the Builder sentence, and set any and every possible option in that one line.
I also added two example classes to the test package. One which was a copy of one you already had, only using the Builder class and the other one is a demo of switching icons after instantiation ... with a splash of color ☺.
That purple chain link icon was difficult to see in a dark theme so I made new icons to see how they would look and of the ones I made the red icon seems to work best in both light and dark mode.
Here are the icons.
They aren't great, but they don't suck either.