File picker or folder selector for local running app

[nghia-vo]

For local running app, it's critical to be able to select local files (i.e open file picker dialog). In my applications, file-size can be > 20GB. Is it possible to modify upload module for this purpose?

[nghia-vo]

For example, I would like users click a button which pop up a dialog to select a file or a folder. Then, the file-path or folder-path is returned and I can do something else with it (i.e. loading an image and do some image filtering...)

[rodja]

The file picker dialog uses the internals of the browser. For security reasons it does not provide the full path of the selected files. See #269 for a similar discussion. But you could build your own file browser which acts on the filesystem of the local running app.

[falkoschindler]

Since we can't use Quasar's file picker for getting file paths, we will probably need to implement some kind of file picker ourselves. A first prove of concept is probably only a few lines of code. Does anyone from the community like to try it?

[nghia-vo]

Thanks very much. Please do. I keen to try it.

[nghia-vo]

Streamlit users would like to have the same thing: streamlit/streamlit#904 (ticket from 2020) but still waiting. It would be great if nicegui can do that first.

[falkoschindler]

@nghia-vo Absolutely! 😎
I looked into the discussion and it seems like after three years they realized the same limitation we are facing:

some browsers do not expose the path of the file because it presents a security risk
streamlit/streamlit#904 (comment)

There are two noteworthy workarounds:

• A file selector that presents the content of a server directory:
  https://discuss.streamlit.io/t/upload-files-to-streamlit-app/80/2
  That's what I had in mind.

• Writing to a temporary file:
  Let file_uploader return path, instead of reading the file in streamlit/streamlit#904 (comment)
  This seems to solve the problem of having to keep the whole file in memory. But we would still be copying huge files from one location to another.

Another weird and probably unstable approach is to combine streamlit with tkinter or wx:
streamlit/streamlit#1019 (comment)
streamlit/streamlit#1019 (comment)

[rodja]

Wow! Thank you so much for the example @polaar! It's a great idea solve the difficult interprocess communication with javascript. Why do you think it may be unstable? The code looks absolutely legit.
I'm not sure how to build a nice generic API for it... but would you like to integrate it as an example? Have a look at https://github.com/zauberzeug/nicegui/blob/main/CONTRIBUTING.md#examples for some simple instructions. We would be more than happy to count you as an official contributor.

[polaar]

Hi, glad it was of some use to you.
Would it be "unstable"? I don't know, I was just echoing the comment I was replying to: Another weird and probably unstable approach is to combine streamlit with tkinter or wx ;-) I don't know the reasons why such a solution might be unstable, so I don't know if they would apply to this solution as well.
Other than that: I feel a little uncomfortable about using webview.active_window(), first of all because it doesn't seem to be an official/documented pywebview api, and maybe also because it might not return the right window. I guess this would only be an issue if you would actually use pywebview to create other windows? Maybe not a problem for creating a file dialog, but might be if you try to use this approach for doing other stuff with the webview window. Seems like there should be a better way to get at the window?
As for contributing: I'm afraid I won't currently have a lot of time to do so.... I'm not even actually using nicegui for anything at the moment, was just playing around a little after discovering it... was a little disappointed that the native mode didn't seem to have file dialogs, and just out of curiosity spent way too much time already to try if I could get something working ;-) But it seemed worth mentioning it here...
(but who knows, maybe sometime...)

[rodja]

Thanks for the effort and sharing your solution. Glad you took the time.

[rodja]

I started a pull-request #917 wich uses a proxy object to call pywebview.window methods. It does not jet implement return values but may be the start of an alternative solution in pure Python.

[rodja]

@polaar #917 got merged and released in 1.2.16. Now you can write

from nicegui import app, ui

async def choose_file():
    files = await app.native.main_window.create_file_dialog(allow_multiple=True)
    for file in files:
        ui.notify(file)

ui.button('choose file', on_click=choose_file)

ui.run(native=True)

[nghia-vo]

I've just tried the tkinter solution. It didn't work with nicegui (I created a button to call the file_picker function, but nothing returns when clicked). For streamlit, it returns an error related to thread usage.

[falkoschindler]

