What do you mean? It is a file manager.
You use it to manage, explore, order your files. It could replace Explorer on Windows, Finder on MacOS or your file manager of choice on Linux.
Apparently they also have some special use cases in mind (if you read the roadmap) like multimedia conversion using ffmpeg woth the ability to offload the processing onto multiple computers.
> What do you mean? It is a file manager. You use it to manage, explore, order your files. It could replace Explorer on Windows, Finder on MacOS or your file manager of choice on Linux.
It's not. Read their description more carefully: it's a Dropbox with slightly extended functionality.
Dropbox is a storage with sync-client, not a file manager (even though it does have a filemanager-view). This app is working on top of storage-services, but it seems not to be like them.
Essentially it's an aggregator of file metadata from multiple sources. Accessing the local database can be a lot faster than accessing the data where it actually lives. It also allows for offline access if the device containing the files is temporarily removed. (Well, by access I mean previews and metadata.)
For example, I have a gigabit LAN with a Synology NAS, a server with a bunch of hard drives, and various networked machines. Gigabit LAN is pretty slow. Getting image previews of RAW photos on the NAS is insanely slow and frustrating. With something like SpaceDrive, you have basically instantaneous access to those previews, metadata, and Everything-like (the Windows application) search capabilities.
I'm really excited about it! I have files strewn about in so many places. Having access to them from a central location, with a single interface, not relying on a slow network, is really great. I might even go crazy and start to organize things with tags.
I remember looking at it a good long time ago. They didn’t have release packages for me to play with so I told myself that I’d check it out later when they are ready. It looks like they released an alpha version an hour ago - hence this is on HN again.
It is a welcome concept. We have blurred the lines between strictly local files and all the cloud storage options these days. I personally maintain those boundaries and almost never mount cloud storage on my Mac, but my wife(as an academic) deals with Dropbox,iCloud drive, Google Drive and whatever Microsoft calls theirs, because the people she works with shares files through them and collaborate with reviews and such. If a solution like this can mask the vendor specific connection hiccups and quirks and provide a transparent file system that appears local but may be backed by $x cloud storage, that would be a nice boost to her workflow.
The key is the usability of such a tool. If the latencies are so high that it feels slower than Finder, then its chances are slim.
Decided to try it out. After the installation, it asks to "create the library", share the analytics and log in - not exactly what I expected compared to other file explorers. Next, I decided to navigate to a random directory on one of my drives. After double clicking, nothing happened. Opening a dir with a context menu action did nothing too. Turns out 15k files in a directory make it effectively non-navigable. Total Commander and Window Explorer have no such issues. Spacedrive still has to iron out the basic file explorer features, it seems.
You can use one of the React-Virtualized components without the slightest idea how it works. TableView from SwiftUI is the same thing - a component that implements virtualization on top of the base GUI library for you.
React is not a UI framework, it's a low level reactive library with very limited scope - even the DOM bindings are shipped separately, and it can be used for much more than just GUI, for example VR experiences or cloud infrastructure deployment. Bring your own batteries.
The issue with the “bring your own widgets” approach in my experience is that it’s unusual for third party widget packages to have anywhere near the sort of depth and breadth of capabilities compared to the same widgets that come OOTB with native UI toolkits. This means “shopping” for the widget with the best tradeoffs for one’s particular use case and making up for whatever inadequacies it comes with yourself (or just living with the inadequacies, resulting in a crappier app), which is annoying at best.
It’s so much nicer to just be able to trust that an extensive library of stock widgets will be able to do whatever it is that you need, as tends to be the case with AppKit/UIKit.
That'd be something provided by the Web platform (through the DOM bindings), not React. React provides a way to work with the DOM elements/native components/etc in a reactive way.
The real problem is that the Web platform doesn't offer a good set of customizable UI elements other than the most barebone basics.
When you're building a cross-platform app OSX isn't the weakest link. It's older versions of Windows and Linux.
And UI libraries like Tailwind, Shoelace etc are surprisingly extensive and constantly being improved. And if something isn't to your liking it's often to trivial to change it.
Seems like a very nice app that works on multiple platforms, and it's even gifted to the community as open source. I don't know where you found the audacity to call something waste of time, but please keep it to yourself.
It uses Tauri which is the Rust equivalent of Electron.
I'm building an app using it now and it's significantly better than past attempts at browser-based, cross platform app development. It is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
And one of the big advantages for me is that I get to leverage Rust's excellent low-level capabilities e.g. cross platform SIMD support, io_uring with minimal investment.
> t is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
It uses system-provided WebView (WebKit on MacOS and Linux, and Edge on Windows) to display the UI shell, so the UI portion will be just as slow as any Electron app.
Sure but most of the issues with Electron apps aren't to do with the web layer.
It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc. And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Rust and Tauri fixes all of those. It's not perfect but for a cross-platform app development library I've not seen anything better. Happy to be enlightened with alternatives.
> It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc.
You've just described almost any web-based UI ;)
> And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Most of the slow interactions come from the web-based UI. I mean, Slack needs 17% CPU to draw an animated emoji. And it's already running in a hyper optimised Chrome: https://twitter.com/dmitriid/status/1486364312910368769
It could target Win32, GTK and Qt all at compile time (even Android and OS X but that never got developed all that far AFAIK), depending what runs on your target platform, while you get common components and RAD at design time. I haven't seen anything like it since and sadly the language and ecosystem are mostly dead, which is a shame, because the idea was brilliant and it actually worked (and is still used in some software, like CudaText and PeaZip I think).
I tried to build something much simpler than this.
For integration with cloud services you're going to run into OAuth, and guess what, that dance happens in a browser: get access to cloud drive -> get sent to provider login <<web>> page (or authorization page) -> get sent somewhere else.
I mean, you can build it without the browser, but a key and very early step involves a browser, you need it anyway. Might as well ship your own if you can do it.
I presume that by TableView you mean List { } component. Sadly, there is no component for large horizontal lists in SwiftUI and no, ScrollView with LazyHStack is not an answer due to memory issues.
Hey thanks for trying Spacedrive! The bug you're experiencing is known when browsing before adding a "Location". We index Locations ahead of time to generate a cache that makes browsing super fast, Spacedrive is, contrary to some replies here, designed for big data, we cache and virtualize everything.
Next update we'll fix the bug browsing non-locations, as those who open the app tend to try browsing first, before adding as a location it seems. It's alpha software so I hope you give us time to iron it all out!
Honestly, you can't call yourself a "file explorer" if you fail the basic task of exploring files without an additional step of "adding a location" (wat?)
Also, judging from the GitHub description, it's not a file explorer. It's a slightly extended Dropbox:
--- start quote ---
From cloud services to offline hard drives, Spacedrive combines the storage capacity and processing power of your devices into one personal distributed cloud, that is both secure and intuitive to use.
We're early alpha, our product is free and open source
At the end of the day, it is an amazing experience simply just to search and organize files from not just devices, but disconnected drives. Search is lightning fast, the UI is clean and you own all the data, given its local first and peer-to-peer.
Hate it if you must, but we're super passionate about it and are ruthlessly working to reach full stability across all platforms.
You are definitely suffering from miscommunication here. Calling it a file explorer is a bit misleading. I think what your project aims to be is really cool and very useful, but a file explorer is a secondary trait to what it actually is.
Firstly, I'm not really an expert on marketing, so take what I say as mere opinion not fact.
I think that you should be pitching it a little differently: many people are confused about what your soundbite is actually saying (I also thought it was a file explorer, like all other file explorers I have even used).
Maybe lean hard into a phrase like "Unified file browser; see all files on all your devices, all at once, all the time".[1]
The other thing I would emphasise is that this isn't syncthing. You don't have to mention syncthing by name, but you could emphasise that "Your files aren't synced between devices, they're visible to all your devices".
Too many people who would otherwise use this would dismiss it with "I'm already using syncthing"! AIUI, you aren't syncing files between devices, only syncing file-listings.[2]
PS. For my own use, unfortunately, I don't need something like this. Sorry.
While it would be a nice to have in theory, it just doesn't solve any pain-points I am currently experiencing.
For example, any important document I need to read on different devices is already either in my email, or on google drive. I view movies on Netflix+AMZ+Disney+, I only ever share photos with others, not with other devices that belong to me. It's rare that I look at a file stored locally on my phone and say "I need to see this on my PC", or vice versa. It just never happens.
[1] That came out sounding super-weird: I did warn you that I wasn't any good at marketing :-)
[2] I expect you provide value on top of that, like transparently copy-n-paste between two different devices, even from a third device.
You know, I had quite a bashful [though in a good spirit] comment on your work before, but, thankfully, HN throttled me.
But thanks to your reply here now I not only can't endorse you, but I have an evidence what you really make some extremely opinionated thing and everybody else is wrong.
I can't wish you luck and I don't see myself as someone who would wait for news for this project.
Why are people pricks like this? Actually building a product and getting early feedback is literally the play book YC live and die by.
Here you are in the church of pg giving shit to people following the scriptures of pg.
Creators - ignore shit like this. Keep iterating. I like your idea, your execution will get better and better. Well done both on releasing stuff and going open source!
The explanations tell's me it's loading and interacting with remote file systems, not hosting them on their own. Which makes it different from dropbox&co., and a file explorer.
There has to be a better strategy than caching and virtualizing to not tip over with large files. Why not just do whatever is your system's equivalent of a SQL LIMIT query? I can't think of a good reason as to why you need to index everything when the view is limited to maybe 100 files tops.
Windows Explorer does struggle with many files in a directory on a HDD. It doesn't cache the sort order, so opening it with anything other than alphabetical order means waiting 5+ minutes for it to sort them.
That is because the OS developer wants to push their product, not because it is something users want.
A third party cannot decide to provide something users do not want. Maybe they can get it preinstalled on Windows PCs or ANdroid phones. I cannot see MS (Or Google) being very happy with that.
Since always. Technically, any file explorer is accessing distributed storage. First the multiple storage-devices in your local system, later the different storage in your local network, which then grew to support remote servers like FTP, Webdav, etc. And modern file managers have for some years now also support for cloud-storage like OneDrive or Dropbox. Nothing new here, except being an app build from the ground up for supporting this specific targets.
> First the multiple storage-devices in your local system, later the different storage in your local network, which then grew to support remote servers like FTP, Webdav, etc.
These are not distributed file systems.
> And modern file managers have for some years now also support for cloud-storage like OneDrive or Dropbox.
OneDrive and Dropbox are not tied to any file manager.
I recently discovered Double Commander (I Managed to overlook it for years). Once i started using it I couldn't go back to Total Command or Free Commander.
It was kind of inevitable that after VC-funded terminals, mail clients, launchers sooner or later there would be file explorer.
As someone on Linux (popOS), I also gladly welcome it, as even the best file explorer I know (nemo) could use niceties that you find on Windows or macOS.
I'm highly skeptical of the economics of it though. The only way I would see it working out, if their planned "sync" product would be able to overcome the entrenchment of iCloud/OneDrive/Dropbox, which seems like a tall order. As a user I'd pay ~$50/year, but that would take a lot of customers to sustain even the current team size.
"It was kind of inevitable that after VC-funded terminals, mail clients, launchers sooner or later there would be file explorer."
Well, Nautilus [1] (nw "Gnome Files" apparently) was created for Gnome quite a long time ago now. The company was Eazel and included some ex-Apple luminaries. So money spent on file managing is nothing new.
OK, that explains why I have so many problems with the Nautilus UI! I switched to Thunar but it's missing some nice-to-haves. I'll have to check Nemo.
Regarding Spacedrive... Seems a solid idea but I think their UI goals (looks fancy) might not be aligned with my preferences (minimal, fast, high functionality, no jank).
The cloud storage is the part I'm not interested in. I already use Syncthing, and it fills that need really well (tough with a UX so meh that I'd be hesitant to hand it to non-developers). I'm interested in e.g. tagging of files and a good GUI, and Syncthing doesn't really do any of that (unless I've missed something).
What I would love to see is a UI on top of Syncthing that would allow for remote management so that it would be easier to add and remove folders without having to visit the remote devices physically.
I suppose I really should just get on and do something myself. :-(
I think for there are two already okay options. As Syncthings UI is already in the browser, one would be to just host that page in a way that it's remotely accessible (e.g. in you VPN, where I can highly recommend Tailscale). The other would be to use the option that Syncthing has built in to auto-accept folder invites from certain devices (that's what I have set up on my always-on server so I don't have to SSH into it every time).
I do miss the preview sidebar (bigger than thumbnail, renders and paginates PDFs even) and spacebar to pop a lightweight Preview.app modal window from when I used macOS.
What do you mean? Commercial file mangers exist for decades now. They are a bit out of style with everything being open source, but the old guard is still around on Windows & MacOS, and new fledglings appear on mobile regularly.
That was my reaction too, but FUSE is Linux only while this is cross-platform.
I am not convinced file managers need to be cross platform. There are plenty that will run on any desktop, IMO mobile platforms need different functionality and a very UI.
The real product as described on their website (not the github repo the linked) is that it is a drop box like sync service integrated into a file manager. I think most non-geeks will find it confusing compared to something that integrates with the familiar OS default file manager.
Yeah, FUSE is Linux only. But for completeness, for macs there is macFUSE, and for Windows there is winfsp. Both of these have fewer filesystems than FUSE, and I've used neither so I don't know how well they work.
If they think they can make a better file manager, great, go ahead. But including transports in the file manager means that remote data only looks integrated, it isn't actually available to local apps.
Or (just as bad) they'll decide they need a copy-to-local and copy-back-to-network mechanism, which will work for some files opened by some apps but not all. Arghh.
Nemo (under Linux) does that for some protocols (eg. Android media transfer), and it is very annoying, especially as there are already FUSE drivers for (at least some) such protocols. In practice it means that the only thing you can do using Nemo is copy/move files around.
That's a very good point, I didn't even think about the aspect that FUSE is available system-wide, for all other applications to use transparently. That makes Spacedrive seem to come up really short, in comparison.
Why is this written in React? I understand Rust doesn't have any GUI frameworks (like Qt), but is this the way, then? Is it an adversity to learning something new?
You can reasonably write a C++ app or with Qt and write your GUI stuff in QML, and even plug in Lua, Python, or JavaScript as a scripting language. Yes, thats work.
Using a browser to render is just an easier version of using a GPU API like OpenGL to build your GUI. Your OS comes with gui stuff, use it.
Other than that, cool enough, though something like pcmanfm support adding remote locations as well...?
> I understand Rust doesn't have any GUI frameworks (like Qt), but is this the way, then?
Yes. If you want to build a cross-platform desktop app with Rust, Tauri + React would also be me recommendation right now.
Tauri makes it quite easy to drop down to Rust if you need to (for high-performance operations and everything interfacing with the OS), and it also comes with pre-built packaging for the main different platforms. With React you are able to leverage a great ecosystem that has existing UI components for many things (unlike most native Rust GUI frameworks). It also allows you to reuse you frontend engineers and all their expertise when it comes to web technologies (and working with designers).
True, but it's still less indirection than compiling to web and then embedding a browser, which is how the linked frameworks seem to approach the situation.
The old age problem of having an open project where people don't understand what an alpha is.
You give this out to the world for feedback and people moan its not working.
I am old geek and back in the day you knew an Alpha was just for the playground to kick around - most likely will crash, worse case will destroy you PC but you have a play / provide some feedback and wait for the next release.
A lot of other projects do everything in the dark and do a big ta da at the end - and missed the opportunity for the community of "alpha" or "beta" testers to provide some feedback along the way.
Keep going - its added to my list to take look once in beta as I prefer to play in that playground rather than the alpha one these days.
It's the old-age disconnect between the marketing, the claims and the actual functionality.
For example, the title claims that it's a file explorer. However, someone in the comments shows that it fails at actually exploring files. Something which even an alpha project would not fail to do considering the claim.
Only when you read through the marketing copy and the comments, you realise that it's a hybrid cloud/local/cross-device Dropbox that creates a view of your files across systems/locations, and only once it's done that, only then can it do the actual file exploring. At least for now.
The title doesn't claim it IS a file explorer, it is an alpha version of something that aims to become a file explorer (for some definition of "explorer"). That's exactly the point of the OP?
> UPDATE: Spacedrive is under active development, we are in the pre-alpha stage, with builds occasionally released via GitHub actions, official alpha coming soon.
I think expectations broke as companies shifted from a focus on polished shrinkwrap to a ubiquitous race to market with continuous deployment.
For them, “alpha” and “beta” became ways to say “fresh out of the oven” and high profile revenue-generating products were proudly emblazoned with those words for years.
At this point, it doesn’t even mean anything. Half the internet is running on some 0.11.45-alpha of something or other, maintained by corporate engineering teams whose total compensation is in the millions.
It makes it legitimately hard for people to know what to expect and what standard to hold things to.
Time to wrap around and have -omegas. When that standard becomes the norm we can keep going backwards until -alpha, at which point we can use --omega and so on.
Ok, I don't know if I'm doing it correctly, but there is no way to type some letters to jump to the folder starting with that name right? Also, no Cut/Copy/Paste/Delete yet I guess. Also, the one reason I run away from Finder on macOS is that it has no way to set 'Enter' to open or 'Delete' to delete files, and refuses to simply add a 'Cut' and paste option for files and folders (I know how to 'Move' after 'copying', but that's not the point, the point is that it's just stupid). Please make sure you don't do those mistakes. Keep whatever defaults you want, but at least have an option to enable 'Cut', 'Open', and 'Delete' with their expected buttons.
A cross platform file explorer that has a nice UI and plugins is awesome. Many people have more 2 devices runing with different OS. But still, Web techs maybe not a good fit for system tools, for its heavy stack.
I like the idea. The vision is similar to Window's Explorer: seamless integration between offline files and online resources like Google Drive, Dropbox, OneDrive, Webdav, Samba, etc; fast, cached thumbnails; an indexer for fast search; encryption, backup etc. Of course in Windows Explorer all those features suck to varying degrees, some so hard they might as well not exist. So seeing an alternative implementation is nice, especially if it tries to take all these concepts even further. Most other file explorers stop far short of that vision.
I've been keeping tabs on this for quite a while. Some feedback:
- Indexing one of my localdev directories has taken a robust 35+ minutes so far, and I will likely not wait until the end of it
- Like others have commented, latency is an issue (macOS M1 14inch base model). I've added a location and even there it sometimes takes 2-4 seconds after opening a folder to see any files
- Am I missing something or are there no tabs yet?
- Extremely lean (too much) in the ways of file sorting and grouping (non-existent), although I wager this will be worked upon during development
- It does feel like I have to do a lot of work to get to sensible indexing (add lots of locations by hand, and so forth)
- I know it's local first, but the way telemetry and login work really does not sit right with me.
Overall I'm almost sure it's not a fit for me, as interacting with it was a bit disappointing, but I can see an audience and there's still ways to go. It looks really good. Best of luck!
File explorers really should be one of the simplest tools available in a given desktop environment. Really, there are many tools getting the Electron treatment which should be vastly simpler than this insane upward ratchet of complexity JavaScript dominance has introduced into the equation.
Super nice someone working through this, as it's the perfect target for Tauri, the motivation inside the GitHub makes it an exciting project that goes beyond just a regular file browser.
Since it has some glorified web app functionality, a non-tauri web demo with a remote `core` daemon would be super nice.
> Using a "Virtual Distributed Filesystem" (VDFS), in other words; a decentralized database that emulates a filesystem. It indexes hardware filesystems to create a master database that is synchronized in realtime between your devices running Spacedrive.
> What makes this different to Dropbox or Google Drive?
> It is not a storage provider, Spacedrive is simply a database that exists on top of existing storage layers, from cloud services like Dropbox, Google Drive and iCloud to physical devices and external drives you already own. It doesn't provide you more storage, rather a supercharged view of your existing storage.
So more like Syncthing? Or rather Windows File Sharing/Samba? I don't really get it
That explanations read like it's taking in any kind of file system, local or remote, and combines them into one unified file system. Not really new, but most other file managers focus on the popular storage-services (Dropbox, Google Drive, OneDrive, samba, ftp), and are not open source. If you can easily create plugins for any remote storage, not just the traditional file storages, or even make up your own, then it could become something promising.
it was added last minute without any clear explanation for our users, our fault. i will be changed next update. eventually logging in will be a quick way to connect devices, like Tailscale does
I don't wanna rag on this project and all the bugs since it's clearly in its super early days, but I keep wondering if there's something I'm missing:
Why no miller columns? Not a question just to Spacedrive but really any file manager, it's the main reason I pay and use OneCommander and it's surprising to me how few of them actually implement it, everything else feels a downgrade to me.
163 comments
[ 2.9 ms ] story [ 243 ms ] threadApparently they also have some special use cases in mind (if you read the roadmap) like multimedia conversion using ffmpeg woth the ability to offload the processing onto multiple computers.
It's not. Read their description more carefully: it's a Dropbox with slightly extended functionality.
For example, I have a gigabit LAN with a Synology NAS, a server with a bunch of hard drives, and various networked machines. Gigabit LAN is pretty slow. Getting image previews of RAW photos on the NAS is insanely slow and frustrating. With something like SpaceDrive, you have basically instantaneous access to those previews, metadata, and Everything-like (the Windows application) search capabilities.
I'm really excited about it! I have files strewn about in so many places. Having access to them from a central location, with a single interface, not relying on a slow network, is really great. I might even go crazy and start to organize things with tags.
It is a welcome concept. We have blurred the lines between strictly local files and all the cloud storage options these days. I personally maintain those boundaries and almost never mount cloud storage on my Mac, but my wife(as an academic) deals with Dropbox,iCloud drive, Google Drive and whatever Microsoft calls theirs, because the people she works with shares files through them and collaborate with reviews and such. If a solution like this can mask the vendor specific connection hiccups and quirks and provide a transparent file system that appears local but may be backed by $x cloud storage, that would be a nice boost to her workflow.
The key is the usability of such a tool. If the latencies are so high that it feels slower than Finder, then its chances are slim.
[1] https://github.com/spacedriveapp/spacedrive/releases/tag/0.1...
Not blaming them - the framework should support it out of the box. You shouldn’t have to understand virtualized lists.
I made a TableView in SwiftUI and I can scroll through thousands of without having the slightest idea how it works under the hood.
React is not a UI framework, it's a low level reactive library with very limited scope - even the DOM bindings are shipped separately, and it can be used for much more than just GUI, for example VR experiences or cloud infrastructure deployment. Bring your own batteries.
It’s so much nicer to just be able to trust that an extensive library of stock widgets will be able to do whatever it is that you need, as tends to be the case with AppKit/UIKit.
The real problem is that the Web platform doesn't offer a good set of customizable UI elements other than the most barebone basics.
And UI libraries like Tailwind, Shoelace etc are surprisingly extensive and constantly being improved. And if something isn't to your liking it's often to trivial to change it.
I'm building an app using it now and it's significantly better than past attempts at browser-based, cross platform app development. It is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
And one of the big advantages for me is that I get to leverage Rust's excellent low-level capabilities e.g. cross platform SIMD support, io_uring with minimal investment.
It uses system-provided WebView (WebKit on MacOS and Linux, and Edge on Windows) to display the UI shell, so the UI portion will be just as slow as any Electron app.
It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc. And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Rust and Tauri fixes all of those. It's not perfect but for a cross-platform app development library I've not seen anything better. Happy to be enlightened with alternatives.
You've just described almost any web-based UI ;)
> And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Most of the slow interactions come from the web-based UI. I mean, Slack needs 17% CPU to draw an animated emoji. And it's already running in a hyper optimised Chrome: https://twitter.com/dmitriid/status/1486364312910368769
> Happy to be enlightened with alternatives.
Qt :)
Unfortunately, it’s licensing is not suitable for everyone.
Unironically, FreePascal/Lazarus had a decent shot at this with LCL: https://en.m.wikipedia.org/wiki/Lazarus_Component_Library
It could target Win32, GTK and Qt all at compile time (even Android and OS X but that never got developed all that far AFAIK), depending what runs on your target platform, while you get common components and RAD at design time. I haven't seen anything like it since and sadly the language and ecosystem are mostly dead, which is a shame, because the idea was brilliant and it actually worked (and is still used in some software, like CudaText and PeaZip I think).
Aside from that, something like MAUI could be worth a look: https://dotnet.microsoft.com/en-us/apps/maui
Or as fast as any website built with a pinch of care to performance.
I do applaud anyone that tackles the challenge of building a proper native cross-platform UI.
It is one of the ultimate goals in software so wish them all the best.
[1] https://book.iced.rs
For integration with cloud services you're going to run into OAuth, and guess what, that dance happens in a browser: get access to cloud drive -> get sent to provider login <<web>> page (or authorization page) -> get sent somewhere else.
I mean, you can build it without the browser, but a key and very early step involves a browser, you need it anyway. Might as well ship your own if you can do it.
You don't need to embed a browser engine for this, let alone build the entire app inside a browser.
Now do the same for: Windows · Linux · iOS · watchOS · Android [1].
I'd rather embed the browser and get a free cross platform UI toolkit that's guaranteed to work everywhere :-)
[1] https://github.com/spacedriveapp/spacedrive
This one?
Next update we'll fix the bug browsing non-locations, as those who open the app tend to try browsing first, before adding as a location it seems. It's alpha software so I hope you give us time to iron it all out!
Also, judging from the GitHub description, it's not a file explorer. It's a slightly extended Dropbox:
--- start quote ---
From cloud services to offline hard drives, Spacedrive combines the storage capacity and processing power of your devices into one personal distributed cloud, that is both secure and intuitive to use.
--- end quote ---
At the end of the day, it is an amazing experience simply just to search and organize files from not just devices, but disconnected drives. Search is lightning fast, the UI is clean and you own all the data, given its local first and peer-to-peer.
Hate it if you must, but we're super passionate about it and are ruthlessly working to reach full stability across all platforms.
I don't think many people on here actually understand it.
Comparison table on your website showing what makes it different to Dropbox etc. would help.
I think that you should be pitching it a little differently: many people are confused about what your soundbite is actually saying (I also thought it was a file explorer, like all other file explorers I have even used).
Maybe lean hard into a phrase like "Unified file browser; see all files on all your devices, all at once, all the time".[1]
The other thing I would emphasise is that this isn't syncthing. You don't have to mention syncthing by name, but you could emphasise that "Your files aren't synced between devices, they're visible to all your devices".
Too many people who would otherwise use this would dismiss it with "I'm already using syncthing"! AIUI, you aren't syncing files between devices, only syncing file-listings.[2]
PS. For my own use, unfortunately, I don't need something like this. Sorry.
While it would be a nice to have in theory, it just doesn't solve any pain-points I am currently experiencing.
For example, any important document I need to read on different devices is already either in my email, or on google drive. I view movies on Netflix+AMZ+Disney+, I only ever share photos with others, not with other devices that belong to me. It's rare that I look at a file stored locally on my phone and say "I need to see this on my PC", or vice versa. It just never happens.
[1] That came out sounding super-weird: I did warn you that I wasn't any good at marketing :-)
[2] I expect you provide value on top of that, like transparently copy-n-paste between two different devices, even from a third device.
You know, I had quite a bashful [though in a good spirit] comment on your work before, but, thankfully, HN throttled me.
But thanks to your reply here now I not only can't endorse you, but I have an evidence what you really make some extremely opinionated thing and everybody else is wrong.
I can't wish you luck and I don't see myself as someone who would wait for news for this project.
Here you are in the church of pg giving shit to people following the scriptures of pg.
Creators - ignore shit like this. Keep iterating. I like your idea, your execution will get better and better. Well done both on releasing stuff and going open source!
Likewise if you decide to charge for some parts of the tool then you're more than welcome to.
Ignore the haters.
A third party cannot decide to provide something users do not want. Maybe they can get it preinstalled on Windows PCs or ANdroid phones. I cannot see MS (Or Google) being very happy with that.
These are not distributed file systems.
> And modern file managers have for some years now also support for cloud-storage like OneDrive or Dropbox.
OneDrive and Dropbox are not tied to any file manager.
As someone on Linux (popOS), I also gladly welcome it, as even the best file explorer I know (nemo) could use niceties that you find on Windows or macOS.
I'm highly skeptical of the economics of it though. The only way I would see it working out, if their planned "sync" product would be able to overcome the entrenchment of iCloud/OneDrive/Dropbox, which seems like a tall order. As a user I'd pay ~$50/year, but that would take a lot of customers to sustain even the current team size.
Well, Nautilus [1] (nw "Gnome Files" apparently) was created for Gnome quite a long time ago now. The company was Eazel and included some ex-Apple luminaries. So money spent on file managing is nothing new.
[1] https://en.wikipedia.org/wiki/GNOME_Files
Regarding Spacedrive... Seems a solid idea but I think their UI goals (looks fancy) might not be aligned with my preferences (minimal, fast, high functionality, no jank).
Eazel was 22 years ago, I highly doubt your problems with Nautilus have anything to do with them.
[1] https://syncthing.net/
I suppose I really should just get on and do something myself. :-(
Have you tried Dolphin on Linux?
These days I mostly use broot.
https://github.com/libfuse/libfuse
https://github.com/libfuse/libfuse/wiki/Filesystems
I am not convinced file managers need to be cross platform. There are plenty that will run on any desktop, IMO mobile platforms need different functionality and a very UI.
The real product as described on their website (not the github repo the linked) is that it is a drop box like sync service integrated into a file manager. I think most non-geeks will find it confusing compared to something that integrates with the familiar OS default file manager.
https://github.com/osxfuse/osxfuse/wiki/List-of-macFUSE-File...
https://winfsp.dev/doc/Known-File-Systems/
If they think they can make a better file manager, great, go ahead. But including transports in the file manager means that remote data only looks integrated, it isn't actually available to local apps.
Or (just as bad) they'll decide they need a copy-to-local and copy-back-to-network mechanism, which will work for some files opened by some apps but not all. Arghh.
Nemo (under Linux) does that for some protocols (eg. Android media transfer), and it is very annoying, especially as there are already FUSE drivers for (at least some) such protocols. In practice it means that the only thing you can do using Nemo is copy/move files around.
https://news.ycombinator.com/item?id=9224
You can reasonably write a C++ app or with Qt and write your GUI stuff in QML, and even plug in Lua, Python, or JavaScript as a scripting language. Yes, thats work.
Using a browser to render is just an easier version of using a GPU API like OpenGL to build your GUI. Your OS comes with gui stuff, use it.
Other than that, cool enough, though something like pcmanfm support adding remote locations as well...?
Another question, why Prisma?
Yes. If you want to build a cross-platform desktop app with Rust, Tauri + React would also be me recommendation right now.
Tauri makes it quite easy to drop down to Rust if you need to (for high-performance operations and everything interfacing with the OS), and it also comes with pre-built packaging for the main different platforms. With React you are able to leverage a great ecosystem that has existing UI components for many things (unlike most native Rust GUI frameworks). It also allows you to reuse you frontend engineers and all their expertise when it comes to web technologies (and working with designers).
And Slint? And egui? And the Qt bindings crates?
You can say that they aren't as mature as Qt, but they are often good enough compared to something that runs in a browser.
You can't make an app that looks even half as good as Spacedrive using QT, egui etc.
Slint is 100% capable of matching this, lol
$ spacedrive spacedrive: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
You give this out to the world for feedback and people moan its not working.
I am old geek and back in the day you knew an Alpha was just for the playground to kick around - most likely will crash, worse case will destroy you PC but you have a play / provide some feedback and wait for the next release.
A lot of other projects do everything in the dark and do a big ta da at the end - and missed the opportunity for the community of "alpha" or "beta" testers to provide some feedback along the way.
Keep going - its added to my list to take look once in beta as I prefer to play in that playground rather than the alpha one these days.
I like the idea!
For example, the title claims that it's a file explorer. However, someone in the comments shows that it fails at actually exploring files. Something which even an alpha project would not fail to do considering the claim.
Only when you read through the marketing copy and the comments, you realise that it's a hybrid cloud/local/cross-device Dropbox that creates a view of your files across systems/locations, and only once it's done that, only then can it do the actual file exploring. At least for now.
the project page has that front and center, it's only really the submission title that's implying otherwise.
> Spacedrive – an open source cross-platform file explorer (github.com/spacedriveapp)
Then the github file about section says...
> Spacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.
Then the github page opens by saying...
> Spacedrive - A file explorer from the future.
And claims it offers...
> a free file management experience like no other.
So I think we can forgive people for thinking it is a file explorer!
> UPDATE: Spacedrive is under active development, we are in the pre-alpha stage, with builds occasionally released via GitHub actions, official alpha coming soon.
For them, “alpha” and “beta” became ways to say “fresh out of the oven” and high profile revenue-generating products were proudly emblazoned with those words for years.
At this point, it doesn’t even mean anything. Half the internet is running on some 0.11.45-alpha of something or other, maintained by corporate engineering teams whose total compensation is in the millions.
It makes it legitimately hard for people to know what to expect and what standard to hold things to.
- Indexing one of my localdev directories has taken a robust 35+ minutes so far, and I will likely not wait until the end of it
- Like others have commented, latency is an issue (macOS M1 14inch base model). I've added a location and even there it sometimes takes 2-4 seconds after opening a folder to see any files
- Am I missing something or are there no tabs yet?
- Extremely lean (too much) in the ways of file sorting and grouping (non-existent), although I wager this will be worked upon during development
- It does feel like I have to do a lot of work to get to sensible indexing (add lots of locations by hand, and so forth)
- I know it's local first, but the way telemetry and login work really does not sit right with me.
Overall I'm almost sure it's not a fit for me, as interacting with it was a bit disappointing, but I can see an audience and there's still ways to go. It looks really good. Best of luck!
Since it has some glorified web app functionality, a non-tauri web demo with a remote `core` daemon would be super nice.
why do I want to login a file explorer man this timeline is weird
From the first line of the link:
>> Spacedrive is an open source cross-platform file manager, powered by a virtual distributed filesystem (VDFS) written in Rust.
You log in because it’s a remote file system. Think Dropbox, not file explorer.
> How does it work?
> Using a "Virtual Distributed Filesystem" (VDFS), in other words; a decentralized database that emulates a filesystem. It indexes hardware filesystems to create a master database that is synchronized in realtime between your devices running Spacedrive.
> What makes this different to Dropbox or Google Drive?
> It is not a storage provider, Spacedrive is simply a database that exists on top of existing storage layers, from cloud services like Dropbox, Google Drive and iCloud to physical devices and external drives you already own. It doesn't provide you more storage, rather a supercharged view of your existing storage.
So more like Syncthing? Or rather Windows File Sharing/Samba? I don't really get it
Why no miller columns? Not a question just to Spacedrive but really any file manager, it's the main reason I pay and use OneCommander and it's surprising to me how few of them actually implement it, everything else feels a downgrade to me.