Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #2539. Menu should use Frame instead of DrawFrame. #2540

Merged
merged 1 commit into from
Apr 13, 2023

Conversation

BDisp
Copy link
Collaborator

@BDisp BDisp commented Apr 13, 2023

Fixes #2539 - Include a terse summary of the change or which issue is fixed.

Pull Request checklist:

  • I've named my PR in the form of "Fixes #issue. Terse description."
  • My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
  • My code follows the Terminal.Gui library design guidelines
  • I ran dotnet test before commit
  • I have made corresponding changes to the API documentation (using /// style comments)
  • My changes generate no new warnings
  • I have checked my code and corrected any poor grammar or misspellings
  • I conducted basic QA to assure all features are working

Copy link
Collaborator

@tig tig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hero!

At some point, it seems Menu would be better off just being a view where each menu item is just a View (a Label?). Each 'frame' (e.g. separators) the menu would then be those View's Border.

Terminal.Gui/Views/Menu.cs Show resolved Hide resolved
@tig tig merged commit 5317489 into gui-cs:v2_develop Apr 13, 2023
@BDisp BDisp deleted the v2_menu-frame-fix_2539 branch April 13, 2023 20:38
@BDisp
Copy link
Collaborator Author

BDisp commented Apr 13, 2023

Well I was very lazy and I only used the view frame and the internal menu separator by changing the coordinates, but it could also be in the way you point to.

@tig
Copy link
Collaborator

tig commented Apr 13, 2023

Well your lazyness just caused me a bunch of work because I assumed you had done it carefully. 😠 💘

I'm merging #2483 now, but you'll see me merging in this PR into it broke some Menu tests that I had to disable because I ran out of time.. I'd love it if you'd look at them.

Menu.cs will be about 30% shorter if it can be made to fully leverage LineCanvas.

Thanks.

@BDisp
Copy link
Collaborator Author

BDisp commented Apr 13, 2023

@tig in the case of the Menu there is no need to use LineCanvas, with Frame it works well. Beside that I must understand better how it works. I'll see the unit tests.

@BDisp
Copy link
Collaborator Author

BDisp commented Apr 13, 2023

@tig you are mixing Frame with LineCanvas. Also the OnRenderLineCanvas must be call at the beginning of the Draw. What is bad in your design is that you are drawing the Border after the subviews content are drawn. To draw normal frame the Frame is more than sufficient. If you want join borders then we must use the LineCanvas, but using both in the same view is very stranger.

@BDisp
Copy link
Collaborator Author

BDisp commented Apr 13, 2023

@tig I swear I already had the menu to work before but something broke it. Is it not possible to draw a simple edge around the view frame? Run UICatalog and you'll see the menu is working as expected.

@tig
Copy link
Collaborator

tig commented Apr 13, 2023

@tig you are mixing Frame with LineCanvas. Also the OnRenderLineCanvas must be call at the beginning of the Draw. What is bad in your design is that you are drawing the Border after the subviews content are drawn. To draw normal frame the Frame is ore than sufficient. If you want join borders then we must use the LineCanvas, but using both in the same view is very stranger.

My design is not fully implemented yet. If you read the spec you'll see that.

When this is all complete the Frames will be drawn INDEPENDENTLY and BEFORE the View's content is drawn.

See #2482

@BDisp
Copy link
Collaborator Author

BDisp commented Apr 15, 2023

Hero!

At some point, it seems Menu would be better off just being a view where each menu item is just a View (a Label?). Each 'frame' (e.g. separators) the menu would then be those View's Border.

I understand what you mean, but it will imply a full refactor on the Menu which I don't know if it worth. I'll add the enable/disable border feature in the menus.

@BDisp
Copy link
Collaborator Author

BDisp commented Apr 15, 2023

For those much more brave than me here is a suggestion for two items without separator (remember that each member is a View):

┌───────┐
│ One   │
└───────┘
┌───────┐
│ Two   │
└───────┘

Since there is no separator the bottom thickness of the One item must be 0 and the top thickness of the Two item must also be 0. This will result the follow output:

┌───────┐
│ One   │
│ Two   │
└───────┘

More harder is when a separator is needed. In this case the bottom thickness of the One item must be 1 (default) and the top thickness of the Two item must be 0. This will result the follow output:

┌───────┐
│ One   │
└───────┘
│ Two   │
└───────┘

But the job isn't finished yet. It's needed to join the left with a and on the right with a and the final result will be the follow output:

┌───────┐
│ One   │
├───────┤
│ Two   │
└───────┘

I don't want to give any lesson to anyone, but I only alert for the complexity, not for the steps above, but to the views that must be added to the superview and beside dealing with all menu/sub-menus opened, we needed to handle more much more views than currently has.

@tig
Copy link
Collaborator

tig commented Apr 16, 2023

The whole point of my latest big pr was to make two views that touch blend borders automatically!

Just set UseSuperviewLineCanvas = true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants