vimprobable-users

[Vimprobable-users] Features for next version

[Daniel C. <dan...@gm...>]

Hi!

Cause of the forthcoming release of the version 1.0 I took advantage of the
situation to ask if there is a roadmap of features to implement for version
1.1 or 1.0.1. If there isn't such a roadmap, maybe we can discuss it here.

Features I want to see implemented:

1) On the project site of uzbl I found a nice JavaScript that can block
   loading of flash objects and load them on mouse click
   (http://www.uzbl.org/wiki/flashblock). But at the time we have no
   possibility to load user specified scripts if a page was opened. I think it
   could be a nice feature to implemented something like the style.css for
   user scripts 'script.js' and a configuration variable to allow/disallow the
   loading of the script file. Is this an over bloated feature or would it be
   a nice to have for someone else too?

2) Often I find myself searching for something interesting via a searchengine
   and opening several results into new browser windows, to read them later.
   Maybe I could configure my windowmanager to open the new windows in the
   Background, to keep on searchengine's result page until I've opened all the
   pages I considered as interesting. But I believe it would be a very
   interesting feature, to have the ability to yank URLs into a list and to
   open them later - something like the 'u' command to open last closed page
   or the 'p' or 'P' command to load URL from clipboard.

   I think we could use a file to yank the URLs into it and have a command to
   open the first URL from it and pop it from the list. After reading the page
   or some related page the command can open the next short time bookmarked
   page. We could use a lowercase letter command to open the next URL from
   list into current window and the uppercase one, to open it into a new
   vimprobable instance. An additional command like :open could be implemented
   to show the entries of the list and to select a URL from it to open. The
   URL list could prevent users from open many pages only for the reason to
   mark them for reading later.

Daniel

Re: [Vimprobable-users] Features for next version

[Serge E. H. <se...@ha...>]

Quoting Daniel Carl (dan...@gm...):
> Hi!
> 
> Cause of the forthcoming release of the version 1.0 I took advantage of the
> 2) Often I find myself searching for something interesting via a searchengine
>    and opening several results into new browser windows, to read them later.
>    Maybe I could configure my windowmanager to open the new windows in the
>    Background, to keep on searchengine's result page until I've opened all the
>    pages I considered as interesting. But I believe it would be a very
>    interesting feature, to have the ability to yank URLs into a list and to
>    open them later - something like the 'u' command to open last closed page
>    or the 'p' or 'P' command to load URL from clipboard.

I like it!  Kind of like readitlater.  For extra points, a third hint follow
option (not sure which keystroke) which just moves the chosen link right
into that list without ever opening it.  'Q<followed by f-like hinting>'
maybe?

-serge

Re: [Vimprobable-users] Features for next version

[Hannes S. <ha...@yl...>]

Hi!

Daniel Carl <dan...@gm...> wrote:
> 1) (http://www.uzbl.org/wiki/flashblock)

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. 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.

> 2) to have the ability to yank URLs into a list and to open them
> later - something like the 'u' command to open last closed page or
> the 'p' or 'P' command to load URL from clipboard.

This is an excellent idea and it should be very easy to implement. If
we get the future hinting policy straightened out, it could even be
possible to squeeze this into the 1.0 release.

Since we're planning, I'd like to bring up one very general point: the
future release/version number policy.

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?

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.

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?

What does everybody think?

Hannes

Re: [Vimprobable-users] Features for next version

