netrik-general — all kinds of discussions, ideas, announcements etc.

Re: [netrik] branches (was: Finish to replace option --monochrome by --bw)

[Stéphane A. <sa...@fr...>]

Hello,

Le mercredi 03 décembre 2014 à 02:25:03, Olaf Buddenhagen a écrit :
> On Tue, Dec 02, 2014 at 12:50:32PM +0100, Stéphane Aulery wrote:
> 
> > I look at the CVS web interface but do not see the commit. I wonder if
> > this is the right repository.
> 
> It's not in HEAD; but it should become visible when you select the
> "b1_16" branch -- which is what the last two releases were made from;
> and where the next bugfix release will also be made from, if we do
> one...

Yes, I had not seen. I'm not used to CVS. I have all the information I
need, thank you.

Regards,

-- 
Stéphane Aulery

[netrik] branches (was: Finish to replace option --monochrome by --bw)

[Olaf B. <ola...@gm...>]

Hi,

On Tue, Dec 02, 2014 at 12:50:32PM +0100, Stéphane Aulery wrote:

> I look at the CVS web interface but do not see the commit. I wonder if
> this is the right repository.

It's not in HEAD; but it should become visible when you select the
"b1_16" branch -- which is what the last two releases were made from;
and where the next bugfix release will also be made from, if we do
one...

A lot of the recent fixes exist only on the 1.15.x and 1.16.x release
branches. The idea was to merge them back to HEAD only once a major
round of refactoring on the HEAD branch is complete...

-antrik-

Re: [netrik] Finish to replace option --monochrome by --bw

[Stéphane A. <sa...@fr...>]

Hello,

Le mardi 02 décembre 2014 à 04:46:45, Olaf Buddenhagen a écrit :
> 
> On Fri, Nov 21, 2014 at 10:40:56AM +0100, Stéphane Aulery wrote:
> > 
> > and I have made a patch to fix embedded documentation in screen.c for
> > --monochrome / --bw option.
> 
> Thanks for the fix :-) I committed it to the "stable" (1.16.x) branch.
> (Along with some related documention fixes...)

Thank you very much !

I look at the CVS web interface but do not see the commit. I wonder if
this is the right repository. I wanted to have a record for later when the
maintainer will modify the package.

Regards,

-- 
Stéphane Aulery

Re: [netrik] Finish to replace option --monochrome by --bw

[Olaf B. <ola...@gm...>]

Hi Stéphane,

On Fri, Nov 21, 2014 at 10:40:56AM +0100, Stéphane Aulery wrote:

> A user of netrik reported this bug :
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720134
> 
> and I have made a patch to fix embedded documentation in screen.c for
> --monochrome / --bw option.

Thanks for the fix :-) I committed it to the "stable" (1.16.x) branch.
(Along with some related documention fixes...)

-antrik-

[netrik] Finish to replace option --monochrome by --bw

[Stéphane A. <sa...@fr...>]

Hello,

A user of netrik reported this bug :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720134

and I have made a patch to fix embedded documentation in screen.c for
--monochrome / --bw option.

Can you integrated it please ?

Thanks for yours help.

Regards,


-- 
Stéphane Aulery

[netrik] Progress

[Andrey K. <kon...@gm...>]

Hi,

Is netrik still being developed? CVS seems pretty old.

Best wishes,
AVK

Re: [netrik] hascii

[<ola...@gm...>]

Hi,

On Wed, Dec 22, 2010 at 07:30:53PM +0100, Benjamin Koppe wrote:

> Do you plan to include the hascii software in order to watch youtube
> etc in text mode?

Do you mean HasciiCam, as in http://ascii.dyne.org/ ? If so, this is a
server-side solution vor ASCII video streaming. It makes no sense for a
web browser. Rather, we'd need to implement something client-side with
aalib (which is used at the core of HasciiCam as well BTW) or libcaca.

As for plans: I'm rather sceptical. In the very beginning, I considered
doing something like that; but I concluded that it wouldn't be useful.
While the actual video content might render good enough to be somewhat
usable, the UI controls programmed in Flash wouldn't.

This might be worth reconsidering for the HTML5 <video> tag though, as
in this case the UI is implemented by the browser itself.

-antrik-

[netrik] hascii

[Benjamin K. <Ben...@gm...>]

Do you plan to include the hascii software in order to watch youtube  
etc in text mode?

Re: [netrik] @longdesc support in netrik

