Settings page support email with the ability to email the dev of a certain effect, even if the effect came from a separate debian package

[beta382]

Since this is intended to be extensible, and since people wanting to extend this will probably do so by releasing a separate package containing their scripts, it would become a support nightmare when you start receiving email saying "Hey, this effect doesn't work right!", when that effect wasn't created by you.

You could include a "Report an Issue" button in the settings pane, that when pressed, gave the user an alert (or took them to another page) reading:

Hey, is your issue with Cylinder, or just one of the effects?

letting you choose between "Cylinder" or "An effect". If "An effect" is selected, the user is taken to a page displaying all of the effects, and when one is selected, they are taken to an email composition view, with the effect resolved to the email of the person who developed it. I know how to do this resolution using shell script, here is my code:

FILENAME='absolute_path_of_script_file'  // e.g. /Library/Cylinder/Beta382/Curl and Roll Away.lua
PACKAGE=$(dpkg -S "$FILENAME" | awk '{print gensub(/:$/, "", "g", $1)}')
if [[ "$PACKAGE" != "" ]]; then dpkg -s "$PACKAGE" | awk '{if ($1 == "Author:") {print gensub(/^.*<(.*)>.*$/, "\\1", "g", $0)}}'; fi

Running this on my device using the example filename yields:

[email protected]

All that needs to be done is for this command to be run from your end (Is it possible to run system commands using Obj-C? I honestly don't know, although I am certain that it is).

It handles cases where the script is not in a debian package (i.e. user-made, or taken from a reddit thread) by outputting absolutely nothing, which is rather easy to catch, just say "Sorry, I couldn't automatically determine the author of that effect, please contact the person you got it from". Special casing would need to be done for scripts included by default (get the emails of your contributors)

[rweichler]

GENIUS. Definitely implementing this.

And yeah, int system (const char *command) in stdlib.h does this

Actually FILE *popen(const char *command, "r") from stdlib.h would be better suited for this

[ridn]

Perhaps you could require that anyone who submits a package containing effects to include a file with contact information, the you just read from the file (most likely a property list), which could be stored in their particular folder.

[beta382]

(Kinda biased, cause it's my idea)

I think it would be easier to do it /automatically/ than to ask people who submit extensions to Cydia to include an extra file with their effects, because I'm pretty sure that repo maintainers would do a sub-par job of enforcing that. Unless you are talking about people who have their effects included by default, and would need special-casing.

[ridn]

I understand it'd be easier, I'm just concerned whether or not this would be considered good practice using system commands like this. (Not that I'm one who knows very much about good practice). As for the pre-included scripts it would probably make sense to do it that way because it would eliminate having to "hard-code" each address.

On Feb 23, 2014, at 5:07 PM, beta382 [email protected] wrote:

(Kinda biased, cause it's my idea)

I think it would be easier to do it /automatically/ than to ask people who submit extensions to Cydia to include an extra file with their effects, because I'm pretty sure that repo maintainers would do a sub-par job of enforcing that. Unless you are talking about people who have their effects included by default, and would need special-casing.

— Reply to this email directly or view it on GitHub.

[rweichler]

Not bad practice, and you don't have to hard code anything. When you submit a package to a main repo you have to provide an email address for support in the deb.

As for the pre-included scripts, I should be getting support emails for those anyway since I included them in Cylinder by default.

[ridn]

I was referring to the pre-included scripts for the "hard-coded" part. Because they're not from a package. Though since you say contact you anyway just ignore that.

On Feb 23, 2014, at 8:36 PM, Reed Weichler [email protected] wrote:

Not bad practice, and you don't have to hard code anything. When you submit a package to a main repo you have to provide an email address for support in the deb.

As for the pre-included scripts, I should be getting support emails for those anyway since I included them in Cylinder by default.

— Reply to this email directly or view it on GitHub.

[rweichler]

Oh, my bad

[rweichler]

I really need to implement this