[patch]: fix the meta-refresh warning code
Long time no post! Here's a fix for an outstanding TODO in html.cc. It replaces the code that creates the HTML META REFRESH warning (which sends HTML to Html_write_raw()) with a function that creates the widgets directly. There are still a few issues: * The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same? * The new widgets do not have 'width="100%"' set, so the horizontal layout is slightly different. * The redirect link colour does not reflect whether the link URL has been visited. * It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . I couldn't figure out how to do that so I just copied a few things like the link colour and text decoration. If someone tells me how to do this properly I'll revise the code. Please comment! Jeremy Henty
Hi Jeremy, Good to see you around! On Sat, Sep 19, 2009 at 11:32:19PM +0100, Jeremy Henty wrote:
Long time no post! Here's a fix for an outstanding TODO in html.cc. It replaces the code that creates the HTML META REFRESH warning (which sends HTML to Html_write_raw()) with a function that creates the widgets directly.
Hopefully I'll review it in the next days.
There are still a few issues:
* The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same?
Not necessary. That was an old feature for narrow displays.
* The new widgets do not have 'width="100%"' set, so the horizontal layout is slightly different.
* The redirect link colour does not reflect whether the link URL has been visited.
* It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . I couldn't figure out how to do that so I just copied a few things like the link colour and text decoration. If someone tells me how to do this properly I'll revise the code.
AFAIS, the warning widget needs its own scheme, like the rest of the panel.
Please comment!
More in the next days... -- Cheers Jorge.-
On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote:
* The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same?
Not necessary. That was an old feature for narrow displays.
In that case, shouldn't we remove USE_TABLES entirely?
* It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . ...
AFAIS, the warning widget needs its own scheme, like the rest of the panel.
Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be. I still haven't worked out how to apply the CSS stylesheets to the widgets I create (the style engine mechanism isn't being applied because I create the widgets directly instead of from HTML). I tried adding calls to styleEngine->{startElement,endElement}() but nothing happened. I'm clearly still missing something. I'll have another look, but any tips will be welcome! Regards, Jeremy Henty
Hi Jeremy, On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote:
On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote:
* The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same?
Not necessary. That was an old feature for narrow displays.
In that case, shouldn't we remove USE_TABLES entirely?
* It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . ...
AFAIS, the warning widget needs its own scheme, like the rest of the panel.
Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be.
Yes, this would be possible. Other browsers also have similar extensions. They seem to start with a '-' usually ("-webkit...", "-moz..."). But generally if we generate messages in the rendering area, we can't avoid that someone fakes them on his webpage.
I still haven't worked out how to apply the CSS stylesheets to the widgets I create (the style engine mechanism isn't being applied because I create the widgets directly instead of from HTML). I tried adding calls to styleEngine->{startElement,endElement}() but nothing happened. I'm clearly still missing something. I'll have another look, but any tips will be welcome!
That should work. You need those styleEngine->{startElement,endElement}() calls and then use styleEngine->style() for your widgets. See plain.cc for an example. And of course you need to specify corresponding css either in the user agent style in css.cc or for testing just in your ~/.dillo/style.css file. Regards, Johannes
Johannes wrote:
On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote:
On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote:
* The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same?
Not necessary. That was an old feature for narrow displays.
In that case, shouldn't we remove USE_TABLES entirely?
* It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . ...
AFAIS, the warning widget needs its own scheme, like the rest of the panel.
Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be.
Yes, this would be possible. Other browsers also have similar extensions. They seem to start with a '-' usually ("-webkit...", "-moz..."). But generally if we generate messages in the rendering area, we can't avoid that someone fakes them on his webpage.
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan, but maybe that was the xhtml one, or maybe I'm just mixed up.)
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Johannes wrote:
On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote:
On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote:
* The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same?
Not necessary. That was an old feature for narrow displays.
In that case, shouldn't we remove USE_TABLES entirely?
* It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . ...
AFAIS, the warning widget needs its own scheme, like the rest of the panel.
Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be.
Yes, this would be possible. Other browsers also have similar extensions. They seem to start with a '-' usually ("-webkit...", "-moz..."). But generally if we generate messages in the rendering area, we can't avoid that someone fakes them on his webpage.
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan, but maybe that was the xhtml one, or maybe I'm just mixed up.)
That's exactly the plan. A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click). Sorry for not having the time yet to test the code... -- Cheers Jorge.-
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport? Regards, Jeremy Henty
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago. -- Cheers Jorge.-
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files. -- Cheers Jorge.-
Jorge wrote:
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files.
ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.
On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote:
Jorge wrote:
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files.
ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.
FLTK2 is dead (that's almost official). Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]). In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-) FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary. [1] http://fltk.org/newsgroups.php?s7257+gfltk.development+v7263+T0 -- Cheers Jorge.-
On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote:
On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote:
Jorge wrote:
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote:
On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
> Would it be less trouble to have this widget as a child of the UI > instead of in the rendering area? (I sort of had the impression > that was the plan...
That's exactly the plan.
A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files.
ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.
FLTK2 is dead (that's almost official).
Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]).
In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-)
FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary.
You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have: * window title * status bar * popup Windows (from dpi's) I think we should try to keep the UI simple and consistent by reducing the number of concepts. Cheers, Johannes PS: I recently tried http://surf.suckless.org/ and I'm rather impressed by the minimal UI.
Johannes wrote:
On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote:
On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote:
Jorge wrote:
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote:
On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote:
> > Would it be less trouble to have this widget as a child of the UI > > instead of in the rendering area? (I sort of had the impression > > that was the plan... > > That's exactly the plan. > > A simple fltk widget that hides/shows (as the findext bar) and > that gives a text message. It should also support a fake HTML link > (underlined word that reacts to left click).
Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files.
ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.
FLTK2 is dead (that's almost official).
Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]).
In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-)
FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary.
You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have:
* window title * status bar * popup Windows (from dpi's)
I think we should try to keep the UI simple and consistent by reducing the number of concepts.
Maybe it would be nice if popup windows turned into something like a popup bar.
PS: I recently tried http://surf.suckless.org/ and I'm rather impressed by the minimal UI.
I read a little about surf and uzbl recently, but then webkit was too big for me to want to download. (Surprised a person would intentionally name a browser 'surf' nowadays. I had thought of web "surfing" as a term as thankfully dead and buried as "information superhighway" or "cyberspace".)
On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote:
Johannes wrote:
On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote:
On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote:
Jorge wrote:
On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote:
On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > Would it be less trouble to have this widget as a child of the UI > > > instead of in the rendering area? (I sort of had the impression > > > that was the plan... > > > > That's exactly the plan. > > > > A simple fltk widget that hides/shows (as the findext bar) and > > that gives a text message. It should also support a fake HTML link > > (underlined word that reacts to left click). > > Ah, I think I misunderstood the reference to "custom widget" in the TO > DO note. I was fixated on the Dillo Widget system and didn't realise > it was talking about a new FLTK widget. Maybe my patch isn't the way > to go. Still, it would be nice for the custom widget to be properly > CSS-styled. Maybe it be could another FltkViewport?
As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago.
Ehmmm, by "Xdefaults", I mean the default X resource files.
ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.
FLTK2 is dead (that's almost official).
Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]).
In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-)
FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary.
You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have:
* window title * status bar * popup Windows (from dpi's)
I think we should try to keep the UI simple and consistent by reducing the number of concepts.
I agree on consistency, and hopefully a reduced number of concepts. * window title Most probably unnoticed and no way to put a link there. * status bar Too ephemeral and no link too. * popup Window IMHO: Too intrusive for the user. The popup bar is the same concept as for findtext and the control panel. In this case we're reducing the number of concepts by taking out one UI element (injected HTML) and replacing it with a popup bar.
Maybe it would be nice if popup windows turned into something like a popup bar.
This could reduce the number of concepts even further, but not for "Open file", "save page", "save page as...", and downloads. It requires some thought (on the possible gain/loss/effort)... -- Cheers Jorge.-
On Sun, Sep 27, 2009 at 04:14:29PM -0400, Jorge Arellano Cid wrote:
I agree on consistency, and hopefully a reduced number of concepts.
* window title Most probably unnoticed and no way to put a link there. * status bar Too ephemeral and no link too. * popup Window IMHO: Too intrusive for the user.
The popup bar is the same concept as for findtext and the control panel.
In this case we're reducing the number of concepts by taking out one UI element (injected HTML) and replacing it with a popup bar.
Maybe it would be nice if popup windows turned into something like a popup bar.
This could reduce the number of concepts even further, but not for "Open file", "save page", "save page as...", and downloads.
I fully agree, but a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars?
It requires some thought (on the possible gain/loss/effort)...
One drawback of the popup bar is the additional resize / redraw of the rendering area. Cheers, Johannes
Johannes wrote:
a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd
should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars?
Yeah, that might require a little more cleverness than we would really prefer to implement -- although when I was playing with same_domain with image loading on, I did get one of those ssl warning bombings, and boy are they definitely no fun at all as separate windows.
On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote:
I fully agree, but
a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd
should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars?
Don't forget that one page can pop up multiple simultaneous dialogs (because although the modal dialog locks the GUI, it doesn't stop the IO callbacks from running). That's not a problem when each call to a_Dialog_*() pops up its own dialog, but what happens when several of them want to use the same popup bar? I guess each popup bar will have to manage a list of concurrent requests instead of just one. Regards, Jeremy Henty
On Mon, Sep 28, 2009 at 07:22:29PM +0100, Jeremy Henty wrote:
On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote:
I fully agree, but
a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd
should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars?
Don't forget that one page can pop up multiple simultaneous dialogs (because although the modal dialog locks the GUI, it doesn't stop the IO callbacks from running). That's not a problem when each call to a_Dialog_*() pops up its own dialog, but what happens when several of them want to use the same popup bar? I guess each popup bar will have to manage a list of concurrent requests instead of just one.
Yes, it comes with effort. I'd say let's have the popup bar for META refresh (and faulty XHTML) and keep the popup dialogs. Now, if someone ;), comes with a better idea, with implementation, it'd be good to look into. BTW, I'm working on the dpi/dpip part (lots of things). Hopefully I'll come up with a solution for the dialog bombing among the bunch of patches/code-changes in my queue. -- Cheers Jorge.-
On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote:
Johannes wrote:
You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have:
* window title * status bar * popup Windows (from dpi's)
I think we should try to keep the UI simple and consistent by reducing the number of concepts.
Maybe it would be nice if popup windows turned into something like a popup bar.
Sounds good to me. So we would just have alternative implementations for a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd
PS: I recently tried http://surf.suckless.org/ and I'm rather impressed by the minimal UI.
I read a little about surf and uzbl recently, but then webkit was too big for me to want to download.
Yes, it's quite large.
(Surprised a person would intentionally name a browser 'surf' nowadays. I had thought of web "surfing" as a term as thankfully dead and buried as "information superhighway" or "cyberspace".)
good point :-)
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org