Replies: 6 comments
-
In WinUI #190, @YuliKl wrote:
I suggest that it would be best to apply YuliKl's wording literally. Limit the user but not the programmer. Also don't limit the internals of the new splitter Control to these min and max pane sizes. The new Control can be given guideline/suggestion limits and/or user limits, but it needs the ability to ignore or modify these limits when it is impossible to apply them, depending on window size etc. Currently GridSplitter is limited by
In order to perform well in all circumstances, |
Beta Was this translation helpful? Give feedback.
-
Thanks @verelpode, I think In my XAML Studio app, I ran into this type of problem recreating VS Code's Activity Bar/Side Bar area and being able to allow the user to resize it. For that I created a new Splitter called My plan has been to refactor a common base for GridSplitter and ContentSizer in the toolkit, as I made improvements to use the mouse pointer code we have in the toolkit now when I wrote ContentSizer; however, I haven't had time yet. |
Beta Was this translation helpful? Give feedback.
-
I'll put this in the 6.0 milestone for now. |
Beta Was this translation helpful? Give feedback.
-
Oh yes, that's another relevant issue I forgot to mention. I also encountered this issue. I think this issue should be included in a new design of a splitter.
In regards to backwards compatibility. In regards to new apps, I don't think any kind of splitter widget should be publicly placed in a I think, in order to make it reliable, the concept needs to be changed to horizontal and vertical orientation like how This means the whole splitter concept can be radically simplified, without losing the ability to have both horizontal and vertical splitters in the same window. Because the new concept is simpler, it's much more feasible to make it completely reliable, user-friendly, and programmer-friendly. In contrast, the existing design of I've watched people trying to untangle programming messes with roughly the same amount of entanglement as
|
Beta Was this translation helpful? Give feedback.
-
Linking back to discussions on details of GridSplitter from this unmerged PR: #2018 When I get to this work (Aug/Sept?), I'll start with the common base between @verelpode @skendrot would you be interested in helping to summarize a distinct list of scenarios you'd like to see GridSplitter handle? I'm thinking akin to what the WinUI folks do in their issue templates where there's a table of items of basic requirements for things we expect to work, stretch goals, and things that are explicitly out of scope? It'd be nice to have some nice upgrade path for existing GridSplitter users, but 7.0 will be a major release, so we can make some breaking changes if needed. E.g., our start is:
|
Beta Was this translation helpful? Give feedback.
-
Linking to #2719 as well |
Beta Was this translation helpful? Give feedback.
-
I'm opening this issue to discuss problems with
GridSplitter
, as requested by @michael-hawker. Actually I presumed that GridSplitter was only in the Community Toolkit and not officially in UWP because the WinUI team already knew of problems; already knew that changes to GridSplitter's API are desirable, but yes it's good to open a new issue and get feedback from multiple people.Currently 2 versions of
GridSplitter
exist:Both of those versions have mostly the same API/design. My opinion is that this design is problematic from a programming point of view. From a user point of view, GridSplitter is good except when it malfunctions (or is misconfigured) and produces mangled GUI visible to the user.
One of the problems is what happens when you try to limit the user to a minimum pane size without breaking compatibility with a small app window size. It's very easy to accidentally configure GridSplitter incorrectly, and even if you do configure it correctly, it still does not behave well when the user resizes the window to a small size.
In my opinion, in order to make a rock solid alternative to
GridSplitter
, it should be made independent ofGrid
-- it should not useGrid
. It can potentially useGrid
internally if desired, but not in the public API.In closed issue #465, @SeriousGeorge wrote:
@SeriousGeorge raised a valid issue, but I think his issue was closed because unfortunately he mentioned "a timeline control" and this confused the issue, but nevertheless his core point was valid. If people still don't understand what he said, then I'll make screenshots or diagrams to explain the problem and solution.
In closed issue #1666, @wstaelens experienced difficulty configuring GridSplitter. Even if his case is fully analyzed and determined to be his mistake and not a bug in GridSplitter, it still indicates problems with the design of GridSplitter. It's far too easy to misconfigure GridSplitter. The design of GridSplitter can be simplified and improved in a manner that eliminates this problem of GridSplitter being too difficult to configure. (And as I said, problems still exist even after configuration mistakes are fixed.)
To adequately describe the GridSplitter problems, I think I'll have to write some sample code that demonstrates problems, and also post a couple of screenshots of GUI mangled by GridSplitter. I won't be able to get around to this task this week, but in the meantime, people can start posting their feedback/experiences with using GridSplitter in Universal Windows apps, and I'll also post more detail next week or when I get the chance.
Another important question: Touchscreens. In regards to GridSplitter in Community Toolkit not WPF, are people satisfied or dissatisfied with its compatibility/behavior when operated by users on touchscreen-based devices that have no mouse?
See also: "Allow app users to resize NavigationView's Pane" #190
Beta Was this translation helpful? Give feedback.
All reactions