QT issues including domterm: unrecognized option '--qtdomterm'

[mcarans]

I upgraded to Mint 21 and had to rebuild DomTerm so I pulled latest. I am using the version of QT5 that comes with Mint 21. On running with qtdomterm, I get: domterm: unrecognized option '--qtdomterm'. domterm --qt works though.

[mcarans]

Another issue is that copy and paste with the mouse doesn't seem to work any more. (I have built with libclipboard).

[PerBothner]

Sorry about changing the option names. I decided to change the browser-specifier options to work a little differently, starting with -B. Some (but not all) of the old browser-specifiers (such as --qt) still work, but -Bqt or -Belectron or -Bfirefox is now preferred.

I specificlly changed the Qt-based options because the -Bqt is now a synonym for -Bqt-widgets (which is is new and uses a browser engine per sub-window) as opposed to -Bqt-frames (which uses iframes like other frontends). The former has major benefits (especially for browse windows) but is newer and may have some artifacts.

A related problem is not having a good platform to announce changes and new features. There is a domterm mailing list. If I though anybody was reading it, I could use that. I could also set up some discussion/forum site, but I have little experience with managing such forums - or even monitoring one on a regular basis. I'm an old email guy, and I don't have the experience or habits to switch. (Partly because there are just too many options. Discourse is one but there are too many others.)

[PerBothner]

I might have a fix for the copy-and-paste problem. It is mixed up with some other changes I'm working on, specifically zooming. I'll see if I can get it checked in sooner rather than later.

[mcarans]

@PerBothner No problem. Would it be possible to make the command qtdomterm use -Bqt-widgets instead of failing with unrecognized option '--qtdomterm'?

I look forward to your copy paste fix.

[PerBothner]

I thought you meant using --qtdomterm on the command-line, manually.

I checked in a fix which I hope should work. (Not copy/paste yet, though.)

[mcarans]

@PerBothner Great thanks, the fix worked for qtdomterm.

On the copy paste, it works when using the keyboard (CTRL-SHIFT-C, CTRL-SHIFT-V), just not when selecting copy or paste in the menu that appears when you right click.

[PerBothner]

I checked in a fix for copy/paste - I hope. libclipboard may not be needed any more. I built DomTerm without libclipboard and the cases I tried all seem to work.

Note the change I checked in is part of a larger change in setting the correct "context" (child or parent frame) so I might easily have broken something. So let me know if you notice anything.

[mcarans]

