Re: [Vimprobable-users] Features for next version
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
From: Daniel C. <dan...@gm...> - 2011-08-14 17:53:30
|
Hi! On Sat, Aug 13, 2011 at 09:14:25PM +0200, Hannes Schüller wrote: > As mentioned in previous discussions, I don't care at all about that - > simply because I don't have Flash installed, so I don't need to block > it. The blocking of flash wasn't the point of interest. It was only an example for running JavaScript from user for every Pageload. > It seems to be a popular request, though. If it is done, my only > request is that it should actually *block* these elements, not just > *hide* them. If I read the script right the flash is blocked. > As announced already, I would put the version 1 branch into bug-fixing > mode. The question is: Should we do the same for the version 2 branch > and make future development on a completely new one? I'm not even sure if it's a good idea to separate vimprobable1 and vimprobable2 into different branches. It make the maintaining a little easier, but I think to apply bugfixex also to the version 1 could be forgotten. I'm not using version 1 and so I apply patches only for version 2. I'm not familar with the version 1, but could we use precompiler flags to let the user decide which version to compile, or would this make the sources to complicate to understand? > The reason I'm proposing this is this: Adding more and more features > obviously makes the browser more 'fat' gradually. This might go too far > for some people. Continuing development on the same branch would mix up > bugfixes and new features, making it "all or nothing" for the users: > If they want bugfixes, they also have to take the new features they > probably don't even want. On the other hand, starting new branches > regularly allows people to either go on following the bleeding edge > development or sticking to a trusted, feature-frozen, but nevertheless > maintained version. Maybe we can follow the vim, that allows the user to compile in different fat versions or to enable/disable every single feature by hand. So we don't have to apply bugfixes on several branches. > On a related note, there is the question of version numbering. Should > we have: > - Vimprobable1 1.0 and Vimprobable2 1.0 or > - Vimprobable 1.0 and Vimprobable 2.0? Could we abandon the deviding of version 1 and 2 and have only one flexible to compile vimprobable? Vimprobable1 could be a vimprobable compiled with tiny option, vimprobable2 compiled with the huge option, or so. Daniel |