[Leif H. S. <xn-...@xn...>]

ola...@gm..., Fri, 15 Oct 2010 11:53:23 +0200:
> On Wed, Oct 13, 2010 at 03:13:53AM +0200, Leif Halvard Silli wrote:
> 
>> netrik currently has no support for @longdesc.
> 
> Hm... Doesn't sound too hard to fix. I'll try to prioritize it when I
> get back to netrik hacking :-)

Cool :) 
 
>> I have a concrete proposal for how it should be implemented: The best
>> approach seems to me to be to implement it as if the image is an image
>> map, where the URL inside @longdesc represents the link of the image
>> map.
> 
> Well, there is actually no support for image maps in netrik so far. It's
> not a high priority feature -- I don't remember ever missing it...

Then I think netrik is the only text browser without image map support. 
Lynx, Elinks, Links, w3m and retawq all have it. You should probably 
implement both. :-)
 
> I think it should be pretty easy though simply to translate image maps
> as a list of links. Longdesc would indeed be kinda similar in this
> regard 

It is so cool when people agree. :-)

> -- however, the code actually implementing the translation would
> be totally distinct I believe.

OK. Interesting. But I guess it is also valuable to have similar 
concepts even if the code is different ... 

>> Text based browsers has a certain user base amongst blind users
> 
> Yeah, I know... That's where most feedback came from in the past :-)
> Thus prioritizing longdesc support probably makes sense...

Glad to hear it. I'd be happy to test, whenever you have something!
-- 
leif halvard silli

Re: [netrik] @longdesc support in netrik

[<ola...@gm...>]

Hi,

On Wed, Oct 13, 2010 at 03:13:53AM +0200, Leif Halvard Silli wrote:

> netrik currently has no support for @longdesc.

Hm... Doesn't sound too hard to fix. I'll try to prioritize it when I
get back to netrik hacking :-)

> I have a concrete proposal for how it should be implemented: The best
> approach seems to me to be to implement it as if the image is an image
> map, where the URL inside @longdesc represents the link of the image
> map.

Well, there is actually no support for image maps in netrik so far. It's
not a high priority feature -- I don't remember ever missing it...

I think it should be pretty easy though simply to translate image maps
as a list of links. Longdesc would indeed be kinda similar in this
regard -- however, the code actually implementing the translation would
be totally distinct I believe.

> Text based browsers has a certain user base amongst blind users

Yeah, I know... That's where most feedback came from in the past :-)
Thus prioritizing longdesc support probably makes sense...

-antrik-

[netrik] @longdesc support in netrik

[Leif H. S. <xn-...@xn...>]

Hi!

netrik  currently has no support for @longdesc. 
@longdesc provides "link to long description (complements alt)". 
See: http://www.w3.org/TR/html4/index/attributes.html 
Example: <img alt="Chart fo the development" 
longdesc="description-of-chart" src=i.jpg >
Example page: http://malform.no/testing/longdesc/im...@lo...

Any chance that netrik could implement @longdesc support?

I have a concrete proposal for how it should be implemented: The best 
approach seems to me to be to implement it as if the image is an image 
map, where the URL inside @longdesc represents the link of the image 
map.

Thus, practically speaking, I would expect @longdesc to work in netrik, 
more or less the same way the following image map example works: [1]

|1] http://malform.no/testing/longdesc/ARIA+area@rel=longdesc.html

(That example [1] has been crafted solely in order to show one may 
mimic the @longdesc behavior by using a simple image map.)

One particular detail: For image maps, the link text is provided via 
the @alt attribute of the <area> element. However, for @longdesc, 
screenreaders such as the well known Jaws, offers a "hard coded" text.  
In Jaws's case, the hard coded text is "Press enter for long 
description". And hence in the example [1], the @alt attribute of the 
<area> element provides "Press enter for long description" as the link 
text, in order to replicate how @longdesc works in Jaws.

Whether netrik should do the same, or if netrik should simply present 
the address of the link as link text, is probably up for debate. 
Perhaps a combination: Offer a hard coded text, in combinatio with the 
URL. Something like this:

        Long description: http://example.com/long/desc.html

The latter seems optimal to me.

PS: I have also filed the same bug for Elinks ... text browsers have 
pretty uniform support for image maps, and I hope that they could 
implement @longdesc uniformly too. See 
http://bugzilla.elinks.cz/show_bug.cgi?id=1104 I have also suggested 
for Lynx that they too implement @longdesc - see Lynx' mailinglist and 
this bug: http://savannah.nongnu.org/bugs/index.php?31319

