You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
The text was updated successfully, but these errors were encountered:
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 :).
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.
@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.
The text was updated successfully, but these errors were encountered: