Ghidra dark theme and UI: build a readable analysis workspace

A reverse engineering workspace needs to support long reading sessions and rapid movement between evidence. Dark colors alone do not solve that problem. The useful question is whether you can distinguish selection from highlights, read a long expression without losing its type, and move from a call to its caller without reorganizing the desktop.

Start with an existing supported theme, then change the smallest number of settings necessary for your display and workflow. Keep a reproducible record of those choices. Opcodex’s design direction includes a cleaner interface around Ghidra’s engine, but this article describes a workspace method you can use today in Ghidra. It does not claim that an Opcodex desktop theme package has already shipped.

Use the application’s theme system

The upstream theme implementation uses named identifiers for colors, fonts, and icons. Modules can define defaults in *.theme.properties files. This indirection allows a theme to change a value without a source edit, as described by the official ThemeManager API documentation.

For normal workspace customization, use the application’s theme controls instead of editing arbitrary Java code or replacing assets in an installation. Keep a copy of an exported custom theme, if you create one. Do not assume that a theme identifier found on the internet exists in every release. Check it against your installed version before depending on it.

Define a visual acceptance test

Before changing colors, open a representative function with a few parameters, a loop, a call, and a conditional branch. Include a table and a dialog in your check. A theme that looks excellent in a screenshot of the Decompiler may have unreadable disabled buttons or selected table rows.

Use this short test after every substantial change:

• Ordinary text is readable against the primary background.
• Selection, search results, and persistent highlights remain distinguishable.
• Focus is visible when navigating by keyboard.
• A warning is understandable without relying on color alone.
• Table headers, inactive tabs, and disabled controls are legible.
• Dialogs do not switch to an unexpected low-contrast palette.
• Text still fits after a font-size increase.

Test the actual display you use for work. Bright ambient light, a low-quality external screen, and display scaling can turn a pleasing palette into a tiring one. Capture both normal and selected states when sharing feedback; static unselected text is the easiest state to get right.

Choose type for evidence, not decoration

A code font should distinguish 0 from O, 1 from l, and punctuation such as braces, brackets, and parentheses. Review real addresses and expressions at your intended font size. Do not select a font solely from a large promotional specimen.

Keep text scaling and row density separate. Smaller fonts may display more functions, but if reading an address requires leaning forward, the density gain is illusory. Increase the main reading font until it is comfortable, then remove low-value panes to recover space. A readable workspace with fewer simultaneously visible tools is often more useful than an unreadable dashboard containing everything.

Avoid assuming every colleague has your font installed. If you distribute a theme, document the preferred font and a reasonable system fallback. Check redistribution terms before shipping a font file with an application or repository. Merely being freely downloadable does not establish a redistribution license.

Build two task layouts

For navigation, favor a stable relationship between the Listing and Decompiler. Put the symbol or function list near them and keep a small output area available for errors. Avoid placing the main code view on a floating window that disappears behind the project manager every time you switch tasks.

For type recovery, give the data type tools and references more room. You are comparing offsets, callers, and field uses, so a giant call graph may be less useful than an extra table. The right layout is determined by the question being answered rather than by a universal screenshot.

Write the layout intent in a tiny configuration note:

navigation:
  primary: listing + decompiler
  secondary: functions + references
  temporary: console

type-recovery:
  primary: decompiler + structure editor
  secondary: callers + data type manager

This is a descriptive note, not an importable Ghidra configuration file. Its value is that you can reconstruct the workspace even if a release changes how layout preferences are stored.

Reduce toolbar and menu friction carefully

Track which operations you repeat during a real session: following references, changing a signature, navigating back, adding a comment, or opening a tool window. Learn or assign shortcuts through the supported application controls. Check for conflicts and keep a short personal reference nearby.

Do not remove an unfamiliar action because its label looks technical. It may be important for another architecture or project workflow. If you are designing a shared default, hide complexity progressively and preserve discoverability through menus and help. A solo developer’s daily workflow should inform defaults without becoming the only workflow the product permits.

For extension authors, keep visual changes inside documented theme and docking mechanisms where possible. Core patches create more maintenance work and may behave differently on supported platforms. Opcodex’s architecture documentation describes the principle of retaining the upstream engine and preferring extensions for added behavior.

Check keyboard and window behavior

Run a short task using only the keyboard. Open the program, reach a function, follow a reference, return, and save. Note any focus trap or control whose state is only apparent when a pointer hovers over it. Theme work should improve these states rather than treat them as secondary details.

Move the application between displays with different scaling. Open a dialog near the edge of the screen and confirm it remains reachable. Save and reopen a workspace copy to check whether its layout remains usable. Record your operating system and scaling values when reporting a problem because window behavior can depend on that environment.

Keep visual changes separate from analysis changes

When evaluating a theme, use a known program database and avoid renaming or retyping at the same time. Otherwise, improved output may be mistaken for a visual improvement, or a new type error may be blamed on the theme. A controlled comparison makes feedback actionable.

If the code is still confusing after the workspace becomes readable, use the decompiler model checklist. To understand which Opcodex customization is available versus planned, consult theming and the changelog. A good interface makes evidence easier to inspect; it never makes an unverified interpretation true.