Text based browsers has a certain user base amongst blind users - and 
@longdesc's purpose is to point to a description of an image, so the 
blind can understand it better than a short @alt text may do. Hence, it 
would be great if you could implement it.

Btw, this page collects information about support and use of @longdesc: 
http://www.d.umn.edu/~lcarlson/research/ld.html -- leif halvard silli
-- 
leif halvard silli

Re: [netrik] Input System Proposal

[sarneaud <Sim...@ut...>]

Okay, sorry it's been a month.

Here are the files and patches for the input system.  I've seen a few vi-inspired projects that could do with this functionality, so I've coded it keeping open the idea of sucking most of it into a shared library.

As a rough overview, there's
* an FSM engine (inputFSM.c)
* a bunch of bindable commands (key-commands.c)
* a spec for the system data (inputData.vic)
* a compiler for the above spec (compiler)
* a PATRICIA trie implementation (trie.c)
 
> > > > My code also has a basic implementation of page marking 
> with m 
> > > and '.
> > > 
> > > Well, this is one thing I originally meant to implement; but 
> I must
> > > admit that I'm not so sure anymore... While it seems useful, 
> I don't
> > > think I ever actually used this feature in w3m -- probably because
> > > it's needed so seldom, that in the few cases where I *could* have
> > > used it, I didn't even think of the possibility...
> > > 
> > > I'd like to know whether it's just me, and other people use 
> it more
> > > regularily?
> > 
> > Hmm, I use it heaps in vi, sometimes in less and rarely in 
> vimperator.
> I don't think I ever used it in less... But perhaps that's 
> because I
> usually use Vi when reading larger texts :-)
> 
> > Vimperator quickmarks are what I really use.
> 
> What's that?
> 
> Note that I don't really know much about Vimperator... When I first
> tried it a couple of years ago, it was too buggy to be useful -- 
> and I
> couldn't motivate myself to try it again since then :-(

Quickmarks are, for me, the best feature of Vimperator.  If there were no other reason for having a vi-like interface, I'd probably install Vimperator for the quickmarks.

They are like bookmarks but faster.  They are like the regular marking feature but for the web as a whole.  For example, one day I loaded up my webmail page and typed 'Me'.  Now I can go back to that page instantly by keying 'goe'.  I have a bunch of these marks.  'goc' gives me a C/C++ library reference; 'goB' takes me to internet banking.

Re: [netrik] Input System Proposal

[<ola...@gm...>]

Hi,

On Sat, May 15, 2010 at 09:20:22PM +1000, sarneaud wrote:
> From: ola...@gm...

> > I must admit that over the years, I have become pretty sceptical
> > about configurability in general.
> > 
> > For one, it tends to add considerable complexity that few people
> > actually use. The more individualist ones will probably configure
> > their own keybindings the first time they set it up; and perhaps
> > also the second... But when sitting at another system for the third
> > or fourth time, they's just go "oh fuck it", and stick with the
> > defaults.
> 
> I agree.  Personally, I've tweaked a few keys on my Vimperator install
> but I expect most users won't care.  I think it's more likely that
> users will download key configs made by others than make their own if
> they want changes.  Configurability is a just side benefit of keeping
> data out of the code.

Well, data-driven implementations are generally preferable for
performance reasons :-)

I'm just not sure it's worthwhile to make the data runtime-loadable...
It tends to make the code considerably more complicated, and much harder
to manage changes.

I don't think I would really object if someone actually implemented
loadable keybindings, as long as it doesn't make things much more
complex. However, I definitely don't consider it a ToDo item :-)

> > There is a deeper problem as well: trying to cover various options
> > in the UI limits the possibilities for optimisation. Changing the
> > behaviourin one single point means that other things become
> > inconsistent,awkward, or outright impossible. For a consistent and
> > efficient UI, all bits need to be custom-fit to each other -- it
> > just doesn't work when individual options can be configured
> > independently.
> 
> In this case, though, I'm certain there will never be any overall
> benefit to optimising the response time to special cases of keyboard
> input sequences.

I wasn't talking about code optimisation here :-)

When talking about UI efficiency, I mean reducing the number of
keystrokes necessary to perform common tasks; making things more logical
and streamlined; etc.

