Cgeo: [Log: adding images] add resorting option and reintroduce image title prefix

[eddiemuc]

Is your feature request related to a problem?
Adding of images to logs is currently a long image-per-image-procedure involving at least four clicks through 3 dialogs (in log dialog click "add", in image dialog click "stored", in image select intent choose image, in image dialog click "ok"). This is ok in case you want to edit other image properties like title and description anyway. For people simply wanting to add a couple of pics (maybe 2 or 3) however this is quite painful.

Describe the solution you'd like
Currently there is a single "add" button in the log. Idea is to place three (icon) buttons there instead:

• "add from storage": opens image select intend, allows for selection of multiple images, those are added with default title, empty description and scaled down to a predefined size (maybe 640ox)
• "add from camera": opens camera intend, pic is placed in list with same logic as above
• "add (advanced)": works exactly like today's button (opens c:Geo's own advanced image select dialog)

Additionally I would make tipping of image in a list open a context menu with options "edit" (opens c:geo image dialog) and "remove" (removes entry from image list

Describe alternatives you've considered
Alternative is to do nothing. Feature does not add new functionality.

Additional context

• Discussion in #8970 shows that existing dialog should stay
• fast select is inspired by other caching apps

[Lineflyer]

Why not replacing the own image select dialog completely by your idea of using the image intents.

But this would mean the log view needs to be extended by subtitle and scaling selector.
Wouldn't this be even more consistent instead of having two selection methods?

[Lineflyer]

So each picture would need:

• Title (current prefix field could be used)
• Subtitle/Description
• Scale selection

[eddiemuc]

Why not replacing the own image select dialog completely by your idea of using the image intents.

But this would mean the log view needs to be extended by subtitle and scaling selector.
Wouldn't this be even more consistent instead of having two selection methods?

This would mean that the image title list could get very long/big in the log dialog. Would that be a problem?

The usage you suggest with resp of "title" vs "title prefix" is still not clear to me. Currently you can give each img its own "title" (in the image dialog). For those imgs where this title is empty, the "title prefix" (editable in the log dialog) plus a number is used as title. This can be changed of course. Are you suggesting not to make individual img titles editale any more (just the "prefix" then set for all images)? Or is it something else? Sorry for my slow understanding...

As of the scaling: is it really valuable for the user to set a scaling per log image? I don't see anything like this in other apps dealing with pic upload. E.g. Whatsapp just scales down your images in the background without you ever seeing any of this.

[fm-sys]

My suggestion:

• only two buttons (add from file & add from camera)
• selected files are directly shown in the log activity
• click on an image at log activity directly opens edit image dialog (without context menu first)
• maybe an additional delete button directly visible for each image
• for the scaling maybe a shared preferences option for the default scale (settings > logging)
• at edit image dialog show the default title (image prefix + index like shown at the log activity) if no individual title is set for the image

[eddiemuc]

@fm-sys I like your idea. Two questions:

• If we make the image items editable-on-click but add (e.g. at the end of the line) a trashcan-icon-button for delete -> would that be ok from GUI perspective (button for delete, but no button for edit)?
• direct selection of images via add from file/camera means that we must apply some default scaling either immediately or on send (in case user does not go into edit menu). If we apply scaling immediately, user cannot scale "up" again afterwards without quality loss. If we apply scaling on send then send might take a little longer (also, if send fails, images are already downscaled anyway). Any preference (or a third idea)?

[fm-sys]

If we make the image items editable-on-click but add (e.g. at the end of the line) a trashcan-icon-button for delete -> would that be ok from GUI perspective (button for delete, but no button for edit)?

Yes from my side! Maybe we can also make the images sortable via drag & drop. Then we would have quite the same UI as in RouteSortActivity... (but probably that's another feature request)

direct selection of images via add from file/camera means that we must apply some default scaling either immediately or on send (in case user does not go into edit menu). If we apply scaling immediately, user cannot scale "up" again afterwards without quality loss. If we apply scaling on send then send might take a little longer (also, if send fails, images are already downscaled anyway). Any preference (or a third idea)?

How is it done currently? The best would probably to execute scaling while upload, and delete the original files only if submitting the log ends successfully. From what I guess scaling does only take some ms up to maybe one second maximum, so is doesn't really matter as uploading the images takes some seconds anyway.

[eddiemuc]

How is it done currently?

Currently, scaling is applied each time you click "ok" in the "add image" dialog (according to the setting of the "scaling" selection dropdown in that dialog. Also, each time you do that a new copy of the image is stored to your phone (and the existing one remains). If you open this dialog again and scale "up" later then quality will get worse...
Not making a (scaled) image copy on offline log save would be an option of course, but it also means that if someone attaches an image to a log, then (using another app than c:geo) deletes that image from disk, then goes back to c:geo to send the log -> then this will fail because image is not found any more.

[MagpieFourtyTwo]

What if adding the image to the log will scale the pic to the max level in the scale drop down (resp. the max, gc.com allows) and then save it to c:geo's pic dir, from where it will be scaled prior to uploading and be deleted, as soon as the log has been either cleared or sent ...?

BTW: The default of "No scaling" seems to be kind of "dangerous" to me - just think of today's 100 MP cameras ... taken into account that gc.com will scale the pic anyway, this is in fact just a waste of mobile data plan. Thus I would suggest to use a reasonable default, based on gc.com's max scale size (which I in fact currently do not know, but I guess it's even less than 1920x1080 resp. 2 MP).

Ah, any chance to get these pics uploaded (and used on gc.com) with fieldnotes ...?

[eddiemuc]

What if adding the image to the log will scale the pic to the max level in the scale drop down (resp. the max, gc.com allows) and then save it to c:geo's pic dir, from where it will be scaled prior to uploading and be deleted, as soon as the log has been either cleared or sent ...?

Good idea, I like it. Currently that would be 1024px

BTW: The default of "No scaling" seems to be kind of "dangerous" to me - just think of today's 100 MP cameras ... taken into account that gc.com will scale the pic anyway, this is in fact just a waste of mobile data plan. Thus I would suggest to use a reasonable default, based on gc.com's max scale size (which I in fact currently do not know, but I guess it's even less than 1920x1080 resp. 2 MP

Afaik gc.com has a size-based upload limit of 3MB per image (or something in that area).

Ah, any chance to get these pics uploaded (and used on gc.com) with fieldnotes ...?

I never had any contact with field notes in the past. Are images supported there from gc-side?

[MagpieFourtyTwo]

I never had any contact with field notes in the past. Are images supported there from gc-side?

Maybe (read: "Would be great"), but in fact I don't know for sure,
although the API documentation at least seems to pretend that it should be possible somehow.
Nevertheless, have never ever seen a pic added to a fieldnote (formerly known as draft),
and not even a button on the website, to add an image to a draft ...
But perhaps someone with knowledge of this mega brilliant paid genuine app can say more ...?

Anyway, the more I think of such a possibility, the more I like it - being able to do so would in fact really help a lot.

BTW: Does the given resolution (like e. g. 1024px) refer to the longest side or what does this mean?
Cause if it's the longest, we should probably extend the list range up to 1920 resp. gc.com's max ...

[eddiemuc]

BTW: Does the given resolution (like e. g. 1024px) refer to the longest side or what does this mean?
Cause _if_ it's the longest, we should probably extend the list range up to 1920 resp. gc.com's max ...

Currently it refers to the longest side. "scaling to 1024p" in this context means "reduce the size of the image proportinally such that after the scale the longest side is not longer than 1024px". If you "scale" an image where both sides are already equal or less than 1024px then the image is not touched at all.

[geocachermgo]

Just a question: are the EXIF info removed in any case by c:geo?

[alan666notb]

Just a question: are the EXIF info removed in any case by c:geo?

I raised this issue awhile ago in #6026, the act of 'scaling' an image in cgeo removed the Exif data.
If you choose to upload an image without scaling it, the Exif data is left in.
(I think it should always be removed by default).

[MagpieFourtyTwo]

I think it should always be removed by default

👍

[geocachermgo]

me too, see comment on #6026: Since 2018 it makes no sense to keep it since it's removed by gc

[eddiemuc]

In case you wonder why there is no progress on this one: I am really blocked by the image button problem I issued here: #8979

Without this I have following options only:

• Use "text" buttons (don't really want to do that to be honest)
• Reuse existing icons (but I have not found a really nice one for "camera")
• Mixing the above ("plus" icon for "add from storage" and "text" button "Camera" for camera)
• Create icons in a way that they will look "different" from the other icons in c:geo

Don't really like any of the above...

If we come closer to a release and this is still unresolved, my offer stands to simply remove the title image prefix field for the time being (as offered in #8970 ) so we can go into production with a consistent but not yet finalized view. This can be done on very short notice. Alas, I have no idea regarding the timeline for the release this stuff will be in.

[eddiemuc]

PR #9138 contains the NON-GUI-parts of this Issue. See details there.

[eddiemuc]

For fast-select of images directly in log view, what do you thing about following icons:

For selecting from camera:

For selecting (multiple) images from storage:

(both icons are from https://material.io/resources/icons)

[eddiemuc]

I have a more general question:
I noticed that in activities, there are often creations of anonymous instances of AsyncTask to perform background work and resync with UI afterwards.
Android Studio always warns me that this might create memory leaks because instances hold a reference to activity internal. So I would like to replace those occurrences with usage of explicit static class (did that in case of image loading now)

But is this even the right way for asynchronous work in c:geo? Or is there maybe some RxJava routine that should be used instead of AsyncTask?

[bekuno]

I am afraid that no one can answer the questions about the historical course of events more precisely. Most of the developers who wrote the code are no longer active. Only @rsudev it this occasionally.
Furthermore, it should be considered that Android has changed a lot over the years. That means that today's possibilities (under consideration of minSdkVersion (currently 21)) can differ a lot from the original ones.

[eddiemuc]

Added PR #9186 to finalize implementing this feature. GUI will look like this:

I hope I did not forget anything?

[fm-sys]

Only a resorting option would be a nice add-on (like it is done for individual route) Mabe as long click action?

And I would reintroduce the image title prefix (and make it only visible once one or more pictures are added for upload)

[eddiemuc]

Only a resorting option would be a nice add-on (like it is done for individual route) Mabe as long click action?

And I would reintroduce the image title prefix (and make it only visible once one or more pictures are added for upload)

That's a fair remark. This was mentioned in the thread and I overlooked it, sorry for that.
Looking into code I saw that individual route uses a different list control to achieve this instead of RecyclerView which is user for images. Googling tells me that RecyclerView also supports drag&drop though. So it is a bit of work to sort out easiest way to integrate and retest this. Either we leave this issue open (but rename it) or we create new issue. What do you think?

Note for self: https://medium.com/@ipaulpro/drag-and-swipe-with-recyclerview-6a6f0c422efd

[fm-sys]

Reopening it for easier tracking, as there is still something left (adding resorting option and reintroducing the image title prefix)

[eddiemuc]

Reopening it for easier tracking, as there is still something left (adding resorting option and reintroducing the image title prefix)

I am working on resorting and will do some refactoring while at it (aim is to use same image selection logic also for trackable logs, I remember that @Lineflyer pointed that out some time ago)

Regarding the image title prefix I am inconclusive whether cgeo community really wants this feature.

[fm-sys]

Regarding the image title prefix I am inconclusive whether cgeo community really wants this feature.

I personally would really love to see this feature. But maybe we can find a better name for it and only show this input field when it's useful (one ore more images with default name are attached to the log)

[eddiemuc]

Regarding the image title prefix I am inconclusive whether cgeo community really wants this feature.

I personally would really love to see this feature. But maybe we can find a better name for it and _only_ show this input field when it's useful (one ore more images with default name are attached to the log)

Adding it again is easy, also adding logic "show only if one or more image is selected" is easy. What would be a good alternative name for it though?

[Lineflyer]

Adding it again is easy, also adding logic "show only if one or more image is selected" is easy. What would be a good alternative name for it though?

I took a look at the new implementation and its really nice!!

Still, what would be the purpose of this "Image title prefix"? The user can click on the image and the full (old) dialog opens, where he can assign the title and subtitle if he wants to.
The only unlogical thing I see is, that the preset title "Bild 1" is not shown as title when opening the dialog. That would also solve the problem and make the usage obvious, wouldn't it?

[eddiemuc]

The only unlogical thing I see is, that the preset title "Bild 1" is not shown as title when opening the dialog. That would also solve the problem and make the usage obvious, wouldn't it?

Current implementation shows and uses the "Bild x" logic for all images where user does NOT enter a caption manually (i.e. where the caption is empty). The "Bild x" thingy is notassigned "fixed" too - if you delete an image of a list without captions assigned, you'll notice that "Bild x" changes to "Bild (x-1)" for all images under the deleted image. I figured, IF someone wants to set a manual caption he/she surely don't want to have "Bild x" as a starting point. So why put it in the caption field? It will only upset users who first have to delete it.

If you want to have same default naming logic as for waypoints here, I can change that too. Would that be the wish of the community?

[eddiemuc]

| | |

[eddiemuc]

Added PR #9205 which contains LOTS of refactoring behind-the-scenes as well as introducing drag/drop for log images (see screenshots in my last comment, https://github.com/cgeo/cgeo/issues/8978#issuecomment-711041267)

[fm-sys]

Looks good, only one little thing: I would make image title/properties in the listview vertically centered

[eddiemuc]

Looks good, only one little thing: I would make image title/properties in the listview vertically centered

The empty space you see there would be filled with the description if there would be any on the image. Here is a screenshot where one image has a (long) description and the other one has not:

[fm-sys]

The empty space you see there would be filled with the description if there would be any on the image.

But why set the height to a fixed value (android:lines="2")? If there is no description, it should be completely gone... As it's a bit off topic I can also prepare a PR myself, if you would appreciate it?

[eddiemuc]

The master for the height of an image row is the image which is always 100x100. I did not think it important that descriptions need to be put fully there. Same goes for image caption and image information btw.

But yes, it is valid to discuss whether image row height is adjusted to content. How is this handled in other lists (e.g. waypoints)?

[eddiemuc]

Btw it would be good to wait until my PR is merged until something is modified in that area. Refactoring was very heavy, lots of files and classes renamed and code moved, and work in current code state will most likely be hard/impossible to merge with this.

[eddiemuc]

@fm-sys it takes longer than expected for the PR to get merged. If you don't want to wait that long, and if you only want to change the layout of an image list item, I can offer you to include a new layout file in my PR if you provide it to me.

In current PR, the following layout file is used:
https://raw.githubusercontent.com/cgeo/cgeo/baad672efcd852e71eefa87993bc93d4ca4985ed/main/res/layout/imagelist_item.xml

[fm-sys]

I'm fine with waiting. This week I have quite a lot to do and therefore not much time for c:geo anyway...

[fm-sys]

While working on it, I noticed that the picture names aren't updated correctly:

I will try to fix this together with my changes...

[eddiemuc]

I think this is a result of me being lazy and putting both image size info and image name in the same two-lined text field, and when the first line is too long and breaks into the second line then the image name gets thrown out...
Sorry...

[fm-sys]

Oh, I even did not notice it. Thanks!

I think this is a result of me being lazy

For fixing this, I would leave out the force line break completely and use a "," instead as a file size number without the unit is not very meaningful anyway. So I'm even lazier than you ;-)

Actually I was talking about the image title numbers (1, 3, 4, 4) which are not updated correctly. But I just found the reason for it...

[fm-sys]

What do you think: Which one is the way to go? imo the second one looks way more clear...

[eddiemuc]

I would prefer too the second option, it seems kind of strange that list entries habe different heights in the first one.

[Lineflyer]

Option 2 :)

[fm-sys]

Done. PR is #9235