[Jason R. <jas...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/08/11 07:14, Hannes Schüller wrote:
> 
> 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?
> 
> 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.

I would favour this approach: allowing those who wish to continue to use
the more minimal browser to do so, and giving those who want to access
the more featureful version that choice.
> 
> 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?

The former: the latter makes Vimprobable 2.0 sound like the later
release of Vimprobable 1.0

Cheers,

/J


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJORtUIAAoJEEReUuqxvU5ARgsIALrwxvkWfi95dbQvdj/r/ktl
iMJX1C9m5i+XPUhDcJWE0oW2WEO/1ivGXx0T7bKNeOc174mp8t29e1bfHP3A2xvc
KfhQlBxdRPyBYsgrhfgghl6NSovljyX0F+FGfWCTSbp8El66A/e7anAED7ZHwO2X
MziiFf4YRSmrd2QylQ2T6kr6xLL6bhbfX0KCVKYu+nV/yGsphiQiGwhn19A96PvI
CAbHJVeyaDNLsNYcBu26qun++spcrbLY4JhGSs/kHfqtMHU0D/p7lJp2R+Tm/9Kt
jQUCJkkO0Ba17viOPSrA3heDhJkxhE7LJvDjs3JiHVPF1KiXtrqi0Lv6XvinfKI=
=4oW8
-----END PGP SIGNATURE-----

Re: [Vimprobable-users] Features for next version

[Matto F. <ma...@ma...>]

Hi,

On Sat, Aug 13, 2011 at 06:43:45PM +0200, Daniel Carl wrote:
 
> 1) On the project site of uzbl I found a nice JavaScript that can block
>    loading of flash objects and load them on mouse click
>    (http://www.uzbl.org/wiki/flashblock). But at the time we have no
>    possibility to load user specified scripts if a page was opened. I think it
>    could be a nice feature to implemented something like the style.css for
>    user scripts 'script.js' and a configuration variable to allow/disallow the
>    loading of the script file. Is this an over bloated feature or would it be
>    a nice to have for someone else too?

I am not a fan of flash and in the day-to-day use of Vimprobable I have never
run into the need of something like this. But I wouldn't vote against it if
it doesn't require much resources.

> 2) Often I find myself searching for something interesting via a searchengine
>    and opening several results into new browser windows, to read them later.

[ ... ]

>    to show the entries of the list and to select a URL from it to open. The
>    URL list could prevent users from open many pages only for the reason to
>    mark them for reading later.

What I have been thinking about is a efficient way to shoot the current URL
into an external script. Whatever that script does, is up to the user.
Perhaps this is a more generic approach, that would allow for something you 
want but also allow users to come up with much more usefull things.

OTOH, I do this now with the usage of the windowmanager. I do a yank of
the current URL into the copy-and-paste buffer, and let ratpoison do the 
work (with "get-selection"). So if this could be done from within 
ratpoison, perhaps it could also be done from within other 
windowmanagers ...

Cheers,

Matto

Re: [Vimprobable-users] Features for next version

[Daniel C. <dan...@gm...>]

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

Re: [Vimprobable-users] Features for next version

[Hannes S. <ha...@yl...>]

Hi!

Daniel Carl <dan...@gm...> wrote:
> On Sat, Aug 13, 2011 at 09:14:25PM +0200, Hannes Schüller wrote:
> > 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?

For once, yes, it would increase source code complexity, yes.
Concerning bugfixes, the opposite of what you assume is the case I'd
say: different branches make more work.

> > 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.

See above, this would still increase code complexity, making it much
less readable, less reliable, more prone to errors and race conditions
etc.

Hannes

Re: [Vimprobable-users] Features for next version

[Daniel C. <dan...@gm...>]

Hi!

I have some feature from pentadactyl that I would like to have already in
vimprobable. The possibility to hit CTRL-I within a textarea to open a
configurable editor with the contents from the textarea. On Save the new
content will be transfered back into textarea. Yes, I can do this handy, but
in this way it's much faster.

For the future we could also think about a simple help system that allows the
user to open helppages on :help.

Daniel

Re: [Vimprobable-users] Features for next version

[Hannes S. <ha...@yl...>]

Jason Ryan <jas...@gm...> wrote:
> > 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?  
> 
> The former: the latter makes Vimprobable 2.0 sound like the later
> release of Vimprobable 1.0

Well, it *is*, isn't it? It's a branch of the original code with stuff
added to it.

Hannes

Re: [Vimprobable-users] Features for next version

[Jason R. <jas...@gm...>]

On 15/08/11 at 08:13am, Hannes Schüller wrote:
> Jason Ryan <jas...@gm...> wrote:
> > > 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?  
> > 
> > The former: the latter makes Vimprobable 2.0 sound like the later
> > release of Vimprobable 1.0
> 
> Well, it *is*, isn't it? It's a branch of the original code with stuff
> added to it.
> 
Ah, I hadn't grasped the nature of the relationship: I thought they were
developed in parallel.

