license question

[IzzySoft]

Thanks for making your app available openly – code and APK! I've searched your repo, but could not find any license information – which means the permission you're granting to your code is "read only" and "all rights reserved". Would you mind specifying a license – ideally a F/LOSS one approved by OSI/FSF(see SPDX for a good selection)? Thanks in advance!

[dgudim]

Hello. Thanks for being interested in my project! You are the first guy to open an issue on my repo :) Yes, i forgot to add the license, it's now here. I have a question to you too: do you want to publish my app to IzzyOnDroid? Because i see your nickname is IzzySoft.

[IzzySoft]

You are the first guy to open an issue on my repo :)

Apologies for being late then, I didn't find it earlier :rofl:

it's now here

Thanks!

do you want to publish my app to IzzyOnDroid?

Aww… now I feel caught. Indeed that was my intention, and that's what I've just done seeing the license was there now – so your app will show up here in about an hour. Be welcome to pick a badge to link there e.g. from your Readme if you like :smiley:

PS: and should you wish to establish Fastlane structures in your repo to be in control how your app is presented, and would like the one I've set up in my repo for starters, I might be the first one opening a PR in your repo here and gladly provide it. Just say a word :wink:

PPS: Next station could possibly be F-Droid.org then?

[dgudim]

PPS: Next station could possibly be F-Droid.org then?

yup, was planning on doing that

However, the app is not yet production ready and the last version contains several nasty bugs, you caught me off guard. Well, how much you say i got, 1 hour? Bugfix speedrun lets gooo.

About that fastlane stuff, yea, sure, much appreciated.

[IzzySoft]

However, the app is not yet production ready and the last version contains several nasty bugs, you caught me off guard. Well, how much you say i got, 1 hour? Bugfix speedrun lets gooo.

Ouch, just missed it by 25 minutes: 8 pm CET (7 pm UTC) is the publication. Update run starts good an half hour before that, and usually finishes within 20 minutes. So update will become available with the next run tomorrow. Unless you say it's urgent enough to justify an "emergency run".

About that fastlane stuff, yea, sure, much appreciated.

On its way then, expect an incoming PR within the next 15 minutes.

[dgudim]

Nice, I'll merge it tomorrow (My timezone is +3 so it's midnight). Thanks again

[dgudim]

@IzzySoft If I want to add Russian localization to my fastlane, do I need to notify you? And also, is there a tool to generate changelog files on release creation?

[dgudim]

Are you kidding me XD

[IzzySoft]

If I want to add Russian localization to my fastlane, do I need to notify you?

No. Only for Klingon (as that would make me curious) :speak_no_evil: :rofl: Earnest: Other locales are picked up automatically. Not so other "elements", as I need to check what "kind" you use to set the proper optimization flags. E.g. do I need to convert images to JPG or are they better left PNG, should I take fulldesc as-is (because you use excellent HTML) or better run Markdown over them or even skip them as you use to totally mess up :speak_no_evil:, is there any feedback I should give for "wrong" formatting (like separating bullet-point lists by empty lines for proper Markdown or keeping shortdesc ≤ 80 char and changelogs ≤ 500 char) etc.

Sure I could simply take everthing as-is and ask why I should care. But self-answering that: UX (← buzzword), optimal presentation, saving bandwith, saving the world (:see_no_evil:). WWW == WinWinWin: best experience for users, best representation of your apps, best serving the environment :smiley:

And also, is there a tool to generate changelog files on release creation?

I've heard of "Github actions" generating such from commits etc (like this one or that, just use the search engine of your least mistrust to look for e.g. "github action changelog generation") – but that approach IMHO requires some precautions: not only keeping the result inside the 500 char limit, but also making sure to have good commit messages and not having (or instead excluding) "unimportant ones".

Are you kidding me XD

THAT wasn't me :zany_face: I never said you must use the fastlane binaries (in fact I've never used them myself), just the structures. But yeah, that's probably the most famous complaint I usually get :rofl: Remember that meme of "iPhone 20" when they released the 5? Same width as the 5, but the height of empire state building? From my side: it should be screenshots, and thus have the proper aspect ratio. How you define "proper" is relative – within boundaries. Should be a long way until the two of us would disagree (well, at 5.0 I'd definitely ask questions – but at 2.5 I'd raise an eye brow at most).

[IzzySoft]

is there any feedback I should give for "wrong" formatting

