-
-
Notifications
You must be signed in to change notification settings - Fork 64
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
Panel Scrollbar Update (clean) #749
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the solution to the scrollbar problem is going to be to adjust the ContentRegion
for it.
It makes sense for things like webbrowsers because the content is assumed to be reactive on its own for various sizes, but we're not fluid like HTML + CSS allows. We're far more like WinForms. Since the ContentRegion can be defined, this gets into some weird behavior.
As a big issue with the scrollbar currently is that it can overlap the content in the panel, it may be ideal to just provide a virtual function that returns a Rectangle which is used to then place the scrollbar. The default implementation would implement it for the Panel control where it sits in the middle of the border line (which is visible when ShowBorder is true). Other controls which inherit from Panel could then provide their own Rectangle to position the scrollbar if they need something special. I think this helps things remain more standard and gives more flexibility than the Scrollbar Padding property.
I think we can get a PR through for the MaxWidth and MaxHeight through much quicker if we can focus on them seperately. I think that the scrollbar still needs more discussion before we decide on the solution here.
/// <summary> | ||
/// See if the <see cref="Scrollbar"/> is beeing drawn. | ||
/// </summary> | ||
public bool Drawn | ||
{ | ||
get => Visible && _scrollbarPercent < 0.99; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the plan is to move towards not having a scrollbar control at all, I'd like to avoid adding any "short-cut" APIs that can be done by the consumer itself.
//get => _panelScrollbar != null && _panelScrollbar.Drawn; | ||
//get => _panelScrollbar != null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs cleaned up.
protected Vector2 _scrollPadding = new Vector2(4, 0); | ||
/// <summary> | ||
/// Padding on the left side of the <see cref="Scrollbar"/>. | ||
/// </summary> | ||
public Vector2 ScrollPadding { | ||
get => _scrollPadding; | ||
set => SetProperty(ref _scrollPadding, value, true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is ScrollPadding for? I don't see it referenced anywhere else except in the ScrollbarWidth (and that appears to only use the X).
protected bool _scrollbarVisible = false; | ||
|
||
/// <summary> | ||
/// Space which is taken from the <see cref="Scrollbar"/> to be drawn inside the <see cref="Panel"/>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't a panel. This is a container.
/// The rectangle which will be colored behind the <see cref="Control"/> by BackgroundColor. | ||
/// <br/><br/>Default: <see cref="Rectangle.Empty"/> | ||
/// </summary> | ||
protected Rectangle _backgroundColorBounds; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we perhaps had a misunderstanding about this. Background color should fill the full bounds. We can get rid of this.
The tint I was referring to shown here is drawn by the panel control itself and fills the ContentRegion
.
Blish-HUD/Blish HUD/Controls/Panel.cs
Lines 313 to 318 in 736ba25
if (_showTint) { | |
spriteBatch.DrawOnCtrl(this, | |
ContentService.Textures.Pixel, | |
this.ContentRegion, | |
Color.Black * 0.4f); | |
} |
this.ContentRegion = new Rectangle(leftOffset, | ||
topOffset, | ||
_size.X - leftOffset - rightOffset, | ||
_size.X - leftOffset - rightOffset - (ScrollbarVisible ? (ScrollbarWidth / 2) + (ScrollbarVisible ? 0 : RIGHT_PADDING) : 0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should be magically updating the boundaries of ContentRegions like this. It's confusing if your ContentRegion is not the size that you have specified as a developer and further it gets us into weird domino behaviors with panels that manage the position of their children based on the content region size.
var cR = ContentRegion.ToBounds(this.AbsoluteBounds); | ||
var contentScissor = Rectangle.Intersect(scissor, cR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this change for?
protected Point _maxSize = Point.Zero; | ||
/// <summary> | ||
/// Maximum Size the <see cref="Container"/> can autoresize to. | ||
/// </summary> | ||
public Point MaxSize { | ||
get => _maxSize; | ||
protected set => SetProperty(ref _maxSize, value, true); | ||
} | ||
|
||
/// <summary> | ||
/// Maximum Width the <see cref="Container"/> can autoresize to. | ||
/// </summary> | ||
public int MaxWidth { | ||
get => _maxSize.X; | ||
protected set => SetProperty(ref _maxSize.X, value, true); | ||
} | ||
|
||
/// <summary> | ||
/// Maximum Height the <see cref="Container"/> can autoresize to. | ||
/// </summary> | ||
public int MaxHeight{ | ||
get => _maxSize.Y; | ||
protected set => SetProperty(ref _maxSize.Y, value, true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
It currently doesn't make any sense to have all three of these. Setting MaxWidth or MaxHeight on its own would result in a control that has either a 0 width or a 0 height since the check below only compares it against Point.Zero and doesn't check the individual dimensions.
-
You're setting the value on the structs X and Y values which I don't think is a good idea. These would need to create a new Point like we do in the Control Size shortcuts (Width and Height properties).
-
Since sizing modes are available for both width and height individually, it seems reasonable to me to just have MaxWidth and MaxHeight. No need for MaxSize. They can be kept in separate
int
s anyways. At no point do we actually use them as a point so it's just an unnecessary data type holding something we can store directly. -
The description helps to clear things up, but it'd probably be best to apply the MaxWidth and MaxHeight to the control at all times instead of just when autoresizing. It removes any confusion in the behavior. That is to say that setting Size, for example, should also be limited by the MaxWidth and MaxHeight.
@@ -118,6 +118,60 @@ public abstract class Container : Control, IEnumerable<Control> { | |||
set => SetProperty(ref _autoSizePadding, value); | |||
} | |||
|
|||
protected Scrollbar _panelScrollbar; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anything for the scrollbar itself should be in the Panel
control. Panel is the highest level control that has implemented the scrollbar and I don't see a reason to move its implementation up into the Container. Containers are intended to be fairly barebones.
If an implementer wishes to share this functionality then they can implement the Panel
control as they do now.
Oh well... Tbh then we might discard the whole PR. We've talked about it to implement it as a eventually temporary solution to the scrollbar overlapping the content, as I did not felt comfortable to adjust the scrollbar to "not be a control anymore". The reason it is implemented as it is, is that it has to be within the control bounds to not be cut off. Sizes had to update in order to adjust properly to window size if a window is resizeable. As I've said, if this is not a solution you want to see implemented we can discard it, i will implement custom classes for my stuff until there is a fix. I might look into it again, but before I do I really need to know how your solution has to look, but at that point it might be easier/better to let you deal with it. |
Kudos, SonarCloud Quality Gate passed! |
Container.cs
Properties:
Methods:
Scrollbar.cs
Properties:
Panel.cs
Methods:
RecalculateLayout
UpdateScrollbar
FlowPanel.cs
Methods:
all variants of ReflowChildLayout
Control.cs
Properties:
Methods:
Draw