Add a QuickViewFragment and buttons for it

[EmmanuelMess]

Description

Issue tracker

Related #2092

Automatic tests

• Added test cases

Manual tests

• Done

Build tasks success

Successfully running following tasks on local:

• ./gradlew assembledebug
• ./gradlew spotlessCheck

[EmmanuelMess]

@VishalNehra 12 function limit? Most of these are short functions, please increase limit.

[VishalNehra]

Done, please retrigger the build

[EmmanuelMess]

Done, please retrigger the build

Done

[EmmanuelMess]

@VishalNehra issues are black history icon in appbar and monetization?

[EmmanuelMess]

@VishalNehra why is this stuck it doesn't even change behaviour on release builds.

[VishalNehra]

@VishalNehra why is this stuck it doesn't even change behaviour on release builds.

Sorry, what's stuck?

[EmmanuelMess]

@VishalNehra why is this stuck it doesn't even change behaviour on release builds.

Sorry, what's stuck?

The PR, it is marked as draft.

[VishalNehra]

@EmmanuelMess Oh, you mean for review? We discussed on this right. We decided on few changes. Plus we wanted to migrate to a plugin for the same.

[EmmanuelMess]

@EmmanuelMess Oh, you mean for review? We discussed on this right. We decided on few changes. Plus we wanted to migrate to a plugin for the same.

How are we going to migrate to the plugin?

What changes, I need a list here so I can work on them.

[VishalNehra]

@EmmanuelMess Sure.. from the top of my head... It'll be a simple list of fragments / activities able to handle image / music intents in the plugin plugin application.. and from amaze it'll just be a conventional open file intent call, where our plugin activity will show up.

So I see no changes in amaze right now (maybe later we show a small one time demo of how they can purchase our plugin to quickly see the image when they press on it)

[EmmanuelMess]

Sure.. from the top of my head... It'll be a simple list of fragments / activities able to handle image / music intents in the plugin plugin application.. and from amaze it'll just be a conventional open file intent call, where our plugin activity will show up.

I won't implement that, as I said, that would remove the benefits of having a fast system to show how files look in the app, and I believe it will not go with the features a file manager should provide.

So I see no changes in amaze right now (maybe later we show a small one time demo of how they can purchase our plugin to quickly see the image when they press on it)

I need to know how the division of code should be done, what parts go on the plug in and what goes in Amaze. I would prefer as much as possible to be implemented in Amaze. The more systematic the choosing of code the better.

[VishalNehra]

I won't implement that, as I said, that would remove the benefits of having a fast system to show how files look in the app, and I believe it will not go with the features a file manager should provide.

Oh, don't worry, it'll be fast view in the app only as a form of plugin. The activity can be a small dialog instead of a full screen image view. I would like to quote an app shared by @TranceLove to get an idea of what I mean.

I need to know how the division of code should be done, what parts go on the plug in and what goes in Amaze. I would prefer as much as possible to be implemented in Amaze. The more systematic the choosing of code the better.

With the above approach the plugin will handle everything through intent, I don't think there would be a need to put any image viewer code in Amaze (neither should we, as you yourself stated, it's not responsibility of a FM).

Lemme know the confusion, we can discuss on the group.

[EmmanuelMess]

I don't think there would be a need to put any image viewer code in Amaze (neither should we, as you yourself stated, it's not responsibility of a FM).

There is IMO the need for fast visualization of arbitrary files on Amaze, especially for files on the cloud or via ssh, to exceed would be to add more gallery features like cropping or intents IMO.

There is no image viewer code in Amaze, it is almost all managed by Glide, and then there is a generic view hierarchy for all quick views.

With the above approach the plugin will handle everything through intent,

Can we implement the intent management correctly without extensive code writing for managing different sources, like internal storage, ssh, ftp, etc?

[EmmanuelMess]

Lemme know the confusion, we can discuss on the group.

IMO it seems easier for me to keep track of the conversation points on GitHub.

[VishalNehra]

There is IMO the need for fast visualization of arbitrary files on Amaze, especially for files on the cloud or via ssh, to exceed would be to add more gallery features like cropping or intents IMO.

The fast visualization can be done with plugin as well. We can have caching as well for remote files if we want. And plugin will be easier to monetize.

[VishalNehra]

to exceed would be to add more gallery features like cropping or intents IMO.

It'll be published as plug-in, so no need to add those all features initially.
Later if we want we can always expand feature set.

[EmmanuelMess]

It'll be published as plug-in, so no need to add those all features initially.

IMO those can never be added as it would consume dev time from other more file manager related features and not be part of what a file manager should do.

[EmmanuelMess]

The fast visualization can be done with plugin as well. We can have caching as well for remote files if we want. And plugin will be easier to monetize.

I understand the need to have a plugin, but how should code separation be done?

Also, this does not have intents currently for loading files, will intents work correctly with files from the cloud?