Ah. And there we go:

Do you **always forget things** to do or **have a lot of them** to remeber? <br>
Want to **easily keep track** of them? <br>
Then this app is for you, take **full advantage of your lockscreen real estate** and view your todo list right on it! <br>
**No need to unlock the phone**, it's all there! <br>

Seriously? Multiple points with that:

• you use explicit Markdown which is not handled directly with HTML (Do you **always forget things** to do). This works fine with my repo, but not elsewhere (all other places would take the asterisks literally). Same time you use HTML that has corresponding Markdown (<br>), indicating you want to use it elsewhere. That somehow contradicts, so I'm not sure if it was intended, so I thought to better drop a note to make sure.
• it looks like those were intended to be bullet-points. Or separate paragraphs. Or really one paragraph with multiple explicit line-breaks but no "spaces" between. Not sure what.
• the trailing <br> (at the last quoted line) does not make sense, it will lead to a "long gap". But maybe you wanted exactly that. Let's see what it would be turned into: <b>No need to unlock the phone</b>, it's all there! <br></p>\n<p><br><b>Features include:</b> (pointer what I mean: <br></p>\n<p><br> == 3 empty lines)

So what should it be? First, do you want to go "full Markdown" – or keep "best compatibility" with different sysstems? Currently, none of the two is accomplished. As pointed out in the PR, there's a small guide on my corresponding wiki page :wink: Once that's decided, consider the other two points. Let me know if I can help with that then. As it should format "OKish", I'll for now take it as "Markdown input" (pulled with your next release, so still room for adjustments if you want them).

Current settings here:

    Fastlane: https://github.com/dgudim/Scheduler/tree/master/fastlane/metadata/android
    FastlaneFeatures: title,shortdesc,fulldescMD,icon,screenshots

When you add changelogs, let me know to enable them here. That can be done for a single locale (in which case my updater would always only pick the matching one, e.g. for versionCode: 15 the 15.txt from en-US) or globally (all changelogs from all locales). Your say :wink:

[dgudim]

Thanks for the feedback, it's my first time creating something like that, so yeah, i am pretty crap at it. Will replace markdown with html. I am in the process of creating changelogs, should I also use html in them?

[IzzySoft]

Will replace markdown with html.

Which will cause issues elsewhere (e.g. F-Droid.org would replace each \n with <br>\n). May I again point to that wiki page, and the formatting recommended there ("Markdown Lite")? That has proven as the best "compromise".

I am in the process of creating changelogs, should I also use html in them?

I'd rather not. First you only have 500 chars altogether, so you better avoid any overhead. Second, same formatting issue with F-Droid. AFAIK they should be "plain text" – but "Markdown style" bullet-point-lists are fine.

Let me know if I shall cross-check once you're ready. Danger of more "moaning" ahead then maybe :see_no_evil:

[dgudim]

Is this fine for the description?

<i>Scheduler</i> is a small app that shows your todo list on your lockscreen.

<p>
Do you <b>always forget things</b> to do or <b>have a lot of them</b> to remeber? 
Want to <b>easily keep track</b> of them?
Then this app is for you, take <b>full advantage of your lockscreen real estate</b> and view your todo list right on it! 
<b>No need to unlock the phone</b>, it's all there! 
</p>

<b>Features include:</b>

- Your todo list on the lockscreen
- Sync with your system calendars (google, samsung, local)
- Configurable per-day wallpapers
- Material you theming support
- Plethora of settings
- Low memory and cpu consumption
- And more

And this for the changelog

<b>v0.5.0</b>

Many under the hood changes:
- Improved how calendar refreshing works, now supports per-day refresh
- Improved how entry parameters work, made the cached
- Fixed deleted events in a recurring sequence being duplicated instead of deleted
- Simplified permission request xml
- Added notification permission to the request screen for the future support of android 13
- Fixed `android.view.WindowLeaked` on dialogs
- Replaced list view with recycler view on the main screen

[dgudim]

I am confused with that markdown-html-plain text

[IzzySoft]

If you could first answer the central question: Shall it just be fine for my repo – or also render fine in other places like F-Droid.org (if you intend to apply there) and PlayStore? As soon as I know that, I can propose how it should look best.

Then, second: Shall the first paragraph have those "forced line breaks", or shall it just be a "fine paragraph with text flow"?

[dgudim]

