Closed sabeechen closed 1 year ago
I think that's a great initiative, @sabeechen
From a roadmap point of view, these are the major things that might happen from now on:
So, right now I understand the E-TKT's archetype is pretty solid, which means the approach you brought makes sense and will not prevent any development. Instead, it might even improve as collaboration will surely take advantage of that clear structure.
Also, for me it will be surely a great opportunity to learn, I'm looking forward to it! I trust whatever you bring ;)
Great idea, i agree! I would probably go for one piece at a time, simpler to get an overview and there are a lot of moving pieces. Today the code is quite interleaved and many things rely on each other, for example the print progress is updated in a display function. Sort of makes sense since that functionality is available there but not if you are looking to create functional modules with clean, well defined interfaces. Will be interesting to see where it goes, i would probably go for a function based layout instead (display, print, music, web), but both have merit.
If you do a music module, would you make that non-blocking? Cuz that would be cool 😄
Yeah, its got some oddities. But maybe it won't for much longer? I made a proposal for my massive refactor in this PR. Non-blocking execution is on my mind, but won't be in this change. Its a tricky thing to get working in the device's state model but possible down the line.
Implemented on #46
I think it would be a good idea to refactor the E-TKT from its current (largely) single file structure into one that encapsulates its functionality into multiple classes. There are many advantages to this, but the biggest I see are:
These are the typical upsides of breaking up and encapsulating functionality. As usual it also comes with some downside, if things are broken up naively then it can often become more work to add functionality because the relationships between parts doesn't reflect what they actually need to do. My goal would be to avoid that, and I think I'm familiar enough with the project to do it well. I have a lot of professional experience doing this kind of thing, though not specifically with C++.
Here is how I'm initially thinking of breaking things up:
While actually untangling the relationships whats needed might change, but I think its likely things will look close to this.
From my personal experience its better to make big changes like this quickly all at once to minimize the time it impacts people with pending changes. Id want to break it all up quickly and coarsely in one PR, when go through and refactor/clean up individual classes by themselves at a more leisurely pace.
Alternative would be to check-in each new class one at a time, slowly carving out functionality from LabelMaker.cpp. This is less disruptive to concurrent contributors but can take a lot longer to complete.
As things are broken up I'd like to move toward enforcing a C++ style, the most obvious choice is probably Google C++ Style with clang, but any of the common alternatives would be fine so long as its adhered to, including something we make custom. Most projects choose one of the well-known styles (Google, Microsoft, Mozilla, etc) and then just override rules as they see fit.
@andreisperid You have your finger on the pulse of whats going on with this project currently. Do you think this is a good idea, and if so do you think now is a good time to do it?