Time part of custom prompt showing incorrectly on next line on startup

[mcarans]

I have a custom prompt with the time on the right hand side. When DomTerm first loads, the time incorrectly shows on the next line, but subsequently is ok. See the following screenshot:

[PerBothner]

Hm. I do have a right prompt for Fish that show the time - and that seems to work.

If you give to detailed steps to reproduce your problem, I can look into it.

[mcarans]

I notice DomTerm prints the size of the terminal briefly on startup and then it disappears. The terminal size eg. 149x32... appears where the time would be and it looks like it pushes the time down, then it disappears. Maybe the terminal size could be shown briefly in the window title instead?

The theme I am using is https://github.com/Bash-it/bash-it/blob/master/themes/brainy/brainy.theme.bash which I installed through bash-it (which is similar to oh-my-zsh and oh-my-fish).

My settings.ini for DomTerm is:

shell.default = /bin/bash
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}

The end of my .bashrc looks like this (before this bash-it automatically added some stuff including an env var with the name of the theme - brainy):

source "$BASH_IT"/bash_it.sh

if [ "$PS1" != "" ]
then
  if [ -n "$DOMTERM" ]
  then
    source ~/.local/share/DomTerm/bash-preexec.sh
    source ~/.local/share/DomTerm/shell-integration.bash
  fi
fi

[PerBothner]

I got brainy to work - similar to your screenshot - but the first line does show the time on the right similar to other lines.

"I notice DomTerm prints the size of the terminal briefly on startup and then it disappears. The terminal size eg. 149x32... appears where the time would be and it looks like it pushes the time down, then it disappears. Maybe the terminal size could be shown briefly in the window title instead?"

That shouldn't be an issue - the popup notification is in a separate "overlay" - it does not appear in the terminal "buffer". If it "pushes the time down", that could be a browser bug What browser are you using? I tested both Electron and Firefox. Are you using the latest DomTerm from git?

[mcarans]

@PerBothner I am using QTDomTerm - have you tried Brainy with that? BTW, I had assumed QTDomTerm would be faster than the Electron based version - is that right or is there no difference?

[PerBothner]

I do see some issues with the theme when the prompt doesn't fit on a single line. And it does seem to be mis-behaving worse/differently when using Qt.

I'm somewhat confused because I'm using Qt 5.15.2 (as installed on Fedora 33), but the "userAgent" reports QtWebEngine/5.6.1 Chrome/45.0.2454.101 - which would be quite old, but this page suggests I should be getting a much more recent version Chromium. So it is possible the problem is a very old version of Chromium - or something else.

I could probably implement a work-round, but it doesn't seem a high priority - I'm inclined to wait to see if Qt6 fixes it.

The command domterm status is useful to see version numbers and more. Pressing and releasing the Ctrl key is also useful.

I doubt there would be a noticeable speed difference between Qt or Electron or --chome/--chome-app as they're all based on Chromium, though possibly different versions. Electron might have slightly more overhead (especially memory use) because it uses Node for the menu/window management but that is likely to be minor. However, I have no data behind that.

I'm experimenting with a tab/sub-window library using Qt. If that works out, at that point qtdomterm would probably be the nicest front-end.

[mcarans]

Thanks for looking into it.

domterm status gives:

DomTerm version 2.9.0 (git describe: 2.1-367-g0e0c2a2)
Copyright 2021 Per Bothner and others
Using Libwebsockets 3.2.0
Reading settings from: /home/mcarans/.config/domterm/settings.ini
Backend pid:2376 command-socket:/run/user/1000/domterm/default.socket
Window 1:  qtwebengine: 5.12.8, chrome: 69.0.3497.128
  session#1: pid: 2421, tty: /dev/pts/0

The Chrome version I get looks much more recent than yours.

domterm --chrome has the same problem for me.

[PerBothner]

After starting domterm --qt, domterm --electron, and domterm --chome-app I get:

Window 1:  qtwebengine: 5.6.1, chrome: 45.0.2454.101
  session#1: pid: 30768, tty: /dev/pts/1
Window 2:  electron: 10.1.1, chrome: 85.0.4183.93
  session#2: pid: 30930, tty: /dev/pts/2
Window 3:  chrome: 87.0.4280.141
  session#3: pid: 31073, tty: /dev/pts/3

(The latest non-beta Electron is 11.2, which has Chromium 87.)

This is somewhat strange, as /usr/lib64/libQt5WebEngineCore.so links to libQt5WebEngineCore.so.5.15.2, which should be newer. Perhaps a packaging weirdness/bug in Fedora 33 - maybe due to security or licensing issues, or just lack of packager time.

Have you tried other front-ends?

[mcarans]

I don't have electron set up right now but if I do domterm --chrome and domterm--chrome-app, I get:

> domterm status
DomTerm version 2.9.0 (git describe: 2.1-367-g0e0c2a2)
Copyright 2021 Per Bothner and others
Using Libwebsockets 3.2.0
Reading settings from: /home/mcarans/.config/domterm/settings.ini
Backend pid:7451 command-socket:/run/user/1000/domterm/default.socket
Window 1:  qtwebengine: 5.12.8, chrome: 69.0.3497.128
  session#1: pid: 7498, tty: /dev/pts/0
Window 2:  chrome: 87.0.4280.141
  session#2: pid: 7761, tty: /dev/pts/1
Window 3: 
  disconnected .3
Window 4:  chrome: 87.0.4280.141
  session#4: pid: 8331, tty: /dev/pts/3

[PerBothner]

Is the problem also present on Chrome? What about Firefox? (You probably don't want to use a regular browser for your normal terminal, but --chrome-app is definitely usable, as is --webview (which uses WebKit from Apple via Gtk on Linux) when configured in.)

[mcarans]

Yes, the problem is also present on Chrome (87.0.4280.141) using --chrome-app. I've not tried electron or webview so far.