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.