DRAFT: File Dialog example

[klytje]

I added a new example of a file dialog using the external nativefiledialog_extended library. The main features of the example is a reusable file dialog element, a simple text autocompleter, and the manipulation of background colors of input_boxes.

[klytje]

Questions:

I don't like using the link_libraries(nfd) in the CMakeFiles. It would be way nicer to use target_link_libraries, targetting only the executable itself. But since it is constructed in a different project, CMake doesn't accept this. Is there a better way of doing this linking?

I'm having some issues making the new file dialog element look nice - ideally I'd like the x button to be right next to the
input_box, sharing a single frame. I'm not super sure how to create a negative space between these two elements though. Any ideas beyond modifying the input_box element itself?

Comments on the autocompleter are welcome! I'm not sure if we should have it in this example or not - I already had it implemented for my own project, so I thought why not. It is meant to autocomplete parts of, or the full path to, input files when it can be deduced. E.g. for the .txt input files, when the user enters a / it'll search the folder for .txt files; if only a single match is found it'll automatically be entered; if there are multiple matches, the longest common prefix is found and entered. I have some additional questions/thoughts regarding this should we decide to keep it.

The code itself is still missing comments and a minor refactoring away from using static elements.

[djowel]

I'm having some issues making the new file dialog element look nice - ideally I'd like the x button to be right next to the
input_box, sharing a single frame. I'm not super sure how to create a negative space between these two elements though. Any ideas beyond modifying the input_box element itself?

I think we need to add D and reverse D buttons, instead of just the usual round rect buttons. Something similar to those used in Bootstrap's input groups (example):

Square buttons too for those in the middle of groups:

[klytje]

Oh yeah that'd be perfect for this example. I can take a shot at it when I find some spare time. Perhaps the best interface would be an overload of the existing button, but with an additional parameter describing the amount of curving? Taking values between 0 (sharp corners) and 1 (half-circle)?

[djowel]

Oh yeah that'd be perfect for this example. I can take a shot at it when I find some spare time. Perhaps the best interface would be an overload of the existing button, but with an additional parameter describing the amount of curving? Taking values between 0 (sharp corners) and 1 (half-circle)?

I think an enum for the shape would be sufficient.

Please study the button_styler code which demonstrates a way to pay for only the things that you need using template magic.

https://github.com/cycfi/elements/blob/master/lib/include/elements/element/gallery/button.hpp

[klytje]

I think the amount of curvature is a matter of personal taste, so hard-coding it in through a limited number of enums wouldn't be sufficient. Especially if we want to support half-circular edges as well, in which case we've essentially covered the entire range of values we would have to support anyway.

Example of half-circular edges:

Regarding the cost, we could just leave the current implementation as it is, and have the overloaded method return a specialized button supporting this feature.

[djowel]

I think the amount of curvature is a matter of personal taste, so hard-coding it in through a limited number of enums wouldn't be sufficient. Especially if we want to support half-circular edges as well, in which case we've essentially covered the entire range of values we would have to support anyway.

Example of half-circular edges:

Regarding the cost, we could just leave the current implementation as it is, and have the overloaded method return a specialized button supporting this feature.

Please study the code. There is actually already an option for the curvature. It's the corner_radius.

[djowel]

Regarding the cost, we could just leave the current implementation as it is, and have the overloaded method return a specialized button supporting this feature.

Please study the code I linked to above. It's not your typical OOP. There's some template magic happening there. The code has zero overhead already. You pay for a feature only if you need it.