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

[Discussion] Split UI entirely off of main NetSparkle project #77

Open
Deadpikle opened this issue Dec 9, 2019 · 2 comments
Open

[Discussion] Split UI entirely off of main NetSparkle project #77

Deadpikle opened this issue Dec 9, 2019 · 2 comments
Milestone

Comments

@Deadpikle
Copy link
Collaborator

@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.

@Deadpikle Deadpikle mentioned this issue Dec 9, 2019
27 tasks
@Deadpikle Deadpikle added this to the 2.0.0 milestone Dec 9, 2019
@cjmurph
Copy link

cjmurph commented Dec 9, 2019

There was way too much duplication in my quick scratch up between the UI projects. I was cringing while doing it. It's by no means an optimal solution.

I still think it's an idea worth pursuing, hopefully someone smarter than me can offer a better solution :).

@Deadpikle Deadpikle modified the milestones: 2.0.0, 3.x Mar 23, 2020
@Deadpikle
Copy link
Collaborator Author

I am still open to doing this eventually, but I want to leave it off the table for 2.0, which is taking me enough time to get ready as it is without more refactoring due to my limited free time. I've changed the milestone to a tentative '3.x' accordingly.

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

No branches or pull requests

2 participants