@PerBothner Thanks. The fix worked. The only issue is that after right click pasting the top menu bar seems to be activated (so using arrow keys for example doesn't work until I left click in the window):

[PerBothner]

I've seen that sometimes, but I haven't yet figured out a pattern so I can reproduce it reliably.

[mcarans]

@PerBothner Does using the mouse to copy paste make it happen for you?

[PerBothner]

"Does using the mouse to copy paste make it happen for you?"

No, I can't make it happen. Could you give me your configure command line, how you invoke domterm, and what actions you do to trigger it?

[mcarans]

I use ./configure --with-qt. I launch Domterm with qtdomterm. I typed 1234567890 and selected 3456 with the mouse, then right clicked and chose copy. The problem occurs every time for me.

Details of my versions:

DomTerm version 3.0.0 (git describe: 2.9.4-273-gc78587f-dirty)
Copyright 2022 Per Bothner and others
Using Libwebsockets 4.0.20
Reading settings from: /home/mcarans/.config/domterm/settings.ini
Backend pid:7824, command-socket:/run/user/1000/domterm/default.socket
Window 1:  qtwebengine: 5.15.9, chrome: 87.0.4280.144
  Terminal#1: pid: 7904, tty: /dev/pts/0

My settings.ini:

shell.default = /bin/bash
command.electron = /home/mcarans/Programming/electron/electron
window.geometry = 1280x600
style.dark = on
style.user =
 |div.domterm { --monospace-family: "JetBrains Mono","Monospace","FreeMono"; font-size:14px }
 |div.domterm {  --main-light-color: white; --main-dark-color: black }
 |div.domterm-spacer {background: none }
 |div.domterm {--dt-blue: #729FCF; --dt-green: #8AE234; --dt-yellow: #FCE94F; --dt-red: #EF2929}

I'm using bash-it with theme brainy which is a two line prompt.

[PerBothner]

I'm still not able to reproduce it - though (as mentioned) I have seen the behavior before. I'm using the same version of Qt as you.

I think it is almost certainly an outline that the browser adds to highlight the focused element. See here. See this rule in hlib/domterm-default.css to disable focus outline for the caret:

 span[std="caret"]:focus {
      outline: none; /* disable browser's default focus style */
 }

It should be possible to disable what you're seeing with a CSS rule like:

section.lm_tabs:focus { outline: none }

You may have to experiment to find the correct CSS selector. If might be easier in Electron or another front-end, at least to inspect the node tree. To inspect elements in Qt you have to use the --remove-debugging-port option - but it has some weird interactions.

Arguably, the underlying "bug" is why is the menubar getting focus in the first place? Unfortunately, focus is very tricky and hard to debug. Focus interacts with the selection and caret in ways that are unclear and not well-documented.

[mcarans]

@PerBothner I downgraded to this version of DomTerm and it doesn't have the issue in case that helps with debugging:

https://github.com/PerBothner/DomTerm/releases/tag/2.9.4

I have to admit that I prefer the appearance of the older version althouh I can see that some may prefer the compactness of the newer one.

[PerBothner]

Version 2.9.4 is way too old to be helpful with debugging (I believe it predates the custom titlebar, at least with menu embedding), especially if I can't reproduce the problem.

Did you try adding this to domterm-defaults.css:

section.lm_tabs:focus { outline: none }

If that doesn't work, try:

*:focus { outline: none }

You can force the system titlebar with the titlebar=system setting. But if you suggestions for improving the appearance of the custom titlebar, please let me know. More generally, if you use dark mode (which seems to be the case from your screenshot), I could do with some suggestions for colors or theming.

[mcarans]

@PerBothner I searched for domterm-defaults.css but could not find it. Please could you tell me where it is located.

EDIT: ah got it, it is domterm-default.css not domterm-defaults.css

[mcarans]

@PerBothner *:focus { outline: none } removed the highlighting around the menu bar but the arrow keys still do not function until I left click in the window (as if the focus is still not on the current line).

[mcarans]

@PerBothner With titlebar=system, copy paste does not work at all - not with keyboard shortcuts or mouse. That is whether or not I compile with libclipboard.

[PerBothner]

Copy/paste seems to be working again when using -Bqt (-Bqt-widgets), with or without libclipboard.

[mcarans]

@PerBothner I can confirm it works. Thanks a lot! The issue with focus doesn't happen if I have a title bar.

In answer to your earlier questions about dark mode settings, this setup for dark mode works well for me:

shell.default = /bin/bash
command.electron = /home/mcarans/Programming/electron/electron
window.geometry = 1280x600
style.dark = on
style.user =
 |div.domterm { --monospace-family: "JetBrains Mono","Monospace","FreeMono"; font-size:14px }
 |div.domterm {  --main-light-color: white; --main-dark-color: black }
 |div.domterm-spacer {background: none }
 |div.domterm {--dt-blue: #729FCF; --dt-green: #8AE234; --dt-yellow: #FCE94F; --dt-red: #EF2929}
titlebar=system

Improvements I can think of to the dark mode are:

1. make the background completely black or grey instead of patterned
2. make the menu background black or grey with white text
3. make the tab bar black or grey with white text
4. remove the pink outline around the window

I'm not sure if any of those are currently possible or require coding.

[mcarans]

Here is an example of what the standard Linux Mint terminal (Gnome Terminal) looks like in dark mode in case of interest:

I would envisage colours along those lines for dark mode.

[PerBothner]

I'd like to move discussion of dark mode styling to a separate issue: #114