NetSparkleUpdater / NetSparkleUpdater/NetSparkle
[Discussion] Split UI entirely off of main NetSparkle project
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 832
- Forks
- 103
- PR merge metrics
- No merged PRs in 30d
Description
@cjmurph has made a proposal that even more UI code be split off into their own projects. His code is here: https://github.com/cjmurph/NetSparkle/tree/seperate-ui Regardless of the outcome of this discussion, I want to thank him for the time and effort he's put into this. (I'm also sorry for the wait!)
The proposal is essentially that the UI projects respond to NetSparkle's event handlers rather than implementing a UI Factory. This cleans up the main NetSparkle project from dealing with all the intricacies of being compatible with both WinForms and WPF. However, it sort of results in a lot of duplicated ideas/code between the NetSparkleForms and NetSparkleWPF projects.
Personally, I like the idea of cleaning up the main NetSparkle project. I cringe a bit with all the threading and other weirdness. cjmurph also did some valuable work on splitting out WPF code to ViewModels as well as some other valuable refactoring work that we could / should bring in regardless. However, I think that this proposal adds potential increased complexity to creating a custom UI, and I don't prefer to keep up the duplicated code/ideas between the two UI projects. In addition, I think the current way the UI is setup, while blah in some regards, might be easier for forward compatibility -- you can just keep using the same UI factory and get compile-time warnings/errors when things change rather than "oops I didn't implement a new event that's necessary".
I would like to personally propose not making the overall change and just keep the status quo, but I'd like to also submit that we have a sample project that only hooks into events and not the UI Factory to demonstrate how users can do that. That sample project could show everything in the same window just as a proof of concept on how to hook into events.
I am open to other sides of the issue! Please let me know if you have other thoughts.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the proposal on the seperate-ui branch and comparing its approach with the existing NetSparkleForms and NetSparkleWPF projects. The work is done when the UI architecture decision is settled and, if the current approach remains, an event-handler-only sample project is specified and added.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- desktop
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100