ransome1 / sleek

todo.txt manager for Linux, Windows and MacOS, free and open-source (FOSS)
https://github.com/ransome1/sleek/wiki
MIT License
1.34k stars 104 forks source link

Sleek is not able to read or write to Google Drive folder (on Linux, Fedora 36 Silverblue, Gnome 42) #444

Closed samjcarter closed 1 year ago

samjcarter commented 1 year ago

Description

When either creating a new todo.txt (to) or loading an existing todo.txt* (from) Gnome desktop's integrated Google Drive directories, Sleek is not able to complete the operation.

Creating a new todo.txt causes a crash/Sleek closes. Loading an existing file fails silently without an error message or console output.

As a result, with the above software, you can't use Sleek in combination with Google Drive's sync capability to edit a todo.txt from another device.

Reproduce

Setup

  1. Use the software versions listed above if possible. If not possible, a google account (I used a personal one) is still required.

  2. Using Gnome settings app, scroll to Online Accounts.

  3. Select Google and follow the setup instructions there. Make sure you leave permissions for "Files" enabled when setup asks.

  4. Install Sleek from the flatpak on flathub & run it.

Read Existing

  1. create a todo.txt at the new location mounted by the setup, e.g: google-drive://user@gmail.com/.../to-do/todo.txt. This is to test loading it into Sleek.

  2. Click the grey Open todo.txt button on the left with the folder icon.

  3. Click the blue Open todo.txt button.

  4. Browse to the location of the todo.txt you created in the google-drive://user@gmail.com/.../to-do/todo.txt mount and create the new file.

In the case of reading an existing todo.txt, Sleek fails to fails to read the file, and you can then close the open dialogue and continue using other files, but without the new one you wanted.

Create new

  1. Click the grey Open todo.txt button on the left with the folder icon.

  2. Click the blue Create todo.txt button.

  3. Browse to the location google-drive://user@gmail.com/MyDrive/todos/new_todo.txt mount and press Create todo.txt here.

In the case of attempting to create a new todo.txt that you have placed in Google Drive already, Sleek closes/crashes upon selecting the desired file. When you restart Sleek, the new file was not created.

Errors

The console reports the following when clicking on the Grey Open todo.txt button:

No console output is added when either selecting an existing file, or creating a new one.

(anonymous) @ matomo.js:53
files.mjs:299 Success: Created jail for modalChangeFile
navigation.mjs:59 Success: File changer modal built and opened
matomo.js:12 There was an error setting cookie `_pk_id.3.4209`. Please check domain and path.
ao @ matomo.js:12
dx @ matomo.js:33
aR @ matomo.js:42
cF @ matomo.js:46
dj @ matomo.js:51
cW @ matomo.js:53
(anonymous) @ matomo.js:53
matomo.js:12 There was an error setting cookie `_pk_ses.3.4209`. Please check domain and path.
ao @ matomo.js:12
dx @ matomo.js:33
cn @ matomo.js:42
cF @ matomo.js:46
dj @ matomo.js:51
cW @ matomo.js:53
(anonymous) @ matomo.js:53
files.mjs:299 Success: Created jail for modalChangeFile
navigation.mjs:59 Success: File changer modal built and opened

Expected behaviour

In each case I would expect the todo.txt to be loaded or created, as per the indicated button functions, and that the resulting todo.txt in Sleek would be editable, that any saved changes would upload to Google Drive.

System Information

Sleek flatpak 1.3.0, installed from Flathub via the "Gnome Software" app.
Fedora 36 (Silverblue) 36.20221120.0
Gnome 42.2
X11

Context

I'm using Sleek to manage tasks for (self-employed) visual effects work projects. I'd like access to the todo.txt on my iPhone.

The desire to use Google rather than Dropbox, iCloud, (...etc), is because the Google integration is available "out of the box" on the Gnome desktop environment, and also works on iOS/Android/Windows.

SyncThing is a no-go because it won't run on iOS. Dropbox, for example, isn't available by default on Linux and requires a not-so-nice-to-use tool to be installed. iCloud also won't work for obvious reasons.

My work platform needs to be Linux and Silverblue fits the requirements of my software tools well. Fedora workstation may also do what I need since the container tools I use on Silverblue can be installed. That's on the off-chance this is due to something Silverblue is doing that interferes with either Sleek or the Gnome Google Drive integration.

But changing OS isn't the preferred solution.

ransome1 commented 1 year ago

@samjcarter thanks for reporting this. Before I look into it, can you tell me, if the same thing happens, if you use the AppImage build of sleek, that can be downloaded here on GitHub?

ransome1 commented 1 year ago

