Always show the File Tree button in the toolbar

[Smooth-E]

Behold! The much requested File Tree button can be now kept in the toolbar!

This pull request aims to add a preference which makes the File Tree button always visible in the editor toolbar as an action. This will make it easier and faster to open the File Tree drawer for those who use Gesture Navigation on Android 12+ devices.

Tasks

• Create the described preference preference
• Solve the issue of Material Toolbar showing the maximum of three icons on most devices which is, in some cases, unwanted and it also makes this new preference useless
• Make so that on Android 12+ devices the preference is enabled by default.
  At the end of the day I ended just checking whether the Gesture Navigation is in use when the preference is first accessed. This reduces the number of checks and also takes all of the Android versions with Gesture Navigation available.
  This would be even cooler if we can detect which Android vendor distribution is used, so we won't enable the preference on Android distros where Gesture Navigation does not break the slide-to-open Drawer functionality (e.g. MIUI).
  The previous statement is really not that possible to implement. The manufacturer of the device is the only information we can somewhat trust. Device fingerprint, OS name and its particular model are the pieces of information that will not lead us to the answer of whether a user is running stock MIUI or a custom ROM which relies on MIUI binaries. On might suggest to check whether the device is rooted, but a lot of custom ROMs implement root anti-detection built-in these days.

[Smooth-E]

As stated here Android's Material Toolbar displays 3 icons on devices with the DPI of 360. Those three icons are usually two functional actions and the three-dots to open the overflow menu. This often renders the behavior of the toolbar rather unnatural. For example, on my device there are three icons displayed in the Toolbar and when I switch from editing to the bottom sheet, the Undo icon is replaced with Run Tasks. This is also while plenty of space in the Toolbar left unused on the left side of it.

I think we should make use of the SHOW_AS_ACTION_ALWAYS attribute in some clever way. For example, actions may have an additional data field defining their importance. The most important actions then will be given the flag of SHOW_AS_ACTION_ALWAYS, others will be given SHOW_AS_ACTION_IF_ROOM.

I am also curios, what happens if a lot of actions are set to SHOW_AS_ACTION_ALWAYSand the Toolbar gets overflown. Will those actions be placed into the overflow menu or will it create visual inconsistencies?

Edit: Yes. Making too many actions to be always visible in the toolbar breaks the user experience. It is said so in the javadoc for SHOW_AS_ACTION_ALWAYS.

[Smooth-E]

As mentioned in the edit, setting too much items to SHOW_AS_ACTION_ALWAYS breaks the user experience. However, if we think of the Importance concept, the fact that SHOW_AS_ACTION_ALWAYS ignores how much space is left in the toolbar, we can calculate the space ourselves and then calculate, how many actions we can fit into the bar.

The component that is responsible for how many icons the toolbar will display is the ActionbarPolicy. This is an internal Android's component which we are not capable of overriding and passing to our custom toolbar view, for example.

While writing this message I actually tried overriding some internals off the Toolbar and here is the dead end, since the field is private, The Presenter is what uses mentioned ActionbarPolicy inside of itself to measure, how many items a Toolbar can display.

This might mean that for intended behavior to be implemented, we should write our own implementation of a Toolbar or use some third party library which already did so.

[Smooth-E]

The issue with the Material Toolbar and its inability to display more icons is now solved.

[itsaky]

It seems like the PR is still a work in progress, so I'm converting it to a draft. Mark it as ready once it's completed.

[Smooth-E]

Every proposed feature seems to be implemented now. You are welcome to review the code @itsaky.

Please note, that in some cases, for example in the XML editor (text based), the File Tree button is pushed into the overflow by Redo, Undo and others, especially on small screen. I am thinking of an editor's toolbar items arrangements preferences to implement next. However, I think that this will take more time and is out of scope for this Pull Request.

[itsaky]

Thank you for your contribution.