The TopPanel and BottomPanel of ConsoleWindowSystem reserve space even when hidden ?

[changlv]

The TopPanel and BottomPanel of ConsoleWindowSystem reserve space even when hidden ?

Could we make them release the occupied space when they are not visible?

After all, every line of display space is valuable for a terminal UI.

Happy coding! Haha~

[nickprotop]

@changlv Good question — I went and checked the code, and there are two separate things here, so let me split them:

The top/bottom status bars already do what you're asking. When a bar isn't visible, it reserves zero rows — the space is genuinely reclaimed, not blanked. The height is literally Visible ? 1 : 0, and the desktop area is computed from that, so a hidden top/bottom bar gives its row back to your windows/desktop. So if you hide a bar, you should already be getting that line back. (If you're seeing otherwise, that's a bug and I'd love a repro.)

What I suspect you're actually seeing is a borderless window's frame. A window created with .Borderless() (or .HideTitle()) does not reclaim the border/title rows — it draws spaces there instead of border characters. So a borderless window still has a 1-cell invisible margin on all four sides, and content still starts one row down. That's intentional: BorderStyle.None means "invisible border," not "no border / zero margin" — the layout dimensions are deliberately unchanged.

And honestly, that's a behavior I lean toward keeping — I actually like a borderless window having a bit of breathing room around its content rather than slamming text right up against the screen/desktop edge. So I'm hesitant to remove that margin outright.

So before I change anything: which one are you seeing? Is it

• a hidden status bar that still seems to eat a row (→ bug, send a repro), or
• a .Borderless() / .HideTitle() window where you want the frame space reclaimed for content?

If it's the second, I'm open to it as an opt-in (a true zero-inset borderless mode), leaving today's bordered-with-margin behavior as the default. Let me know what you're after.

[changlv]

@nickprotop After confirmation, the issue is related to the borders of the Window component(not ConsoleWindowSystem).

If possible, I would like to have a truly borderless Window component that can fully fill the terminal.

Margin and Padding properties should be used to handle spacing around boundaries.

In my opinion, this will be especially beneficial for single-window applications.

A genuine borderless design also optimizes multi-layer layouts, as it eliminates wasted border padding when multiple controls are stacked.

[changlv]

@nickprotop Also, PanelControl isn't what I expected. I thought it was a non-scrollable container.

[nickprotop]

@changlv Confirmed it's the Window border, not the panels — and a truly borderless Window that fills the terminal makes sense, especially for single-window apps. I'll build it.

The plan: borderless = fully chrome-less. No border means no interactive frame — no title bar, no drag-to-move, no resize, no buttons. It just fills its rect and shows content. That's the clean fit for a single-window app.

It'll also support padding, so you can stay borderless but keep a little space around the content if you want (which I like too) — no padding = fills the whole rect, add padding for breathing room. Default will be no padding (true fill).

---

On PanelControl — you're right it's not scrollable, but it's also not a container: it's just a box around markup text, one content control.

What you're after already exists — CollapsiblePanel with .NonCollapsible(). That's a plain, non-scrollable container locked open, and it stacks its child controls vertically (each full width, in the order you add them). Add .HideHeader() and it's just a box around whatever controls you put in it:

Controls.CollapsiblePanel()
    .NonCollapsible()
    .HideHeader()
    .AddControl(controlA)   // stacked
    .AddControl(controlB)   // below A
    .Build();

So you don't need a horizontal grid with one column — it stacks vertically on its own. (If you ever want it to scroll, give it a MaxContentHeight or wrap it in a ScrollablePanel.) Does that match what you expected PanelControl to be?

[changlv]

@nickprotop Thanks for your explanation. CollapsiblePanel matches my expectations perfectly. Happy coding!

[nickprotop]

@changlv This is done and on master now — a new BorderStyle.Frameless.

A frameless window fills the entire terminal with no border and no chrome — no title bar, no drag handle, no resize edges, no buttons. Content starts at the very top-left cell; nothing is reserved. It's the single-window-app case you described:

new WindowBuilder(windowSystem)
    .Frameless()
    .Maximized()        // fills the whole desktop, content edge-to-edge
    .AddControl(myContent)
    .BuildAndShow();

And the padding you asked about — borderless but with a little space around the content — is opt-in:

.Frameless().WithPadding(1)     // 1-cell margin all around
// or per-side: .WithPadding(new Padding(left, top, right, bottom))

A few notes:

• It's distinct from .Borderless() / BorderStyle.None, which keeps the invisible 1-cell frame (content still starts one cell in) and stays interactive. Frameless reclaims the frame entirely.
• Since there's no frame to grab, a frameless window isn't mouse-draggable/resizable, but you can still move/resize it in code (SetPosition / SetSize) or from your own key bindings. (No close button either, so handle ESC yourself if you want it closable.)
• A scrollable frameless window keeps its scrollbar — it reserves the last content column for it so it never overlaps your text.

There's a short write-up in the new docs/WINDOWS.md, and the DemoApp "Border Styles" page now has a Frameless button to try it live.

Whenever you get a chance, could you build from master and confirm it does what you had in mind? Happy to adjust if the behavior or the API names aren't quite what you expected. Thanks for the suggestion — it's a genuinely nice addition.

[changlv]

@nickprotop We could borrow the naming convention from Android: Hidden (reserves layout space), Gone (completely removes the element with no reserved space).
Happy coding!

[nickprotop]

@changlv That's a sharp analogy — BorderStyle.None vs BorderStyle.Frameless really is the same Hidden vs. Gone split: None keeps the frame's space (invisible but reserved), Frameless removes it entirely (reclaimed). The Android naming captures that distinction well.

I could add Hidden/Gone as additive aliases (non-breaking — None is already shipped API I won't rename). But I'd lean against it: it'd leave two enum values that mean the same thing, which tends to confuse more than it helps — people end up unsure which to reach for. So I'll keep the single pair None/Frameless. The model you're describing is spot-on, though — thanks for the framing. Happy coding!

[changlv]

@nickprotop Let's skip using aliases; keeping things concise is important.

Additionally, I suggest renaming BorderStyle.Frameless to BorderStyle.Gone. The term Frameless reminds me of the Window.Borderless() method, but the behavior of Borderless is not equivalent to Gone — it merely acts as Hidden.

[nickprotop]

@changlv On the rename — honestly, this is partly taste, and I should own that. Frameless just reads naturally to me; I come from a Delphi VCL / WinUI / Win32 background, so "a window with no frame" is the obvious phrasing in my head, and Gone isn't a word I reach for. You might genuinely be right, though — the Android Hidden/Gone vocabulary is second nature to a lot of developers now, and that's a real audience. So it's less "you're wrong" and more "we're coming at the name from different traditions." I'm inclined to keep Frameless because it's the one that feels clear to me, and a name I'm comfortable explaining is worth something.

Here's the question I'd put back to you, though: is the two-word split even worth it? We've got Borderless/None (invisible frame, space reserved — your "Hidden") and Frameless (frame fully reclaimed — your "Gone"). Whatever we name them, is having two distinct border concepts clear to you as a user, or is the distinction itself the confusing part? If the two-concept model earns its keep, the names are a detail; if it doesn't, that's the thing worth fixing. Curious how it lands for you.

[changlv]

@nickprotop

The main concern is that developers might easily mistake Window.Borderless() == BorderStyle.Frameless.

or get confused about the behavioral differences between Window.Borderless() and Window.Frameless().

This only needs to be noted in the XML summary comments though; it’s not a critical problem.

[nickprotop]

Done — added <remarks> XML doc comments to both builder methods in WindowBuilder.cs, cross-referencing each other so IntelliSense surfaces the distinction at the call site:

• Borderless() now documents that it maps to BorderStyle.None, keeps the 1-cell frame reserved-but-invisible, does not reclaim the space, and points to Frameless() for that.
• Frameless() now documents that, unlike Borderless()/None, it reclaims the frame space so content fills the whole window rect.

On master (commit 32077e7). Thanks for the suggestion.