Killy wrote: ↑Sun Dec 16, 2018 5:28 pm
Actively maintained open-source project can live under your control. It's easier to contribute to maintained project than spin off a fork.
If you just publish the sources archive - that will mean you're giving away the control over it to unknown people. Moving to Github/Gitlab yourself will mean you're still in control and we can trust this project. Github is simpler, Gitlab gives more control over your project, including free private project if you don't feel like making it public yet. If you have some concerns about the usage of open source project, then address it in the license.
There won't be many people rushing into the project, but for some of us it's the chance to get the desired feature done. Still, important part of maintaining of the project is to keep it focused - have a guide/roadmap for contributors, explaining what directions this project can or can not go...
I already have a git repo (I just don't particularly trust git hub
) so I host my own git repo on my own git server - either way it will be trivial to publish that and keep control to some extent.
Killy wrote: ↑Sun Dec 16, 2018 5:28 pm
I think splitting GUI from from the core app will give more benefits than complexity. If anything, reducing the coupling between functionally different parts will provide a cleaner interface, easier to understand the responsibilities of each part, thus reducing the complexity. And the fear of doing so signifies some already existing problems to me.
As I said, they are already separate in many aspects - the GUI is all inside the EXE (and thats all that is in there pretty much) and the hook all inside the DLL... The main communication between them IS the XML settings file (ok there are few other little bits and pieces, to allow the button highlights, layer tab changes etc). Of course, I'm not unhappy to admit its not perfect - some of it (mostly in the hook DLL) is all a bit of a mess (but much less so than a few years ago as I have slowly been refactoring it to a more sensible structure). But thats fairly normal in something that has evolved over 15 years as a hobby
... If I were to start again I would do things differently no doubt.
Killy wrote: ↑Sun Dec 16, 2018 5:28 pm
I see no benefits to keep GUI in memory. Currently, it opens slower than it would be to start a new 50+ MB process anyway, for some reason (for me at least).
Yes the XML library I use seems to be a bit slow - but actually the slowest thing is (it seems) using combo-boxes with lots of entries in them (the button dropdowns) really killed performance in MFC, even after visualizing them... Not something I experience in C# generally (which is my go to day to day environment).
It is probably possible to find a C++ GUI toolkit that will allow to provide more complex controls with low memory footprint, easier to maintain, in case we want to avoid extra runtime dependencies by all costs. But I can't bet on this, it will require more research - I know some libs, but I seldom touch any C++ code.
(With open source project, experiments like this can be done in separate branches.)
If separating it happens, then there would be no point separating it to another C++ app - the whole point would be to get some easier environment.. Although while C# is nicer, Im not sure, when it comes to GUI, there is ever an "easy" environment...