Cgeo: Ability to share a direct link to a given geocache log

Created on 29 Aug 2020  路  54Comments  路  Source: cgeo/cgeo

Is your feature request related to a problem?
Currently, when you long press on a geocache log, the top bar changes with three options displayed: a clipboard, a share icon and a three dot icon that, when tapped, shows a menu with an option to translate the log to your native language. When you select the clipboard icon, the content of the log is copied to the clipboard and, similarly, when you select the sharing icon, it is the content of the log that you can send to another application.

Describe the solution you'd like
Of course it is useful to be able to copy the content of a log. But it would also be great to be able to copy/share the direct link to a given log. For example, for GC7, there's the oldest (in GC database at least) log ever, https://coord.info/GL1. This function would also be practical till #2012 is implemented, as a nice workaround to edit one's own logs in a browser.

Describe alternatives you've considered
None

Additional context
I only use geocaching.com, but it is possible to link to a given log on opencaching.de (example), though I don't know if it's reflected in the API results.

For geocaching.com, here is some JS that emulates how it could be done (equivalent is possible with jsoup)

document.querySelectorAll(".log-row").forEach(function(log){
    console.log(log.querySelector(".AlignRight a"))
})
Feature Request

Most helpful comment

Why do we need to display the log id at all (in the dialog)? It's just an internal id and of no direct use to the enduser. IMHO Log of <username> would be sufficient.

All 54 comments

I don't know how these GL... codes are generated and whether we can either parse or even generate them (if they follow a certain formula). But the feature request itself I think is reasonable and a nice addon for those needing it.

It doesn't matter to me if we get a link in the form of https://coord.info/GL1 or https://www.geocaching.com/seek/log.aspx?LUID=a34f628d-fcd1-4923-9e20-0d34457b3cb7. Having the coord.info link sure would be nice to have but as a next step maybe (I would have sworn I saw the formula to convert these LUID to their original values years ago), but it looks like LUID (Log UID?) may be just a UUID (see this forum post), hence, random. cgeo would need to download and parse the log page to get the coord.info code, expensive just to have a more beautiful link.

This would be a valid and already useful first step to #2012 (as already said). I am in full agreement with @Lomanic s last post. I would use LUIDs for now since loading log pages just for nice links seems too much overhead ( takes long loading time).

As already partly discussed in #2012 I would also use this to replace the long/short press logic with a simpler logic: short press opens context menu with all options for a log available (including convert using ROI13 as currently done on short press). If that's all right?

Update: I played around with some samples of GL-codes. I seems the algorithm to convert LogIds to "Log-codes" is exactly the same as for converting GC-Ids in GC-codes (except that a GL is prefixed instead of GC). With this knowledge I would rather construct coord.links instead of using the LUID.

Is there already a conversion routine somewhere in c:geo for GcIds <-> GcCodes? Otherwise I will add it.

Is there already a conversion routine somewhere in c:geo for GcIds <-> GcCodes? Otherwise I will add it.

gccodeToGCId() in connector/gc/GCConstants.java looks like that.

gccodeToGCId() in connector/gc/GCConstants.java looks like that.

Thanks, that's the place. Unfortunatley I need the reverse thing ("gcid to gccode" resp "logid to logcode"), but I will add it here.

I only have accounts on geocaching.com and opencaching.de myself. I hope all other opencaching websites are handling API the same way as the german one via OkapiClient.
Does anyone know whether it is possible to directly link to cache logs on geocaching.su and extremcaching.com? (and can provide some sample links)
And are there any other supported geocaching-platforms which I might have missed?

You mean link to logs not to caches, do you?

Because link to caches should IMHO already be supported for all platforms.

@eddiemuc
For geocaching.su you might ask @okainov, don't know for extremcaching.com

You mean link to logs not to caches, do you?

Yes I mean links to logs. Sorry, that was a typo. I will correct it