I was planning to apply to main fdroid repo but almost everyone uses your repo, so I'll probably stick with just your for now. However, i want to publish it to playstore later.

Shall the first paragraph have those "forced line breaks"

Yes, looks nicer, still not great but nicer

[dgudim]

But if your repo supports html that doesn't mean that fdroid app does too, right?

[dgudim]

In neo store it looks like this, which is meh

[dgudim]

@IzzySoft So, the final thought: I want it to look nice on neo store/fdroid app and on PlayStore, that's it

Waiting for you to respond, then will update description and publish changelogs

[IzzySoft]

I was planning to apply to main fdroid repo but almost everyone uses your repo, so I'll probably stick with just your for now.

Hehe, OK, then we have full flexibility (as long as you don't plan for Play). Didn't know my repo already was that popular :star_struck:

But if your repo supports html that does't mean that froid app does too, right?

Oh, now we're mixing things. If you take a look inside the index files you'll find that all descriptions in there are formatted as HTML – so yes, the client supports only HTML one could say, or at least expects to find HTML for descriptions. The difference is in how the input is processed. In simple terms:

• F-Droid: Read file › sanitize › br2nl › save.
• My repo: if-then-else based on per-app config:
  • fulldescMD: read file › use Markdown converter to create HTML › sanitize › save.
  • fulldescNL: read file › sanitize › br2nl › save (like F-Droid does).
  • fulldesc: read file › sanitize › save (no conversion).

So once you change the input, I'd need to adjust the config – or it might look strange. No prob in processing HTML as Markdown, but all else doesn't look that nice in the end.

Screenshot

That seems to come from NeoStore, right? Strange. Let me check… Gosh, the official client too! WTF. I've always only checked the results on the website it seems. So how often is nl2br performed then? Guess that would look even worse if we had it in the F-Droid.org repo as HTML to begin with. At least it still has the bullet points there:

Here is what the `index-v1.json" (used by both clients, v2 is not yet implemented at least in the official one) has:

               "description" : "<p><i>Scheduler</i> is a small app that shows your todo list on your lockscreen.</p>\n<p><br><b>Features:</b></p><ul>\n<li>Your todo list on the lockscreen</li>\n<li>Sync with your system calendars (google, samsung, local)</li>\n<li>Configurable per-day wallpapers</li>\n<li>Material you theming support</li>\n<li>Plethora of settings</li>\n<li>Low memory and cpu consumption</li>\n</ul>\n",

And here what my updater created from the full_description.txt I've sent you in the PR:

<p><i>Scheduler</i> is a small app that shows your todo list on your lockscreen.</p>
<p><br><b>Features:</b></p><ul>
<li>Your todo list on the lockscreen</li>
<li>Sync with your system calendars (google, samsung, local)</li>
<li>Configurable per-day wallpapers</li>
<li>Material you theming support</li>
<li>Plethora of settings</li>
<li>Low memory and cpu consumption</li>
</ul>

To me that looks like both, the Android client AND the F-Droid.org website perform nl2br on what the index has. So I probably remembered wrongly where the conversion takes place. Just checked some examples from the F-Droid.org index: Yupp. Some apps have plain-ASCII in there. So it takes the full_description.txt into the index as-is and leaves interpretation to the client(s).

Well, what do we do now with that insight? Still best to use "Markdown lite" in the full_description.txt then ("inline" elements are fine, "block" elements should be avoided) – but I'd need to see if I should convert that on import, or on website output…

[IzzySoft]

PS: Ideally all clients would send it through a "Github flavored Markdown" renderer instead of applying nl2br…

[dgudim]

The difference is in how the input is processed.

Ohhhh, got you

Ok, that means this one is fine, right?

<i>Scheduler</i> is a small app that shows your todo list on your lockscreen.

<p>
Do you <b>always forget things</b> to do or <b>have a lot of them</b> to remeber? 
Want to <b>easily keep track</b> of them?
Then this app is for you, take <b>full advantage of your lockscreen real estate</b> and view your todo list right on it! 
<b>No need to unlock the phone</b>, it's all there! 
</p>

<b>Features include:</b>

- Your todo list on the lockscreen
- Sync with your system calendars (google, samsung, local)
- Configurable per-day wallpapers
- Material you theming support
- Plethora of settings
- Low memory and cpu consumption
- And more

And what about changelogs?

[IzzySoft]

Ok, that means this one is fine, right?

It seems for now it won't make a difference, as client-side formatting will make it look like in the screenshots anyway. I cannot change the way my repo handles preparation on such a short call, will need to consider it though. As pointed out, as long as each client runs the description through nl2br, all block-level formatting (like paragraphs and lists) will look ugly in them (with those extra line-breaks); I cannod do anything about that. This must be fixed in the clients. I'll then need to see which way processing can be adjusted at my end, but that will take a little.

And what about changelogs?

As said, they are supposed to be plain-text. I'd still leave bullet-point lists separated from surrounding paragraphs by an empty line (so in your example, add a line break before the list); IIRC even I process them only nl2br.

That said, nl2br alone will deform everything that needs proper text flow – like bullet-point list with longer items, paragraphs which are not single-line in their source, etc. Which is why I had set it up the way it is now – which turns out to only work nicely with my website presentation but not in other clients :sob:

[IzzySoft]

Maybe I could try to always convert fulldesc input to a single-line HTML string. Ugly to work on if one needs to fix things, but should look fine in the clients…

[dgudim]

Ok then, thanks for all the help so far, i updated fulldesc and added changelogs

[IzzySoft]

Just was pointed to the corresponding client-side rendering issue. 5 years, still open… And look what people are proposing from the start ("use Markdown rendering") :man_shrugging: Still reading that one to figure why it is not done that way.

Meanwhile I've just checked some options, and here's what I could do. Currently, everything fulldesc is converted to HTML on import. I will keep it that way, but additionally, I could remove all line-breaks – which should get us rid of the client-side issue we just discovered. Should I need to edit a file directly, I just figured I can simply convert back-and-forth using the html2markdown and markdown commands.

Let me give that a try. I've just done that with the description of Scheduler (after some minor adjustments: Markdown line-breaks are TWO empty spaces at the end of the line; feel free substituting with the <br> again if that's easier for you, result should be identical), built a new index (looks OK in the WebUI) and currently run fdroid deploy. Once that's done, please take a look with your favorite client and let me know if it looks fine to you; I'll do the same here. If we agree this is the way it looks best, I'll adjust the code accordingly (for fulldesc only) and pull your Fastlane afresh (currently, I've only hand-picked the fulldesc) to confirm the code adjust is working.

Deploy is through, please go ahead! Looks a bit better now I'd say, though still not as good as I hoped. For comparison, here's the screenshot from above next to the current one, both from the very same official F-Droid client:

Now it's your turn with NeoStore :smile:

PS: Only thing this might break: <pre><code>(multiple lines)</code></pre>. And yes, I have that in some of the descriptions. So I hesitate doing that automatically. But if you prefer that for your app: I'll not stop you setting up fulldesc as a single HTML line and then have me take it as-is – though I'd then need to verify my sanitizer keeps it that way.

[IzzySoft]

Does not seem to much difference in NeoStore, though:

(sorry, had to perform this one as well as I now need to trigger a manual update run which will overwrite the description again; testing with formatting I broke the run :scream: Will copy back afterwards)

[dgudim]

Looks good to me, but why is there no space here? Other then that, great

[IzzySoft]

but why is there no space here?

Human error I guess (I made it one-line-HTML while turning those intended line-breaks into <br> manually, I might have mis-stepped at that place). Well, kind of: of them?</br>Then this app :see_no_evil: Fixed now for the next run tomorrow (then also including the latest changelog, currently only picked from en-USmatching versionCode of the most recent release).

I still don't get why Neo removes the bullet points. But that's a different thing and needs to be addressed by them. Meanwhile, how do we want to handle this (until the client does)? I hesitate turning all fulldescs into single-line HTML, as it would break e.g. the mentioned code quotes. You're free to change it into a one-liner HTML in your Fastlane, though; should that not render properly, let me know to switch from fulldescMD to just fulldesc and take it as-is (i.e. only run sanitizing, as that cannot be switched off) for your app.

[dgudim]

Yeah, I would much prefer it to look nice in the store, having it as one line in the source is no problem, so I'll do that, can you open a pull with new one line description please? I don't want to do it myself if it's already done, I'll merge it tomorrow morning

[IzzySoft]

I'm a bit drowning at the moment, someone just assigned me some 50 or so issues (I must have missed that zero when saying "send it over" :see_no_evil:) So I hope a copy-paste here will do? Not sure for the outcome with Google, though, if its full HTML. So please tell me when you know :wink:

<p><i>Scheduler</i> is a small app that shows your todo list on your lockscreen.</p><p>Do you <b>always forget things</b> to do or <b>have a lot of them</b> to remeber?<br>Want to <b>easily keep track</b> of them?<br>Then this app is for you, take <b>full advantage of your lockscreen real estate</b> and view your todo list right on it!<br><b>No need to unlock the phone</b>, it's all there!</p><p><br><b>Features:</b></p><ul><li>Your todo list on the lockscreen</li><li>Sync with your system calendars (google, samsung, local)</li><li>Configurable per-day wallpapers</li><li>Material you theming support</li><li>Plethora of settings</li><li>Low memory and cpu consumption</li></ul>

[dgudim]

Everything is fine, I understand you, the fulldesc also seems fine

[IzzySoft]

Great! Btw, I just had a similar discussion with another dev. They came up with an unexpected trick – in case you want to adopt that. I first thought that should be the Polish description placed into the wrong directory (en-US/full_description.pl) until I realized it's a Perl script :see_no_evil: Guess I'll link to that from my Wiki page for now.

Oh: and yes, feel free to close this issue here then :smile:

[dgudim]

That's a nice solution, i am definitely using that.

[IzzySoft]

Seems to have a minor bug, though:

<p>Do you<b>always forget things</b>to do or<b>have a lot of them</b>to remeber?

Apart from "remember" (typo on your end), it eats too many spaces. Must be lines 16+17:

$text =~ s/> />/g;
$text =~ s/ </</g;

At least the latter removes all spaces preceding an <, and thus causes Do you <b>always to become Do you<b>always. Here's a fix, replace those 2 lines by these 3:

$text =~ s/\/(p|div)> /\/$1>/g;
$text =~ s/br> /br>/g;
$text =~ s/ <(p|br|div)/<$1/g;

You can of course add more block level elements to the first and last line (like blockquote,cite,dd.dl,dt,ol,ul,li), I've just picked the most common to keep it easier to read :wink:

Already reported at its source.

[dgudim]

Thanks, fixed both the typo and the bug

[IzzySoft]

You didn't include the other elements, though. And sure you re-created the *.txt after the fix was applied?

your lockscreen.</p><p> Do you

Should not be a problem, but that space after the opening <p> should have been eliminated by line 17 of the script – as should it's all there! </p><p> have the space before the closing tag removed by line 19.

Argh! My bad. OK, fixed version for lines 17-19:

$text =~ s/(p|div|ol|ul|li|blockquote|cite|dd|dl|dt)\>\s/$1>/gi;
$text =~ s/br> /br>/g;
$text =~ s/\s<\/(p|br|div|ol|ul|li|blockquote|cite|dd|dl|dt)/<\/$1/gi;

No need to re-run now, just please update for the next round :wink:

[dgudim]

Updated with the new fixes, should be fine now, thanks

[dgudim]

That's what i came up with for the release creation, pretty handy

cd ..

set -e
set -x

printf "\nBuilding debug apk\n"
./gradlew assembleDebug

printf "\nBuilding release apk\n"
./gradlew assembleRelease

VERSION_NAME=$(./gradlew -q getVersionName | tail -n 1)
VERSION_CODE=$(./gradlew -q getVersionCode | tail -n 1)

CHANGELOG=./fastlane/metadata/android/en-US/changelogs/$VERSION_CODE.txt

TAG=v"$VERSION_NAME"

echo "Built $VERSION_NAME ($VERSION_CODE)"

if test -f "$CHANGELOG"; then
    echo "$CHANGELOG exists, choose another version"
else
  touch "$CHANGELOG"
  echo "Fill the changelog and press enter"

  read -r

  git commit --all

  git tag "$TAG"
  git push --tags
  gh release create "$TAG" -F "$CHANGELOG" ./app/build/outputs/apk/*/*.apk

fi

[IzzySoft]

Not being a dev I do not completely understand it – but as long as it gains the required results it should be fine :smile: What always confuses me in such cases is evaluating and setting versionName/versionCode with the APKs already built. IMHO those should be set before building them so they match on all ends. But if they do match in your case, all left for me is :man_shrugging:

Should you one consider having your app at F-Droid.org, something like this won't work but will cause automatic updates to be disabled. F-Droid's CheckUpdates needs those values as literals.