{{ message }}
Repository navigation
better dark mode styling #114
Description
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.
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.
Activity
PerBothner commentedon Aug 24, 2022
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 commentedon Aug 24, 2022
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 commentedon Aug 24, 2022
"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 settingscommand - 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 commentedon Aug 27, 2022
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 commentedon Aug 27, 2022
@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 commentedon Aug 27, 2022
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 commentedon Aug 27, 2022
"New terminal tab" should work now. Also "New terminal below" etc, which was similarly broken. This was a problem specific to using
titlebar-systemwith-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 commentedon Aug 28, 2022
@PerBothner The reason I use
titlebar=systemis because of the issue I mentioned before. Withtitlebar=domtermwhen I right click and copy text, the focus is lost so that I can no longer move the cursor with the arrow keys. Withtitlebar=system, it works as it should. Do you know what could be the problem?PerBothner commentedon Aug 28, 2022
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 commentedon Aug 28, 2022
The problem seems to the
maybeFocuscall in thepopupMenufunction inhlib/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 commentedon Aug 28, 2022
@PerBothner
-Bqt-framesworks ok for me.-Bqt-framesturns 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 commentedon Aug 31, 2022
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-framesseems 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 commentedon Sep 1, 2022
Yes, that has fixed the orange outline with
-Bqt-frames.-Bqtstill 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 commentedon Sep 1, 2022
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).
PerBothner commentedon Sep 1, 2022
-Bqtstill has the issue that the arrow keys don't move the cursor after selecting and copying text withe the mouseI checked in a fix for this. That one was simple.
mcarans commentedon Sep 1, 2022
I can confirm it works. Thanks a lot!
A bug I found is when I click the menu item "About DomTerm", I am not able to close the about window.
If I run
domterm --help, how do I exit the help?PerBothner commentedon Sep 2, 2022
"A bug I found is when I click the menu item "About DomTerm", I am not able to close the about window."
Should be working now. Note that clicking the link doesn't work, but that is a separate issue (specific to
-Bqt), which I'll look into.Not being able to exit
domterm -helpis another focus-related issue - this time not-Bqt-specific. You can exit it with the Escape key - but you need to focus (click) the window first. (Needing to click is of course a bug.)mcarans commentedon Sep 3, 2022
I can confirm closing About DomTerm works.
PerBothner commentedon Sep 3, 2022
domterm help(ordomterm --help) should now also focus so keyboard actions work. Auto-paging also works. (There are some issues with paging, especially with html help files, but they will have to wait.)Opening links should also work better.
Still looking at focus issues clicking the titlebar. The problem you're seeing is easily fixable (remove the
if (DomTerm.focusedWindowItem)code in_handleLayoutClick) but that causes other problems. (The code is there for a reason ...)mcarans commentedon Sep 4, 2022
The fix for focus for
domterm --helpdidn't work for me. I still have to click in the terminal after running the command to be able to exit with Escape.PerBothner commentedon Sep 12, 2022
I checked in a fix for focus being lost on
domterm --help.I'm working on another qt-widgets-specific focus annoyance: Clicking in the titlebar doen't give focus to the curent pane.
mcarans commentedon Sep 12, 2022
Great thanks a lot! I can confirm domterm --help doesn't lose focus (I can exit with Escape without clicking first)