Talking about Vi vs. Emacs keybindings specifically, the different
interaction approach (modal vs. non-modal) has major implications on
functionality. In Readline for example the Vi mode misses some features
compared to the default Emacs mode, because implementing them would
require a different approach, and nobody took the trouble...

For a more complex UI, it can only get harder.

> > Also note that I don't really believe in static configuration files.
> > Almost all settings should be possible to change within the running
> > application.
> > 
> > (Admittedly, netrik doesn't have any facility for this so far...)
> 
> I agree that would be neat.  Most programs with good runtime
> configurability persist the configuration with config files, of
> course.

Right :-)

> > Indeed this is *one* of the reasons why I have preferred the FSM
> > approach: my original plan was at some point to implement some kind
> > of continuation mechanism, so we could get parallelism without using
> > threads...
> > 
> > However, nowadays I think that functionality which is seperate
> > enough to make sense running in parallel, most of the time probably
> > can be split off into separate processes alltogether.
> 
> Both approaches have pluses and minuses so I don't think it's clear
> right now.

Well, it's rather clear to me :-)

I'm not sure yet along which lines the modularisation should be done
exactly; but separating the layouting and the UI into different
processes is definitely going to be part of it...

Note that uzbl proves this is doable. (In fact the ideas of uzbl are
very similar to mine in some regards -- though the implementation I
envision for netrik will be very different in a number of points...)

> My feeling is to make the code clean enough that either (or both) can
> be taken up in future, which isn't a bad idea anyway. *shrug*

I'm all for making code clean :-) However, the goal should be
implementing the *current* functionality in the cleanest possible way.
Trying to design code with future uses in mind tends to achieve the
opposite...

There is actually enough proof of that in the existing netrik codebase.
When I originally wrote the layouting code, I wasn't familiar with the
YAGNI principle yet :-(

Anyways, to make it very clear: I like the FSM approach in it's own
right. This discussion is really just some general musings, with no
direct application to the code in question :-)

> > > My code also has a basic implementation of page marking with m 
> > and '.
> > 
> > Well, this is one thing I originally meant to implement; but I must
> > admit that I'm not so sure anymore... While it seems useful, I don't
> > think I ever actually used this feature in w3m -- probably because
> > it's needed so seldom, that in the few cases where I *could* have
> > used it, I didn't even think of the possibility...
> > 
> > I'd like to know whether it's just me, and other people use it more
> > regularily?
> 
> Hmm, I use it heaps in vi, sometimes in less and rarely in vimperator.

I don't think I ever used it in less... But perhaps that's because I
usually use Vi when reading larger texts :-)

> Vimperator quickmarks are what I really use.

What's that?

Note that I don't really know much about Vimperator... When I first
tried it a couple of years ago, it was too buggy to be useful -- and I
couldn't motivate myself to try it again since then :-(

> Because it's such a vi thing, maybe it's worth having a simple
> implementation anyway, in such a way that it is low overhead (an extra
> pointer per page) when not used.

Yeah, I'm a bit undecided about this; but not really opposed.

It's not the implementation that concerns me here though, but rather
using up two more keys :-) I wonder whether we might run low on
available keybindings, once all missing features are in place...

BTW, you haven't posted your code yet, have you? I'm eager to see it :-)

-antrik-

Re: [netrik] Input System Proposal

[sarneaud <Sim...@ut...>]

----- Original Message -----
From: ola...@gm...
Date: Saturday, May 8, 2010 3:02
Subject: Re: [netrik] Input System Proposal
To: net...@li...

> I must admit that over the years, I have become pretty sceptical about
> configurability in general.
> 
> For one, it tends to add considerable complexity that few people
> actually use. The more individualist ones will probably 
> configure their
> own keybindings the first time they set it up; and perhaps also the
> second... But when sitting at another system for the third or fourth
> time, they's just go "oh fuck it", and stick with the defaults.

I agree.  Personally, I've tweaked a few keys on my Vimperator install but I expect most users won't care.  I think it's more likely that users will download key configs made by others than make their own if they want changes.  Configurability is a just side benefit of keeping data out of the code.

> There is a deeper problem as well: trying to cover various 
> options in
> the UI limits the possibilities for optimisation. Changing the 
> behaviourin one single point means that other things become 
> inconsistent,awkward, or outright impossible. For a consistent 
> and efficient UI, all
> bits need to be custom-fit to each other -- it just doesn't work when
> individual options can be configured independently.

