Closed brucealthompson closed 1 month ago
I don't understand what you are trying to say or what notify.NewFileOpen()
refers to given that we don't have a notify
package here. Why can you not use dialog.NewFileOpen()
and pass in a callback there that then sends your data to the backend?
I don't understand what you are trying to say or what notify.NewFileOpen() refers to given that we don't have a notify package here.
Very sorry. I meant dialog.NewFileOpen().
Why can you not use dialog.NewFileOpen() and pass in a callback there that then sends your data to the backend?
I believe you have the use case backwards. The files to select are on the server, not the client. The client runs the UI front end. The client can actually be a wasm that is served from the server. So the client UI is selecting a file(s) on the server.
I think I could actually make the extensions myself if I get some idea of where to look in dialog.NewFileOpen() to make the extensions.
If you want to mount a remote file dataset then you probably want to register the file provider ("repository"). The file browser can then be told to look there instead ("SetLocation"). You should not need to do any modification to the toolkit to make this happen.
If you want to mount a remote file dataset then you probably want to register the file provider ("repository"). The file browser can then be told to look there instead ("SetLocation"). You should not need to do any modification to the toolkit to make this happen.
Sorry. This is not the use case. The use case includes Javascript running in a browser. There is no remote filesystem API available to Javascript running inside a browser. For example, dialog.ShowFileOpen() is currently a NULL implementation in a fyne generated wasm.
Javascript in a browser CAN call server hosted APIs. My implementation plan is to expose server APIs that the javascript based client can call to browse files on the server. Should work just "fyne". The only issue is I do not have an API call in the fyne toolkit that can display the file list once I get it from the server.
Essentially, I would like to split the dialog.ShowFileOpen() into a frontend UI and a backend file info API. The frontend simply displays the file list given to it by the backend and provides a callback(s) to the backend when there is a UI event that requires a new file list from the back end. I am sure dialog.ShowFileOpen() is already organized like this. There is just no interface between front end and back end exposed via the API right now.
The only issue is I do not have an API call in the fyne toolkit that can display the file list once I get it from the server.
Yes you do, that is what the repository registering can support - any type of filesystem can be loaded into the storage repository and worked with / iterated over etc.
I am sure dialog.ShowFileOpen() is already organized like this. There is just no interface between front end and back end exposed via the API right now.
Yes it is set up to do this - the interface between the front and back is the storage API which loads data through the registered storage repositories. You can see that Fyne ships with 3 turned on "file://", "http://" and "https://" though for obvious reasons we open the file dialog in the file space not the web repository space.
For example, dialog.ShowFileOpen() is currently a NULL implementation in a fyne generated wasm.
This comment is not making sense to me - there is no code inside the dialog package that can possible return nil
instead of an instance of the file dialog, at least that I can see. What test are you performing and where are you seeing the nil
?
Yes you do, that is what the repository registering can support - any type of filesystem can be loaded into the storage repository and worked with / iterated over etc.
OK. I think this may be my misunderstanding I see an API called: func (f *FileDialog) SetLocation(u fyne.ListableURI)
I also see the interface repository.Repository https://docs.fyne.io/api/v2.4/storage/repository/repository.html
It sounds like I can use the existing http repository or create a new repository that reads from my server. If their any example code that shows how to use the http repository in the context of fyne?
This comment is not making sense to me - there is no code inside the dialog package that can possible return nil instead of an instance of the file dialog, at least that I can see. What test are you performing and where are you seeing the nil?
I think this is my misunderstanding again. I used dialog.ShowFolderOpen() instead of dialog.NewFolderOpen(). dialog.ShowFolderOpen() does nothing in js likely because there is no default file repository set for js.
If their any example code that shows how to use the http repository in the context of fyne?
It works just like file - you would pass the location a URI that starts https:// instead of file://
It works just like file - you would pass the location a URI that starts https:// instead of file://
OK. It sounds like I need to extend the http repository since my implementation will actually support CanList() and List() as I am actually supporting an http based view into a filesystem on a server.
Thanks for all your help. I made the decision to use fyne about 18 months ago and have never regretted it.
I will close this ticket when I have completed the implementation.
Ag yes, those are missing I forgot sorry. Are you using, or would you consider, WebDAV? If that was the case I could see an argument for adding the repository type to Fyne or fyne-x...
Are you using, or would you consider, WebDAV? If that was the case I could see an argument for adding the repository type to Fyne or fyne-x...
I personally do not need all of WebDAV. I just need to be able to pick a directory in a hierarchical directory list. But of course if there was a WebDAV repository type I would absolutely use it. In fact, I think I am going to use a webdav implementation in the server. Simpler than trying to write something from scratch.
I guess this should be closed in preference of #5200 ?
I agree. Also worth noting for future requests, I just want to say that I'm not a fan of using the wording "I need". Saying that you need something sounds like trying to force us to do something and that's not cool. If would have been better to just label the issue something like "Support inputing data from API in FileDialog" in this case :)
Hmmmm……
So there is no interest in developing a fyne repository for WebDav?
From: Jacob Alzén @.> Sent: Tuesday, October 15, 2024 2:58 PM To: fyne-io/fyne @.> Cc: Bruce Thompson @.>; Author @.> Subject: Re: [fyne-io/fyne] Need a dialog similar to NewFileOpen() that allows file data entered from API (Issue #5187)
I agree. Also worth noting for future requests, I just want to say that I'm not a fan of using the wording "I need". Saying that you need something sounds like trying to force us to do something and that's not cool. If would have been better to just label the issue something like "Support inputing data from API in FileDialog" in this case :)
— Reply to this email directly, view it on GitHub https://github.com/fyne-io/fyne/issues/5187#issuecomment-2415122991 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPC5H7PABHCR7CIXLGXMHTZ3V6VLAVCNFSM6AAAAABPS7DZMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGEZDEOJZGE . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AIPC5H2WFWBVLTI7FTOMWL3Z3V6VLA5CNFSM6AAAAABPS7DZMKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUP6PNC6.gif Message ID: @. @.> >
So there is no interest in developing a fyne repository for WebDav?
I don't think anybody said that.
This is not a feature request for WebDav - the title issue is implemented pending a bug fix which is why I proposed closing it.
Added a new feature request for webdav repository. https://github.com/fyne-io/fyne/issues/5203
Checklist
Is your feature request related to a problem?
I am writing a multi platform application using Fyne. I used to have the UI and backend all as a single application.
Now I have broken apart frontend and backend using an API between them. The monolithic application uses dialog.NewFileOpen(). Now that I have broken the application apart I see that dialog.NewFileOpen() no longer works. First, it does not do anything in a wasm (of course). In a natively complied client, it lists the files on the client instead of the server.
Is it possible to construct a solution with the existing API?
dialog.NewFileOpen() is the base API for this enhancement.
Describe the solution you'd like to see.
Since I have an existing API between client and server, I am looking for a FileOpen dialog that takes its file / directory information data from the API itself. I assume there would need to be a new parameter with a list of file URLs added to the "NewFileOpen" for initialization as well as a callback which is called when the user selects a directory object.
Essentially, I would like to split the dialog.ShowFileOpen() into a frontend UI and a backend file info API. The frontend simply displays the file list given to it by the backend and provides a callback(s) to the backend when there is a UI event that requires a new file list from the back end. I am sure dialog.ShowFileOpen() is already organized like this. There is just no interface between front end and back end exposed via the API right now.