SyncThing is a no-go because it won't run on iOS. Dropbox, for example, isn't available by default on Linux and requires a not-so-nice-to-use tool to be installed. iCloud also won't work for obvious reasons.

A side note: I use Syncthing on iOS as well. There's a paid app called Mobius Sync. It simply wraps a Syncthing instance into a native iOS wrapper and so far works pretty good. Unfortunately it is closed source, I don't really understand why there isn't a maintained FOSS alternative for iOS.

samjcarter commented 1 year ago

@samjcarter thanks for reporting this. Before I look into it, can you tell me, if the same thing happens, if you use the AppImage build of sleek, that can be downloaded here on GitHub?

I've downloaded the AppImage build from https://github.com/ransome1/sleek/releases/download/v1.3.0/sleek-1.3.0.AppImage and carried out the same steps as above. The AppImage does work as expected (with regard to the issue described above) for both cases; reading an existing to-do.txt & creating a new one.

AppImage Comment a) I'm not able to open Sleek's console with Ctrl + Shift + I. This works in the FlatPak version but not with the AppImage, so I can't double-check whether the same console output appears.

AppImage Comment b) In the case of opening an existing todo.txt, the file is no longer named todo.txt on the tab in Sleek. The name appears as an alphanumeric string. This could be something the Google Drive integration is doing.

AppImage Comment c) The AppImage build is quite slow to create new tasks (about a 4-second delay from creating to it appearing on the list). Again, this could be something the Google Drive integration is doing though. If I create a todo.txt in my $HOME then it's fast to add to-do items, like usual.

Please advise if you think it's worth creating issues about any of the comments a-c, or if it sounds more like the Google Drive integration is to blame. I assume the Google integration watches files, has locks on them until some check or change is performed over the WAN and probably also changes original file names for content addressing needs (or something).

Does the AppImage check narrow this issue down to something FlatPak related?

samjcarter commented 1 year ago

SyncThing is a no-go because it won't run on iOS. Dropbox, for example, isn't available by default on Linux and requires a not-so-nice-to-use tool to be installed. iCloud also won't work for obvious reasons.

A side note: I use Syncthing on iOS as well. There's a paid app called Mobius Sync. It simply wraps a Syncthing instance into a native iOS wrapper and so far works pretty good. Unfortunately it is closed source, I don't really understand why there isn't a maintained FOSS alternative for iOS.

@ransome1 Thanks for pointing out Mobius Sync. I might look into that as an alternative if it can integrate with 'vanilla' Syncthing.

ransome1 commented 1 year ago

Does the AppImage check narrow this issue down to something FlatPak related?

That is very likely. In Flatpak we need to declare permissions to access specific functions of an OS. Amoung others we need to declare what part of the filesystem sleek is permitted to access.

As you can see here, sleek only has access to your home folder and the mnt and media folders: https://github.com/ransome1/com.github.ransome1.sleek/blob/master/com.github.ransome1.sleek.yml#L17

I don't really understand how the google drive is mounted, but if you can make sure it is mounted into a folder, that is located in the usual locations (home folder, media or mnt), we might get this working. According to this, there is an application that mounts Google drive to specific folders: https://www.linuxuprising.com/2018/07/mounting-google-drive-on-xfce-or-mate.html (Section: Using Google Drive OCamlFUSE to mount Google Drive in Linux). Maybe it is worth trying.

ransome1 commented 1 year ago

AppImage Comment b) In the case of opening an existing todo.txt, the file is no longer named todo.txt on the tab in Sleek. The name appears as an alphanumeric string. This could be something the Google Drive integration is doing.

AppImage Comment c) The AppImage build is quite slow to create new tasks (about a 4-second delay from creating to it appearing on the list). Again, this could be something the Google Drive integration is doing though. If I create a todo.txt in my $HOME then it's fast to add to-do items, like usual.

Do those things also happen with files somewhere on your filesystem, like your desktop for instance?

samjcarter commented 1 year ago

AppImage Comment b) In the case of opening an existing todo.txt, the file is no longer named todo.txt on the tab in Sleek. The name appears as an alphanumeric string. This could be something the Google Drive integration is doing. AppImage Comment c) The AppImage build is quite slow to create new tasks (about a 4-second delay from creating to it appearing on the list). Again, this could be something the Google Drive integration is doing though. If I create a todo.txt in my $HOME then it's fast to add to-do items, like usual.

Do those things also happen with files somewhere on your filesystem, like your desktop for instance?

No they don't. It behaves as intended when reading/writing to files under my $HOME directory, including $HOME/Desktop. Those things must be due to the Google integration - possibly in combination with something that is different on Silverblue compared to "normal" Fedora Workstation. The directories and permissions aren't set up quite the same on Silverblue.

github-actions[bot] commented 1 year ago

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.