For geocaching.su, from what I see from the page (thanks to this handy bookmarklet), here is a link to a log https://geocaching.su/?pn=101&cid=24636#p504980. But if we want to see an older log on a cache visited more than thrice, this link https://geocaching.su/?pn=101&cid=17885#p477362 that points to the (currently) 3rd most recent log (by player STORMAN) is hidden by default and the anchor doesn't work. To point to the same log, an alternative is https://geocaching.su/?pn=101&cid=17885#paneIcon477362 (same id), but while the browser scrolls to the right place, the log is still hidden behind a + button.

Also, the logbook RSS feed doesn't directly link to a specific log for each entry, which hints me that it's not possible to link to a specific log on this platform.

For geocaching.su, from what I see from the page (thanks to this handy bookmarklet), here is a link to a log https://geocaching.su/?pn=101&cid=24636#p504980. But if we want to see an older log on a cache visited more than thrice, this link https://geocaching.su/?pn=101&cid=17885#p477362 that points to the (currently) 3rd most recent log (by player STORMAN) is hidden by default and the anchor doesn't work

@Lomanic I think just noone before has used this functionality before =) And this link looks&feels quite correct, so I might make a fix in the code to check whether anchor is present and expand the corresponding log plus maybe add some kind of highlight for the referred note. So I'd propose you proceed with taking this type of links and I'll modify the website code soon to make it really working (maybe tonight or in couple of days)

@okainov thanks for the info, I will use the link format above. Are you a developer for geocaching.su?

Are you a developer for geocaching.su?

@eddiemuc correct =)

his link https://geocaching.su/?pn=101&cid=17885#p477362 that points to the (currently) 3rd most recent log (by player STORMAN) is hidden by default and the anchor doesn't work.

Implemented, should work now, feel free to check. Also now the icon near the log is a link to this log.

(if it doesn't work - flush JS cache)

You're definitely faster than me. I might need a while for my part...

@okainov my c:geo has problems logging into geocaching.su. So I have another question for you: when I download logs, in which field would I find the log-id (so I can use it later to create an url to it)?

Does anyone know of an Opencaching.de cache where it is fine for me to send some test logs? (to see whether I get the expected log-id back)

You can use my cache Ocfb5c - Come in and fly out

@okainov my c:geo has problems logging into geocaching.su. So I have another question for you: when I download logs, in which field would I find the log-id (so I can use it later to create an url to it)?

What kind of problems? After you register it should work smoothly :)

As per our doc, https://geocaching.su/api/documentation.html, it should be as id item inside logs dict. It seems like I don't set it in c:geo though... https://github.com/cgeo/cgeo/blob/master/main/src/cgeo/geocaching/connector/su/SuParser.java#L262

Here is some example of json response, feel free to modify logic and add corresponding test :) https://github.com/cgeo/cgeo/blob/master/tests/src-android/cgeo/geocaching/connector/su/SuParserTest.java#L59

Ocfb5c

Thanks, I just used it for a test (log is already deleted again) and may use it again

@okainov regarding my login problem: I created an account at geocaching.su with my nickname eddiemuc, I got a password via email and I can log in via webpage.

