Several GUI and Window Management Issues When Running ResInsight in Linux XFCE Sessions

[RezaeiDoust]

Description

When running ResInsight in a Linux XFCE desktop session (instead of GNOME), multiple GUI-related issues occur that significantly impact usability. The same workflows behave as expected when ResInsight is launched in a GNOME session.

---

Part 1: Calculator Dialogs Become Non-Editable
Problem: Both the Grid Property Calculator and the Summary Calculator become non-editable when opened in an XFCE session.

Steps to Reproduce
1. Log in to Linux using an XFCE desktop session.
2. Start ResInsight.
3. Open either the Grid Property Calculator or Summary Calculator.
4. Attempt to create or modify a calculation.

Expected Behavior: All calculator fields should be editable, allowing users to create and modify expressions.
Actual Behavior: The calculator dialogs open, but the input fields cannot be edited.

---

Part 2: Window Focus Issues Prevent Returning to 3D View
Problem: Window focus and stacking behavior do not work correctly in XFCE.

Steps to Reproduce
1. Log in to Linux using an XFCE desktop session.
2. Start ResInsight.
3. Open a grid model and display it in a 3D View window.
4. Open a Summary Plot window.
5. Switch to the Summary Plot window.
6. Attempt to switch back to the 3D View window.

Expected Behavior: Users should be able to freely switch between Summary Plot windows and 3D View windows, with the selected window being brought to the foreground.

Actual Behavior: The most recently activated window remains on top, making it impossible to bring the 3D View window back to the foreground.

Additional Information
Both issues are reproducible in XFCE sessions.
The same workflows function correctly in GNOME sessions.
The issues appear to be related to GUI focus handling and window management under XFCE.

These problems make ResInsight difficult to use in XFCE environments and may indicate a desktop-environment compatibility issue.

[kriben]

Assessment by claude (fable). I have to test on XFCE first:

● I've dug through the window-management code. Here's my assessment of what can cause both parts of issue #14529.

  TL;DR

  Both symptoms trace to the same pattern: ResInsight shows/raises its windows with show() + raise() but (in the failing
  paths) never calls activateWindow(). On X11, raise() is just a client restack request that the window manager is free to
  ignore — and xfwm4 (XFCE), with its focus-stealing prevention, does ignore it unless the window is also explicitly activated
  via _NET_ACTIVE_WINDOW with a fresh user timestamp, which is what Qt's activateWindow() sends. GNOME's mutter is more
  permissive about client raise requests, which is why the same code works there.

  Part 2: Can't switch back to the 3D window — a concrete asymmetry in the code

  The two switching directions are implemented differently:

  - Switching to the Summary Plot window (RiaGuiApplication::getOrCreateAndShowMainPlotWindow(),
  RiaGuiApplication.cpp:1149-1150) does:
  m_mainPlotWindow->raise(); m_mainPlotWindow->activateWindow();
  - Switching back to the 3D window (RicShowMainWindowFeature::showMainWindow(), RicShowMainWindowFeature.cpp) does only:
  mainWnd->show(); mainWnd->raise(); — no activateWindow().

  That matches the reported behavior exactly: going to the plot window works, coming back does not, and "the most recently
  activated window remains on top." Under xfwm4 the plot window is the active window, so the 3D window's bare restack request
  is suppressed. The same missing-activation pattern also exists in RiaGuiApplication::onFileSuccessfullyLoaded()
  (RiaGuiApplication.cpp:1332,1337) and the snapshot paths (lines 909-922).

  Notably, the codebase already knows about this class of problem — RimSummaryPlotManager.cpp:548 has a comment: "If the dock
  widget is floating, activateWindow() must be called to make sure the top level widget has focus".

  Part 1: Non-editable calculator dialogs — same root cause, different symptom

  Both calculators are cached, non-modal QDialogs parented to a main window (RiuMainWindow::gridCalculatorDialog(),
  RiuMainWindow.cpp:2083-2090), shown with:

  dialog->show();
  dialog->raise();     // RicShowGridCalculatorFeature.cpp:57-58 and :101-102
                       // RicShowSummaryCurveCalculatorFeature.cpp:74-75

  Again no activateWindow(). If xfwm4 never grants the dialog keyboard focus (raised-but-inactive window, focus-stealing
  prevention blocking the implicit focus transfer — especially on re-show of the cached dialog, where Qt only remaps the
  window), the dialog is visible but all keystrokes still go to the main window. To the user that reads as "the input fields
  cannot be edited": no caret, typing does nothing. The fields themselves (caf::PdmUiTextEditor for the expression, etc.) are
  never set read-only in code — there is no code path that could disable them platform-dependently — which further points at
  focus delivery rather than widget state.

  A possible aggravating factor: the docking framework

  ResInsight uses Qt Advanced Docking System. On Linux/X11, for every window manager except KWin, ADS gives floating dock
  containers Qt::FramelessWindowHint with its own title bar
  (ThirdParty/qtadvanceddocking/src/FloatingDockContainer.cpp:660-683). Frameless windows sit outside xfwm4's normal
  focus/stacking management and are a known source of focus oddities on non-KDE/GNOME WMs. This matters if any dock widgets
  are floating and can be tested cheaply: ADS honors an ADS_UseNativeTitle=1 environment variable to force native decorations.

  What a fix would look like / what the user can try

  - Code fix: add activateWindow() after raise() in RicShowMainWindowFeature::showMainWindow(), both calculator show paths,
  and the onFileSuccessfullyLoaded() raises — mirroring what the plot-window path and RiaImportEclipseCaseTools.cpp:233
  already do. This is Qt's documented sequence for programmatic window activation and is what xfwm4 needs.
  - User-side workarounds to confirm the diagnosis: disable "Focus stealing prevention" (and check "Automatically raise
  windows when they receive focus") in XFCE's Window Manager Tweaks; and/or launch ResInsight with ADS_UseNativeTitle=1 to
  rule the docking framework in or out.

[magnesj]

how to start XFCE on RHEL8
select XFCE from the config dialog next to the Sign In button