Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do I get path to selected file or folder? #49

Open
debunge opened this issue Feb 21, 2015 · 7 comments
Open

How do I get path to selected file or folder? #49

debunge opened this issue Feb 21, 2015 · 7 comments

Comments

@debunge
Copy link

debunge commented Feb 21, 2015

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/>

@miketheprogrammer
Copy link
Owner

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.

@debunge
Copy link
Author

debunge commented Feb 22, 2015

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.

@miketheprogrammer
Copy link
Owner

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.

@debunge
Copy link
Author

debunge commented Apr 1, 2015

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?

@miketheprogrammer
Copy link
Owner

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" [email protected] 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
#49 (comment)
.

@miketheprogrammer
Copy link
Owner

In truth I still have not even had time to consider the switch. We may not do it. Depends, on need.

@FPurchess
Copy link
Contributor

FYI: also see breach/thrust#282

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants