Embed an optional browse button in ctkPathLineEdit:
Q_PROPERTY(bool showBrowseButton READ showBrowseButton WRITE setShowBrowseButton)

Would this be instead of linking to a QPushButton as in these instructions?
https://github.com/commontk/CTK/issues/14

yes, ctkPathLineEdit would offer the option of having a browse button inside the widget directly.

Please clean up qSlicerCLIModuleUIHelperPrivate::createFileTagWidget()

Do you mean that inside this function would be a good place to use ctkPathLineEdit instead of QLineEdit?

Yes, but please update your repo, it's already the case.
I just use a QToolButton manually, and it should be using the ctkPathLineEdit built-in toolbutton when it will exist.

Browse button added in ctkPathLineEdit in: https://github.com/commontk/CTK/commit/0de5ad082c0ba0d68056ca40a4e31ea2b9bd0556

From Andrei on 08/28/2012:
[...]
What I do not like is that it becomes intuitive only once you start
typing something meaningful. It just does not look like the place you
would use to select the path. [...] here are some ideas for discussion:
a) initialize the widget with the currently selected path, don't have
it blank, also maybe make it grayed out to make it look different from
the regular LineEdit
b) what is the purpose of the drop-down "v" button on the right? It has
no effect for me. Is this history? How does an item get added to that
history?
c) for the "Browse" button, add some icon that would hint the user that
it is for path selection ("..." does not seem to be intuitive enough)
d) IMO, there should be an option to disable editing of the line edit
part of the widget, and use it only for displaying the selected path,
so that user interacts with it using only browse button, and maybe
history button.

a) I agree. Note for developer, consider using QLineEdit::placeholderText
b) it is for the history, items can be set only at the application level. Maybe it should be off by default though. Could also add a mode where any current path is added in the list (especially in the d case)
c) I agree
d) Great idea

One more idea: once an item is selected, does it make sense (and is it possible?) to display an icon to the left of the text, to indicate what kind of item was selected (directory vs file)?

This is currently targeted for 4.3 and is lower priority. Having a fresh eye on the topic would be great. If you have any question, feel free to ask to Chris

I don't believe I had anything substantial on this issue.

Seems like the browse button in ctkPathLineEdit expects to choose a file. Is this intentional?
If yes, there should be a boolean that controls whether the browse button opens a file selection or directory selection dialog.

The type of browse dialog is controlled by the type of filter:
https://github.com/commontk/CTK/blob/master/Libs/Widgets/ctkPathLineEdit.cpp#L419

Instead of an additional property, I suggest extended documentation in the .h instead.

Work-in-progress topic: https://github.com/jcfr/Slicer/tree/1672-change-ctkdirectorybutton-into-ctkpathlineedit

Fix committed to 2145-support-for-installing-extension-from-file branch.