On Wed, Jan 21, 2015 at 3:02 PM, Ben Fritz <[email protected]> wrote: > On Wednesday, January 21, 2015 at 1:33:35 PM UTC-6, Tim Lebedkov wrote: > > > > > > my patch "Switch the NSIS installer to MUI2" > > > > (https://code.google.com/p/vim/issues/detail?id=279) was not > > > > merged in 2 months. This is clearly too slow for 20 lines of > > > > changes.
Interesting, my installer has been using MUI for a very long time. I just built one with MUI2.nsh but don't notice any differences. Are the defaults actually different, or does the second simply have more capability? This patch does appear to be very straight forward. But the Vim Windows installer has always used a separate binary installer within the package to do the heavy lifting. So there's really not a "need" to improve the current installer or add capabilities. That said, my (Cream) Windows installer bypasses Vim's default binary installer entirely. It was a personal itch. I wanted to improve: o Terminal windows popping open during installation o Command prompt entries for installation options on a GUI software o The binary inflexibility in properly installing shortcuts, menu items, and registry entries (you have to patch the installer code in C to adjust installation options) o Modern installation splash graphics, icons, and interface NSIS has plenty of capability to manage these so I let it. Since my audience was the Cream for Vim one, it seemed appropriate. But the typical Vim audience is an entirely different one. > > > For a beginning, you could maintain a separate installer so that > > > people can actually try that it works and you get feedback. Then > > > you can also gradually change further things, if this is > > > required. That's what I did. It started out as just for me, but I pushed them up for others to use, occasionally cleaning up a bit here and there. Now the Cream builds have over 500k downloads. This is also good to identify build environment idiosyncracies. Other than my custom NSIS, I use strict defaults in Vim code and dependent libraries. Rarely, I get feedback about some particular environment which nearly always gets traced to the dependent, but once or twice to Vim. > > If my changes will be merged with speed of 20 lines every 2 years, > > it would take 100 years to merge 1000 lines. [...] Ben's lengthy comments (removed) are right on. The goal is stable and maintainable software. The addition of features compounds required maintenance efforts. For necessary fixes or features, core adjustments like these might be feasible, but there are precious few big features being added these days. Stay engaged with the development community and fix bugs. Maybe set up a webpage to host your patches, builds, and commentary. That's the best way to contribute back to a project so long standing. Over time, a contributor's stature will grow in proportion to their contributions and their input will become correspondingly weighted. There have been many contributors come and go over the years, but Bram is still here maintaining the project and their features! -- Steve Hall [ digitect dancingpaper com ] Cream for Vim http://cream.SourceForge.net SteveHallArchitecture http://SteveHallArchitecture.com -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
