Closed ransome1 closed 11 months ago
Hey @thejevans. I converted the discussion into an issue, so that it pops up on the project's board.
This functionality should now be available in the latest developer preview: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev8
There is now a setting, which allows you to feed any file type into sleek. Feel free to give it a try and let me know if it works.
@ransome1 It works great!
I tested 2.0.0-dev8.deb on ubuntu 23.04 with kernel 6.3.7 and it doesn't work. When I toggle on the setting I can't open any file even .txt. In default file selector I can't see any files, only directories. The file selector window still asks for "text files". If you want some specific debugging info ask away. Should I open a new bug report?
edit: rant: yarn is not TS package manager on linux it is own tool that does it's own legacy things. please note this in readme section of building from source
I didn't check it on Linux, only on MacOS. @thejevans since it is working for you; On what OS are you on?
This is quick and dirty fix. I think there shouldn't be a variable that enables the unsafe behavior. But that comes from a perspective as a linux user.
Thanks @ludrol. What is it that makes it unsafe either generally or on a Linux system?
The other issue is that .todotxt
is an edge case. There might be not another user besides @thejevans who will ever use it. I'm not happy with adding it to the code. What if somebody else needs for example .todo
as an extension?
As the allowed file extensions are a comma separated list, we could also put this list to the config file as a setting: allowedFileExtensions: ['txt']
. If somebody really needs some other extension than .txt
, he or she could just edit the config file.
Thoughts?
Unsafe
Not unsafe but enables stupid behaviour for the user. For example enables to open binary files where binary files shouldn't be opened. I trust user more and they should be to blame for their stupidity, but that's my opinion.
.todotxt
File extensions are arbitrary. Anyone can put anything at the end of the file. There isn't a file extensions registration office. And we are pretty sure that .todotxt file has the same syntax as todo.txt, plus enables us to mark files that are used with this specific syntax easly.
If user wants a todo for Bob and makes bob.txt how do we know what user put inside? If we make new extension bob.todotxt then a) files can be renamed easly b) text editors won't want to open that file but they can.
I think we should look on how .csv files are handled they are "plain text" and shouldn't be handled with a text editor.
config file
Putting arbibitrary values in one place is good coding practice.
I think there should ba a dialogue box (alredy implementd by OS) to choose what file types are allowed.
I have implemented this behaviour in the fix. When you enable all file extensions in the popup there is filetype chooser where you can choose witch filetype you are selecting. (Text files or All files)
I propose we
.txt
:)allowedFileExtensions: ['txt']
(@thejevans you would need to do this manually like this allowedFileExtensions: ['txt, todotxt']
...)allowedFileExtensions
. (@thejevans ... until this is deployed)Would that be a proper solution?
I think there should ba a dialogue box (alredy implementd by OS) to choose what file types are allowed.
I don't know what exactly you're referring to here.
Let's look for example at paint on windows (screenshot in polish locale)
We have list of file extensions (.png, .bmp and others) we have "all image extensions" and "all files"
That is objectively good design. We let the user choose what they want to open.
- remove the "All files" option
I disagree. Users need an option to open all files.
- we remove the setting which allows all file extensions
I agree
- and 4.
This should be in one place. In the openFile() code is good. UI element would be nice but development time would be wisely spent elsewhere.
In my opinion todo.txt
has bad file naming scheme. It is better to stick witch classic file extensions than invent new ways to name files in confusing ways. example.todotxt
clearly marks the file type that I can rename it to whatever I want.
I don't know your development philosophy and I can't make a compelling argument that will sway your decision. I stand with libre mindset for opensource software. User should be free to use software as they please. And that means allowing users to open any any file type.
I don't know your development philosophy and I can't make a compelling argument that will sway your decision.
Rather than a strict development philosophy I have a design philosophy in mind, which is keeping it simple for the user.
If I as a user now see .todotxt
popping up in that list, I will ask myself Is this is a relevant file type? Is this maybe sleeks own file type? Should I use it?
and Why does it not seem to be a text file?
Because in your current proposal you're separating between Text Files (.txt .md)
and todotxt Files (.todotxt)
. What makes .txt
and .md
text files but .todotxt
not?
The other issue is that .todotxt is an edge case. There might be not another user besides @thejevans who will ever use it. I'm not happy with adding it to the code. What if somebody else needs for example .todo as an extension?
Or .mdTasks
or .simpleTodos
or whatever will come up in the context of some other application. Do you really want to add all these extensions in the code? I don't.
After reading through this thread again, wouldn't it be the most feasible solution to simply have it separated between Text files
(only .txt) and All files
?
98,53% of our users will use the default Text files
anyways, is what my gut tells me. And the others can switch to All files
and select whatever binary they want to inject into sleek ;) This would make it light on the interface and in the code too. With minimal adjustments, your PR almost covers it.
Sorry for the delay, I was away from my desk for a few days.
I didn't check it on Linux, only on MacOS. @thejevans since it is working for you; On what OS are you on?
I was on my Windows 11 machine at the time. I didn't test on my other machines because my hardlink workaround still worked. I just tested the AppImage on NixOS with KDE Plasma, and I get the same behavior that @ludrol mentioned.
@ransome1 I think the solution you mention in your last comment is a good way to implement this, assuming it works for all OSs. File extensions are generally a decent heuristic for file behavior, but they are still just a heuristic. Having a way to work around them is a solid thing to have.
I have access to PCs running Windows 11 and various linux distributions, and I'm happy to test future fixes.
Discussed in https://github.com/ransome1/sleek/discussions/512