Re: [elinks-users] color schemes

[cga2000]

On Wed, Jun 07, 2006 at 08:59:24AM EDT, Jonas Fonseca wrote:
> cga2000 <[EMAIL PROTECTED]> wrote Tue, Jun 06, 2006:
> > On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote:
> >
> > > Someone posted a patch for something like this, using the X libraries.
> > > It never was polished to a degree where it was worth merging, tho'.
> > 
> > Interesting. Obviously 64k or 16M different colors doesn't make much
> > difference. None that I can see anyway. I asked the xterm maintainer how
> > the 256-color palette was chosen but he did  not give me much detail. My
> > personal concern was that the default xterm palette has very few blues.
> > So if you try to harmonize the contents of an xterm with for instance
> > the default background of Window Maker (I call it WindowMaker blue) you
> > don't find an xterm color that is anywhere near. That's when I started
> > taking an interest in these aspects.
> 
> I know next to nothing about how good it works. It has been there since
> I joined the project. BTW, I have a little script that prints out all
> the nice colors: http://jonas.nitro.dk/tmp/256.sh ...
> 
works very nicely. I'll add the color numbers to the display for my own
use.

> > > Sorry, that I was not clear. I am talking about using JavaScript for
> > > browser scripting, not document scripting. 
> > 
> > Ok. I need to add JavaScript to the list of things I must look into.
> > I'll check and see if there is an online tutorial available somewhere.
> 
> I see, that Miciah might be putting some API docs of SMJS browser
> scripting together. Else .js files in contrib/smjs/ should be a help.
> JavaScript is a fairly simple language where many things works "as
> expected".
> 
> > > That is, using JavaScript
> > > to define hooks that can handle stuff from the goto URL dialog or
> > > preformat the HTML source.
> > 
> > Yes, but I do need it for page rendering as well..? Especially those
> > home pages that have some sort of horizontal menu bar that ends up a
> > vertical list of links in my setup?
> 
> That is usually controlled by CSS (another area where ELinks is falling
> behind). CSS let's you define that the tag  which is otherwise a
> block element (that should start on a new separate line, or paragraph if
> you will) is instead an inline element, where multiple  tags should
> appear on one line. Bad description, but I hope you get the point.
> 
clear enough. 

