X11 resources aren't used by modern X UI toolkits (e.g GTK+/KDE) but they're pretty powerful. Other request is for other people to try the test script I posted above with whatever terminal emulators they have to hand and report the result.XTerm can be configured through command line switches, or through X11 resources. (In fact, qterminal also fails to support the -T option, so it's definitely not providing x-terminal-emulator as it claims.) Since at least three emulators (one of them is the QT app qterminal) show it, while all the others don't, I don't know whether bug reports need to be filed against each one separately, or if (preferably) there is some library package causing it.
My request for help is to try to identify the package causing the bug.
REMOVE XTERM UXTERM CODE
(The options listed in that Konsole code did provide some more Bad Words for qterminal, though not the gtk emulators.) Any exceptions, listed or not in any documentation, surely constitute a bug? Ie the command called after -e should be passed all the following arguments, no ifs or buts. To be honest, I'm not really looking for workarounds to what is essentially buggy behaviour (although one exists for my own particular use case).Īll these terminals I tested are supposed to (according to their debian/control file) provide the Debian virtual package x-terminal-emulator, whose handling of the -e option is well defined: … l-emulator So I think the documentation should list magic arguments to clear up this behaviour. Since -name and -title are likely X11-specific magic options, in your experiments, they get removed by the root application object, and the application never sees them, which is why they go missing. Application-specific options are of course implemented in the application-specific parser, and in Qt, QApplication will remove 'magic' options it has handled and pass on only the remainder to the application.
In Qt's case, this object is called QApplication (actually there's a hierarchy of QApplication, QGuiApplication, QCoreApplication and so on), and QApplication parses command line arguments BEFORE the application-specific argument parser sees the arguments.
No application that is a GUI app should have to handle all these special options individually, which is why the application root object often handles these kinds of arguments before the actual application code takes over.
Most toolkits also have at the root of any toolkit-based application a root object that handles some essential functions, for example the event loop for window events used by all widgets, but also basic application setup like parsing command line arguments, setting application style, handling GUI platform specific behaviours or canonical options, for example, X11 applications can often set their X11 window class or window name from a special command line argument. ) and more specific widgets for specific use cases (terminal emulation widget.). The terminal emulators are GUI applications based on an object-oriented model, meaning that their window is composed from standard widgets at the base (window, menu bar. I don't know about GTK-based applications but I can at least say something for Qt-based and KDE-based (=Qt-based by proxy), but for GTK it likely works similar.
0 kommentar(er)
