TGD: Master Issue tracking TG issues that must be fixed in v2

[tig]

Via @tznind "we have lost support for the FrameView because drag/move doesn't work properly with it." here

gui-cs/TerminalGuiDesigner#189

May be same issue: "Borders are disabled for now I think too for same reason (they break click drag)"

[tig]

@tznind With this:

• Preps for and partially Fixes #2491 - Refactors Toplevel and Application Navigation #3634

ANY View is now draggable:

• Set Arrangement = ViewArrangement.Movable | ViewArrangement.Overlapped

(Obviously if you want tiled, don't set the Overlapped flag)

By default FrameView in v2 is NOT enabled for either of these.

But Window is (and when #2491 is done, it will NOT be derived from Toplevel and will be basically the same as FrameView with a shadow and different border).

[tig]

WIth #2537 any view will be sizable too.

[tig]

My plan with #2537 is to leverage IDesignable such that if design mode is enabled, Border will be able to be "hidden" such that a View without a Border can be dragged.

Same for dragging multiple views.

[BDisp]

Since the TGD as access to internal TG objects may be could have some kind of mechanism that allow TGD to enable drag and restore defaults when finish drag.

[tznind]

There is a LOT of code in TGD to do this drag. Complex bits include:

• Preventing drag for axis which are not compatible Pos type (e.g. lock X to Pos.Right of Something but still drag along Y axis)
• Undo/Redo
• Drag to sub/super view
• Multi view drag
• Keyboard support

It's probably a good 10% of the designer codebase. And it's heavily coupled to other bits of code like

• view selection system
• Operation stack
• Global mouse manager.

Not saying we can't make it part of core, just that it's going to get complex fast 😀 but up for trying.

Regarding internal, I think policy is to try and avoid.

[tig]

Since the TGD as access to internal TG objects may be could have some kind of mechanism that allow TGD to enable drag and restore defaults when finish drag.

As previously discussed, we want to move away from having TGD have internal access. We should make these mechanisms public.

Of course, we CAN do this over time, but I'd like to really try to make it happen before V2 release!

[tig]

There is a LOT of code in TGD to do this drag. Complex bits include:

• Preventing drag for axis which are not compatible Pos type (e.g. lock X to Pos.Right of Something but still drag along Y axis)
• Undo/Redo
• Drag to sub/super view
• Multi view drag
• Keyboard support

It's probably a good 10% of the designer codebase. And it's heavily coupled to other bits of code like

• view selection system
• Operation stack
• Global mouse manager.

Not saying we can't make it part of core, just that it's going to get complex fast 😀 but up for trying.

Regarding internal, I think policy is to try and avoid.

How willing are you to migrate this code into TG as needed?

[tznind]

I can try but it is going to be difficult. And not fast because of scale. Designer basically has a complete parallel mouse handling system based on global handler and hit detection.

[tig]

I can try but it is going to be difficult. And not fast because of scale. Designer basically has a complete parallel mouse handling system based on global handler and hit detection.

My head's still not clear on this, but I'm now thinking the place to rally here is around IDesignable.

We put it on View and expand it with whatever methods/properties TGD needs. Since I've moved most mouse handling code into Application and out of View & Toplevel (more do do), we can put the right logic in Application.Mouse.cs to enable calling out to TGD (and other designers). We can even go as far as adding a 4th Adornment that is only lit up when IDesignable.DesignMode == true that sits between Border and Padding that TGD can leverage.

The goal would be to enable TGD to minimize throwing away as much as that code as possible whilst leveraging the new architecture in TG V2.

Just spitballing of course to get the juices flowing. This will be an interesting challenge. I'll repeat again: We don't ship V2 until TGD is amazing on it.

[BDisp]

Instead of adding a new Adornment why not enabling all the mouse features anywhere on a view if IDesignable.DesignMode == true. So, the mouse will have the same features on Margin, Border, Padding and Viewport.

[tznind]

I think we should split to 2 goals

1. Enable TGD to function like it did before with Borders/FrameView.
2. Migrate TGD resize/move code to core

The first will enable a polished use experience and full range of Views supported in TGD in relatively short period of time.

The second is far more ambitious and will take longer.

1. Enable FrameView and Borders as simply as possible

I will have to refresh my memory on the exact issue with Borders and FrameView but I think it was around hit detection and the 'out of the box' FrameView being moveable. Probably can fix that in CreateSubControlDesign where it explicitly makes everything focusable we can just make everything immoveable and let the original TGD move code take over.

There are already some Border related hacks that TGD applies in its extension version of FindDeepestView e.g. see UnpackHitView

/// <summary>
/// <para>
/// Sometimes <see cref="View.FindDeepestView"/> returns what the library considers
/// the clicked View rather than what the user would expect.  For example clicking in
/// the <see cref="Border"/> area of a <see cref="View"/>.
/// </para>
/// <para>This works out what the real view is.</para>
/// </summary>
/// <param name="hit"></param>
/// <returns></returns>
public static View? UnpackHitView(this View? hit)
{

      if (hit != null && hit.GetType().Name.Equals("TabRowView"))
      {
          hit = hit.SuperView;
      }

      // Translate clicks in the border as the real View being clicked
      if (hit is Border b)
      {
          hit = b.Parent;

      }

      // TabView nesting of 'fake' views goes:
      // TabView
      //   - TabViewRow
      //   - View (pane)
      //     - Border (note you need Parent not SuperView to find Border parent)

      if (hit?.SuperView is TabView tv)
      {
          hit = tv;
      }

      return hit;
  }

2. Migrate 'design' code from TGD to Terminal.Gui

This is the Design class which is at the core of TGD.

It is how TGD distinguishes between Views the user created e.g. a TabView and those that are subcomponents that are not ineded to be treated seperately e.g. the TextField in a ColorPicker or the TabRowView in a TabView.

We might start tackling this feature with a new namespace Terminal.Gui.Designer rather than trying to put everything under an IDesignable interface which is on all views?