> > > I have some (mostly 256 related) at http://jonas.nitro.dk/screenshots/
> >
> > I had looked at these a few weeks back. I took another look while
> > writing this and now I see things I didn't see back then. I compared
> > those sites that are still around such as OSTG, OSDN, slashdot.. and
> > it's obvious I'm not quite there yet.. 
> 
> Well, with slashdot's new design (they went away from table-based
> design to CSS-powered design) it looks broken in my ELinks too. :(
> So many difference might be because of changes to the website and
> ELinks lack of CSS support. Not that it makes it easier for you.
> 
cf. my reply to Miciah.. :-(

> > > Screenshots sells, I agree. Although most apps are easily downloaded,
> > > configured and installed, the first appearance by which you make the
> > > decision whether to even bother with all that may often be a
> > > screenshot.  And properly more so for something as seemingly
> > > "out-dated" as a text-mode browser.
> > 
> > What would be nice is to have the web pages and the screenshots.
> > Because even if the site still exists six months from  now the
> > contents.. or even the page design.. are going to be different. Thus if
> > the new user has the html document and the .png .. when he wants to make
> > sure his configuration is optimal he just needs to point elinks to the
> > web document and compare with the screenshot. He might need to change
> > his font to the one that was used when the the screenshot was taken but
> > otherwise it should be pretty painless? 
> 
> Yes, this would guard against "deceptive" screenshots like the /.
> screenshot above.
> 
> > > > I don't know if it's realistic/possible but it might be a good idea
> > > > to have elinks "test pages" .. you go to the test page and if you're
> > > > set up right you should see this.. and a link to a screenshot. 
> > > 
> > > It's certainly a new approach to a more visual tutorial and might suit
> > > ELinks better than the poor introduction we have now. On the other
> > > hand I wonder if most users of text-mode browser is this "visually
> > > oriented".  But then again, Links2 has this calibration page to help
> > > you get the basics working and that is of course a great help.
> > 
> > thanks, "calibration" is pretty much what I had in mind. And it should
> > remain pretty simple. Just giving the new user the ability to verify
> > that web pages are rendering correctly. As to a tutorial I don't really
> > see the need for one. As long as a default configuration is provided the
> > user can learn the basics of elinks by just using

Re: [elinks-users] color schemes

[cga2000]

On Wed, Jun 07, 2006 at 01:28:20AM EDT, Miciah Dashiel Butler Masters wrote:
> If I may butt in...
> 
> On Tue, Jun 06, 2006 at 08:33:48PM -0400, cga2000 wrote:
> > On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote:
> > > cga2000 <[EMAIL PROTECTED]> wrote Mon, Jun 05, 2006:
> > > > On Mon, Jun 05, 2006 at 10:08:37AM EDT, Jonas Fonseca wrote:
> > > >
> > > > I'm not really convinced 256 colors was such a good idea to begin
> > > > with.  Naturally, it's orders of magnitude better than the 8/8 or
> > > > even 8/16 on regular terms.. But why not go the whole hog and have a
> > > > terminal that supports what the video card is capable of? 16-bit -
> > > > 64k colors would probably have been a sensible choice and made life
> > > > easier for everybody?
> > > > 
> > > > Only one extra byte per cell.. 
> 
> The onus is on the developers of the terminal emulators. I'm still
> waiting for 256-colour support on the Linux console.

I agree 100%. Terminal emulators are emulating what the hardware had to
offer over 25 years ago - instead of building "in software" the
terminals of today. And I'm being nice.. These so-called emulators
appear to mostly emulate earlier models. I believe that the VT420 -
I'm not a specialist and I really don't have the time to check right
now.. so correct me if I'm wrong - had split-screen mode capability.
> 
> > > Someone posted a patch for something like this, using the X libraries.
> > > It never was polished to a degree where it was worth merging, tho'.
> 
> Which patch was that?
> 
> > Interesting. Obviously 64k or 16M different colors doesn't make much
> > difference. None that I can see anyway. I asked the xterm maintainer how
> > the 256-color palette was chosen but he did  not give me much detail. My
> > personal concern was that the default xterm palette has very few blues.
> > So if you try to harmonize the contents of an xterm with for instance
> > the default background of Window Maker (I call it WindowMaker blue) you
> > don't find an xterm color that is anywhere near. That's when I started
> > taking an interest in these aspects.
> 
> You can use X resources to change XTerm's palette. man xterm or look
> in /etc/X11/app-defaults/XTerm-color (at least on Debian systems). 

That I am familiar with. I have a couple of color scheme files that I
can "xrdb -merge" to emulate the kde konsole schemes in an xterm. You
can also probably do the same thing on-the-fly by echoing escape
sequences to the xterm. I have tested it manually for the extended
colors (16-231) and presumably the "greys" (232-255) but not for the
basic colors.

> Mind you, ELinks will not necessarily know that you've changed the
> colours, so if you weird things (change red to blue), it might reflect
> strangely in ELinks's rendering.
> 
.. add to it that I have yet another intervening layer (gnu/screen) to
battle with.. Probably would not affect the output - the colors -  but
it does matter where escape sequences are concerned.

> > > > > Ok, but if you feel like modding up your ELinks you should really try
> > > > > the Spidermonkey Javascript scripting backend created by Miciah.  It's
> > > > > fairly easy to get working on a debian system 
> > > > 
> > > > Really? I was never able to get xterm, gnu/scren, and elinks.. to build
> > > > from source - the debian way, I mean.. I was in a rush and it seemed I
> > > > had to become a debian packaging expert before I could hope to get that
> > > > to work.. So now I have a bunch of stuff that's all /.configure'd and
> > > > compiled from source. Annoying.
> 
> I don't bother packaging ELinks; I just install to my home directory.
> You can install to /usr/local, or maybe try something like checkinstall
> (which is packaged in Debian).
> 
> > > I can imagine. Only ever felt the need to compile school related stuff,
> > > elinks, git, (cogito), and xterm. The last one to get 256 colors, and I
> > > am still using the one I compiled on my previous debian system.
> > > 
> > > > This said, I'm very curious of the Javascript capabilities and I would
> > > > really like to see the difference it makes. I do run into pages where I
> > > > am stuck and I have to fire up mozilla and I suspect that not having
> > > > Javascript enabled is part of my problem. 
> > > 
> > > Sorry, that I was not clear. I am talking about using JavaScript for
> > > browser scripting, not document scripting. 
> > 
> > Ok. I need to add JavaScript to the list of things I must look into.
> > I'll check and see if there is an online tutorial available somewhere.
> 
> My preferred tutorial is to read code. My preferred reference is
> 
> --note that that is oriented towards Web programming, tho. I should
> probably write some documentation for the browser scripting interfaces.

I meant "introduction".. just to quickly gain a general understanding
of JS.
> 
> > > That is, using JavaScript
> > > to define hooks that can h

Re: [elinks-users] color schemes

[Jonas Fonseca]

Miciah Dashiel Butler Masters <[EMAIL PROTECTED]> wrote Wed, Jun 07, 2006:
> If I may butt in...

Certainly, I was wondering if I was the only developer
reading/responding to the mailing list. ;)

> On Tue, Jun 06, 2006 at 08:33:48PM -0400, cga2000 wrote:
> > On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote:
> >
> > > Someone posted a patch for something like this, using the X libraries.
> > > It never was polished to a degree where it was worth merging, tho'.
> 
> Which patch was that?

I can't find it in the archive and can't even remember when it was
posted. I don't think I ever managed to get it working but remember that
one of it flaws was that it broke communication between ELinks instances
(interlinking).

-- 
Jonas Fonseca
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users

Re: [elinks-users] Popups with ECMAscript

[Jonas Fonseca]

Ed Hurst <[EMAIL PROTECTED]> wrote Tue, Jun 06, 2006:
> Greetings. Context: I run elinks on FreeBSD 5.5, and have ECMAscript
> enabled via Spidermonkey. I typically use Konsole (KDE 3.4.2).
> 
> On one site, I actually got little Xterm windows popping up with the ads
> we all hate:
> 
> http://www.sun-sentinel.com/news/local/broward/sfl-65realbodies%2C0%2C7410541.story?coll=sfla-news-broward
> 
> Is there some measure I can take to disable this "feature" without
> removing the option for JScript? I actually need it for some sites.

You could try to put something like

 set ecmascript.block_window_opening = 1

in ~/.elinks/elinks.conf ...

> (Please forgive me for not subscribing, but like most of you I have too
> much on my plate to join every list from which I might gain help. I'll
> be reading the archives, but you are welcome to respond directly by email.)

That's ok, I've added you to the sender filter whitelist, so other posts
from you are not withheld. The current setup (using Reply-To) doesn't
get you on the CC list automatically but if you read the archive that
should not be a problem.

-- 
Jonas Fonseca
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users

Re: [elinks-users] color schemes

[Miciah Dashiel Butler Masters]

If I may butt in...

On Tue, Jun 06, 2006 at 08:33:48PM -0400, cga2000 wrote:
> On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote:
> > cga2000 <[EMAIL PROTECTED]> wrote Mon, Jun 05, 2006:
> > > On Mon, Jun 05, 2006 at 10:08:37AM EDT, Jonas Fonseca wrote:
> > >
> > > I'm not really convinced 256 colors was such a good idea to begin
> > > with.  Naturally, it's orders of magnitude better than the 8/8 or
> > > even 8/16 on regular terms.. But why not go the whole hog and have a
> > > terminal that supports what the video card is capable of? 16-bit -
> > > 64k colors would probably have been a sensible choice and made life
> > > easier for everybody?
> > > 
> > > Only one extra byte per cell.. 

The onus is on the developers of the terminal emulators. I'm still
waiting for 256-colour support on the Linux console.

> > Someone posted a patch for something like this, using the X libraries.
> > It never was polished to a degree where it was worth merging, tho'.

Which patch was that?

> Interesting. Obviously 64k or 16M different colors doesn't make much
> difference. None that I can see anyway. I asked the xterm maintainer how
> the 256-color palette was chosen but he did  not give me much detail. My
> personal concern was that the default xterm palette has very few blues.
> So if you try to harmonize the contents of an xterm with for instance
> the default background of Window Maker (I call it WindowMaker blue) you
> don't find an xterm color that is anywhere near. That's when I started
> taking an interest in these aspects.

You can use X resources to change XTerm's palette. man xterm or look
in /etc/X11/app-defaults/XTerm-color (at least on Debian systems). Mind
you, ELinks will not necessarily know that you've changed the colours,
so if you weird things (change red to blue), it might reflect strangely
in ELinks's rendering.

> > > > Ok, but if you feel like modding up your ELinks you should really try
> > > > the Spidermonkey Javascript scripting backend created by Miciah.  It's
> > > > fairly easy to get working on a debian system 
> > > 
> > > Really? I was never able to get xterm, gnu/scren, and elinks.. to build
> > > from source - the debian way, I mean.. I was in a rush and it seemed I
> > > had to become a debian packaging expert before I could hope to get that
> > > to work.. So now I have a bunch of stuff that's all /.configure'd and
> > > compiled from source. Annoying.

I don't bother packaging ELinks; I just install to my home directory.
You can install to /usr/local, or maybe try something like checkinstall
(which is packaged in Debian).

> > I can imagine. Only ever felt the need to compile school related stuff,
> > elinks, git, (cogito), and xterm. The last one to get 256 colors, and I
> > am still using the one I compiled on my previous debian system.
> > 
> > > This said, I'm very curious of the Javascript capabilities and I would
> > > really like to see the difference it makes. I do run into pages where I
> > > am stuck and I have to fire up mozilla and I suspect that not having
> > > Javascript enabled is part of my problem. 
> > 
> > Sorry, that I was not clear. I am talking about using JavaScript for
> > browser scripting, not document scripting. 
> 
> Ok. I need to add JavaScript to the list of things I must look into.
> I'll check and see if there is an online tutorial available somewhere.

My preferred tutorial is to read code. My preferred reference is

--note that that is oriented towards Web programming, tho. I should
probably write some documentation for the browser scripting interfaces.

> > That is, using JavaScript
> > to define hooks that can handle stuff from the goto URL dialog or
> > preformat the HTML source.
> > 
> Yes, but I do need it for page rendering as well..? Especially those
> home pages that have some sort of horizontal menu bar that ends up a
> vertical list of links in my setup?

EMCAScript in documents shouldn't usually significantly affect the
rendering of documents; normally it is more important towards
functionality. Particularly in ELinks, which doesn't support enough
ECMAScript to support the whiz-bang interfaces that really do depend on
ECMAScript to dynamically generate content, add and hide stuff, and so
on, you should see little difference in how a document is actually
displayed based on whether you have ECMAScript enabled.

The example of the mis-rendered menu bar is probably an issue
of ELinks's limited CSS support.

> > > > Having a sane default configuration is very important. The many
> > > > options is a weakness if you end up scaring new users away. If
> > > > they feel they have to know of all the little details.
> > > 
> > > That's pretty much what I meant. But as a new user I only noticed
> > > all the options when I took a look at the elinks.conf file. But then
> > > I was in so much of a rush that I did  not really look at the o -
> > > "Option Manage

[elinks-users] Popups with ECMAscript

[Ed Hurst]

Greetings. Context: I run elinks on FreeBSD 5.5, and have ECMAscript
enabled via Spidermonkey. I typically use Konsole (KDE 3.4.2).

On one site, I actually got little Xterm windows popping up with the ads
we all hate:

http://www.sun-sentinel.com/news/local/broward/sfl-65realbodies%2C0%2C7410541.story?coll=sfla-news-broward

Is there some measure I can take to disable this "feature" without
removing the option for JScript? I actually need it for some sites.

(Please forgive me for not subscribing, but like most of you I have too
much on my plate to join every list from which I might gain help. I'll
be reading the archives, but you are welcome to respond directly by email.)

-- 
Ed Hurst
--
Bible Application - http://ed.asisaid.com/bible/index.html
Plain & Simple Computer Help - http://ed.asisaid.com/
Mission, Method & Means - http://ed.asisaid.com/blog/
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users

Re: [elinks-users] color schemes

[Jonas Fonseca]

cga2000 <[EMAIL PROTECTED]> wrote Tue, Jun 06, 2006:
> On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote:
>
> > Someone posted a patch for something like this, using the X libraries.
> > It never was polished to a degree where it was worth merging, tho'.
> 
> Interesting. Obviously 64k or 16M different colors doesn't make much
> difference. None that I can see anyway. I asked the xterm maintainer how
> the 256-color palette was chosen but he did  not give me much detail. My
> personal concern was that the default xterm palette has very few blues.
> So if you try to harmonize the contents of an xterm with for instance
> the default background of Window Maker (I call it WindowMaker blue) you
> don't find an xterm color that is anywhere near. That's when I started
> taking an interest in these aspects.

I know next to nothing about how good it works. It has been there since
I joined the project. BTW, I have a little script that prints out all
the nice colors: http://jonas.nitro.dk/tmp/256.sh ...

> > Sorry, that I was not clear. I am talking about using JavaScript for
> > browser scripting, not document scripting. 
> 
> Ok. I need to add JavaScript to the list of things I must look into.
> I'll check and see if there is an online tutorial available somewhere.

I see, that Miciah might be putting some API docs of SMJS browser
scripting together. Else .js files in contrib/smjs/ should be a help.
JavaScript is a fairly simple language where many things works "as
expected".

> > That is, using JavaScript
> > to define hooks that can handle stuff from the goto URL dialog or
> > preformat the HTML source.
> 
> Yes, but I do need it for page rendering as well..? Especially those
> home pages that have some sort of horizontal menu bar that ends up a
> vertical list of links in my setup?

That is usually controlled by CSS (another area where ELinks is falling
behind). CSS let's you define that the tag  which is otherwise a
block element (that should start on a new separate line, or paragraph if
you will) is instead an inline element, where multiple  tags should
appear on one line. Bad description, but I hope you get the point.

> > I have some (mostly 256 related) at http://jonas.nitro.dk/screenshots/
>
> I had looked at these a few weeks back. I took another look while
> writing this and now I see things I didn't see back then. I compared
> those sites that are still around such as OSTG, OSDN, slashdot.. and
> it's obvious I'm not quite there yet.. 

Well, with slashdot's new design (they went away from table-based
design to CSS-powered design) it looks broken in my ELinks too. :(
So many difference might be because of changes to the website and
ELinks lack of CSS support. Not that it makes it easier for you.

> > Screenshots sells, I agree. Although most apps are easily downloaded,
> > configured and installed, the first appearance by which you make the
> > decision whether to even bother with all that may often be a
> > screenshot.  And properly more so for something as seemingly
> > "out-dated" as a text-mode browser.
> 
> What would be nice is to have the web pages and the screenshots.
> Because even if the site still exists six months from  now the
> contents.. or even the page design.. are going to be different. Thus if
> the new user has the html document and the .png .. when he wants to make
> sure his configuration is optimal he just needs to point elinks to the
> web document and compare with the screenshot. He might need to change
> his font to the one that was used when the the screenshot was taken but
> otherwise it should be pretty painless? 

Yes, this would guard against "deceptive" screenshots like the /.
screenshot above.

> > > I don't know if it's realistic/possible but it might be a good idea
> > > to have elinks "test pages" .. you go to the test page and if you're
> > > set up right you should see this.. and a link to a screenshot. 
> > 
> > It's certainly a new approach to a more visual tutorial and might suit
> > ELinks better than the poor introduction we have now. On the other
> > hand I wonder if most users of text-mode browser is this "visually
> > oriented".  But then again, Links2 has this calibration page to help
> > you get the basics working and that is of course a great help.
> 
> thanks, "calibration" is pretty much what I had in mind. And it should
> remain pretty simple. Just giving the new user the ability to verify
> that web pages are rendering correctly. As to a tutorial I don't really
> see the need for one. As long as a default configuration is provided the
> user can learn the basics of elinks by just using it. Same as any gui
> app. 

Call it tips and tricks or cheat sheet instead of tutorial. But yes,
"learning while using" makes the learning experience feel less steep.

One thing to put in these test pages would be the bottom table in
test/css/styletags.html maybe with a "4ever" appended ... ;)

> > BTW, being new to ELinks, you should go over contrib/elinks.f