.NETpad 2025: Finalizing the Tabs Layout (Premium)

After weeks of experimentation, I've finally arrived at what I feel is an acceptable compromise for tab overflow in .NETpad. This compromise is the result of limitations in WPF, in particular the TabControl control I will rely on, and probably my limitations as an enthusiast developer, too. But I think it's in keeping with the spirit of previous versions of this app. You go to war with the army you have, as they say.

This isn't the biggest technical hurdle in bringing tabs to .NETpad. But it's been looming over me since the beginning, by which I mean the May 2024 announcement that Microsoft was bringing WPF back from the dead. That inspired me to start my .NETpad modernization effort, which I eventually split into two parts, the work I did last year that resulted in .NETpad 3.0 for Windows 11, and the work I'm doing this year in this series.

I have more time for the work I'm doing this year, and I'm going to need it. Adding tabs is difficult, and in working up the backend tab management capabilities, I've repeatedly reached the limitations of my brain capacity in ways that are both fascinating and disturbing to me. My limitations as a developer also play a role, and I feel like there are more sophisticated ways to do what I'm doing. But in the good news department, I have pretty much figured that out. I have the foundation I need to support multiple tabs and their associated documents and state. I could make this happen (and will).

But before I can do that, I had to solve some basic layout issues. I've touched on this several times, I think, but most recently in .NETpad 2025: Thinking About Layout (Premium), where I explained how Notepad handles this and why the limitations in WPF will make duplicating that pretty much impossible. And I discussed some of my work trying to get a tabbed-based .NETpad as close as possible to .NETpad visually and functionally. Since then, I think I've arrived at that place.

As noted, it's a compromise.

The top of the .NETpad main app window--which is a Row in a WPF Grid--consists of several controls from the left to right. They are:

App icon
TabControl (with one or more TabItem controls)
Add new tab button
Some amount of empty space (not a control, though it could be)
Minimize window button
Maximize/Restore window button
Close window button

Something like this.

The user can take actions--like resizing the app window and adding/removing tabs--that impact the layout. But all of those top level controls need to be visible at all times. So the minimum width of the app window needs to accommodate all those controls, including some minimum number of TabItems. Three or four, perhaps.

Aside from the TabControl (and the blank space), each of the controls noted above is a fixed width. Achieving that layout with XAML, the XML-based user interface language in WPF, is easy enough. But if I use a TabControl in that top Grid row and keep adding TabItems, it will grow...