I just created an example with a local file picker built in NiceGUI. It uses an AG Grid to show the content of the current directory and allows for up/down navigation and multi-selection. An upper_limit can be used to limit the navigation in order to prevent the user from traversing the whole file system on the server.

There might be some edge cases and security risks I haven't thought of (e.g. what about links?), but that's why I uploaded it as an example and not an official NiceGUI element (yet). Please let me know what you think! 🙂

https://github.com/zauberzeug/nicegui/tree/main/examples/local_file_picker

[smojef]

This is great! But for some reason, if I set the directory to '..', it always returns None if I pick a file from a subfolder (on Windows at least).

[nghia-vo]

I've just tested that, but the web browser keeps loading...

I'm using WinOS computer.

[rodja]

That is strange. Could you retest with our latest release 1.1.4?

[nghia-vo]

Just updated. It works now. Fantastic! Thanks very much. One more request :), the file pickler can't see other files in other drivers (similar to jupyter notebook). Can we make it see other drivers too?

[nghia-vo]

About security risks, can we set a condition in nicegui to enable the function only if the IP is local?

[nghia-vo]

Related discussion to request about see files in other drivers:
jupyter/notebook#1334
https://stackoverflow.com/questions/55078484/open-jupyter-notebook-from-a-drive-other-than-c-drive

[rodja]

@nghia-vo said:

the file pickler can't see other files in other drivers (similar to jupyter notebook).

Do you mean different "disks" in Windows? Eg. C:/ or D:/. Why is that? I do not have a Windows system to test. What does Python pathlib do in such cases?

[nghia-vo]

Yeap, it's C:/, D:/.... If I run nicegui from C:/ it only shows files and folders in C:/. If I want to see files in D:/ I have to run nicegui in command line from D:/. This is the same problem as jupyter notebook. WinOS doesn't have a single root like Linux.

[falkoschindler]

On Unix you can use an upper_limit of "/" to allow navigating all up to root, because taking the parent of the parent and so one eventually yields "/":

>>> Path('/some/path').parent.parent
PosixPath('/')

So the condition self.path != self.upper_limit is not true anymore and there will be no dots ".." for upward navigation in the table.

On the other hand, the origin of a Windows path seems to be ".":

>>> Path('C:/some/path').parent.parent.parent
PosixPath('.')

Therefore I guess you can try local_file_picker(..., upper_limit='.') to allow for switching the drive.

[falkoschindler]

This might be completely wrong, since you don't get a PosixPath on Windows. But I also don't have a Windows machine to try.

[falkoschindler]

Oh yes, Path('C:/some/path').parent.parent.parent is "/" because on Unix "C:/some/path" is understood as relative to the current directory ".". So the parent of "C:" (or "./C:") is "." This will clearly not work on Windows.

[falkoschindler]

I just pushed 6aa4956 to allow upper_limit=None to disable it. If it is disabled, we simply check if the current path is equal to its parent. This seems to be true for the root path - at least on Unix.

[nghia-vo]

Right, can we a workaround like jupyter notebook: "jupyter notebook --notebook-dir=D:/" to indicate the top drive?

[falkoschindler]

@nghia-vo I'm struggling to find a solution for navigating between drives. But if you want to restrict the file picker to a single drive (other than C:) you should be able to simply call something like local_file_picker('D:/some/path', upper_limit='D:/'). (Or is it local_file_picker('D:\some\path', upper_limit='D:\')?)

[nghia-vo]

Ha, thanks for that. If the link shared in one of the links I sent above can be of any help: https://github.com/jpmorganchase/jupyter-fs

[nghia-vo]

