Priority: Not Evaluated
Affects Version/s: 5.15.2, 6.2.0
Fix Version/s: None
Component/s: GUI: Look'n'Feel
Operating System: Arch Linux
KDE Plasma Version: 5.23.1
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-zen1-1-zen (64-bit)
Graphics Platform: X11
QGuiApplication::setApplicationDisplayName() is intended to append an application name to all windows' titles (like "file.etm - ExoTracker"). In practice it comes with serious flaws:
- If your application is named ExoTracker, the suffix vanishes on windows whose regular title ends in ExoTracker. For example if you open an editor dialog for an instrument named ExoTracker, the dialog's suffix disappears. And if you rename your instrument to another name, the suffix magically reappears.
- If your title is named "ExoTracker[*]", then the asterisk is only present (and the suffix only appears) when you call QWidget::setWindowModified(true)!
- Your program doesn't know whether the suffix is shown. (This isn't important to fix if the other issues are fixed.)
- The separator differs between Windows ( - ) and Linux ( - , en dash). Your program doesn't know what separator is used, and can't control it either.
- As a result, on Linux you can get ugly dialog titles like "Instrument 00 - Name - ExoTracker" (a hyphen followed by an en dash).
- If the suffix makes some dialogs' titles too long, you can't turn it off on a per-window basis.
I think a reasonable solution is to add a flag so the app author can choose (on a per-window basis) to unconditionally show the application name, or unconditionally hide it.
It might also be helpful to add a global flag to control the initial or default title display of new windows, since the static methods of QMessageBox and QFileDialog don't let you set flags on the QDialog created internally. Should the flag also control existing windows, whose title flag hasn't been set? Should it also control windows set to "use current behavior"? Or only windows set to "unset/default", adding another (excessive) state distinct from "current behavior"?
If the above control is added, the hyphen-dash inconsistency is less urgent IMO, since you can hide the application name (and the dash separator) in any dialog where you put a hyphen in the title.
However, on Linux this would still result in some windows using hyphens while other windows use en dashes. In my app, my QMainWindow and QFileDialog would be titled "Text Here - ExoTracker" (en dash), while my editor dialogs would be titled "Instrument 00 - Name" (hyphen). This is less noticeable than having hyphens and dashes in the same window's title, but still an inconsistency. Perhaps it's still beneficial to add a method to get or set the current separator? (Though what would the getter return on Mac, where applicationDisplayName isn't shown at all?)
This is somewhat related to QTBUG-70382, but that bug report seems to have multiple complaints (can't show full path in title, applicationName isn't shown on main window, applicationDisplayName is shown on all dialogs) filed under one issue. I think the user expects more flexibility than Qt currently supplies, and would be better off calling QWidget::setWindowTitle() themselves, and not calling QGuiApplication::setApplicationDisplayName(). This is the approach I ended up taking for the time being.