Icon Size Discussion

[EasyG0ing1]

Hi Dustin,

I thought it might be best to have this discussion on an issue.

(I know this seems like a lot of words for such a simple thing, but being thorough never ruined anything)

As I was contemplating whether or not to include the ability to define icon size as an argument in the animation feature, I looked over the code everywhere a reference to icon size happens and a couple of things occurred to me:

1 - I think after having much discussion concerning icon size -as has been the case in different issues - it seems to be a constant that Windows likes one size while MACs like a different size but that once those sizes are used, decreasing the size only makes the icon look bad and increasing the size beyond that sweet spot - at least on a mac - has no effect at all.

2 - So then does it make sense to work towards removing the option of sizing the icon at all?

As I thought that through; what made the most sense to me, would be to work towards removing size options altogether, while allowing someone to change the size one time and have that change remain constant - which fits Builder style quite well but could also be worked into traditional class constructors.

So in that line of thinking, I would like to deprecate all constructors and methods that accept the sizing of the icon as arguments ... with the eventual complete removal of that code after some time has passed.

This is how I would implement it in the code:

I would use a class - preferably a record class, but those don't exist in Java 11 which is I believe what you publish the library in ... The class will only have two integer variables for width and height. Then, one instance of that class (call it iconScale) where the values for W and H are set based on the running operating system.

Then, whenever a call is made to a method that does not require icon dimensions to be specified, the values in iconScale will be used.

Then, we use the method setIconSize that will give people the option of overriding the values in iconScale - where I tend to lean into having that as a separate method as well as a Builder option but not massaging it into the formal constructors.

Then deprecate all methods and constructors that accept size values and change the Javadocs explaining what the plan is and encouraging the use of the non-deprecated code.

Public methods that accept dimensions as an argument will continue to call the related private methods that use those values, while the public methods that don't take those values result in the related private methods using the values from iconScale.

With everything in place like that, once we pull the trigger on removing the deprecated code, we will only need to delete the code without making any other changes and everything will continue to work under the new model.

I see two major advantages to transitioning over to this model:

1 - The code becomes much simpler because icon size is now relegated to one single object and that object is only referenced in a small number of methods where the only public-facing method would be in setIconSize and nowhere else.

2 - Library usability becomes much simpler requiring less thought to use it (gee what size should I make these icons to meet the requirements of the constructors and methods?), where under the new model no one need be concerned about it ... this also declutters (a little bit) the code that uses the library.

If you like the plan, I'll submit the PR right away and make all of the Javadoc changes as well as describe the plan in the README.

I tend to think that the only way this could ever be problematic for users of the library - would be in those cases where they miss the version upgrade that has the marked deprecations and they end up going straight to the version that has that code removed which would then break their code completely, though it would be a relatively easy fix for them, it would be the only scenario where someone could be caught off guard. But if we let the deprecated code stay in for like six months or so, I think most people would see the deprecation and make adjustments accordingly before pulling the final trigger on the new model.

Overall, the notion of simplifying any library is of course the holy grail of writing such code. This scenario is certainly minor ... but still relevant I think.

Your thoughts on this?

[dustinkredmond]

@EasyG0ing1 I like your idea, as well as the way you choose to implement it. I do not have a problem with marking items as deprecated and keep them in the releases until a few versions have passed. We can reserve a major version to fully delete these.

This seems like it would definitely help simplify things!