As a workaround, in local_file_picker we can add a method to pop up a dialog for users to select a hard-drive from a list (if the number of drivers > 1) (https://stackoverflow.com/questions/827371/is-there-a-way-to-list-all-the-available-windows-drives), then files in the selected driver will be displayed as the current local_file_picker doing.

[vickorian]

So it's pretty straightforward to use the win32api to ask for drive letters in the system. It will even report mapped network drives.

from local_file_picker import local_file_picker
import win32api

from nicegui import ui

def drive_selector():
    drives = win32api.GetLogicalDriveStrings()
    drives = drives.split('\000')[:-1]
    return drives

drs = drive_selector()

async def tog_update()-> str:
    print(toggle1.value)

toggle1 = ui.toggle(drs,value=drs[0], on_change=tog_update)

async def pick_file() -> None:
    result = await local_file_picker(toggle1.value, multiple=True)
    ui.notify(f'You chose {result}')

ui.button('Choose file', on_click=pick_file).props('icon=folder')

ui.run()

please ignore the diagnostic stuff in there. But this should be sufficient to do what is needed. in at least the most rough sense. You guys can obviously package it up into something more streamlined, but this answers the question at least. Great job on the file picker though.That's the hardest part.

This is not a System agnostic solution though, as i'm sure you're aware. Which would require determining file system type, which can be done by looking at the os.sep and running a different protocol for each version.

[YH20220622]

I've got a tkinter approach,

from nicegui import ui
import tkinter as tk
from tkinter import filedialog

root = tk.Tk()
root.withdraw() 

def run_tk_filedialog(e):
    root.wm_attributes("-topmost", 1)  # to make sure the filedialog pops up at the top
    file_path = filedialog.askopenfilename() 
    root.wm_attributes("-topmost", 0)

    mylabel.text = str(file_path)

mylabel = ui.label('File path: ')
my_btn = ui.button("pick", on_click=run_tk_filedialog)

ui.run()

it seems ok while running in native mode. But if I deploy the app on one machine and visit the app through webbrowser by another PC, clicking the button will only show a file dialog on the server machine, the visiting PC get nothing.

Hope any one can solve this!

[rodja]

What would you expect a local file picker to do when used remotely? In my opinion a local file picker (especially a native one like you did with tkinter) is only viable in a local setting. For remote cases, https://nicegui.io/documentation/upload is exactly what you need, or not?

[YH20220622]

When I use this remotely, I would expect it open the local file picker of the remote server, not the file explorer of the client side.
As I said, when clicking the button on the client side, nothing shows on the client screen, only people who can see the screen of the server can see the file dialog.

[rodja]

I would expect it open the local file picker of the remote server

The local file picker (build in tkinter) should show the filesystem of the remote server? Tkinter is not a web framework. It can not be opened remotely.

[YH20220622]

Sure. I just imagine having an app built by nicegui which can manage the server remotely.
The example code of 'local_file_picker' can be used in this scenario. If visiting it remotely, it will pop up the dialog which shows the filesystem of the server.
For a local app, file dialog with tkinter can meet my requirement. For remote use, the example 'local_file_picker' is good to use, though it lacks some functionality such as creating folders, path navigation, bookmarks.

[rodja]

I think this is finally solved. For web apps there is no way around an implementation similar to our local file picker example.

And thanks to @polaar, we also now have the ability to open a regular file picker in native mode:

from nicegui import app, ui

async def choose_file():
    files = await app.native.main_window.create_file_dialog(allow_multiple=True)
    for file in files:
        ui.notify(file)

ui.button('choose file', on_click=choose_file)

ui.run(native=True)

[varchasgopalaswamy]

@rodja, when I try this example I get a "connection lost" message. Any idea what I ought to do?

[rodja]

@varchasgopalaswamy, could you please provide a minimal, executable code snippet reproducing the problem. This will allow us to identify and fix it more efficiently. And I think it would be good to create a new question here on GitHub for better organization and readability.

[hoderlump]

This also gives the ability to save a file. Example:

async def save_dataframe_to_Excel():
    filename = await app.native.main_window.create_file_dialog(dialog_type=webview.SAVE_DIALOG, allow_multiple=False, file_types=("Excel file (*.xlsx)",), save_filename="save_filename")
    ui.notify("Writing dataframe to: " + filename)
    df.to_excel(filename)
    ui.notify("... saved")

In both file pickers the allowed file_types need to be passed as tuples in the following way (File description followed by round brackets and a *. with the allowed file extension):
file_types=("TDMS file (*.tdms)", "CSV file (*.csv)", )

[flooxo]

we also now have the ability to open a regular file picker in native mode

Is there also a way to do this in non-native mode?

[zhangguolin333]

we also now have the ability to open a regular file picker in native mode

Is there also a way to do this in non-native mode?

No

[jacoverster]

Hi, I've added a drive selector for Windows (see #1028) based on @vickorian's comment.