refactor: how UI elements are disabled at startup

The default-frame-alist properties are only necessary for the scrollbar.
The variables are enough for the rest. Also, no need to set
x-gtk-use-symtem-tooltips if we're turning off tooltips anyway.

Also moves the UI config that snuck its way into doom-start back to
doom-ui.

lisp/doom-start.el

@@ -106,21 +106,7 @@
   (setq selection-coding-system 'utf-8))
 
 
-;;; User interface
+;;; Support for more file extensions
-;; GUIs are inconsistent across systems, will rarely match our active Emacs
-;; theme, and impose their shortcut key paradigms suddenly. Let's just avoid
-;; them altogether and have Emacs handle the prompting.
-(setq use-dialog-box nil)
-(when (bound-and-true-p tooltip-mode)
-  (tooltip-mode -1))
-(eval-when! IS-LINUX
-  (setq x-gtk-use-system-tooltips nil))
-
-;; Favor vertical splits over horizontal ones, since monitors are trending
-;; toward wide rather than tall.
-(setq split-width-threshold 160
-      split-height-threshold nil)
-
 ;; Add support for additional file extensions.
 (dolist (entry '(("/\\.doom\\(?:rc\\|project\\|module\\|profile\\)\\'" . emacs-lisp-mode)
                  ("/LICENSE\\'" . text-mode)

lisp/doom-ui.el

@@ -263,16 +263,19 @@ windows, switch to `doom-fallback-buffer'. Otherwise, delegate to original
 ;; HACK: I intentionally avoid calling `menu-bar-mode', `tool-bar-mode', and
 ;;   `scroll-bar-mode' because they do extra work to manipulate frame variables
 ;;   that isn't necessary this early in the startup process.
-(push '(menu-bar-lines . 0)   default-frame-alist)
+(setq scroll-bar-mode nil
-(push '(tool-bar-lines . 0)   default-frame-alist)
-(push '(vertical-scroll-bars) default-frame-alist)
-;; And set these to nil so users don't have to toggle the modes twice to
-;; reactivate them.
-(setq menu-bar-mode nil
       tool-bar-mode nil
-      scroll-bar-mode nil)
+      ;; Disabling `menu-bar-mode' causes focus issues on MacOS. The :os macos
-;; Note, that disabling `menu-bar-mode' can cause issues on MacOS. See the
+      ;; module has a fix for this.
-;; :os macos module for a fix.
+      menu-bar-mode nil)
+;; Setting `scroll-bar-mode' isn't enough to disable them, so:
+(push '(vertical-scroll-bars) default-frame-alist)
+
+;; UX: GUIs are inconsistent across systems, desktop environments, and themes,
+;;   and don't match the look of Emacs. They also impose inconsistent shortcut
+;;   key paradigms. I'd rather Emacs be responsible for prompting.
+(setq use-dialog-box nil
+      tooltip-mode nil)
 
 ;; FIX: The native border "consumes" a pixel of the fringe on righter-most
 ;;   splits, `window-divider' does not. Available since Emacs 25.1.
@@ -281,15 +284,6 @@ windows, switch to `doom-fallback-buffer'. Otherwise, delegate to original
       window-divider-default-right-width 1)
 (add-hook 'doom-init-ui-hook #'window-divider-mode)
 
-;; GUIs are inconsistent across systems and themes (and will rarely match our
-;; active Emacs theme). They impose inconsistent shortcut key paradigms too.
-;; It's best to avoid them altogether and have Emacs handle the prompting.
-(setq use-dialog-box nil)
-(when (bound-and-true-p tooltip-mode)
-  (tooltip-mode -1))
-(when IS-LINUX
-  (setq x-gtk-use-system-tooltips nil))
-
 ;; UX: Favor vertical splits over horizontal ones. Monitors are trending toward
 ;;   wide, rather than tall.
 (setq split-width-threshold 160