Interesting idea, really why not?

+1 from me

But let's ask UX-team

I do have the maximize button in the title bar and double-click also maximizes the window. Probably just a flag to be set. But the distributed placement of controls is quite ugly on large screens. We should change the position to 'start' in order to keep it left aligned. Or just don't 'fill' the frame.

(In reply to Heiko Tietze from comment #2)
> I do have the maximize button in the title bar and double-click also
> maximizes the window. Probably just a flag to be set. But the distributed
> placement of controls is quite ugly on large screens. We should change the
> position to 'start' in order to keep it left aligned. Or just don't 'fill'
> the frame.

Heiko, in what Version on what OS do u have the maximize button?
On win10 26.2.0.3 and ubuntu 24.2.7.2 (both x64) i don't have it.

Currently: Version: 26.2.0.3 (X86_64) VCL: kf6 (cairo+xcb)

How exactly do you "open CSV" and what is the (English) title of the "appearing import dialogue"? Me runs Paste Special (shift+ctrl+V), picks "Use text import dialog", which brings up the "Text Import" dialog. Which has means to maximize on kf6, gtk3, and gen.

Created attachment 205682 [details]
Screenshot win10 csv-import dialogue

Confirming with

Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: da88bd54eba4bb3c5a588c211d0233a8eef77ffb
CPU threads: 16; OS: Windows 11 X86_64 (build 22000); UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded

However, we aim for non-resizable window as long the dialog contains no user input with indefinite user input. You may argue that the Fields table could have many columns that require adjustment and scrolling is odd. The dialog can be resized but offers no maximize/minimize buttons.

Michael, what do you think?

Created attachment 205757 [details]
Screenshot of patched csv-import dialogue

Proof of Concept & Question regarding scope

I investigated the Windows VCL backend (vcl/win/window/salframe.cxx). The issue is caused by an explicit check in SalFrame::UpdateStyle that suppresses the WS_MAXIMIZEBOX style for child windows (!hWndParent), even if they are flagged as SIZEABLE.

Observation regarding Window Managers:
I noted that on permissive Window Managers (like KWin on Linux), these dialogs already have a maximize button. This proves that LibreOffice Core logically supports maximizing these dialogs, and that the restriction was artificially enforced by the Windows VCL backend.

My Test:
As a proof of concept, I removed this Windows-specific restriction locally.
Result: The maximize button now appears on Windows. The dialog remains correctly modal, but the UI is now consistent with the SIZEABLE flag.

Code Change for the attached screenshot:

```
diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index 603c57048544..a551e4b09926 100644
--- a/vcl/win/window/salframe.cxx
+++ b/vcl/win/window/salframe.cxx
@@ -372,9 +372,7 @@ SalFrame* ImplSalCreateFrame( WinSalInstance* pInst,
             if ( nSalFrameStyle & SalFrameStyleFlags::SIZEABLE )
             {
                 pFrame->mbSizeBorder = true;
-                nSysStyle |= WS_THICKFRAME;
-                if ( !hWndParent )
-                    nSysStyle |= WS_MAXIMIZEBOX;
+                nSysStyle |= (WS_THICKFRAME | WS_MAXIMIZEBOX);
             }
             else
                 pFrame->mbFixBorder = true;
```
My Question:
This change enables the maximize button for all resizable dialogs on Windows (aligning with behavior on KWin/X11).
Is this generally acceptable, or should I implement a stricter check (e.g. relying on an explicit .ui property) to avoid affecting dialogs that are implicitly resizable but shouldn't be maximized?

I'd appreciate some guidance on how to proceed with this.

(In reply to toro from comment #8)
> This change enables the maximize button for all resizable dialogs on Windows
> (aligning with behavior on KWin/X11).

As a Linux user I have no hard feelings to show min/max buttons on dialog. But the SizableToolWindow has probably by design no minimize/maximize button to keep the titlebar simple/small. The save dialog might serve as an example. However, double-clicking the header still maximizes the window - and we should make at least this happen. 

Michael, Caolan: What do you think?

(In reply to Heiko Tietze from comment #9)
> As a Linux user I have no hard feelings to show min/max buttons on dialog.
> But the SizableToolWindow has probably by design no minimize/maximize button
> to keep the titlebar simple/small. The save dialog might serve as an
> example.

I don't have any strong feelings either, seems like a case for a UX/design team decision.
As was mentioned in comment 8 already, the maximize button shows up for resizable dialogs when using KDE Plasma/KWin and I don't see any reason to prevent maximizing a window when it's resizable anyway, but I don't know what Windows design guidelines are here.

As you mention, the native Windows file dialog also doesn't show a maximize button, also when triggered from other applications.

> However, double-clicking the header still maximizes the window -
> and we should make at least this happen.

Sounds like a potential good solution to me if adding the maximize button is not desirable.

@Reporter: What do you think?

(In reply to Michael Weghorn from comment #10)
> (In reply to Heiko Tietze from comment #9)
> > But the SizableToolWindow has probably by design no minimize/maximize button
> > to keep the titlebar simple/small. The save dialog might serve as an
> > example.
> 
> As you mention, the native Windows file dialog also doesn't show a maximize
> button, also when triggered from other applications.

I see the comparison, but I would argue the use case differs significantly. A "File Open" dialog is transient (search, click, gone). The CSV Import dialog, however, is often a data-heavy workspace where users need to verify column separation across many rows and wide tables. Hiding the maximize capability here decreases discoverability for a feature that is functionally necessary, not just cosmetic.
 
> > However, double-clicking the header still maximizes the window -
> > and we should make at least this happen.
> 
> Sounds like a potential good solution to me if adding the maximize button is
> not desirable.

I investigated implementing this "double-click without button" approach, but:

In `salframe.cxx` (ImplSalCreateFrame), VCL actively enforces that windows without a maximize button also lose the maximize functionality in the system menu:

    if ( !(nSysStyle & WS_MAXIMIZEBOX) )
        DeleteMenu( hSysMenu, SC_MAXIMIZE, MF_BYCOMMAND );

This line removes the `SC_MAXIMIZE` command if the button style is missing. This effectively kills the double-click behavior and the context menu entry.
To support "double-click without button", we would have to modify this menu-deletion logic as well.

> @Reporter: What do you think?

Given the above, enabling "double-click only" would require a deeper and riskier change to the generic VCL menu logic. 
In contrast, simply allowing the button (via the one-liner proposed) is technically clean, low-risk, and provides better UX affordance. Since KWin/Linux already shows the button safely, I prefer enabling the button on Windows as well, by the patch above.

(In reply to toro from comment #11)
> I prefer enabling the button on Windows as well, by the patch above.

Well elaborated consideration, no need to find agreement. Do you need help with submitting the patch? https://wiki.documentfoundation.org/Development/gerrit

(In reply to Heiko Tietze from comment #12)
> Do you need help with submitting the patch?
Thanks for the link! I think I just managed to push it to Gerrit myself (after fighting a bit with SSH and Cygwin).

Here is the change: https://gerrit.libreoffice.org/c/core/+/200343
all correct?

Thomas Rogenmoser committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a426e2f92650497a59e246695521f58122adcdb6

tdf#141381 vcl: enable maximize button for resizable dialogs on win

It will be available in 26.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Thomas: if this is done, feel free to close as fixed.