I didn't want to leave the master branch in a semi-broken state or present what I had come up with in an MR until I could present it as an improvement. It took a while to figure out what I wanted and whether some of what I wanted was even achievable. I haven't been working alone, so some people such as Marco and Nate are aware of the current state of the branch and have been testing it periodically. I'm aiming for a 22.12 release, so I intend to finish the patch over the next month (it's already getting close), leaving 2 or 3 months for additional testing after the merge.
I don't want this discussion to turn into whether or not only my reasons for wanting a higher commit limit/no limit are right, but I recognize it is important to question my reasons since those are a factor in the discussion. On Wed, Aug 24, 2022 at 6:42 PM Milian Wolff <m...@milianw.de> wrote: > > On Mittwoch, 24. August 2022 17:26:33 CEST Noah Davis wrote: > > On Wed, Aug 24, 2022 at 5:12 PM Milian Wolff <m...@milianw.de> wrote: > > > Without any knowledge of your work on the QML port of Spectacle, I would > > > also claim that there is bound to be a lot of generic work that should be > > > possible to land directly in the main branch, no? You are probably > > > splitting up the data representation and UI layer, which can happen > > > early. Then you add a second UI implementation in tandem to the widget > > > one, which can be opt-in until it's ready. Once all is done, you can > > > remove the old widget UI. There's no need to wait a long time for all of > > > this to hit the main branch and work only in a feature branch, no? > > > > The UI is already fairly well separated from the backend simply > > because Spectacle already has a CLI. I simply went through a lot of > > iterations over the past few months in collaboration with Marco while > > trying to come up with the right UI/UX. The branch contains a lot of > > new UI related code that uses Qt Quick/QML. It would be useful for me > > to keep track of these changes so that if anything breaks in the > > process, I can more easily figure out which change did it and ask > > questions if I wasn't the one who made the change. > > Right, as I said I only worked on assumptions in my statement above. > > What prevents you though from merging the partial state of the Qt Quick/QML UI > into the main branch? If you say the code history as it is now is useful, it > should be useful in the future too - and as such could be merged more > regularly? You don't have to enable the new UI for now in the main branch? > > -- > Milian Wolff > m...@milianw.de > http://milianw.de
