Something in 1.13 broke centering child windows

[dodexahedron]

Describe the bug On 1.12.1, a child window added to another window at run-time, with X and Y set to Dim.Center() is displayed in the center of the parent Window that it is added to.

In 1.13.x, the child window is placed at 0,0 when shown. This occurs on Ubuntu 23.04 and on Windows 11 in PowerShell. If the terminal is resized down and then to a size larger than the child window, it then centers itself.

I set a breakpoint to see what was going on.

In 1.13.x, the superview of the child has 0 width and height, even though the parent Window itself has the expected dimensions. In 1.12.x, the superview of the child has the expected dimensions of the parent window.

Note that both of these Windows were created using the TerminalGuiDesigner tool.

The code used to add the child to the parent is just three lines (edited for verbosity):

//Elsewhere in the parent window class:
ChildWindowClass _childWindowAsAFieldBelongingToParentWindow = null;

//Function called by any means to create and show the child for the first time:
public void FunctionThatAddsTheChildWindow()
{
        _childWindowAsAFieldBelongingToParentWindow ??= new( );
        Add( _childWindowAsAFieldBelongingToParentWindow );
        ShowChild( _childWindowAsAFieldBelongingToParentWindow );
}

To Reproduce Steps to reproduce the behavior:

Using 1.13.X (seems broken for any version of 1.13):

