AppFlowy-IO
[Bug] Incorrect application folder name
Describe the bug The application creates a directory in the user's "Document" directory called "flowy". As per application conventions the directory should be called "AppFlowy" (ideally), or "appflowy" if you don't want caps in a directory name.
To Reproduce Steps to reproduce the behavior:
- Install and run the application
- Look in your Documents directory
- Find the "flowy" folder
- See error
Expected behavior The folder should be called "AppFlowy" or "appflowy)
Screenshots
Desktop (please complete the following information):
- OS: Linux/All
- Browser N/A
- Version 0.0.2
Additional context The folder name is hard coded. Maybe this should be in the translation files?
Since the content of the folder is not really human readable, I think the path should be switched to ~/.local/share/appflowy as per XDG specification (https://wiki.archlinux.org/title/XDG_Base_Directory) (there is a link to the full spec on the wiki page). This would also help with Flatpak support in the future since you don't need to have permission to write to Documents this way. Applications shouldn't be writing their human-unreadable data to a visible folder, the directory layout is designed to you don't have to use your Documents folder for anything but actual Documents.
Thanks @Gaming4LifeDE for sharing the knowledge and suggesting a change. We'll evaluate it and consider your suggestions.
Hello :) Just to say that I don't agree with this, no data in the document folder is meant to be human readible (or maybe I don't understand what you mean by "human readable"). It's application data. It's your saved files. Those files could be in binary...
The stuff that we put in the flowy folder is user data, and the user has to know about this so that they can back it up.
I'm not saying that we are doing it perfectly. But I am saying that the user needs to be aware of this data.
I think that for now it's fine to leave it in the documents directory (and rename it to "appflowy"). However, in the future I think that the user should be given full control over where the data is stored. There would probably still need to be a global config file (in .config or somewhere that's appropriate) that has a hardcoded path so that it can know where the user chose to store the data.
Edit: For Windows the global config file could go somewhere in AppData maybe?
@Poly-Pixel Yes, you're right. We will support users to choose their stored path in the future. So I think just leave it there for the moment.
