implement file truncating

[hacknus]

implement file truncating in the middle to prevent filenames from bei…ng displayed over two lines.
Addresses an issue stated in #200

[hacknus]

Could probably be a bit simplified by extracting the path and is_dir from the DirectoryEntry

[fluxxcode]

Thanks for implementing! Could you create an option in FileDialogConfig and a builder method in FileDialog so that it can be activated and deactivated from the backend? With a warning in the docs that if truncate is disabled, scolling will get an offset in large directories.

[fluxxcode]

I've tested it now too. Works really well so far. Here are a few more points:

• I think we can reduce the save margin from 20 pixels to around 10-15 pixels
• We should display the full file name when we hover over a truncated element

[hacknus]

I observed some jumping when putting the offset at 10, so I put it at 15.

The full label is now shown when hovered, but only if it is truncated, not if the full label is already shown

[hacknus]

Used only the DirectoryItem and max_length as inputs.

[fluxxcode]

Hi, I made the following changes to the code:

• Always render file and pin icons
• Reworked truncate_filename to account for different character sizes. You first built it so that the truncate_filename works at char level. The problem is that each char has a different size that needs to be taken into account.
• I did the truncating at the end or at the file extension. This makes the code a little cleaner and looks a little better in the UI than if it was truncated in the middle
• General cleanup

Do you agree and could you review my changes? Thanks!

[hacknus]

thanks for the improvements with the letter sizes!

I don't like truncating at the end though, mainly because now files like
long_project_name_v1.pdf
long_project_name_v2.pdf
long_project_name_v3.pdf
long_project_name_final.pdf

all look identical - which is probably the reason why macOS (and maybe other OS/explorers) split it in the middle or at like 2/3 of the name. But I personally also find the display of a_long_filena...pdf a bit odd to look at since I expect only one dot before the extension..

[fluxxcode]

mh yeah ok that's true. Then I'll try to truncate the name in the middle.

[fluxxcode]

Windows actually truncates right at the end, even without including the file extension.

I've now gotten the truncating in the middle to work with the char sizes, but I'm currently debating whether that justifies the performance. In terms of performance, it's much more resource heavy.

[fluxxcode]

Pushed the changes. Let me know what you think

[hacknus]

Oh, okay, did not know that about windows.

Hmm, how much more resources are we talking about? I don't notice a considerable difference between the two.

I noticed a bug:

if a directory has a dot in it (like a date) it is now interpreted as the extension, thus giving:
2024.11.12_some_folder
something like this:
2...11.12_some_folder
which does not make any sense, I think we should only use the file_stem if the file is not a directory and truncate the whole filename if it is a directory

[hacknus]

We could also add it as an option if one wants to split in the middle or at the end.

[fluxxcode]

Hmm, how much more resources are we talking about? I don't notice a considerable difference between the two.

We have to clone strings several times and iterate the file_stem several times, which we don't need with back truncating. In reality you won't notice much of a difference, but at the latest in large directories when all elements are updated (e.g. when you enter something in the search) it can make a difference in performance.

I noticed a bug:

if a directory has a dot in it (like a date) it is now interpreted as the extension, thus giving: 2024.11.12_some_folder something like this: 2...11.12_some_folder which does not make any sense, I think we should only use the file_stem if the file is not a directory and truncate the whole filename if it is a directory

Ahh lol. Don't think it's because of the file_stem but because of the path.extension. Will fix it.

[hacknus]

shouldn't egui only update the visible items in a ScrollArea? So I think it should not use more resources in large directories or am I wrong?

But yeah, could still make sense to make it optional - especially if it is different across operating systems and people might favor one over the other out of habit

[fluxxcode]

shouldn't egui only update the visible items in a ScrollArea? So I think it should not use more resources in large directories or am I wrong?

Only if you use ScrollArea::show rows. However, we cannot use show_rows when the search contains something because we cannot estimate how many files or directories are relevant to the search. The same applies to the “create_directory_dialog” dialog. Currently, when the dialog is open, it is rendered as the last element in the central panel. There we are also obliged to update every item in the directory.

[hacknus]

Ah, yes, I see. Thanks for the clarification!

[fluxxcode]

FYI: #181

[fluxxcode]

I fixed the problem with directories containing dots. The problem was both path.filestem and path.extension. This doesn't seem to be implemented correctly in the standard Rust library for directories. Could you take another look?

[fluxxcode]

I wouldn't add an option for truncating in the middle or back btw. This is actually something that the user of the file dialog should decide and not the backend app. But user settings is something much bigger that we can implement at some point in the future.

[hacknus]

I wouldn't add an option for truncating in the middle or back btw. This is actually something that the user of the file dialog should decide and not the backend app. But user settings is something much bigger that we can implement at some point in the future.

yeah that makes sense.

I fixed the problem with directories containing dots. The problem was both path.filestem and path.extension. This doesn't seem to be implemented correctly in the standard Rust library for directories. Could you take another look?

Yes, I thought so too. Now it works perfectly, I like it!

[fluxxcode]

Great, thanks for testing! Will merge the PR tomorrow when I've tested on Linux.

[hacknus]

Cool, thanks! I created an issue about the file_stem() function: rust-lang/rust#133399