1. Create a Window with width and height = Dim.Fill(0)
2. Create a Window with explicit dimensions (any will do, so long as they're smaller than the terminal), and with X and Y = Dim.Center().
3. Add that second Window to the first Window, and show it.
4. The child window will be at 0,0,

Expected behavior The child window should be shown positioned at the center of the parent window it was added to, as in 1.12.

Desktop (please complete the following information):

• OS: Windows 11 and Ubuntu 23.04
• Terminal: Happens on any terminal emulator or shell I've tried, including just at a bash prompt, tmux, screen, and zsh.

Started happening after updating to the 1.13 release series. No code changes were made.

[dodexahedron]

I've also tried explicitly calling SetNeedsDisplay on both the parent and child windows, as well as manually changing the X and Y of the child window after it is shown. These have no effect, and the direct superview of the child window still shows dimensions of 0x0, while the parent window itself shows dimensions of 153x57.

However, interestingly enough, dragging the child window with the mouse does still allow it to be repositioned at will.

[dodexahedron]

This is the commit that broke it: 58ad65f34800a87a9223cf24711d50db6eefcbe7

[dodexahedron]

After further experimentation, a call to LayoutSubviews() on the parent window does seem to force the child to center, but this doesn't seem like it should be necessary right after a call to ShowChild

[tig]

This is the commit that broke it: 58ad65f

@BDisp I think we should revert https://github.com/gui-cs/Terminal.Gui/issues/2686. I accepted that PR against my better judgement ... we should not be taking fixes like that into v1, if there's a workaround. Agree?

[BDisp]

Using 1.13.X (seems broken for any version of 1.13):

1. Create a Window with width and height = Dim.Fill(0)

It's enough Dim.Fill().

2. Create a Window with explicit dimensions (any will do, so long as they're smaller than the terminal), and with X and Y = Dim.Center().

Must be X and Y = Pos.Center().

3. Add that second Window to the first Window, and show it.

4. The child window will be at 0,0,

And it's right because the second Window is only specifying the X and Y and not the Width and Height, where the base class (Toplevel) set them to Dim.Fill(). The X and Y = Pos.Center depends on Width and Height and as they have all the first Window size, the X an Y are both equal to 0.

Expected behavior The child window should be shown positioned at the center of the parent window it was added to, as in 1.12.

To positioned at the center of the parent window you must speechifying a size smaller than the parent window. e.g. Width = 10, Height = 10 or Width = Dim.Fill (10), Height = Dim.Fill (10).

[BDisp]

This is the commit that broke it: 58ad65f

@BDisp I think we should revert #2686. I accepted that PR against my better judgement ... we should not be taking fixes like that into v1, if there's a workaround. Agree?

No @tig, because it isn't a bug but by design. If Width is Dim.Fill() X will be 0 and if Height is also Dim.Fill() the Y will be also 0. Using Width = Dim.Fill (10), Height = Dim.Fill (10) will achieve the desired behavior.

[tig]

Did this behavior change beteween 1.12 and 1.13 or not?

[BDisp]

I think there is no problem with the commit https://github.com/gui-cs/Terminal.Gui/commit/58ad65f34800a87a9223cf24711d50db6eefcbe7. It only handles with color and not with layout. Any view that is centered on a parent is always based on the child size. If the child has the same size of the parent, then the location will always be 0,0. I think I've very clear about the issue that @dodexahedron exposed.

[tig]

So, @dodexahedron is incorrect that something changed between v1.12 and 1.13?

[BDisp]

So, @dodexahedron is incorrect that something changed between v1.12 and 1.13?

He may have some reason if it's another behavior than what he described in this issue. But only him can confirm that or providing a valid code that reproduce it. The one he provided with two Window that is derived from Toplevel, omitting the Width and Height they default to Dim.Fill().

[BDisp]

I also compared the current version of the View.cs file with an older version and there isn't any change that may have cause some layout issue.

[dodexahedron]

There absolutely is a change, but it is not to View.cs. It is in Border.cs

That commit breaks it. Immediately prior, it works as expected. With it, it does not work as expected.

To positioned at the center of the parent window you must speechifying a size smaller than the parent window. e.g. Width = 10, Height = 10 or Width = Dim.Fill (10), Height = Dim.Fill (10).

It is.

Perhaps I wasn't clear enough...

Parent window is Dim.Fill(0), and has dimensions that can be inspected as the values I stated.

Child has explicit width and height, smaller than parent, and is added to parent as shown.

It is displayed at 0,0, initially, and only correctly places itself if the window is resized.

The Superview, as Visual Studio shows it on inspection, is not the parent Window itself, but some other object or interface. It isn't something that I made explicitly. And it has width and height of 0. The parent window does not have width and height 0.

[dodexahedron]

This is the parent:

This is the child:

Note X and Y are 0.

I did misspeak, however, and the parent doesn't have width and height 0 (though I'm certain that's what I saw yesterday - I should have taken a screenshot then). But it isn't the Window itself.

After the call to this.LayoutSubviews(); it is centered correctly.

The code in this example is here: https://github.com/snapsinazfs/snapsinazfs/blob/master/SnapsInAZfs/ConfigConsole/SnapsInAZfsConfigConsole.cs#L355

[dodexahedron]

Using 1.13.X (seems broken for any version of 1.13):

1. Create a Window with width and height = Dim.Fill(0)

It's enough Dim.Fill().

2. Create a Window with explicit dimensions (any will do, so long as they're smaller than the terminal), and with X and Y = Dim.Center().

Must be X and Y = Pos.Center().

3. Add that second Window to the first Window, and show it.

4. The child window will be at 0,0,

And it's right because the second Window is only specifying the X and Y and not the Width and Height, where the base class (Toplevel) set them to Dim.Fill(). The X and Y = Pos.Center depends on Width and Height and as they have all the first Window size, the X an Y are both equal to 0.

Expected behavior The child window should be shown positioned at the center of the parent window it was added to, as in 1.12.

To positioned at the center of the parent window you must speechifying a size smaller than the parent window. e.g. Width = 10, Height = 10 or Width = Dim.Fill (10), Height = Dim.Fill (10).

Yes, The Dim/Pos mixup was just my mistake typing up the issue, as I was typing from memory, not copy/paste from code. The windows were created with TerminalGuiDesigner and the dimensions and positions are set properly. That would be a compile error anyway since that's not a method that exists.

See the screenshots I've provided and the code linked in my latest update if there's doubt it's being used correctly...

This behavior did change, and it changed in the commit I referenced, which I confirmed by building myself, including the commit immediately before it on the develop branch, which works correctly.

[BDisp]

Please run this code and tell me if have some issue:

            Application.Init ();

            var childWin = new Window {
                X = Pos.Center (),
                Y = Pos.Center (),
                Width = Dim.Fill (10),
                Height = Dim.Fill (10)
            };
            var win = new Window () {
                Width = Dim.Fill (0),
                Height = Dim.Fill (0),
            };
            win.Add (childWin);
            Application.Top.Add (win);

            Application.Run ();
            Application.Shutdown ();

In 1.13.x, the child window is placed at 0,0 when shown. This occurs on Ubuntu 23.04 and on Windows 11 in PowerShell. If the terminal is resized down and then to a size larger than the child window, it then centers itself.

I didn't have time to test your repo but maybe there is needed some call to SetNeedsDisplay() because was removed much code which was causing repetitive print, affecting performance. If SetNeedsDisplay() isn't called or is called, mainly on a change during a redraw process or in a thread, the NeedsDisplay will be empty. To ensure that the NeedsDisplay will be set is calling this way Application.MainLoop.Invoke(() => myView.SetNeedsDisplay()). Thus, in the next iteration will check for idle handlers to be run. Otherwise, only by resizing the UI is updated.

[dodexahedron]

(Links in this comment are directly to specific lines of interest)

SetNeedsDisplay() was one of the first things I tried, both on the parent and the child, but it does not fix the problem.

This application is started by Application.Run\<SnapsInAZfsConfigConsole>( ErrorHandler );

The UI is not particularly complex, either.

It is a class inheriting from Window (see here) that contains a menu bar and has IsMdiContainer=true. Menu items have actions which create and show the window as described (or as seen here).

It happens with all three of the other Window classes in that application, which, as mentioned, were created with TerminalGuiDesigner.

The child windows all have dimensions and positions like this (excerpt from here):

            this.Width = 148;
            this.Height = 26;
            this.X = Pos.Center();
            this.Y = Pos.Center();

The parent has this:

            this.Width = Dim.Fill(0);
            this.Height = Dim.Fill(0);
            this.X = 0;
            this.Y = 0;

What is odd to me is that the Superview of the child window is not the parent Window:

(Note this screenshot shows the child window, its superview - which is that "ContentView" apparently - and the superview of that, which is the parent window) Why is that? Is it because of how borders are drawn? The dimensions would make sense with that, since it's a border of width 1.

This all sticks out to me as possibly unintended consequences of the performance optimizations coupled with the changes to Border.cs. I have not dived into the various optimizations made, but instinct is telling me that, based on this behavior, it's likely that something was overlooked in the way things are arranged and an additional call to LayoutSubviews() or something similar may be needed, if those optimizations are left in place.

If you do wish to try out that repo, to see what's happening in-situ, be sure to use the Debug-Windows configuration, if you are on Windows. Otherwise, all other configurations are meant for Linux, and have some conditional compilation based on configuration. There are no non-nuget dependencies on Windows (on Linux you need ZFS installed) and it'll run with dotnet run on .net 7 and up. It currently has a call to LayoutSubviews() to work around the problem, so you won't notice the bad behavior unless you comment that out. The ui is invoked only when using the --config-console command line option.

[dodexahedron]

I'm putting together a simpler example, at the moment, both to validate or disprove what I see happening and, if validated, to try to narrow down exactly what is causing it, at least in the application code.

[dodexahedron]

Example complete. This is about as basic as it gets.

Two window classes, both made using TerminalGuiDesigner. Application starts by running the parent window.

Use the menu to add the child window. It will not be centered.

TerminalGuiCenterBugExample.zip

[dodexahedron]

Here's a screen recording of running that application.

https://github.com/gui-cs/Terminal.Gui/assets/8242181/9b5041b5-8971-447c-8aa6-d3490527de08

I'm certainly open to the idea that there's something wrong with the way I'm doing something, in the code, of course. However, intuitively, and based on the documentation, I don't think I am.

The SnapsInAZfs application could certainly use something other than a Window for the child screens, as a Window for each is overkill, in its current implementation, but it was originally designed to have multiple open at once in MDI fashion (and may return to that). That's of course not really relevant to this unexpected behavior, though.

I'm playing around with the example, now, to see if I can find a trigger. Calling LayoutSubviews() on the parent, after adding the child, does center it, the same as the workaround I'm using in SnapsInAZfs, for what it's worth.

[dodexahedron]

Nothing I have tried other than calling LayoutSubviews() seems to fix it, although doing so in the Added event handler for the parent also doesn't work (I think that's just because of when the event is fired, though).

I've tried commenting out everything unnecessary for successfully running the application (aside from the position and dimensions), including not having the menu (in case that was somehow interfering) and just showing the child on a keypress, with the same result.

If I set IsMdiContainer = true on the parent window, it also throws an exception that "End must be balanced with calls to Begin" immediately upon showing the child. This appears to be a spurious exception, because the same happens in SnapsInAZfs, but I'm using the overload of Run that takes an exception handler, and just swallowing it, without any apparent negative effects on the application (that may be worth a separate issue, unless I'm doing something wrong there).

So, I think it is the commit I mentioned, potentially coupled with other changes, that is the root cause. What, specifically, is happening (or, more likely, not happening) to give this result isn't something I've sat down and stepped through the Terminal.Gui code to track down, since the LayoutSubviews() workaround at least seems to work and I just moved on, to continue work on the application, though it's still unexpected/unintuitive behavior.

Anything else I can provide I'm happy to provide.

[BDisp]

@dodexahedron you don't need to call ShowChild( _childWindow ); because this method is used when IsMdiContainer = true. If you want to see a MdiContainer sample check the BackgroundWorkerCollection scenario on the UICatalog project. I already fixes this issue where a Window dynamically added was not calling the LayoutSubviews itself.

[tig]

@BDisp I am still confused.

@dodexahedron's code was working fine in v1.12. It does not work fine in v1.13.

Do we understand what set of changes caused his code to stop working?

[BDisp]

@BDisp I am still confused.

@dodexahedron's code was working fine in v1.12. It does not work fine in v1.13.

I already reverted the https://github.com/gui-cs/Terminal.Gui/commit/58ad65f34800a87a9223cf24711d50db6eefcbe7 and with the https://github.com/gui-cs/Terminal.Gui/files/12190256/TerminalGuiCenterBugExample.zip sample that he provided, I still have the same issue that he stated. Perhaps maybe is any other commit.

Do we understand what set of changes caused his code to stop working?

No, because as I told the issue isn't fixed by reverting the commit. But @tig, please test it by reverting the commit and see if you have more luck.

[dodexahedron]

Check out the commit immediately prior to it - don't just revert it. You wont get the behavior. Then check out that commit. You'll get the behavior. I did it by rolling forward, commit by commit, til it broke, and that was the commit that broke it. 🤷‍♂️

[BDisp]

I already did a hard reset until the commit prior to it and I still can't get your sample to work with center the child on opening, sorry about that. @tig please help me to check if I'm doing something wrong. Thanks.

[dodexahedron]

Hmm. I will do it again next time I'm at a computer to be sure I didn't mess that up myself.

I don't want that to be a red herring, though. Running the example application with 1.12 vs 1.13 from nuget shows the difference, so it's some commit (or combinations thereof) between them.

[dodexahedron]

@dodexahedron you don't need to call ShowChild( _childWindow ); because this method is used when IsMdiContainer = true. If you want to see a MdiContainer sample check the BackgroundWorkerCollection scenario on the UICatalog project. I already fixes this issue where a Window dynamically added was not calling the LayoutSubviews itself.

Thanks for the tip. 😊

[BDisp]

I already run your sample with 1.12 version and still doesn't center the child. How can I get your repo to run? I get this error:

'./Documentation/SnapsInAZfs.8' -> '/usr/local/man/man8/SnapsInAZfs.8'
install: cannot create regular file '/usr/local/man/man8/SnapsInAZfs.8': No such file or directory
make: *** [Makefile:116: install-doc] Error 1

[dodexahedron]

That's actually a helpful thing that should be an issue filed for that project, since the Makefile has only been tested on a small number of environments and probably does have shortcomings on others that haven't been tested explicitly. Thanks for mentioning.

What distro and version are you using, and what .net SDK version?

I've tested that Makefile on Ubuntu 22.04, 22.10, and 23.04, as well as CentOS Stream 8, but that's it, so other environments certainly could have trouble, which I'd like to address so it's easy for anyone.

That error looks like your distro's manpages are probably stored in other directories, and the make install recipe calls the install-doc recipe implicitly, which is what looks like is erroring out.

You can run the individual make recipes that make install runs, without the documentation recipe, or you can run make publish and then just run the application from the publish directory that will be created in the solution folder, without having to install it. Alternatively, you can override the manpage directories by passing the appropriate variables into the call to make, but I'm not at a PC right now, so I couldn't tell you off the top of my head which ones you'd have to set.

You can also run it on Windows from visual studio if you set the configuration to Debug-Windows and add the --config-console argument to the debug launch configuration. That configuration doesn't call anything in ZFS and just uses dummy input data files to simulate it, for debug purposes, and gives enough to provide a useful sample for debugging the configuration console.

However, I don't imagine you should really need to bother with all that for this, since the little sample I put together also demonstrates the problem, though I totally appreciate you trying to run it where I initially found the problem. 😊

That application uses the same method to create and show the child windows as the sample I put together. The child windows just have more subviews in them.

[dodexahedron]

@BDisp I am still confused.

@dodexahedron's code was working fine in v1.12. It does not work fine in v1.13.

Do we understand what set of changes caused his code to stop working?

To be fair, I can't guarantee that the commit I referenced is solely responsible for the problem (I only tried commits in order until it broke), but I can guarantee the behavior changed between the last 1.12 release and the first 1.13 release, and still exhibits the same behavior in the most recent 1.13 release as of Friday. I was just trying to help out in narrowing down the root cause.

The sample application I provided in this thread uses the same method for starting the TUI, creating the child windows, and showing them as the application I discovered the issue in. That sample also, when I ran it, properly centered the child window with 1.12 selected in nuget and does not center it with 1.13.x selected in nuget.

I can provide another screen recording showing it, later, if needed.

Also, the pull request @BDisp submitted looks like it probably should fix this, though I have not yet had a chance to test it myself.

[dodexahedron]

@Bdisp, just to keep things clean and separated (since it's not directly relevant to Terminal.Gui), if you could mention your environment in the issue I just linked (also provided below), it would be greatly appreciated. 😊

https://github.com/snapsinazfs/snapsinazfs/issues/23

[BDisp]

On Windows I already tried using the --config-console argument but always getting error on IConfigurationRoot nlogJsonConfigRoot = new ConfigurationManager( ) Running from the publish I get the error You must install or update .NET to run this application., but I have 7.0.* installed.

$ dotnet --info
.NET SDK:
 Version:   7.0.306
 Commit:    f500069cb7

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/share/dotnet/sdk/7.0.306/

Host:
  Version:      7.0.9
  Architecture: x64
  Commit:       8e9a17b221

.NET SDKs installed:
  6.0.412 [/usr/share/dotnet/sdk]
  7.0.306 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.20 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.9 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/lib/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Running in Publish folder:

./SnapsInAZfs

Framework: 'Microsoft.NETCore.App', version '7.0.0' (x64)
.NET location: /usr/lib/dotnet

The following frameworks were found:
  6.0.20 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=7.0.0&arch=x64&rid=ubuntu.22.04-x64

[dodexahedron]

Interesting. Looks like a dotnet or system issue in resolving the proper version of .net to invoke, which is odd, since it's being compiled as a R2R assembly (when using make publish), and even more odd since the project file explicitly specifies the runtime to use.

I'll have to set up a test VM with both 6.0 and 7.0 to see if I can reproduce that behavior. I imagine I'll need to pass another flag or two to the compiler to avoid that issue on similar systems.

On windows, it's likely the configuration json files specify a bad path for the nlog output, as I have a dev copy of those files on my local machine I've never committed to git.

Just to verify, are you cloning from/checking out the RC1 tag?

[dodexahedron]

That version of .net 7 was either manually installed or installed from the microsoft-prod apt repository, yes? The one in the canonical repository for ubuntu is 7.0.109.

Here are the results of attempting to reproduce the issue you're encountering:

1. I can duplicate similar failure to launch behavior with the SDK installed from the microsoft-prod repository, even without also having version 6 installed. In fact, on a 23.04 VM, it doesn't even report the SDK is installed at all in dotnet --info, even though it is. a. In the past, I've noticed other problems with dotnet on Ubuntu, installed from the Microsoft repository, in various other applications. It seems Canonical must add some customizations of their own to make it work smoothly in Ubuntu. There are many threads around the internet with this same problem, and they are resolved by using the packages provided by canonical.
2. I ran apt purge dotnet* --autoremove to remove all dotnet components from that test VM, removed the microsoft-prod repository from my apt configuration, and then installed the dotnet7 package from ubuntu's repository, and the application worked without problem.
3. I then also installed the dotnet6 package and ran the application again, to see if 6 was interfering, and it worked without issue and without needing to recompile.
4. I recompiled anyway, with both SDKs present, to see if that made any difference, but the application still launched correctly.

This was on a freshly-installed and otherwise empty Ubuntu server VM.

Again, though, I didn't intend for you to spin your wheels trying to get that to work, especially since your PR #2778 does appear to fix the behavior, in the test I just ran on my dev machine. And it's entirely possible that the way I isolated when the behavior changed was not valid, especially since there have been many changes, especially for the performance enhancements (good work, btw), that could have had a hand in it, as things are pretty tightly coupled.

In my outside opinion, it seems you've resolved the problem, so it's probably not worth more time spent on 1.x for that problem, since 2.x likely won't directly benefit from it, anyway. 🤷‍♂️

[dodexahedron]

Also, there is difference in the dotnet --info output using the canonical-provided dotnet packages vs the microsoft-provided packages.

See this, for example, from that 23.04 test VM, with the canonical packages installed:

dotnet --info
.NET SDK:
 Version:   7.0.109
 Commit:    3e9283a8e9

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  23.04
 OS Platform: Linux
 RID:         ubuntu.23.04-x64
 Base Path:   /usr/lib/dotnet/sdk/7.0.109/

Host:
  Version:      7.0.9
  Architecture: x64
  Commit:       8e9a17b221

.NET SDKs installed:
  6.0.120 [/usr/lib/dotnet/sdk]
  7.0.109 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.20 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.9 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.20 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.9 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/lib/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

So I imagine there are probably plenty of other customizations canonical has made that microsoft has not, in their packages, which otherwise require manual configuration if installed from the microsoft repo.

In your specific case, note that in dotnet --info, it's saying everything is in /usr/share, but the runtime itself is looking in /usr/lib, and your $DOTNET_ROOT also points to /usr/lib. Changing that to point to where it's actually installed might fix things.

Also, what is the output of cat /etc/dotnet/install_location_x64 and which dotnet?

[dodexahedron]

Further investigation, with the microsoft dotnet-sdk-7.0 package installed, which yields similar configuration as yours, revealed that this is enough to get it running without modifying other configuration:

ln -s /usr/share/dotnet/sdk /usr/lib/dotnet/sdk

The reason is the microsoft package puts the SDK in the /usr/share folder, but everything else is in /usr/lib, and it looks in $DOTNET_ROOT to find SDKs. Making the symbolic link to the actual installation path allowed it to find it on that test system, and should be a durable solution across apt upgrade runs.

Here's a screen recording of what that looks like after the symbolic link has been made:

https://github.com/gui-cs/Terminal.Gui/assets/8242181/3a83bb21-87f0-433e-826b-caa2a74b9a6a

The light blue "sdk" folder in /usr/lib/dotnet is the symlink to /usr/share/dotnet/sdk

Note you still won't be able to use it at all unless you have zfs installed, and the configuration files have the correct path to the zfs executable specified.

Also, following up on what I mentioned earlier about overriding the manpage path, you can override the root manpage directory that make install uses by running it as $MANDIR=/path/to/man/root make install. The default the Makefile uses is /usr/local/man, which won't be correct for ubuntu 22.04. That's something I should probably change, anyway, for broader compatibility, so thanks for revealing that issue.

If your distro also uses different sub-directories than the default the makefile expects, you can override those, too, with $MAN3DIR, $MAN5DIR, $MAN7DIR, and $MAN8DIR. By default, those are set as $MANDIR/$MAN#DIR where # is the section number, but if you override them, you are overriding the whole path. To find out the proper value for the $MANDIR folder, you can run manpath at the command prompt. I haven't had time to sit down and learn how to work autoconf, so the Makefile is very basic and doesn't have a configure script available to set the appropriate values for the given system.

[dodexahedron]

I've published RC2, which incorporates the manpath changes, so, if you want to keep trying it out, that release should make it easier on you.

[BDisp]

@dodexahedron I can't see your videos on the browser, even I download them and try see in the multimedia reader. It needs the HEVC extensions on Windows 11. Through the phone I can.

[dodexahedron]

Works in Edge and Chrome on my windows 11 machines. 🤷‍♂️

I'll use VP9 or something if I have to post another.

[BDisp]

Works in Edge and Chrome on my windows 11 machines. 🤷‍♂️

I use Firefox and it not work, but I tried on the others browsers and it's only work on Chrome and not on Edge. Perhaps you installed some extensions for that. What's app you use to record videos?

I'll use VP9 or something if I have to post another.

No bother because I can see it on Chrome.

[dodexahedron]

Nah, that's a known thing about Firefox. HEVC is theoretically patent-encumbered, so Firefox doesn't include support for it by default at this time.

I simply am used to encoding with the x265 library so used that out of habit.

[BDisp]

But do you know why it's not working on Edge for me? I use ScreenToGif to create gif but I would like something where I can create a video. What do you recommend?

[dodexahedron]

Couldn't tell ya for sure. I haven't really had to think about codecs since Windows 8 or 10. But, just guessing, perhaps different editions of Windows may not include HEVC by default. The N editions of Windows, for example, tend to be missing some multimedia features as a result of old anti-competition lawsuits.

[BDisp]

Thanks for the clarification, but I have Windows 11 Pro, which I think it should have. Perhaps it's only for insiders for now 😃

[dodexahedron]

Hm. I'm not on an insider build on this machine. There is an N version of Pro, as well. Could also be a regional thing, I guess, depending on laws and distribution rights and whatnot wherever you live. Or could be something to do with the installation image, or perhaps another piece of software that broke it. There are too many possibilities, so any of those would just be a guess. It's also possible, I suppose, that the specific set of encoding options I used may simply not be supported by your system, as I did use a few less-common features to minimize the file size. But that's also just a guess.

Wish I could provide more definitive help on that.

You'd think that, in 2023, we would have made this a seamless process. 😅

[BDisp]

I already get it running on Windows 11 using Visual Studio 2022: All the output are create at \snapsinazfs\SnapsInAZfs\bin\x64 and \snapsinazfs\SnapsInAZfs\obj\x64

https://github.com/gui-cs/Terminal.Gui/assets/13117724/174f3f41-e1bf-4d48-8701-5094357dae7b

But if I try running it on Windows 11 using VSCode I get an error. I'm curious if it's a lacuna on VSCode by not respecting the <Platforms>x64</Platforms> or if it's needs do add some some configuration for the VSCode. I think the problem is the VSCode is building on \snapsinazfs\SnapsInAZfs\bin\Debug and \snapsinazfs\SnapsInAZfs\obj\Debug which isn't compatible with x64.

Edit: This issue only happens if I right click on the SnapsInAZfs project on the SOLUTION EXPLORER->Debug, it build on the wrong folder.

If I right click on the SnapsInAZfs solution on the SOLUTION EXPLORER->Build, it build on the right folder.

[dodexahedron]

Thanks for your assistance with this. Since it isn't Terminal.Gui related, though, perhaps we should move this discussion to that project.

As a general note, it wasn't designed with the original intention of working in VSCode on Windows, but that's perhaps something I should consider for future revisions.

My initial thought, from what you showed, is that you're probably using the Debug configuration, yes? If so, and if on Windows, that's expected not to work. The only configuration that has any real chance of working on Windows is the Debug-Windows configuration.

[dodexahedron]

Just a thought:

When taking a look at the open issues, my spidey sense perked up when I saw #2672, as it seems this case might be relevant to verify against anything done for that issue, to avoid a possible regression on this one.

If it's not relevant, then don't listen to me and carry on. 😅

[BDisp]

Just a thought:

When taking a look at the open issues, my spidey sense perked up when I saw #2672, as it seems this case might be relevant to verify against anything done for that issue, to avoid a possible regression on this one.

If it's not relevant, then don't listen to me and carry on. 😅

That was an issue for v2 and this one is related to v1. I almost finishing with this. It's taking more time than I expected because I'm creating unit tests for all possible scenarios and in some conditions it gave different results when they shouldn't. So, some more time and it will ready to go.

[BDisp]

@dodexahedron I already finished my PR. Can you please test it and verifying if all it's work well. I added two new scenarios from your example, with modifications. On one scenario the child windows is added to the parent as sub-view and on the other scenario the child window run alone as non modal on a Mdi Container parent. Thus, the child window is a parent's MdiChild. Both have methods for create, center, hide/unhide, child border/borderless, parent border/borderless and menu/status bar hide/show. This allow test all possible scenarios beside the unit tests.