Pop-up dialog with customizable

[og900aero]

I don't know how much it would complicate the code, but I think it would be good to have an integrated pop-up window that could be configured:

• title
• text content (it should be possible to pass variables)
• multiple modes of operation (e.g., OK/Cancel, Yes/No)

For example, I just created an alternative rename function that checks whether I am in sudo mode. If not, it uses the built-in function; if so, it displays the current file name with zenity, which can be edited just like the built-in option, and then I rename the file using the rewritten name. It works and it's fine, but it throws up a GUI window, which doesn't really fit with a terminal program. I know there's dialog and whiptail program, but one is worse than the other.

cmd rename_custom &{{
	if [ "$lf_user_sudo_mode" = "true" ]; then
		name=$(basename "$f")
		newname=$(zenity --entry --title="Rename file" --text="New filename:" --entry-text="$name") || exit
		[ -n "$newname" ] && sudo -A mv -- "$f" "$(dirname "$f")/$newname"
	else
		lf -remote "send $id :rename"
	fi
}}

[CatsDeservePets]

This is related to #1616 (comment).
Currently, there is no way of getting user input from inside a shell script and returning it in said script.

[og900aero]

Why is this a problem? It's not a problem in Rust or Zig. It would be surprising if it were a problem in Go in 2025.

[CatsDeservePets]

I haven't looked that deep into it myself. I am certain this is possible. The real question is about the possible complexity which might not be worth it.

However, I will look into this myself after finishing some other things.

[joelim-work]

This is basically just a feature request for 'customizable dialogs', which is related to #84. Feature requests like these (other examples are 'tabs' and 'browse archives') are easy to submit as it involves describing a high-level concept, but are difficult to implement because they are quite complex under the hood and there are many low-level details to consider.

• For the UI, it might be better to just use the existing command line at the bottom rather than draw a dialog box in the middle of the screen. The latter requires development work and opens the possibility for further feature requests to customize the dialog box (e.g. color, style, size, placement, etc.).
• Dialogs are infinitely varied when you consider the different elements, for example yes/no buttons, text input, selection lists, radio buttons, checkboxes, just to name a few. In addition elements can be customized, for example text inputs might have a default provided, can only accept alphanumeric characters, or display asterisks for sensitive inputs like passwords. Imagine trying to specify all of that using lfrc syntax.
• Mapping keys is another concern, perhaps another mode has to be created so that typing y confirms the dialog instead of copying files.

[og900aero]

I agree that the request may be complex, but I think you're overcomplicating it a little.

• the existing command line at the bottom cannot be used in all cases. In fact, most of the time, the requested content cannot be redirected there, or whitespace must be used if, for example, I want to write something out and then refer to that command. I think you solved my request this way back then, and since then there have been parts of cmd ... in lfrc that are not visible, but have hidden whitespaces. I don't think this is a good solution, at best it's a workaround.
• Dialog boxes can indeed be infinitely varied, but why should everything be programmed? The spirit and implementation of Lf is based on minimalism. There are many elements that are not prepared to take every possibility into account. In my opinion, in this case too, we should strive to implement only what is absolutely necessary. For example, in the case of types, an n/Y dialog and a simple input field where you can enter a title so that you know what to type, and a default value so that if someone wants to use the rename function, they can print the directory or file value. But I think radio buttons or multiple choice options go beyond minimalism, as does the ability to color the window.
• Key mapping could be easily solved. There would be a variable whose value would be, say, 1 if this window is displayed, and then the keys would have a different meaning. Let's say there would be a dmap (similar to map and cmap) that would only work when the dialog is displayed.
• Perhaps minimalism would allow for the window position to be displayed with an offset address. The default value would be the upper left corner, and the offset could be specified vertically and horizontally relative to the window's percentage value. But I wouldn't insist on this either, because placing it in the middle of the window is perfectly adequate for me.

[CatsDeservePets]

@og900aero Feel free to submit a PR if you're willing to. If you have any programming experience, Go isn't that hard to pick up.

This seems overwhelming at first, I know. But implementing something you will actually use yourself is highly motivating (at least it was for when implementing #2010 and #2012 to enable Git indicators. These were my first real steps into lfs development and I don't regret it at all).