-
Notifications
You must be signed in to change notification settings - Fork 30
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
TreeView<T> support #280
TreeView<T> support #280
Conversation
@dodexahedron any thoughts on the structure of this new code? |
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.
Very good work. Congrats.
I've been unable to touch any of this since a couple days ago, but I'll certainly have a look as soon as possible and let you know if I have any thoughts. That'll probably either be later tonight, or at some point tomorrow. |
First thing I'd mention, just from the class diagram (haven't checked the code itself yet), is something I've been meaning to mention at Terminal.Gui and made a side mention of in an unrelated issue over there: Attributes. One big application is I think we should consider a means of helping us to avoid having to maintain all these type arrays everywhere, by having either an interface or an attribute (or both) that we can decorate TG types with, to indicate TGD support. An attribute would be nice, because it can be parameterized and those parameters can be used by TGD to protect itself against potential future breaking changes to a type in TG by inspecting such parameters at application launch and taking whatever action is appropriate. For example, those actions could be anything from simply showing a warning to disabling certain functionality all the way to showing a critical error, telling the user to revert to an earlier TG version to use TGD with it, and gracefully exiting before things can get weird. An interface would also be nice, for strong-typing reasons, even when reflection is used, and that's exactly what interfaces are for. If a type in TG can guarantee that it supports a given interface contract we come up with, based on what TGD needs to support that type, the interface can be applied to that type and then TGD can assume that it can use that type. Makes integration testing easier, too. Anyway... I'll take a look at the code itself in a little bit. I'm still going through my github notifications. 😅 |
Side note... I'm excited to see this, in any state! :) |
tests/TreeViewTests.cs
Outdated
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'd like to expand on these tests, both by adding some new ones and just a few tweaks to these two, but that can be added as part of the work I'm doing if you'd rather focus on other stuff.
Nice Gets the job done safely, and that's what matters. :) 🥳 |
Fixes #267
Adding TreeView<object> then TreeView<FileSystemInfo> to a Window (with save/open)
Designer.cs Code
We now have:
Slider<T>
#271)TableView<T>
Support (this PR).This is probably a good place to chat about any refactoring and future proofing of this functionality
User defined Types (e.g.
MyGameObject
) are currently off the cards but should be kept in mind as a future goal.Use Case
As a TerminalGuiDesigner user I want to be able to add any of the core generic views.
TreeView<object>
.Current Implementation
Currently things are a bit all over the place so we need some tidy up.
Classes I like:
TTypes
- Describes what Types can be picked forT
in a given generic ViewFor any given T type we need:
TTypes.GetSupportedTTypesForGenericViewOfType
)ValueFactory
ToCode
that can represent the value being instantiated (currently inTTypes.ToCode
)