Almost that, @kozec. They would be placeholders for files, not for folders. I could write a detailed list of everything, step by step, if it make easier to understand me. Please, forgive me, if I’m being too confuse.
About the utility of what I’m suggesting: I believe we need a way to see which files are available in a folder and to download just the ones we need and when we need them.
We could have the Selective Synchronization folder feature, like dropbox has, but it is useful just if you know the folder. You can’t search on DropBox desktop app for not synchronized files or folders. You can’t navigate easily on it. You can’t have a good panorama of the folder content on it.
I understand that you have to believe in a feature before implement and release it. Nobody wants to be stuck with an annoying legacy feature. As a designer and front-end developer, I have my own regrets. I know this pain.
If I don’t believe in this feature as useful to more people than just me, I would never even post it here.
[quote=“robsonsobral, post:21, topic:1779”]
Almost that, @kozec. They would be placeholders for files, not for folders.
[/quote]Well, that would make synced folder look really messy, but it’s no problem from implementation view. You’ll have many files looking exactly same (using same icon), what’s problem, imho. How bt-sync does this?
They’re keeping both extensions, super_cool_music.mp3.st, which solves another problem too.
I’ve been searching for how Microsoft did it on OneDrive and found that their are removing this feature. They say it’s because the users have no clue about which files are real and which ones are placeholders.
But a lot of users want this feature and need it for reasons like I said. They are asking for different icons for the placeholders.
I think that to keep both extensions is enough for the problem.
While you think about it, I gonna talk to more people and see what they think.
The ones who are more “advanced” computer users, but not yet developers, found the idea amazing and loved it; while the others, that users who use computers in a most basic way, found it strange and want to see it to understand better.
It’s any scientific data, but… It looks like the idea isn’t all bad.
I guess they just registered “.mp4.bts” and “.jpg.bts” as a file extension, in our case it could be “.mp4.syncthing” but I don’t think there should be any icons because the file needs to be downloaded first and cannot be opened, so icons are IMHO confusing. Or they wrote a system plugin that overlays the icons (like Dropbox which uses small icons to indicate sync status)
[quote=“AudriusButkevicius, post:32, topic:1779, full:true”]
To be honest, I couldn’t care less about the icons.
[/quote]I do, having everything looking the same is very bad from UI perspective
That’s why I thought only about folder placeholders originally. That would require registering only one filetype with one icon.
Hacking into file-manager and providing own method for icon handling may be hardest task of entire feature, especially on Linux (and BSD?), where type of file is not always determined by extension.
I think the icons are important, specially because the first intention on this is to make a current feature easier to use, but I don’t know if it’s indispensable at the very first moment. I don’t know Syncthing user base. If the feature see the day light, the icons can be improved on a second moment. We can find edge situations to deal with. There’s always some detail I forget about.
On Mac the file type isn’t determined by an extension too.
I searched on how to do this on Windows and it looks like something uncommon, but not complex. I even inspected on regedit. Is only one file type to register.
I designed some software icons years ago, but they were web based only. Icon design isn’t on my expertise, but I can do some research and try to design some icon overlays. Something to show that the file is a placeholder or it’s being downloaded.
Yesterday I’ve used this feature on Sync and found another reason on why its useful.
I needed to download just the most recent file. I ordered the files by modification date and double clicked the last one. I used the file, deleted it and a placeholder took its place almost instantly.
The placeholder approach certainly is novel and has some advantages, but it’s also some disadvantages. Adding and removing placeholder files that literally do nothing except download the linked file adds a whole bunch of complication to the app itself, but can also be confusing for other apps that are monitoring the share with placeholder links.
For example, say I’m sharing my iTunes library, and I delete a file from within the iTunes app and tell it to move the file to the Trash. This doesn’t actually delete the file from other nodes as expected, it only deletes it from the current node and replaces it with a placeholder that iTunes doesn’t care about.
I would much rather see the interface for .stignore improved. It provides a much less complicated and easier to understand feature (for anyone who has used Dropbox or any other sync tool). I think the Dropbox interface for selecting files and folders to be ignores is great. It’s super simple and easy to understand. It shouldn’t be too difficult to add a GUI or web UI for this.
Just traverse the tree and anything that is not ignored in .stignore is checked. Anything you uncheck in the UI gets added to .stignore. Newly added files are synced by default. Simple.
If you wanted to get tricky, you could invert the behaviour so “*” is at the top of .stignore. When you traverse the tree, anything that is not added (with “!” prefix) is unchecked. Anything you check in the UI gets added to .stignore (with “!” prefix). Simple.
I’m not saying don’t ever implement placeholders. I’m sure they are cool and useful in some cases. But an easier interface to .stignore should be much higher on the list of priorities. It should be much easier to implement, is much easier to understand, and the concept is much more familiar to people.
I talked to some people. Less techy they’re, less they like the DropBox style. They found strange to navigate on a file tree in interface just to download the file and then navigate again on files explorer to open them. I didn’t performed a well scientific research, though. It was just informal talk to half dozen people.
To delete the file, as it is a destructive action, I suggest an function on a context menu.
Buuuuuuut maybe this more traditional way you prefer could have a little tweak: to allow the user to open the file right from the interface, instead of just download it. Something like:
[ ] filename (open local file)
[ ] filename (open local file)
[ ] filename (download and open)
Not actual text suggestion. It’s just to show the basic idea.
I still prefer the placeholders, but I think the point of this forum is to find a good solution together.
This is a great idea, but this is WAY far ahead of where the project is at the moment. This is not worth your effort yet… Why? Well, the #1 reason is such a feature has GOT to be cross platform… And that means built into the protocol – so it works in Java, GTK, Web, whatever.
(The ONLY way I see to do it now is if you piggyback on the BEPv1 protocol using the read-only file permissions flag). And that’s not a good way, heh.
Right now the protocol doesn’t support your idea, although I like your idea. I am in favor of writing a BEPv2 protocol … I’d even do the work for it… Anyway all that aside…
To do that in GTK, it means we’d need to put it in a hacky revision of the BEPv1 protocol, which will contain the data necessary for on-demand drive mounting (ie. like Bitcasa). and sharing of preferences among clients.
i’m on board, but not until the basics are worked out…Namely, protocol redesign. But I think #1 priority is take stock and fix existing critical bugs and UI issues. Then redesign later.
As @AudriusButkevicius pointed, there’s no need to change the protocol. This isn’t a new feature, but a different way to interact with the current available selective sync and to solve one of its main issues: currently you can’t to know the content of the folder to choose what to download before download it.
It isn’t the only way, but it was proved a good one, by SkyDrive implementation, and we have the chance to avoid Microsoft mistakes.