However, when I try to authorize via c:geo I immediately get an error message (can't even type in my username or password). c:geo log says:

2020-09-23 18:35:53.069 21798-21883/cgeo.geocaching I/cgeo.geocachin: Explicit concurrent copying GC freed 6623(533KB) AllocSpace objects, 0(0B) LOS objects, 47% free, 6681KB/12MB, paused 905us total 55.118ms
2020-09-23 18:35:53.185 21798-21883/cgeo.geocaching D/LeakCanary: Rescheduling check for retained objects in 2000ms because found only 3 retained objects (< 5 while app visible)
2020-09-23 18:35:53.261 21798-21943/cgeo.geocaching D/EGL_emulation: eglMakeCurrent: 0x7334524f1a00: ver 3 0 (tinfo 0x73349c9a5320)
2020-09-23 18:35:53.526 21798-21943/cgeo.geocaching I/chatty: uid=10134(cgeo.geocaching) RenderThread identical 30 lines
2020-09-23 18:35:53.532 21798-21943/cgeo.geocaching D/EGL_emulation: eglMakeCurrent: 0x7334524f1a00: ver 3 0 (tinfo 0x73349c9a5320)
2020-09-23 18:35:53.717 21798-22682/cgeo.geocaching D/cgeo: [OkHttp] 401 [] (794 ms) GET https://geocaching.su/api/oauth/request_token.php?oauth_callback=callback%3A%2F%2Fwww.cgeo.org%2Fgeocachingsu%2F&oauth_consumer_key=&oauth_nonce=2fb3b0e769d9b5332a4a6aff43ba055e&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1600878952&oauth_version=1.0&oauth_signature=d8hcJLw7Dnh1AtmQoqKCd%2BT8qL8%3D (h2) {Network$LoggingInterceptor.intercept:368/RealInterceptorChain.proceed:109/Network$HeadersInterceptor.intercept:346/RealInterceptorChain.proceed:109/RealCall.getResponseWithInterceptorChain$okhttp:201/RealCall$AsyncCall.run:517/ThreadPoolExecutor.runWorker:1167/ThreadPoolExecutor$Worker.run:641/Thread.run:919}
2020-09-23 18:35:53.725 21798-21943/cgeo.geocaching D/EGL_emulation: eglMakeCurrent: 0x7334524f1a00: ver 3 0 (tinfo 0x73349c9a5320)
2020-09-23 18:35:53.734 30087-854/? E/InputDispatcher: Window handle Window{3820564 u0 cgeo.geocaching/cgeo.geocaching.connector.su.SuAuthorizationActivity} has no registered input channel
2020-09-23 18:35:53.737 21798-21798/cgeo.geocaching V/cgeo: [main] [cgeo.geocaching.connector.su.SuAuthorizationActivity].showToast(c:geo failed to initialize authorization process.){1} {ActivityMixin.showCgeoToast:89/ActivityMixin.lambda$postShowToast$0:97/-$$Lambda$ActivityMixin$yJpeeGV9DJnO56wwb2wbuXHdTAM.run:6/Activity.runOnUiThread:6904/ActivityMixin.postShowToast:97/ActivityMixin.showToast:116/AbstractActivity.showToast:77/OAuthAuthorizationActivity$RequestTokenHandler.handleMessage:100/Handler.dispatchMessage:107/Looper.loop:214}
2020-09-23 18:35:53.749 21798-21943/cgeo.geocaching D/EGL_emulation: eglMakeCurrent: 0x7334524f1a00: ver 3 0 (tinfo 0x73349c9a5320)

Don't know what s the problem

That's suspicious... I have nightly from 14th of June and it's fine. As I'm in the fields now, I don't want to try the latest nightly yet... Can it be that it was broken recently somehow? Can someone else try clicking "authorize cgeo" for gc.su in the latest versions?...

And does OC authorization work for you? It should be very similar - open webpage with login form and then return back to cgeo..

Just authenticated normally to gc.su with current nightly build.

On the dev device (where i was not logged in to geocaching .su: "c:geo failed to initialize authorization process".

For OC.de the website call for the authorization was fine.

edit: with dev version from yesterday master branch.

image

@okainov same error situation for me as for @bekuno : same error message, and oc works fine. I am solely using the emulator, I dont know if that's part of the problem

I would call it "decrypt / encrypt" instead of "Toggle ROT13". That's also the way how ceocaching.com calls it and is way more clear for from-time-to-time-cachers...

I would call it "decrypt / encrypt" instead of "Toggle ROT13". That's also the way how ceocaching.com calls it and is way more clear for from-time-to-time-cachers...

Ok, I will change it

I am solely using the emulator, I dont know if that's part of the problem.

No key for gc.su in your build environment?

I am solely using the emulator, I dont know if that's part of the problem.

No key for gc.su in your build environment?

Yes! I forgot.
@okainov Is the key from https://github.com/cgeo/cgeo/issues/5269#issuecomment-262447699 further usable?
If yes - @Lineflyer - can you resent it to the team?

I am solely using the emulator, I dont know if that's part of the problem.

No key for gc.su in your build environment?

Yes! I forgot.
@okainov Is the key from #5269 (comment) further usable?
If yes - @Lineflyer - can you resent it to the team?

Ok, same here of course, no key in build env...

If yes - @Lineflyer - can you resent it to the team?

Sent

@okainov Is the key from #5269 (comment) further usable?

Yeah, it should be the same :)

If yes - @Lineflyer - can you resent it to the team?

Sent

@Lineflyer did you send it only to bekuno or the whole team. Because I did not receive it and I would need that key too...

@Lineflyer did you send it only to bekuno or the whole team. Because I did not receive it and I would need that key too...

Seems you are not yet part of the mailing list (@SammysHP : Can you add him). I forwarded manually.

@Lineflyer did you send it only to bekuno or the whole team. Because I did not receive it and I would need that key too...

Seems you are not yet part of the mailing list (@SammysHP : Can you add him). I forwarded manually.

Received the key, thanks a lot. @SammysHP would be really nice to be on that list :-)