-- 

http://jasonwryan.com/

Re: [Vimprobable-users] Features for next version

[Hannes S. <ha...@yl...>]

Jason Ryan <jas...@gm...> wrote:
> On 15/08/11 at 08:13am, Hannes Sch__ller wrote:
> > Jason Ryan <jas...@gm...> wrote:
> > > > 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?  
> > > 
> > > The former: the latter makes Vimprobable 2.0 sound like the later
> > > release of Vimprobable 1.0
> > 
> > Well, it *is*, isn't it? It's a branch of the original code with
> > stuff added to it.
> > 
> Ah, I hadn't grasped the nature of the relationship: I thought they
> were developed in parallel.

Well, yes, this is also true. Vimprobable2 was branched off
Vimprobable1. Since then, they have been developed in parallel.
However, truely in parallel: Everything has been done in both branches
at the same time save for the addition of new features depending on "2"
exclusive functions.

Hannes

Re: [Vimprobable-users] Features for next version

[Daniel C. <dan...@gm...>]

Hi!
> 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?
In my opinion vimprobable1 and vimprobable2 are two different things and
not only different version of the same programm. I think vimprobable1
should be in a seperate branch with seperate version numbers. Users that
like the vimprobable1 can checkout this branch and can fetch bugfixes
for it and, maybe, some new fetaures.

Vimprobable2/master could be the other branch and have it's own
versionnumbering.

For the features, it could be useful to have fetature branches (could be
prefixed with feature/*), that exists until the feature is merged into
the master/vimprobable1. After merging we could remove the
featurebranches, to ceep the repository clean.

Like mentiones in a pervious post, I would prefer to put all features
into the master branch and allo them to be enabled/disabled via
precompiler options. For the features the complexity with the switchable
features should acceptable. I think, to have only a basic vimprobable2
and several feature branches could make it difficould for users to merge
the wished browser together. For every bugfix in featurebranch the user
have to merge the sources together. Sometimes merging is hard enought
for developers that  knew the code well, but for a user who want to
build the browser it would be harder.

Daniel

Re: [Vimprobable-users] Features for next version

[Hannes S. <ha...@yl...>]

Hi!

Daniel Carl <dan...@gm...> wrote:
> > 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?
> In my opinion vimprobable1 and vimprobable2 are two different things
> and not only different version of the same programm. I think
> vimprobable1 should be in a seperate branch with seperate version
> numbers. Users that like the vimprobable1 can checkout this branch
> and can fetch bugfixes for it and, maybe, some new fetaures.
> 
> Vimprobable2/master could be the other branch and have it's own
> versionnumbering.
> 
> Like mentiones in a pervious post, I would prefer to put all features
> into the master branch and allo them to be enabled/disabled via
> precompiler options.

So, if we went this way, wouldn't this be "Vimprobable3"? I.e. another
new branch separat from the others? I.e.: Doesn't what you're saying
actually *support* my suggestion to open up yet another branch to keep
Vimprobable2 "cleaner"?

Hannes

Re: [Vimprobable-users] Features for next version

[Daniel C. <dan...@gm...>]

Hi Hannes!

On Mon, Aug 15, 2011 at 02:27:20PM +0200, Hannes Schüller wrote:
> So, if we went this way, wouldn't this be "Vimprobable3"? I.e. another
> new branch separat from the others? I.e.: Doesn't what you're saying
> actually *support* my suggestion to open up yet another branch to keep
> Vimprobable2 "cleaner"?
Do you mean, we should use a seperate branch for every more featureful
vimprobable? This could be a way, but we have to maintain 3 different
versions, apply bugfixes on them, test them... .
To seperate Vimprobable1 is usefull, because it's realy something other
then the more featrueful Vimprobable2. But I think it's do hard to have
to many branches with seperate versions.
I think all future features should be avaiable for Vimprobable2 and be
enabled/disabled via config.h

Daniel

Re: [Vimprobable-users] Features for next version

[Ryan M. <rm...@de...>]

Hi,

> 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?

vimprobable1 should be vimprobable-legacy
vimprobable2 should be vimprobable

All new development should be done as vimprobable, IMHO.

Ryan