| QUOTE (clyde) | ||
... but how would we know if you are the author of a macro or not?. That is, I don't think there is any setting in GSAK that categorically correlates to your gc.com name. You might use your gc.com number for matching but that is not your name, and not everyone uses the number anyway. I suppose if you are using then gc.com ID for matching we could do an api call to fetch the the name and then use that - is that what you were thinking? |
| QUOTE (Kai Team) |
| This also would be unreliable where the macro author doesn't use his or her exact geocaching name in Mac Author (e.g. if two people wrote the macro and both names are listed). Of course if you assumed no match unless there is an exact match, it would prevent overwriting a local copy that is more up to date (as would checking the version number during the update wink.gif). |
You both raise good points that I have to admit I didn't think about. I could see the following implementation as an approximation:
- either use the value of "exact match" or the owner id with the API call to retrieve the name (caveat: wildcard match and regex match won't support this feature)
- skip selection if the name retrieved in the step above exactly matches the value of MacAuthor (caveat: it would not pick up on "sbeelis, inspired by Kai Team")
When making the feature request, I realised this "exclusion" would not be of the same importance to everyone, it would be interesting mostly for macro authors with many macros to maintain, hence why I listed this part of the request as "bonus" at the end.
If you decide to implement the main feature request without supporting the "skipped selection" I could live with it. (After all: having a list to check only requires attention once; the current way where I have to keep checking for each macro increases the chance to a misclick). If you decide to include the "skipped selection" I think the method outlined above by me would probably be "good enough" despite the caveats to make life much easier for a lot of us macro authors.
If anyone comes up with a better way (with fewer caveats) I'm of course happy to listen to suggestions.