In this case, though, I'm certain there will never be any overall benefit to optimising the response time to special cases of keyboard input sequences.

> Also note that I don't really believe in static configuration files.
> Almost all settings should be possible to change within the running
> application.
> 
> (Admittedly, netrik doesn't have any facility for this so far...)

I agree that would be neat.  Most programs with good runtime configurability persist the configuration with config files, of course.
 
> ...
> Indeed this is *one* of the reasons why I have preferred the FSM
> approach: my original plan was at some point to implement some 
> kind of
> continuation mechanism, so we could get parallelism without using
> threads...
> 
> However, nowadays I think that functionality which is seperate 
> enough to
> make sense running in parallel, most of the time probably can be split
> off into separate processes alltogether.

Both approaches have pluses and minuses so I don't think it's clear right now.  My feeling is to make the code clean enough that either (or both) can be taken up in future, which isn't a bad idea anyway. *shrug*

> > My code also has a basic implementation of page marking with m 
> and '.
> 
> Well, this is one thing I originally meant to implement; but I must
> admit that I'm not so sure anymore... While it seems useful, I don't
> think I ever actually used this feature in w3m -- probably 
> because it's
> needed so seldom, that in the few cases where I *could* have 
> used it, I
> didn't even think of the possibility...
> 
> I'd like to know whether it's just me, and other people use it more
> regularily?

Hmm, I use it heaps in vi, sometimes in less and rarely in vimperator.  Vimperator quickmarks are what I really use.

Because it's such a vi thing, maybe it's worth having a simple implementation anyway, in such a way that it is low overhead (an extra pointer per page) when not used.

Simon

Re: [netrik] Input System Proposal

[<ola...@gm...>]

Hi,

On Thu, May 06, 2010 at 12:20:14PM +1000, sarneaud wrote:

> Hi, I came across netrik when I was looking for a browser that would
> let me read html documentation conveniently.  I love the vi interface
> of vimperator and the rapid load time of links and netrik seems to be
> heading for a best of both worlds.

I see. Good to know about specific use cases :-)

> Anyhow, I've come up with a way to handle complex keyboard input and
> built a working sample into the netrik source.

Great :-)

> Complex keyboard handling involves managing a lot of different states,
> so in this system input is handled using a finite state machine (FSM).

Indeed that's what I was considering myself. In fact all the parsers
(HTML, HTTP, URL) in netrik use an FSM approach as well :-)

> * Configurability.  The FSM is configured using a (soon-to-be)
> user-friendly config file.  If the user prefers emacs-style bindings,
> that should be fine.

I must admit that over the years, I have become pretty sceptical about
configurability in general.

For one, it tends to add considerable complexity that few people
actually use. The more individualist ones will probably configure their
own keybindings the first time they set it up; and perhaps also the
second... But when sitting at another system for the third or fourth
time, they's just go "oh fuck it", and stick with the defaults.

However, that's only the individualist ones -- the majority of people
won't even bother the first time...

There is a deeper problem as well: trying to cover various options in
the UI limits the possibilities for optimisation. Changing the behaviour
in one single point means that other things become inconsistent,
awkward, or outright impossible. For a consistent and efficient UI, all
bits need to be custom-fit to each other -- it just doesn't work when
individual options can be configured independently.

The only realistic way to customize the UI is writing alternative
implementations, with their own complete set of consistent keybindings,
behaviours, etc.

Thus I'm more inclined towards the route that "less" has chosen: offer
the most common key combinations from both Vi and Emacs, but don't
implement any configurability. (Except perhaps for special cases like
the alternative cursor key handling that's already in place for the
benefit of braille interface users...)

Having said that, it would be nice to have a "map" facility for macros
like in Vi; and this can *also* be used for completely changing the
keyboard mapping, though only in a rather awkward fashion...

Also note that I don't really believe in static configuration files.
Almost all settings should be possible to change within the running
application.

