On Tue, Oct 25, 2016 at 01:38:17AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > > > I wouldn't bother with this point---fvwm3 should be a separate repository > > > entirely. > > > > Why? Unless some people step up and tell us they'd want to take > > over fvwm2 development, what is the gain of duplicating all > > infrastructure? > > You're assuming fvwm3 is based off fvwm2 for anything. Whilst that might be > true for somethings, I think that should be the exception rather than the > rule. I was serious in my proposal to make fvwm3 a clean break, and it should > be that in its entirety including its own repository.
That leaves much room for interpretation. A "clean break" to me would mean to write it from scratch, and that's practically impossible because the fvwm2 window managing code contains many hundreds of hours undocumented experience with strange applications and optimising communication with the X server. Well, my plan for fvwm3 has always been to make changes to fvwm2 to be able to do things that are not possible with todays code. For example, styles that can be attached to window states or even more complex conditions. One thing that gets in the way of lots of future work is the terrible parser and backwards compatibility of the syntax. I also want to see FvwmButtons being replaced by something flexible, configurable at run time and useable. I have no intention of removing _useful_ features because the code looks ugly. > I question what "infrastructure" might be needed from fvwm2 that would mean > using it as a basis. Developers, repository, webspace. > > That would be good (I'm assuming that you mean just #3). Give me > > some time to organise the fvwm2-stable branch (suggestions for a > > better name welcome maybe "stable-fvwm2"). > > Yes, I was just referring to point #3; let me know when that's good to be > done. As soon as we know that nothing important is missing from dv/stable-fvwm2. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
