Currently, terminal instances are clones (or near-clones) of one another. The only individually-configurable feature I've found is the title. The title and the contents of the buffer are local to the instance, but nothing else appears to be. If the terminal instances were individually configurable, someone who wants to set up different color schemes, font faces/sizes, etc. according to the application that will run in that instance could do so, something that's not now possible.
The problem here is that there's a single configuration file, and it reflects any change in settings. How would it handle many terminal each having its own settings?
To me this sounds like a request for "profiles", as seen in many terminal emulators. (I think it's unreasonable for someone to regularly fiddle with color schemes, fonts etc. just to lose these settings the moment they close the given tab.)
I personally am not fond of profiles: to me they just make configuring harder because I never know whether I should be looking for a certain setting in general preferences or profiles. scratch, is profiles support what you're looking for?
A rule of thumb: Everything's a profile preference, unless different tabs next to each other having different values would be absolutely silly. E.g. imagine the tab bar's position or visibility toggling as you switch tabs, or the overall window toggling between various styles, or the hotkey for opening a new tab changing... [Although a different hotkey for operations local to the given tab's contents (e.g. copy-paste) might make sense to differ. It's not a black and white story.] But yeah let's wait for a clarification of this feature request.
Maybe I am talking about "profiles", but I'm not very clear about exactly what that term means to other people. The way I'd implement what I'm asking for, if I weren't already fully over-committed, is with an analog of css files. So the sysmgr could define some set of classes in a file stored in /usr/local/etc/xfce_terminal or similar: .Foo { background-color:#9999FF ; color:#DDDDDD ; font-family:"Courier New" ; font-size:10pt ; title:"MARIADB" ; ... } .Bar { ... } ...and pass the identifier for the selected class in on the command line when starting up a terminal instance. There might be some kludgery needed to prevent an app running in a dedicated terminal instance thinking it should understand the identifier. Maybe no more than another edit box in the launcher to separate the terminal's command line from the app's. There are a number of open-source interpreters for css syntax/semantics so no need to reinvent that wheel. That part of the work seems (I ruthlessly did *not* look at the current code) as though it would amount to getting the terminal instance to take all its config information from the interpreter's symbol table rather than mostly from whatever central location it looks at now. So, is this "profiles"? (This could actually be a way to do themes, too, now that I come to think about it; see e.g. the pseudo-css used by open-street-map rendering engines)
IMO this is pretty close to profiles. The problem is this approach would require you to manually edit some config file. This means that hardly any people will use it, and hence is probably not worth the required developer effort. Many terminal emulators implement profiles along with a graphical way of configuring them so that the feature is easily discoverable and easy to use.
(In reply to Egmont Koblinger from comment #6) > IMO this is pretty close to profiles. The problem is this approach would > require you to manually edit some config file. This means that hardly any > people will use it, and hence is probably not worth the required developer > effort. > > Many terminal emulators implement profiles along with a graphical way of > configuring them so that the feature is easily discoverable and easy to use. There's nothing preventing the making of a gui configurer with strong HF values. Except developer energy and time, of course. There might even be a good open-source one out there that could provide the core functionality ready-made. A pseudo-css file is really just a way to store the values in a form more human-readable than xml and more readily transformed into a usable symbol table. A gui frontend could certainly write/maintain one. Nor, really, is there anything preventing such a file being distributed with a number of nice-looking classes pre-defined to give people a leg up.
(In reply to Egmont Koblinger from comment #6) > IMO this is pretty close to profiles. The problem is this approach would > require you to manually edit some config file. This means that hardly any > people will use it, and hence is probably not worth the required developer > effort. > > Many terminal emulators implement profiles along with a graphical way of > configuring them so that the feature is easily discoverable and easy to use. Actually, now that I come to think about it, is it really likely that people willing to run Unix or Linux rather than Windoze or a Mac on their desk would shrink from editing Yet Another Config File? Xfce doesn't run under anything else, does it?
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/23. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev