better dark mode styling

[PerBothner]

The current dark mode styling is a little garish, plus it doesn't set the styling for headers/titlebars or menus.

Discussion moved from issue #113.

[PerBothner]

Selecting a dark mode for the GoldenLayout headers and also the menus is probably the highest priority.. There is a dark style available for GoldenLayout, but I have to figure out the best way to enable that.

I think I'd like the default dark colors to have a little more color than your screenshot, though I agree the current colors are bit on the garish side. Complicating things is we need suitable default background colors for "shell integration": prompt, input line, input text. If you want to experiment, try one of the suggested scripts here for Bash, Zsh, or Fish. Prompt, input line, input text should al look different. Prompt and input text backgrounds should provide good contrast with white/light text. Input line and input text backgrounds should be visibly different, but in a more subtle way: Probably a similar color, but the input text background should be a bit darker to provide contrast with text.

The pink outline around the window is probably the wrong color, but I think it is useful to have a frame to mark the border, especially if on top of another window with the same background color. I think it i also useful to have two colors: one when the window is focused and one when it is not. This combines with sub-windows (tiles), for examp;e after a "New Terminal Below" menu command: We want to make it clear which tab is active and which window is focused.

We also need to pick a color for the cursor when it is veritcal bar, and suitable outline and cursor for edit and view modes.

Note the patterned background is only for line "below" the bottom line. Actual output will always be on a plain black or dark gray background. I kind-of like the patterned background for "below the bottom line" but it should probably be more subtle (both for dark and light mode)

So it's a lot more complicated than "make the background completely black or grey" ...

[mcarans]

Could things like whether there is a patterned background below the bottom line or an outline around the window be configurable?

It may be helpful to look at how dark mode is implemented in other terminals eg.
https://code2care.org/macos/turn-dark-mode-on-off-mac-using-terminal-command/images/Toggle%20Dark%20mode%20on%20off%20using%20Mac%20Terminal%20Command.gif
https://cdn.osxdaily.com/wp-content/uploads/2013/02/better-terminal-ui.jpg
https://www.thomasmaurer.ch/wp-content/uploads/2019/09/Cascadia-Code-in-Windows-Terminal-768x409.webp
https://preview.redd.it/66y66eyr1vbz.png?auto=webp&s=9d6a8e8a21f1f7076939d7c017432cad16989bec

[PerBothner]

"Could things like whether there is a patterned background below the bottom line or an outline around the window be configurable?"

Absolutely. And hopefully without having to understand CSS syntax or know the DomTerm Node hierarchy (which might change). Though in the short term you will probably have to use CSS.

Do note that DomTerm is much more than just a terminal. It support graphics and rich text. It is meant to be suitable for rich REPL interfaces, including "shell integration". You will in the future be able to use variable-width fonts in command-linea (which you really want if you want to support grapheme clusters). So comparing how other terminal do things only goes so far. I also (for example) have to consider how web browsers do it.

I think "the way dark is implemented" in DomTerm is actually pretty good. You can easily set your preference in the settings.ini file or the command line. The default is based on your system theme. You can change your preferences on the fly withe the dommterm settings command - you can even have a window with some tiles in dark mode and some tiles light mode. You can relatively easily tweak specific preferences using CSS - though that isn't ideal, of course.

I'm working on dark mode for the GoldenLayout headers, based on a stylesheet from upstream. Conceptually it seems to be working well. The problem is deciding which colors to use where. Juggling multiple css files (form upstream and domterm-specific) adds an extra complication. Also, fixing headers probably doesn't make sense unless I do menus at the same time.

[PerBothner]

I checked in a bunch of changes to dark mode, including headers, goldenlayout manager, menus, scrollbars.

Still considering some header/tab changes, window borders/outlines, colors, and more.

[mcarans]

@PerBothner That looks a lot better! Is the colour of the outline of the window and tab text configurable? I'd like to change it from pink. Also the menu bar appears as black on white for me.

I found that trying to create a "New terminal tab" doesn't work.

[PerBothner]

I'm looking into changes relating to the pane and window outlines.

I believe the menubar appears black on white because you're using titlebar=system, which means you also get the system (toolkit) menubar. It might be possible to fix this with toolkit-specific code, but it's not a priority. Note there is a well-known bug in Chrome on Gnome that it doesn't pick up the system dark-mode setting - that seems to also affect Qt and Electron.

Maybe try titlebar=domterm? I'm hoping you'll find it more pleasant than before.

[PerBothner]

"New terminal tab" should work now. Also "New terminal below" etc, which was similarly broken. This was a problem specific to using titlebar-system with -Bqt-widgets. I removed some no-longer-desirable Qt-specific code and that fixed it. (I had recently done something similar for other commands, but overlooked these commands.)

[mcarans]

@PerBothner The reason I use titlebar=system is because of the issue I mentioned before. With titlebar=domterm when I right click and copy text, the focus is lost so that I can no longer move the cursor with the arrow keys. With titlebar=system, it works as it should. Do you know what could be the problem?

[PerBothner]

I haven't been able to recreate the outline in the menusbar (as seen in your screenshot here) - except once accidentally.
However, I am seeing some problems with copy not working when using iframes or subwindows - and focus being lost.
By default the first pane does not use an iframe. (Except with -Bqt/-Bqt-widgets, where all panes use a separate sub-window.)
It seems to works for the initial pane for all other front-ends, including -Bqt-frames - but only the initial pane. (Except -Bwry, which uses WebKit, seems to work for all panes.)

So the loss of focus may be related to context-switching between the inferior frame and the top window..

[PerBothner]

The problem seems to the maybeFocus call in the popupMenu function in hlib/domterm-menus.js. The intention is to focus the window you click in, if needed. However, the logic doesn't work (any more) for complicated reasons. Trying to figure out the best way to fix it.

[mcarans]

@PerBothner -Bqt-frames works ok for me. -Bqt-frames turns the outline of the window from pink to orange when I select text and it remains orange as long as any text is selected (even if I am no longer pressing any mouse buttons).

[PerBothner]

I've spent some time on menus and how they interact with menus. It was somewhat tricky, but I think it works reasonably well. There are still some awkardness when using -Bqt (-Bqt-widgets) though -Bqt-frames seems pretty solid in this respect.

I think I fixed the orange outline on selection - let me know.

I'm still looking at window and pane borders. I have a prototype, but it still needs some tweaking.

[mcarans]

Yes, that has fixed the orange outline with -Bqt-frames. -Bqt still has the issue that the arrow keys don't move the cursor after selecting and copying text withe the mouse (even though there is no pink outline around the menu any more).

[mcarans]

A small improvement is that the focus could be returned to the previously active terminal window after clicking on the title bar. Currently if you drag the DomTerm window and let go, the focus stays in the title bar rather than returning to the terminal window (so that if you type the output doesn't appear anywhere).