Open debunge opened 9 years ago
Youve got to be created. If you want to use the webbrowser elements then use them like you would a normal web browser. Otherwise create your own file dialog. Remember its just an application. Create a new ui element for browser directories and files. Make a method like MyThrustApp.listDirectory which will get the users home directory(by default) and list contents. Then use another method for navigating to other directories.
Also you can use html5 to do dynamic file uploads, and get the path, also allows drag and drop.
Sometimes browsers allow to get this full path. There are workarounds for IE, FF. For chromium IIRC there is a one, too. The site must be added to trusted list or something. Where do such settings in case of thrust live?
Could you also elaborate a bit on html5 part? I know about drag and drop, but filepath is now accessable anyway.
I get your idea about using my own ui elements, but just wanted to make standard select file dialogue accessible.
Apologies for taking so long to response, @debunge , I actually did not notice your response, and was swamped with a new job.
Basically what i meant is create a basic REST server, for filesystem information assume standard encodeURIComponent for any directory or file names get /list/:path // list contents of a path get /use/:path // use a file at path
Display a custom file browser to the user that allows them to navigate the directory structure.
I just did this for Dropbox/GoogleDrive at my last job so I know it works
You can also allow the user to type in a path as well, and use onKeyUp calls to the server to constantly get filtered results.
The point of Thrust was to do things like this, and share it with others so they could benefit from your hard work.
I will be back soon to maintain this project I hope, as I have also inherited Thrust Core completely.
I see. Thank you for a reply.
tbh this movement to atom-shell worries me a little bit, because I don't understand why it is happening. First, I thought thrust as it was a pretty complete thing, may be in need of some polish, but with no critical functions missing. Will it be (for example, from my, golanger, point of view) just golang bindings for atom-shell?
Essentially. However in the Thrust flavor. Thrust is essentially the same as atom shell. You will of course always be able to use the original thrust. But as far as being able to maintain it we think we need to get closer to atomshell On Mar 31, 2015 9:51 PM, "debunge" notifications@github.com wrote:
I see. Thank you for a reply.
tbh this movement to atom-shell worries me a little bit, because I don't understand why it is happening. First, I thought thrust as it was a pretty complete thing, may be in need of some polish, but with no critical functions missing. Will it be (for example, from my, golanger, point of view) just golang bindings for atom-shell?
— Reply to this email directly or view it on GitHub https://github.com/miketheprogrammer/go-thrust/issues/49#issuecomment-88310610 .
In truth I still have not even had time to consider the switch. We may not do it. Depends, on need.
FYI: also see https://github.com/breach/thrust/issues/282
In traditional setting it is not allowed for js runtime to know path to file which is reasonable. With thrust, on the other hand, getting path to file may be very important as with normal desktop application.
Is there a way for thrust to somehow get name of the file with something like
<input type="file" id="fs" onchange="THRUST.remote.send(getDisplayPath(this))" webkitdirectory directory multiple/>