With right keys, it works like a charm :-). Implementation works now for gc.com, oc.x and gc.su.

@okainov do you have any gc.su-cache where I can issue a test log (so I can check whether my implementation also works with the ids immediately returned)?

@eddiemuc feel free to try on my cache i.e. https://geocaching.su/?pn=101&cid=24387

Works! Thanks a lot for support.
I have to do some code cleanup (among other things renaming db field provider_id to service_log_id), will make a PR soon hopefully.

PR #9065 was issued

As this was also discussed in the PR:
I would not show the log ID in the logbook itself. Most of the time this info is not needed and clutters the UI.
As title for the context menu however its OK, but at this point I would recommend something like "Log entry GL12345 of " as title of the menu.

@Lineflyer Don't remember such a discussion (I remember a discussion regarding an "editable" flag on another PR, not about the log id), but since I already got a second comment with same opinion by @okainov I will remove it.

I don't understand the second recommendation though. "Log entry GL12345 of " seems like a strange title :-) Is there a typo?
Edit: when showing title of contet menu, the log id is not always available. Thus algo must also work when there is no log id

I don't understand the second recommendation though. "Log entry GL12345 of "

ups...comment was truncated.
"Log entry GL12345 of username"

I don't understand the second recommendation though. "Log entry GL12345 of "

ups...comment was truncated.
"Log entry GL12345 of username"

ah, got it now and will change it. But be aware, if log id is not available it will then just be "Log of username"

Why do we need to display the log id at all (in the dialog)? It's just an internal id and of no direct use to the enduser. IMHO Log of <username> would be sufficient.

@Lomanic raised the very good question in the related PR #9065 why to introduce a separate context menu anyway for the log entry options (thus introducing the "problem" to display some sort of "title" for such a dialog :-)) He argues correctly that such a dialog hides in most cases most part of the log entry where it is aimed at and thus the context of the menu is missing (-> hence the need to provide some context via a dialog title)

Most important: I am definitely NOT a GUI design guy! So please forgive me if my initial GUI designs are not up to modern UX standards. Let me tell you why I chose such a context menu in the first place:

  • The existing log list screen (before my change) is not in a very good state UX-wise imho:

    • a short click on log text decrypts/encrypts the log text

    • a long click on log text opens a screen-wide drop-down menu with three entries, two present as icons on my screen ("share" and "copy" symbol) and one in dropdownlist ("translate"). It took me quite a while to find out what this means. Also, it is marked in no way on the screen which log item I clicked before, so context is lost

    • a short click on the AUTHOR of a log opens a context menu (a separate one, not the screen-wide three-dot-one) with several options with regards to the authot

    • a short click on a picture opens this picture on another tab (without any menu inbetween)

I really couldn't idetify an overall UX concept behind all this, and thus I decided to make things maybe a bit more common by converting the long-term-click-logentry-options-in-screen-wide-drop-menu thingy into a short-term-context-menu like it is today also with the author -> so UX gets a little more common. Also, I noticed that Geooh GO is doing it this way.
I added the icons to the context menu because this part, inho, was nice about the screen-wide dropdown menu.