(Admittedly, netrik doesn't have any facility for this so far...)

> * Multi-task friendliness.  The more involved commands (such as
> document search) currently keep state using function calls, which
> block all other processing.  Because the FSM automatically keeps track
> of state, it should be straightforward, for example, to have an
> incremental search happening while pages are loading in the
> background, without any special coding.

Indeed this is *one* of the reasons why I have preferred the FSM
approach: my original plan was at some point to implement some kind of
continuation mechanism, so we could get parallelism without using
threads...

However, nowadays I think that functionality which is seperate enough to
make sense running in parallel, most of the time probably can be split
off into separate processes alltogether.

I haven't yet started reworking netrik in such a manner; but it formed
into a rather firm determination by now...

On the other hand, going by YAGNI, until I actually start doing it, this
plan shouldn't affect the current design :-) Also, there might be some
cases where in-process concurrency will still be necessary. In either
case, it can't hurt to have the option.

(Just to be clear: I like the FSM approach anyways, regardless of these
considerations :-) )

> Also, because it's a complete system for keyboard input, other things
> are possible, such as vi-style command repeats.  This is already
> implemented.  "20l" scrolls down 20 lines.

Great :-)

> My code also has a basic implementation of page marking with m and '.

Well, this is one thing I originally meant to implement; but I must
admit that I'm not so sure anymore... While it seems useful, I don't
think I ever actually used this feature in w3m -- probably because it's
needed so seldom, that in the few cases where I *could* have used it, I
didn't even think of the possibility...

I'd like to know whether it's just me, and other people use it more
regularily?

> If you are interested, I can upload my code and go into more technical
> details about how it works.

Sure :-) It's one of the things that have been on the ToDo list for a
long time.

-antrik-

[netrik] Input System Proposal

[sarneaud <Sim...@ut...>]

Hi, I came across netrik when I was looking for a browser that would let me read html documentation conveniently.  I love the vi interface of vimperator and the rapid load time of links and netrik seems to be heading for a best of both worlds.

Anyhow, I've come up with a way to handle complex keyboard input and built a working sample into the netrik source.  Complex keyboard handling involves managing a lot of different states, so in this system input is handled using a finite state machine (FSM).  The advantages of this are

* Ease of use.  All states are managed automatically, so adding sophisticated features is straightforward.  For example, using key sequences like vimperator's "gg" is no problem at all.

* Configurability.  The FSM is configured using a (soon-to-be) user-friendly config file.  If the user prefers emacs-style bindings, that should be fine.

* Multi-task friendliness.  The more involved commands (such as document search) currently keep state using function calls, which block all other processing.  Because the FSM automatically keeps track of state, it should be straightforward, for example, to have an incremental search happening while pages are loading in the background, without any special coding.

Also, because it's a complete system for keyboard input, other things are possible, such as vi-style command repeats.  This is already implemented.  "20l" scrolls down 20 lines.  My code also has a basic implementation of page marking with m and '.

If you are interested, I can upload my code and go into more technical details about how it works.

Regards,
Simon

[netrik] 1.16.1 (and 1.16.0) release

[<ola...@gm...>]

Hi,

I have finally released 1.16.1, which links links libncursesw instead of
libncurses. (And also includes the ncursesw headers -- though this is
actually meaningless as far as I can tell...)

I'm not quite sure why this is necessary: normal ncurses used to pass
through utf8 characters just fine when running in an utf8 locale, but in
recent systems (Debian lenny) it doesn't anymore -- while using ncursesw
restores the previous behaviour. (The patch was originally created for
Debian by Gerfried Fuchs.)

This doesn't mean there is proper utf8 support now: this fix only
restores the previous, somewhat working state. Proper utf8 support
requires handling multibyte characters, and some other fixes. (Proper
translation of character entity references.)

I think I also never announced 1.16 here, which I released last year. It
has the "link selection mode" feature contributed by Evan Gates.

-antrik-

[netrik] User interface ideas (was: Netrik or Elinks?)

[<ola...@gm...>]

Hi,

On Sun, Dec 28, 2008 at 07:20:45PM -0800, Janos Barbero wrote:

> Anyway, there are a lot of references on the netrik site to all the
> planned UI features, and why netrik has or will have such a great UI.
> Could you tell me briefly what these features are, or link to a
> document describing them?

