@khadanja from your forum account, I was able to trace it down and for some reason our state showed 2 installed apps. This sometimes happens, since we don't closely track our users.
I have reset the state now, so can you try again?
@zylstra You have to SSH into the server and run those commands. You don't need to replace the "password", the root password of the database is actually just password (this is fine since it's not exposed externally and only available on localhost).
@nebulon The problem is fixed now. I was just not able to go in the AppStore view. It only showed the loading circle. And on settings, it told me to add a new cloudron.io account. The Cloudron was running for 1 month and all setup completed.
@robi Installing apps from the store en masse can't be common. I think rn it's flow is best for an average user, but it could be a little more mobile app store like with an "installing" progress bar while you discover other apps, and then it pops up with "installed, click to open" or something via Notifications. I could see it, but again - installing apps isn't common enough I don't think to worry about this since installing is a one-time task.
But I'm glad you brought it up because it would add a bit of polish to have a more "app store" feel to it. Still allowing app discovery while an app's installing. I think Cloudron should be able to do that one day even if it doesn't feel like a priority rn.
@d19dotca I guess that depends exactly on what you want to use the cloudron cli for. A workflow could look like the following:
change/update version of a package in the app
commit the change to git (you could edit and commit directly in e.g. gitea or gitlab)
this automatically triggers the ci platform
this one could do some verification
create the updated docker image
deploy it to your cloudron
The simples form of this could be a post-commit hook in your git hosting tool.
Yes as @girish mentioned, that dialog itself could probably use some rework. I will see what can be improved for 6.0 then, the main appstore view was more important from our perspective to make things more discoverable. So I agree the actual install dialog is logical next. That "install" button being pushed out of the screen on small displays is a longstanding issue as well.
When it comes to an "open source" filter, I think the open code based makes more sense, rather than looking at all add-ons or price. We are talking about filters on Cloudron App Store, therefore think the question is, "is the app actually installed from cloudron app store opened of closed?", not any add-ons people may choose to install later on.
Other options could be to have:
a Free Software filter for program without any proprietary add-ons
a "close sourced" filter for apps where the code of the base app is not available (i.e. that app actually installed from the app store)
a $ filter for program that require a paid license
Mainly I think we should NOT conflate price/money and license type / openness of source case. Take Teamspeak, for e.g., it can be used for free, on a free (as in free beer) license, yet it is proprietary software.
I think that whatever filter option we choose, the openness of the code that is actually being installed from the Cloudron App Store (i.e. without add-ons) is the thing that users should be made aware of / able to easily choose from. So as a first implementation of any filter, I thing the open/closed source filter would be the priority.