When using Thunar and renaming a file, at the validation, if the file is too long, there is a blocking message. Clicking on the "close" button, send back to Thunar, and the proposed filename is lost. Proposition : when typing too long filename, block typing at the maximal size. Second proposition : display maximal size in the "renaming" box.
This was fixed in Nautilus some time ago: https://gitlab.gnome.org/GNOME/nautilus/commit/122f201dcf356460a30a7b260730bcfc7246a614 https://gitlab.gnome.org/GNOME/nautilus/commit/1dfc03550ebc0844bc471effe40382a56e87155c
Thanks for reporting, and for the links ! This seems like a reasonable thing to do ! Are you interested in working on it? I can provide guidance, but its unlikely that I will have time to implementing this myself for a while.
I think I should be able to do something with this. My plan is to make it so that if a file name that is too long is entered, it is not truncated but the name cannot be changed until the new name entered has been edited to make it valid (if the currently entered filename is not valid, a warning icon and message will be displayed). Since a text box to input a file name appears in several places in thunar, I am going to try to implement this as a new widget class (derived from GtkEntry) so that the code can be reused rather than having multiple copies of the code in different places.
Created attachment 9536 demonstrator for possible filename input widget So here is a demonstrator program for the kind of thing I am thinking of. This is just a demonstrator, so the code for the new widget is very rough and unfinished, but I wanted to get an idea of whether this is a feature people want before doing any more work on it. On my system, this file compiles with gcc demonstrate_filename_input.c `pkg-config --cflags --libs gtk+-3.0` The program contains a very unfinished prototype version of a new widget that I am proposing to add to Thunar, called ThunarFilenameInput. The widget functions as a "smart" text entry box that checks if the filename entered is valid or not as the user types. At the moment, the widget does not allow filenames longer than 10 characters (obviously this is not a realistic maximum length!) or ones that contain a directory separator character ('/' on my system), or empty strings. The widget also warns if the name starts or ends with whitespace, but will allow such names to be used. The widget emits signals "text-valid" and "text-invalid" when the text is changed to be in a valid or invalid state (currently these are emitted whenever the text changes, but in the final version I would make it only emit a signal when the valid/invalid state really changes), and these signals can be connected to (as in the demonstrator) to make a button sensitive or insensitive according to the state of the text. When there is a problem, the widget displays an icon and a message. Of course, in the final version of the widget I could do other checks on the text, and also check the text in a better way (at the moment the checking code is very hacky). I propose to replace all GtkEntrys in Thunar that are used to input a filename with (the finished version of) this widget. At the moment, there are several different places in the code where a file name is entered, and they do not behave the same. For example, when creating a new file the text is checked as you type for directory separator characters and to check it is not empty, but when you rename a file there is no checking until after you have pressed "Rename". So what do people think? Is this a good feature to add, and is the approach I have taken good? I like having the error/warning icons and messages, but is this too much? If this seems like a good idea, what things should I check for when validating the filename? Comments and suggestions most welcome!
(and if I do implement this feature I'll close this bug and open a new one as making this change would not just be a bugfix)
Wow, looks real nice to me ! - I agree that we should replace all GtkEntrys in Thunar that are used to input a filename with that widget. - I as well like the having the error/warning icons and messages while typing. - Probably you might want to use a regular expression for matching: https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html Here is some help on the syntax: https://developer.gnome.org/glib/stable/glib-regex-syntax.html - You might want to place the widget in xfce4ui again :) To be reused e.g. in xfdesktop.
Thanks for the thoughts Alex! Yes, regexs look like a good idea. I never think of using them when writing C code despite the fact that there are plenty of libraries that support them - I guess I have it burned into my brain that string manipulation in C always has to be done painfully by hand! Do you think it is better to implement this in Thunar to start with and then move it into libxfce4ui, or to just go straight to submitting a patch for libxfce4ui? Finally, on an admin note, what's the correct status to close this bug with if I'm going to open a new more general bug to replace it? Thanks!
(In reply to Reuben Green from comment #7) > Do you think it is better to implement this in Thunar to start with and then > move it into libxfce4ui, or to just go straight to submitting a patch for > libxfce4ui? I would go straight for libxfce4ui .. probably saves some work later on. > Finally, on an admin note, what's the correct status to close this bug with > if I'm going to open a new more general bug to replace it? I guess "moved" would be appropriate, if you put a link to the new bug into the last comment.
>You might want to place the widget in xfce4ui again :) To be reused e.g. in xfdesktop. However, the rename dialog is provided by Thunar (using its file manager D-Bus interface).
(In reply to Theo Linkspfeifer from comment #9) > >You might want to place the widget in xfce4ui again :) To be reused e.g. in xfdesktop. > However, the rename dialog is provided by Thunar (using its file manager > D-Bus interface). I bet a beer that there are more occasions all across xfce where a filename has to be entered :)
I have now submitted a patch to add a new widget to libxfce4ui (bug #16542)