Well, this is how it ended up for now. I am more than willing to change this to another UX concept, but it would be really nice if it is then applied to all elements of the dialog. Meaning e.g.:

  • If log options shall be displayed only on long-click in screen-dropdown-menu, then imho the same should be the case for author
  • What should then happen on short-click? NOthing? Or would we select some "special action" which is so vitally important and obvious that it should be applied there? Should this action really be "encode/decode"? Which action should that be for author?

One personal remark: I don't like long-clicking actions at all, it would feel better to me if we can omit them totally. But that might be just a personal preference

Why do we need to display the log id at all (in the dialog)? It's just an internal id and of no direct use to the enduser. IMHO Log of <username> would be sufficient.

It gets complicated for me now. How can we come to a project-wide decision on this?

PR is now changed according to state of discussion until around 26.9. 22:20:

  • LogId is removed from log list
  • Context Menu is opened on short-click in separate window
  • added translation options (totally forgot those...)
  • Title is now "Log (logId) of (user)", logId is omitted if not present.
  • Took over text change suggestion and new icon suggestion from pull request comments

@moving-bits one reason for displaying logid might be that this is the only visible indicator to a user why he/she has "share link" and "open in browser" entries or not. He/she has those exactly when c:geo knows this logid. For caches stored before new c:geo version is installed and not refreshed afterwards, the logs of these caches stay that way, so maybe logid is helpful here.

View with logids present:
image

View without logids present (because cache was not refreshed yet) vs. view in today's view (master) after long-click:
| image | image |

And for sake of completeness, new view for author click context menu vs. same view in current master
| image | image |

Please continue discussion, I value every input

@Lomanic I forgot to ask yesterday: what is the source of the icon you provided me? Do we need to add it in the copyright notice list?

Two updates:

  • I re-edited newly added icons because I noticed they were too "big" (without border) compared to existing icons. I also adjusted icon creation description in wiki: https://github.com/cgeo/cgeo/wiki/How-to-create-custom-icons
  • I put the context dialog title into a parameterized strings.xml named cache_log_menu_title

    • the string is fed four string parameters: logid, author, log date in this order

    • current value of cache_log_menu_title is Log %s of %s leading to "Log (logId) of (author)

    • If one wants to change this, e.g. to "Log by (author) as of (logdate)", one can easily change this value e.g. to Log by %2$s as of %3$s

This should solve the title discussion imho. Unfortunately for the discussion "context menu vs screen menu" it is not possible to provide such an easy configurable solution

@Lomanic I forgot to ask yesterday: what is the source of the icon you provided me? Do we need to add it in the copyright notice list?

@eddiemuc Please don't use that, I just grabbed two icons from the noun project and smashed them together with some MS Paint-like online image editor, it's not even the same as the original one (without the link icon) in cgeo and it needs attribution for the original authors. It was just a suggestion.

@lomanic good thing you told me that. I just removed your icon and pushed again.

From my side the PR can be merged and this issue can be closed, except when there are more comments from the community.

As to limit the scope of this already big PR, I think it's good to go. Maybe create another issue to add missing icons on both menus you showed here https://github.com/cgeo/cgeo/issues/8897#issuecomment-699183020 or better add them in before merge.

I'm not a huge fan of the popup UX-wise for the reasons I stated in https://github.com/cgeo/cgeo/pull/9065#issuecomment-699127230, but at least it did let you put some icons that greatly improve readability (long menus with only text labels is an issue, see https://github.com/cgeo/cgeo/issues/8888#issue-686541300). Maybe there should be another issue regarding the cache logs view UX, while it's not exactly the same use-case, the OSS Octodroid app UX is a whole lot better with its discussion view (similar to cache logs). There, each comment has its own tree-dot menu and a long press lets one select text.

Keep in mind I'm only judging from your screenshots as I can't reinstall cgeo for the moment.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rsudev picture rsudev  路  52Comments

SammysHP picture SammysHP  路  49Comments

mirabilos picture mirabilos  路  41Comments

fm-sys picture fm-sys  路  41Comments

Lineflyer picture Lineflyer  路  46Comments