Is this project alive?

[jdev082]

The last commit was 106 days ago, is this project alive? It's my favorite weather app and would hate to see it die.

[julianfairfax]

Good question. Obviously I have an incentive to push my own issue (#399), but with nothing being added/fixed/removed/changed at all, it does kind of seem like the project is a bit quiet.

[papjul]

If you look at the history of commits, it's not unusual. The main developer usually make a lot of commits on a short period and then goes inactive for a long period, and then comes back and repeat. An explanation to this situation could be that the developer is living in a country where Internet is censored and only has access to GitHub on rare occasions (this would explain the very big commits we see when he comes back).

[julianfairfax]

I suppose that's a reasonable explanation given the country he's in.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I hope the maintainer will give access to a frequent contributor to merge PRs. So he will not be the bottleneck anymore

[julianfairfax]

I'm starting to question this again. Previously the dev has come back after a less long absence. I obviously don't think I should dictate development, or that my #399 issue is more important than others, but if the dev is completely absent, I don't see how improvements or fixes, be that the one I'm requesting or others, can happen.

I hope the maintainer will give access to a frequent contributor to merge PRs. So he will not be the bottleneck anymore

Unless this happens, which it should.

[papjul]

I started implementing GitHub action to generate APK on pull requests so that you don't have to wait for it to be merged to test the new features/bug fixes, but unfortunately there seems to be some issues.

As for the pull requests, anyone is free to merge them in a fork, you don't need access to this repo.

[papjul]

I'm quoting a reply from another issue to emphasize on the inactivity of this project.

It seems that with the change requiring new OpenWeatherMap users to provide billing information to use the OneCall API, OpenWeatherMap may no longer be a good source for weather data going forward. Requiring billing information to utilize a FOSS tool (Geometric Weather) is just absurd and goes completely against user privacy.

399 proposes the use of the met.no API used by other FOSS projects like GNOME Weather and KDE Weather, which would solve this problem in its entirety. The only issue is that it needs to be implemented, tested, and then actually released. With that said, it's concerning that the repo owner @WangDaYeeeeee has been inactive since June 10th, and this problem has been going on since August. The discussion on whether the project is even still alive as per #419 further justifies that concern.

As a new user, I'm essentially completely unable to get weather information for most of the world due to the OpenWeatherMap API change, and I'm not willing to provide billing information just to get weather information on an app that's seemingly meant to be FOSS and privacy-friendly (hence the F-Droid version). If the repo owner was active, I may actually be motivated to implement the met.no API feature myself, but since I am not an Android developer, that would require a lot of dedication to learn enough to properly implement a new API. With no guarantee that this project will ever see another update again, I haven't felt any motivation to make that commitment.

I just wanted to bump this issue and include the potential fix to the OpenWeatherMap issue by adding the met.no API in case anyone here had more experience than myself and was willing to implement it themselves. If the maintainer comes back, I may choose to try it myself if no one has made any progress on it.

Your concerns are legit, there are indeed some major, if not critical, issues currently.

I contacted him by email and will let you know how he sees the future of this project.

If I don't have a reply or if he don't plan on being available in the coming weeks, I will make a branch on my fork where I will merge all current PRs, so if anybody wants to contribute, they will be able to do so on a clean copy, as to avoid too many conflicts.

Later, probably, in January, I may have more free time to fix some issues or give a hand to help implementing met.no. However, if possible, I would prefer that Wangdaye implement his "modularize the project" goal first, which, if I'm not mistaken, would allow to develop any source provider as an additional APK. Currently, weather providers are too much tight to the core, and there are a lot of files to edit to actually have a source provider working.

I'm not an Android developer, I do have Java and general programming knowledge, so if someone feels more comfortable in improving the project, feel free to let us know (tagging @rthery in case interested). Currently, my goal is only to merge PRs, fix major issues I can fix, and then merge everything back into the main project.

If someone is skilled in GitHub actions, I would also appreciate a fix to the current GitHub action (it fails currently) that would allow us to have debug APKs generated at each commit.

[julianfairfax]

I'm quoting a reply from another issue to emphasize on the inactivity of this project.

It seems that with the change requiring new OpenWeatherMap users to provide billing information to use the OneCall API, OpenWeatherMap may no longer be a good source for weather data going forward. Requiring billing information to utilize a FOSS tool (Geometric Weather) is just absurd and goes completely against user privacy.

399 proposes the use of the met.no API used by other FOSS projects like GNOME Weather and KDE Weather, which would solve this problem in its entirety. The only issue is that it needs to be implemented, tested, and then actually released. With that said, it's concerning that the repo owner @WangDaYeeeeee has been inactive since June 10th, and this problem has been going on since August. The discussion on whether the project is even still alive as per #419 further justifies that concern.

As a new user, I'm essentially completely unable to get weather information for most of the world due to the OpenWeatherMap API change, and I'm not willing to provide billing information just to get weather information on an app that's seemingly meant to be FOSS and privacy-friendly (hence the F-Droid version). If the repo owner was active, I may actually be motivated to implement the met.no API feature myself, but since I am not an Android developer, that would require a lot of dedication to learn enough to properly implement a new API. With no guarantee that this project will ever see another update again, I haven't felt any motivation to make that commitment. I just wanted to bump this issue and include the potential fix to the OpenWeatherMap issue by adding the met.no API in case anyone here had more experience than myself and was willing to implement it themselves. If the maintainer comes back, I may choose to try it myself if no one has made any progress on it.

Your concerns are legit, there are indeed some major, if not critical, issues currently.

I contacted him by email and will let you know how he sees the future of this project.

If I don't have a reply or if he don't plan on being available in the coming weeks, I will make a branch on my fork where I will merge all current PRs, so if anybody wants to contribute, they will be able to do so on a clean copy, as to avoid too many conflicts.

Later, probably, in January, I may have more free time to fix some issues or give a hand to help implementing met.no. However, if possible, I would prefer that Wangdaye implement his "modularize the project" goal first, which, if I'm not mistaken, would allow to develop any source provider as an additional APK. Currently, weather providers are too much tight to the core, and there are a lot of files to edit to actually have a source provider working.

I'm not an Android developer, I do have Java and general programming knowledge, so if someone feels more comfortable in improving the project, feel free to let us know (tagging @rthery in case interested). Currently, my goal is only to merge PRs, fix major issues I can fix, and then merge everything back into the main project.

If someone is skilled in GitHub actions, I would also appreciate a fix to the current GitHub action (it fails currently) that would allow us to have debug APKs generated at each commit.

I agree with this

[efb4f5ff-1298-471a-8973-3d47447115dc]

@papjul i could take a look at the workflow but i dont see any failures listed. Could u direct me to a failing workflow

[papjul]

@papjul i could take a look at the workflow but i dont see any failures listed. Could u direct me to a failing workflow

All actions fail to generate an artefact (APK). See the warning message: "No files were found with the provided path: app/build/outputs/apk/debug/app-debug.apk. No artifacts will be uploaded."

[rthery]

@papjul Unfortunately I'm not sure to have enough time to get really involved in the project :( But I hope to contribute additional PRs in the future though!

[efb4f5ff-1298-471a-8973-3d47447115dc]

@papjul i could take a look at the workflow but i dont see any failures listed. Could u direct me to a failing workflow

All actions fail to generate an artefact (APK). See the warning message: "No files were found with the provided path: app/build/outputs/apk/debug/app-debug.apk. No artifacts will be uploaded."

@papjul I think it throws this error because the path doesn't exist yet. This is what i could make out of it from a quick look at the workflow code and the file structure of the repo.

[dalaeance]

I contacted him by email and will let you know how he sees the future of this project.

Did you hear back, by chance?

[papjul]

Having no reply from him, I created pull request #440

As explained there, if you want to contribute to this project, I would recommand to make a pull request against my "new" branch to avoid any conflict with what was already previously developed. Your contribution will then appear in pull request #440, while preserving authorship of your commits.

Unless someone wants to step in, I will have a look at how to implement met.no (probably not until next year) so we can have a workaround to many issues discussed.

[dalaeance]

Thanks. I'm not sure how to contribute, as I have no coding skills.

I ended up here to ask the dev if there was a way for the app to report to the System the colours of its live wallpaper (which changes based on time of day and weather), so that Niagara Launcher could automatically adjust its colours accordingly.

But, of course, they've been silent for a while.

[papjul]

I ended up here to ask the dev if there was a way for the app to report to the System the colours of its live wallpaper (which changes based on time of day and weather), so that Niagara Launcher could automatically adjust its colours accordingly.

Please open a new issue.

[papjul]

MET Norway is implemented in #440, feel free to try the debug APK and give feedback ;)

Btw, Wangdaye has committed today on the iOS version of Geometric Weather, so we may see some updates here ;)

[jdev082]

Can you update the version number so that i can keep track of the version I have installed and install updates

[papjul]

I don't know how Wangdaye keep his version scheme, so I don't want to mess with it. You can't install this debug APK as an update, and you can't install it in parallel of the current release. Additionally, I think that GitHub sign with different keys each time, so you have to reinstall it anyway. Remember this is a debug version provided for convenience, but this is not a release ;)

[jdev082]

Maybe change the version to unofficial development or something

[CelianGdfrd]

@WangDaYeeeeee made commits to the iOS version a few days ago, maybe he'll look into things soon ?

[papjul]

He committed on the dev branch few days ago to fix Google Play issues, I rebased my pull request on top of it.

[papjul]

I forked the project, see #492 if still interested