Well, unfortunately this is not so easy -- I'm very poor at putting my
ideas into words :-(

You might want to read the long rambling near the end of this mail:

   http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local

It also touches on things only remotely related to user interface, but I
think it's the most complete description of my vision I have written so
far... I hope you will be able to get a rough idea about my plans
regarding user interface from it.

I actually started my blog ( http://tri-ceps.blogspot.com ) for the
purpose of writing up my ideas regarding user interfaces; but I find
that I'm not able to post often enough to cover the bulk of them. I
didn't get around to write about most of my major ideas so far :-(

-antrik-

[netrik] Netrik or Elinks?

[Janos B. <jbarbero@u.washington.edu>]

Hello,

I would like to contribute to one of these projects to address
shortcomings and get myself a good text-mode browser. Elinks right now
does nearly all of what I need, but there are a few things that could
be more useful.

Anyway, there are a lot of references on the netrik site to all the
planned UI features, and why netrik has or will have such a great UI.
Could you tell me briefly what these features are, or link to a
document describing them? It would be more logical for me to
contribute to elinks development because it's so much more
feature-complete, but the description of your plans for netrik sound
intriguing.

Thanks,
Janos

Re: [netrik] looking forward

[<ola...@gm...>]

Hi,

On Tue, Nov 18, 2008 at 02:22:19PM +0100, wakeup wrote:

> I am really happy to see a www-browser project with goals similar to
> my wishes. :) Keep it up, I am looking forward to your further
> releases and maybe I will drop by when my C experience is expanded.

Thanks for your note -- such feedback is a very good motivation to keep
going :-)

-antrik-

[netrik] looking forward

[wakeup <wa...@er...>]

Hey,
I am really happy to see a www-browser project with goals similar to my
wishes. :) Keep it up, I am looking forward to your further releases and
maybe I will drop by when my C experience is expanded.

-- 
An Ashanti Proverb from Ghana - It is because of beauty, that is why the
woman holds her breasts when she runs, not because the breasts are going
to fall -Fela Kuti

[netrik] vimperator (was: PDF file support?)

[<ola...@gm...>]

Hi,

On Thu, Sep 18, 2008 at 10:02:54AM +0200, Andreas Altergott wrote:

> There is a firefox plugin called vimperator.  Probably this is what you  
> are looking for.

Well, while vimperator is a nice idea, last time I tried it, it worked
so poorly that I had to disable it again :-(

-antrik-

Re: [netrik] PDF file support?

[<ola...@gm...>]

Hi again,

On Mon, Sep 15, 2008 at 05:53:31AM +0200, ola...@gm... wrote:
> On Sat, Sep 13, 2008 at 08:23:33AM +0200, Andreas Altergott wrote:

> > Would it be better to use wget for downloading or implement an own
> > downloading function?
>
> I don't see any reason not to use wget here

Actually, on closer consideration, I do see issues: It's redirects again
that spoil the fun. (This was also the main motivation behind the native
loader in the first place...)

If we save files to disk, we want to extract the base name from the URL,
which we can only do after following all redirects. If we want to launch
an external viewer, we need to know the MIME type, which again we only
know after following all redirects. In either case, Wget is ruled out
:-(

-antrik-

Re: [netrik] PDF file support?

[Andreas A. <alt...@mi...>]

Hi,

Hy Ginsberg wrote:
> Netrik opened my eyes to the possibilities -- I had no idea.  After much 
> consideration I think that what I am really looking for is a simple, 
> lightweight, fast and efficient, keyboard-driven browser; text based is 
> nice because it generally means all those things, but if there was a GUI 
> based browser that fit the bill, that would be fine.  I had high hopes 
> for Opera, but I'm disappointed -- it 
> takes forever to start up, and it tries to be a window manager, which is a 
> bad idea -- I have a really nice window manager ("awesome"), and Opera 
> plays poorly with it.  Any idea if there are any decent options out there?

There is a firefox plugin called vimperator.  Probably this is what you 
are looking for.

Web presence of vimperator
<http://vimperator.mozdev.org/>


Greetings,
Andreas

Re: [netrik] label patch

[<ola...@gm...>]

Hi,

On Fri, Jan 11, 2008 at 05:23:16PM +0100, ola...@gm... wrote:

[Regarding the "label" feature on the b1_16 branch.]

> I'd like to wrap this up and push out a release.
> 
> I view of that, let's discuss the remaining issues.
[...]

As Evan somehow disappeared, I now did the suggested changes (with a
couple of corrections), and a few more. Aside from missing
documentation, it is ready for release now I think.

However, I'm still not completely sure whether we really should release
this feature at all... It certainly is convenient -- I just wonder
whether a similar level of convenience could not be achieved with some
other, more generic features.

As these other features are not likely to go in very soon though, it's
definitely useful for the time being. I just fear that once it is in, it
will be very hard to drop it again, even once the alternatives are in
place...

-antrik-