- Dillo-dev - lists.mailman3.com

dillo close dialog and fluxbox on dual head

by corvid＠lavabit.com

higuita wrote: > i dont know if this is a problem with dillo or with fluxbox, but > when i try to close a dillo with several tabs, i get always the close dialog > (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to > force the dialog to open on head 1, it still opens on head 2. > > if i do the same thing for all other dillo dialogs, like open > file, search (title ask), etc , i fluxbox puts the window in the > configured head. If i try to set the position and head, fluxbox puts the > dialog in the right position, but in the wrong head. How are you instructing fluxbox to do this? > If i try to run the fltk-1.3/test/message test, i can setup the > head of those messages without any problem. > > i'm using the latest dillo3 "hg version" with the latest fltk1.3 > svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. > The main head (1) is right, secondary head (2) is left. They are setup > with xrandr on a ati r600 card: > > xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 > xrandr --output DVI-0 --primary --set underscan off > > > As dillo is the only app i found with this problem, and even other > dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that > is forcing the Choice5 dialog to stay on head 2... probably just because > is on the left (so closer to the 0,0 X11 virtual display corner), instead > of using the virtual position of each head. > > What you think? should i open a bug in fluxbox, in fltk or is > this a dillo problem? Does xprop show any interesting differences between a choice5 window and an ask window?

Aug. 17, 2011

dillo close dialog and fluxbox on dual head

by corvid＠lavabit.com

higuita wrote: > search (title ask) Hmm, that brings up the point that a_Dialog_input() needs to be renamed now that it has a list of search engines stuck inside it.

Aug. 17, 2011

dillo close dialog and fluxbox on dual head

by higuita7＠yahoo.co.uk

Hi i dont know if this is a problem with dillo or with fluxbox, but when i try to close a dillo with several tabs, i get always the close dialog (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to force the dialog to open on head 1, it still opens on head 2. if i do the same thing for all other dillo dialogs, like open file, search (title ask), etc , i fluxbox puts the window in the configured head. If i try to set the position and head, fluxbox puts the dialog in the right position, but in the wrong head. If i try to run the fltk-1.3/test/message test, i can setup the head of those messages without any problem. i'm using the latest dillo3 "hg version" with the latest fltk1.3 svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. The main head (1) is right, secondary head (2) is left. They are setup with xrandr on a ati r600 card: xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 xrandr --output DVI-0 --primary --set underscan off As dillo is the only app i found with this problem, and even other dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that is forcing the Choice5 dialog to stay on head 2... probably just because is on the left (so closer to the 0,0 X11 virtual display corner), instead of using the virtual position of each head. What you think? should i open a bug in fluxbox, in fltk or is this a dillo problem? Thanks in advance for the help and thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Aug. 17, 2011

Horizontal scrolling with mouse buttons

by jcid＠dillo.org

On Mon, Aug 15, 2011 at 02:18:33PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > Quoting Jorge Arellano Cid <jcid(a)dillo.org>: > > > Please try dillo-3.0-pre, following these directions [1]. > >Then report back how it goes. > > > > [1] http://www.dillo.org/source.html > > With that build, the horizontal scroll buttons are inactive. To my > mind this is satisfactory behavior as it does not interfere with the > vertical scrolling of the mouse wheel (previously the only way to > restore vertical wheel scrolling was to restart the program). Good! This looks like an issue with fltk-1.3. FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to handle those buttons. Having something like the following may be worth a try (if you're a coder): if (xevent.xbutton.button == Button4) { Fl::e_dy = -1; // Up event = FL_MOUSEWHEEL; } else if (xevent.xbutton.button == Button5) { Fl::e_dy = +1; // Down event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button6) { + Fl::e_dx = -1; // Left + event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button7) { + Fl::e_dx = +1; // Right + event = FL_MOUSEWHEEL; } else { Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); event = FL_PUSH; checkdouble(); } > Thank you for your response. :) -- Cheers Jorge.-

Aug. 16, 2011

Horizontal scrolling with mouse buttons

by jcid＠dillo.org

Hi, On Sat, Aug 13, 2011 at 09:53:50PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > I have a Logitech wheel mouse which supports horizontal scrolling by > pressing the scroll wheel to either the left or right. These actions > generate mouse button events where the button is identified as > either "6" or "7" respectively. > > Dillo handles these horizontal scroll events properly, but afterward > the scrollwheel no longer works for vertical scrolling (the > scrollwheel up/down events are reported as buttons "4" and "5" > respectively); instead the scrollwheel results in left/right > scrolling. > > I am running Dillo 2.2 on a Slackware system. Please try dillo-3.0-pre, following these directions [1]. Then report back how it goes. [1] http://www.dillo.org/source.html -- Cheers Jorge.-

Aug. 15, 2011

Horizontal scrolling with mouse buttons

by saulgoode＠flashingtwelve.brickfilms.com

I have a Logitech wheel mouse which supports horizontal scrolling by pressing the scroll wheel to either the left or right. These actions generate mouse button events where the button is identified as either "6" or "7" respectively. Dillo handles these horizontal scroll events properly, but afterward the scrollwheel no longer works for vertical scrolling (the scrollwheel up/down events are reported as buttons "4" and "5" respectively); instead the scrollwheel results in left/right scrolling. I am running Dillo 2.2 on a Slackware system. Regards.

Aug. 14, 2011

moveToWidget

by jcid＠dillo.org

On Thu, Aug 11, 2011 at 04:13:51AM +0000, corvid wrote: > Jorge wrote: > > On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > > <div> > > > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > > <div>a div. Move down here and the link url is still shown.</div> > > > Ordinary text outside of the div. Status output is blanked when moving down here. > > > </div> > > [snip] > > > It looks like only testing will tell us whether there're other > > corner cases lurking around. > > Add a title attr to the link. Let the tooltip pop up. Move the mouse > cursor down into the child div. The tooltip remains visible. Oh, yes... Fortunately this is not a problem in the dispatcher. Please check current tip. -- Cheers Jorge.-

Aug. 11, 2011

Tab close button gets clobbered by tabs

by fabio.pasini＠gmail.com

Hello there, >Maybe the main point is to decide how to code tab-overflow >handling in a practical way (and to avoid complex code on the >details/preferences, but having a few ;). Is it feasible to have multiple lines for tabs, something like "Tab Mix Plus" does on Firefox? As an (somehow exaggerated) example: http://thasulinux.files.wordpress.com/2011/03/tab_mix_plus.png When there are too many tabs open, the tab label can become too tiny to be useful, in this cases having multiple lines looks more suitable to me (but, again, it's a personal opinion). Something like keep putting tabs in one line, and if the tabs become too narrow, add a second line, then keep going on (plus displaying a warning popup when some limit is reached) Best regards, F?bio Pasini 2011/8/10 Jorge Arellano Cid <jcid(a)dillo.org> > On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > > Rob wrote: > > > 2) From a practical standpoint, the old tabs seemed to behave a little > > > nicer, in that they would adjust their size a little bit to show more > > > of the title of the page opened in it. As it stands with Dillo 3, you > > > can't see much of the title text before it gets an ellipsis. > > > > I, too, would prefer titles that were not so short and that didn't have > > their descenders clipped. > > The attached code does this. I don't have much time now, so > please give it a look. > > Maybe the main point is to decide how to code tab-overflow > handling in a practical way (and to avoid complex code on the > details/preferences, but having a few ;). > > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 11, 2011

moveToWidget

by corvid＠lavabit.com

Jorge wrote: > On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > <div> > > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > <div>a div. Move down here and the link url is still shown.</div> > > Ordinary text outside of the div. Status output is blanked when moving down here. > > </div> [snip] > It looks like only testing will tell us whether there're other > corner cases lurking around. Add a title attr to the link. Let the tooltip pop up. Move the mouse cursor down into the child div. The tooltip remains visible.

Aug. 11, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

Hi Jorge, Tried your suggestion. Here is what I get, but no images! Many thanks! T $ paths: Cannot open file '/home/trotter/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='about:splash' Nav_open_url: new url='dpi:/bm/' Nav_open_url: new url='http://www.nytimes.com' Dns_server [0]: www.nytimes.com is 170.149.173.130 Connecting to 170.149.173.130 NumPendingStyleSheets=1 Dns_server [0]: css.nyt.com is 209.56.124.23 209.56.124.24 Dns_server [2]: view.atdmt.com is 207.46.193.176 Dns_server [1]: graphics8.nytimes.com is 209.56.124.23 209.56.124.24 Dns_server [3]: i1.nyt.com is 209.56.124.25 209.56.124.24 Dns_server [0]: ad.doubleclick.net is 74.125.225.91 Dns_server [2]: wt.o.nytimes.com is 66.150.117.24 Dns_server [1]: up.nytimes.com is 50.17.182.119 >>>> a_Nav_repush <<<< Nav_open_url: new url='http://www.nytimes.com' ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/2011/08/10/dining/10MOTH_REST/10MOTH_REST-moth.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/global/buttons/moth_forward.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/global/buttons/moth_reverse.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /?d=0/1/&t=1&s=2&ui=51048&r=http%3a%2f%2fwww%2enytimes%2ecom%2f&u=www%2enytimes%2ecomwww%2enytimes%2ecom%3f HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: up.nytimes.com\x0D Referer: http://up.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/2011/08/10/books/10moth_poet/10moth_poet-moth.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/2011/08/11/fashion/BURNOUT1/BURNOUT1-thumbStandard.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/2011/08/10/opinion/10moth_rfd/10moth_rfd-moth.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: i1.nyt.com\x0D Referer: http://i1.nyt.com/\x0D User-Agent: Dillo/3.0-pre\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/multimedia/icons/photo_icon.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /adx/images/ADS/26/30/ad.263018/some_promise_ADA_88x31.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /ads/marketing/mm11/opinion_081011.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/multimedia/icons/video_icon.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /images/2011/08/11/world/11timescast_337/11timescast_337-custom3.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /ads/marketing/mm09/verticalst/nytimes.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /ads/marketing/mm09/verticalst/verticals_opinion.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /adx/images/ADS/23/70/ad.237035/weekender_86x60.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /adx/images/ADS/19/74/ad.197453/global_120x90.jpg HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /ads/blank.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /dcsym57yw10000s1s8g0boozt_9t1x/njs.gif?dcsuri=/nojavascript&WT.js=No&WT.tv=1.0.7 HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: wt.o.nytimes.com\x0D Referer: http://wt.o.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: ACOOKIE=C8ctADEyOS4xODYuMTAwLjE4NC0xNzg2MjI5ODA4LjI5ODI0MjI3AAAAAAAGAAAA2asAAJ6OpkaejqZGmLwAAKmLl0epi5dHNMEAAMPYQk7D2EJOE74AAMHFMUfBxTFHRcgAAIxQwkeMUMJH+L0AALD7t0iw+7dIAgAAAC1EAACejqZGno6mRnhHAADD2EJOw9hCTgAAAAA-; up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " ** WARNING **: IO_write, closing with pending data not sent ** WARNING **:? "GET /adx/images/ADS/24/91/ad.249157/Dealbook_120x90_1.gif HTTP/1.1\x0D Connection: close\x0D Accept: text/*,image/*,*/*;q=0.2\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: graphics8.nytimes.com\x0D Referer: http://graphics8.nytimes.com/\x0D User-Agent: Dillo/3.0-pre\x0D Cookie: up=639Ig71b20SA0Zlw; NYT_W2=New%20YorkNYUS|ChicagoILUS|London--UK|Los%20AngelesCAUS|San%20FranciscoCAUS|Tokyo--JP|; RMID=20b81e615f424cbb1f922c5a; nyt-d=101.CDU1a2L0hCAI0G080s9Imk0qFIL4@e90407b6/272d7704; NYT-Pref=hppznw|0^creator|NYTD.Cookies; zFN=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; zFD=B3F5B3E4B3DAB3CFB3B10B30p8B21aGB10g6AC13E0B0370UA04J1C905v17; adxcl=t*27b69=4ebf40bf:1311485749|t*28366=4eab7a3f:1311876537|t*28364=4eab7a3f:1311703558; adxcs=s*2550c=0:1|s*25056=0:1; NYT-S=1oS/sUPZ71BJWhtsRSDNrH.Hn83gtpvjjMGOX1aoAukQnbLlKgqfdMZ/HbDZvGLHc5V.SRDUp9PGXhUx/6EwL8f7V/kGKeDHtR70YK/xJaaQfevL5Uh6Rar000\x0D \x0D " a_Nav_expect_done: repush! HTTP warning: 'http://www.nytimes.com/adx/bin/clientside/6c6c649cQ2FMQ7DE0mQ5DMQ22c0Q5DQ3D…' cannot be displayed as image; has media type 'text/html'

Aug. 11, 2011

dillo3-pre does not display images

by jcid＠dillo.org

On Wed, Aug 10, 2011 at 03:34:13PM -0700, Globe Trotter wrote: > > > > > ----- Original Message ----- > From: Jorge Arellano Cid <jcid(a)dillo.org> > To: dillo-dev(a)dillo.org > Cc: > Sent: Sunday, August 7, 2011 1:23 PM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > > > > > ________________________________ > > From: Axel Beckert <abe(a)deuxchevaux.org> > > To: dillo-dev(a)dillo.org > > Sent: Sunday, August 7, 2011 9:53 AM > > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > > > Hi, > > > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > > Trying www.nytimes.com or www.huffingtonpost.com or > > > www.politico.com. While the frames are all messed up (as in Dillo > > > 2.2), now even the images do not get displayed. > > ? Images show here. > > ? Weird, I don't know what it may be... > > ? BTW, you have a preferences file full of non-dillo keywords (at > least not ours). Try: > > ? ? mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK > > ? and see what hapopens by starting with the defaults > > --- > > Hi, > > Does anyone have any suggestion as to what could diagnose and possibly fix the problem? I am using Fedora 15 with the LXDE spin. > > Many thanks! > T mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK echo "filter_auto_requests=allow_all" > ~/.dillo/dillorc ./dillo -- Cheers Jorge.-

Aug. 11, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

----- Original Message ----- From: Jorge Arellano Cid <jcid(a)dillo.org> To: dillo-dev(a)dillo.org Cc: Sent: Sunday, August 7, 2011 1:23 PM Subject: Re: [Dillo-dev] dillo3-pre does not display images On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > ________________________________ > From: Axel Beckert <abe(a)deuxchevaux.org> > To: dillo-dev(a)dillo.org > Sent: Sunday, August 7, 2011 9:53 AM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > Hi, > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > Trying www.nytimes.com or www.huffingtonpost.com or > > www.politico.com. While the frames are all messed up (as in Dillo > > 2.2), now even the images do not get displayed. ? Images show here. ? Weird, I don't know what it may be... ? BTW, you have a preferences file full of non-dillo keywords (at least not ours). Try: ? ? mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK ? and see what hapopens by starting with the defaults --- Hi, Does anyone have any suggestion as to what could diagnose and possibly fix the problem? I am using Fedora 15 with the LXDE spin. Many thanks! T

Aug. 11, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > Rob wrote: > > 2) From a practical standpoint, the old tabs seemed to behave a little > > nicer, in that they would adjust their size a little bit to show more > > of the title of the page opened in it. As it stands with Dillo 3, you > > can't see much of the title text before it gets an ellipsis. > > I, too, would prefer titles that were not so short and that didn't have > their descenders clipped. The attached code does this. I don't have much time now, so please give it a look. Maybe the main point is to decide how to code tab-overflow handling in a practical way (and to avoid complex code on the details/preferences, but having a few ;). -- Cheers Jorge.-

Aug. 10, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Mon, Aug 08, 2011 at 06:52:40PM -0400, Rob S wrote: > Hello all, > > This evening I discovered that if I open too many tabs, the close tab > 'X' at the top right of the browser gets clobbered out of sight, until > I close some tabs (with CTRL-w). On the old Dillo (2.x), you could > open a fair amount of tabs, and the x would never be clobbered, but > instead a new instance of Dillo would start, after (I presume) a > predetermined amount of tabs were opened. Oh yes I forgot about this workaround... We had to code a custom tabs widget to have control over certain things, and it helped to make the code much simpler with fltk-1.3 too. Now we have full control of the tab widget, and have not finished coding it yet (especially the overflow case). > On another note, while fiddling with the tabs on Dillo 3 and 2.x, I > got comparing the two, and I think I like the look of the old version > better. I have two reasons: > > 1) I think the old version tabs look nicer (I realize not everyone > will think like me), and more like the tabs you would see in other > browsers. Yes, this is a matter of taste. I've received some emails saying the new tabs are/look better. > 2) From a practical standpoint, the old tabs seemed to behave a little > nicer, in that they would adjust their size a little bit to show more > of the title of the page opened in it. As it stands with Dillo 3, you > can't see much of the title text before it gets an ellipsis. Right. I added a few lines making the new tabs do this in my tree (testing now). Some users may find it useful, others not. It may be a good idea to code tab overflow handling before the release. -- Cheers Jorge.-

Aug. 10, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Tue, Aug 09, 2011 at 01:39:53AM +0000, corvid wrote: > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… I can't reproduce this with valgrind-3.6.1 on wheezy. No valgrind error report before or after these debug messages: a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect Dillo: normal exit! I tested by pushing a remote URL on CLI and closing the window before the page data starts flowing (i.e. to cancel the "expect"), and also with the cancelled download code path. Neither one produced an error. -- Cheers Jorge.-

Aug. 9, 2011

moveToWidget

by jcid＠dillo.org

On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > It seems that things still aren't quite right. Yes. > With my original example that went > > <div> > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > <div>a div. Move down here and the link url is still shown.</div> > Ordinary text outside of the div. Status output is blanked when moving down he > re. > </div> > > the problem is now that I move up to the link, and the status output is > shown, then I move down into the child div, and the status is correctly > cleared, then I move up into the link again, and the status is still blank. The example shows clearly the situation is much more complex than what was anticipated; and this explains why there were redundant workaround-code calls sprinkled in different parts, instead of a clean solution. AFAIS, the new moveToWidget() implementation has helped to get closer to a "clean" way of handling it. The situation is this: .----------------------------. | TextBlock (tb1) | | .-------------------. | | | TextBlock (tb2) | | | | | | | '-------------------' | '----------------------------' When going from tb2 to tb1 with tb1 as the common ancestor, tb1 is not "enterNotified()" because it was already entered. Fortunately in the case of an elder common ancestor, the just-entered textblock gets the enterNotify() call, so it seems adding this corner case to the dispatcher may be the solution. My thus patched tree works OK, so a commit will go soon. It looks like only testing will tell us whether there're other corner cases lurking around. -- Cheers Jorge.-

Aug. 9, 2011

moveToWidget

by corvid＠lavabit.com

It seems that things still aren't quite right. With my original example that went <div> <a href="http://www.dillo.org">I am a link. How exciting!</a> <div>a div. Move down here and the link url is still shown.</div> Ordinary text outside of the div. Status output is blanked when moving down he re. </div> the problem is now that I move up to the link, and the status output is shown, then I move down into the child div, and the status is correctly cleared, then I move up into the link again, and the status is still blank.

Aug. 9, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Rob wrote: > 2) From a practical standpoint, the old tabs seemed to behave a little > nicer, in that they would adjust their size a little bit to show more > of the title of the page opened in it. As it stands with Dillo 3, you > can't see much of the title text before it gets an ellipsis. I, too, would prefer titles that were not so short and that didn't have their descenders clipped.

Aug. 9, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741…

Aug. 9, 2011

Tab close button gets clobbered by tabs

by obeythepenguin＠gmail.com

On Mon, 08 Aug 2011 18:52:40 -0400, Rob S <mr_semantics(a)hotmail.com> wrote: > Hello all, > > This evening I discovered that if I open too many tabs, the close tab > 'X' at the top right of the browser gets clobbered out of sight, until > I close some tabs (with CTRL-w). On the old Dillo (2.x), you could > open a fair amount of tabs, and the x would never be clobbered, but > instead a new instance of Dillo would start, after (I presume) a > predetermined amount of tabs were opened. Offhand I think *that's* because we got rid of the close button for a while, and the "new instance" code went with it... > On another note, while fiddling with the tabs on Dillo 3 and 2.x, I > got comparing the two, and I think I like the look of the old version > better. I have two reasons: ...and *that's* because of some technical difference between FLTK 2.x and 1.3 (I seem to remember Dillo implementing a custom tab widget). I may be completely wrong on both points, of course, since I haven't been following dillo3 too closely. > 1) I think the old version tabs look nicer (I realize not everyone > will think like me), and more like the tabs you would see in other > browsers. > 2) From a practical standpoint, the old tabs seemed to behave a little > nicer, in that they would adjust their size a little bit to show more > of the title of the page opened in it. As it stands with Dillo 3, you > can't see much of the title text before it gets an ellipsis. I agree whole-heartedly on both points. The "bubble" tabs are kind of cute, but I'd prefer a more understated, traditional look. Cheers, ~Benjamin

Aug. 9, 2011

Tab close button gets clobbered by tabs

by mr_semantics＠hotmail.com

Hello all, This evening I discovered that if I open too many tabs, the close tab 'X' at the top right of the browser gets clobbered out of sight, until I close some tabs (with CTRL-w). On the old Dillo (2.x), you could open a fair amount of tabs, and the x would never be clobbered, but instead a new instance of Dillo would start, after (I presume) a predetermined amount of tabs were opened. On another note, while fiddling with the tabs on Dillo 3 and 2.x, I got comparing the two, and I think I like the look of the old version better. I have two reasons: 1) I think the old version tabs look nicer (I realize not everyone will think like me), and more like the tabs you would see in other browsers. 2) From a practical standpoint, the old tabs seemed to behave a little nicer, in that they would adjust their size a little bit to show more of the title of the page opened in it. As it stands with Dillo 3, you can't see much of the title text before it gets an ellipsis. Regards, Rob

Aug. 9, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

----- Original Message ----- From: Jorge Arellano Cid <jcid(a)dillo.org> To: dillo-dev(a)dillo.org Cc: Sent: Sunday, August 7, 2011 1:23 PM Subject: Re: [Dillo-dev] dillo3-pre does not display images On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > ________________________________ > From: Axel Beckert <abe(a)deuxchevaux.org> > To: dillo-dev(a)dillo.org > Sent: Sunday, August 7, 2011 9:53 AM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > Hi, > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > Trying www.nytimes.com or www.huffingtonpost.com or > > www.politico.com. While the frames are all messed up (as in Dillo > > 2.2), now even the images do not get displayed. ? Images show here. ? Weird, I don't know what it may be... ? BTW, you have a preferences file full of non-dillo keywords (at least not ours). Try: ? ? mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK ? and see what hapopens by starting with the defaults Thanks, Jorge. I have been using this file since the time I started using dillo. Anyway, your suggested change did not produce any appreciable effect. $dillo paths: Using /usr/local/etc/dillo/dillorc paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.dillo.org/' Dns_server [0]: www.dillo.org is 134.102.206.165 Nav_open_url: new url='dpi:/bm/' Nav_open_url: new url='http://www.nytimes.com' Dns_server [0]: www.nytimes.com is 170.149.173.130 Connecting to 170.149.173.130 Capi_filters_test: DENY from 'www.nytimes.com' to 'css.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: DENY from 'www.nytimes.com' to 'i1.nyt.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'www.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'graphics8.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'up.nytimes.com' Capi_filters_test: ALLOW from 'www.nytimes.com' to 'wt.o.nytimes.com' HTTP warning: 'http://www.nytimes.com/adx/bin/clientside/a06de63Q2Fomz6hZoiQ7C6ZKOQ7CV-miZ…' cannot be displayed as image; has media type 'text/html' Dns_server [0]: graphics8.nytimes.com is 65.126.84.42 65.126.84.41 Dns_server [2]: wt.o.nytimes.com is 66.150.117.24 Dns_server [1]: up.nytimes.com is 107.20.222.53 Is this also what you get? Someone wrote to me privately the following may work (though for Dillo 2.2.1). However, I am using dillo3-pre (on linux). Offhand, I know some sites now use a trick called "lazy loading" where they default to a blank image, then load the "real" ones with JavaScript.? It's supposed to help page load times by forcing the text to load before images, but breaks non-JavaScript enabled browsers. I've got a patch that works around one common version: ? http://dillo-win32.sourceforge.net/files/10-dillo-r1819.lazy_load.diff What might also help is adding to your dillorc: ? http_user_agent="Mozilla/4.0 (compatible; Dillo 2.2.1)" That tells sites that check your user agent to use simpler, Netscape 4.x-friendly code, which is much closer to what Dillo currently supports.? I've made that the default in the Windows port, since sites like Google Images are almost completely unusable otherwise. By the way, www.nytimes.com, www.huffingtonpost.com, and www.politico.com all work fine here -- I'm running dillo-win32-20110630 (more or less 2.2.1 with some compatibility patches). Thanks again!

Aug. 8, 2011

dillo3-pre does not display images

by jcid＠dillo.org

On Sun, Aug 07, 2011 at 08:36:59AM -0700, Globe Trotter wrote: > > > > ________________________________ > From: Axel Beckert <abe(a)deuxchevaux.org> > To: dillo-dev(a)dillo.org > Sent: Sunday, August 7, 2011 9:53 AM > Subject: Re: [Dillo-dev] dillo3-pre does not display images > > Hi, > > On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > > Trying www.nytimes.com or www.huffingtonpost.com or > > www.politico.com. While the frames are all messed up (as in Dillo > > 2.2), now even the images do not get displayed. Images show here. Weird, I don't know what it may be... BTW, you have a preferences file full of non-dillo keywords (at least not ours). Try: mv ~/.dillo/dillorc ~/.dillo/dillorc.BAK and see what hapopens by starting with the defaults -- Cheers Jorge.-

Aug. 7, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

________________________________ From: Axel Beckert <abe(a)deuxchevaux.org> To: dillo-dev(a)dillo.org Sent: Sunday, August 7, 2011 9:53 AM Subject: Re: [Dillo-dev] dillo3-pre does not display images Hi, On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > Trying www.nytimes.com or www.huffingtonpost.com or > www.politico.com. While the frames are all messed up (as in Dillo > 2.2), now even the images do not get displayed. For me that sounds like that discussion in this thread from a few days ago: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008704.html ??? ??? Kind regards, Axel The DENYs went away but no images. Thanks! -- /~\? Plain Text Ribbon Campaign? ? ? ? ? ? ? ? ? | Axel Beckert \ /? Say No to HTML in E-Mail and News? ? ? ? ? ? | abe(a)deuxchevaux.org? (Mail) X? See http://www.asciiribbon.org/? ? ? ? ? ? ? | abe(a)noone.org (Mail+Jabber) / \? I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web) _______________________________________________ Dillo-dev mailing list Dillo-dev(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Aug. 7, 2011

focus stays on address bar on dillo-3.0 pre

by abe＠deuxchevaux.org

Hi Jorge, On Sun, Aug 07, 2011 at 10:54:01AM -0400, Jorge Arellano Cid wrote: > > > I've found use for both, but now tend more to focusing the main area. > > > > > > Quick poll: what do you prefer? > > > > Focussing main to be able to immediately start scrolling with the > > keyboard after the page has loaded. > > This worked. Oh, ok, cool. Then I don't mind. I have to admit that I didn't test it, but was just annoyed by such issues in general, just again shortly before I read that thread. :-) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 7, 2011

focus stays on address bar on dillo-3.0 pre

by jcid＠dillo.org

On Sat, Aug 06, 2011 at 04:35:04PM -0400, Walter Dnes wrote: > On Sat, Aug 06, 2011 at 06:44:32PM +0300, Rogut??s Sparnuotos wrote > > Jorge Arellano Cid (2011-08-06 11:17): > > > > > > I've found use for both, but now tend more to focusing the main area. > > > > > > Quick poll: what do you prefer? > > > > I wonder who would want to type another URL right after loading the first > > one? > > > > I think that it is more convenient when focus is moved to content. > > I also want focus on main. I agree with the parent post that if > you've just typed/selected a URL, you wouldn't normally want to input a > new one. Done! (BTW, it's good to find something where everybody agrees upon ;). -- Cheers Jorge.-

Aug. 7, 2011

focus stays on address bar on dillo-3.0 pre

by jcid＠dillo.org

On Sat, Aug 06, 2011 at 08:58:24PM +0200, Axel Beckert wrote: > Hi, > > On Sat, Aug 06, 2011 at 11:17:34AM -0400, Jorge Arellano Cid wrote: > > I've found use for both, but now tend more to focusing the main area. > > > > Quick poll: what do you prefer? > > Focussing main to be able to immediately start scrolling with the > keyboard after the page has loaded. This worked. -- Cheers Jorge.-

Aug. 7, 2011

dillo3-pre does not display images

by abe＠deuxchevaux.org

Hi, On Sun, Aug 07, 2011 at 07:39:05AM -0700, Globe Trotter wrote: > Trying www.nytimes.com or www.huffingtonpost.com or > www.politico.com. While the frames are all messed up (as in Dillo > 2.2), now even the images do not get displayed. For me that sounds like that discussion in this thread from a few days ago: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008704.html Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 7, 2011

focus stays on address bar on dillo-3.0 pre

by jcid＠dillo.org

On Sat, Aug 06, 2011 at 04:35:04PM -0400, Walter Dnes wrote: > On Sat, Aug 06, 2011 at 06:44:32PM +0300, Rogut??s Sparnuotos wrote > > Jorge Arellano Cid (2011-08-06 11:17): > > > > > > I've found use for both, but now tend more to focusing the main area. > > > > > > Quick poll: what do you prefer? > > > > I wonder who would want to type another URL right after loading the first > > one? > > > > I think that it is more convenient when focus is moved to content. > > I also want focus on main. I agree with the parent post that if > you've just typed/selected a URL, you wouldn't normally want to input a > new one. I remembered it helped when browsing local images, or content that's separated in pages or slides... Although it doesn't make much sense anymore. -- Cheers Jorge.-

Aug. 7, 2011

dillo3-pre does not display images

by itsme_410＠yahoo.com

Trying www.nytimes.com or www.huffingtonpost.com or www.politico.com. While the frames are all messed up (as in Dillo 2.2), now even the images do not get displayed. I get lots of DENY, etc as in with http://www.politico.com : It appears to the naive observer in me that whatever is not from politico.com gets denied. $ dillo prefs: {show_menubar} is not a recognized token. prefs: {transient_dialogs} is not a recognized token. prefs: {popup_dialogs} is not a recognized token. prefs: {show_popup_navigation} is not a recognized token. prefs: {vw_aafontname} is not a recognized token. prefs: {fw_aafontname} is not a recognized token. prefs: {font_sizes} is not a recognized token. prefs: {use_oblique} is not a recognized token. prefs: {limit_font_decoration} is not a recognized token. prefs: {force_my_colors} is not a recognized token. prefs: {link_color} is not a recognized token. prefs: {visited_color} is not a recognized token. prefs: {text_color} is not a recognized token. prefs: {user_agent} is not a recognized token. prefs: {send_referer} is not a recognized token. prefs: {tab_bar_homogeneous} is not a recognized token. prefs: {tab_bar_scroller} is not a recognized token. prefs: {tab_bar_show_fullscreen} is not a recognized token. prefs: {tab_close_middle_click} is not a recognized token. prefs: {tab_bar_show_single_tab} is not a recognized token. prefs: {tab_instead_of_window} is not a recognized token. prefs: {tab_load_in_background} is not a recognized token. prefs: {tab_title_compress} is not a recognized token. prefs: {compress_vowels} is not a recognized token. prefs: {compress_common_prefixes} is not a recognized token. prefs: {use_dicache} is not a recognized token. prefs: {focus_location_on_new} is not a recognized token. prefs: {generate_submit} is not a recognized token. prefs: {search_charset} is not a recognized token. prefs: {accept_language} is not a recognized token. paths: Cannot open file '/home/maitra/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='about:splash' Nav_open_url: new url='dpi:/bm/' Nav_open_url: new url='http://www.politico.com' Dns_server [0]: www.politico.com is 208.44.23.10 208.44.23.75 Connecting to 208.44.23.10 Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=1 Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'pixel.quantserve.com' >>>> a_Nav_repush <<<< Nav_open_url: new url='http://www.politico.com' a_Nav_expect_done: repush! CssParser::parseImport(): @import base.css Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=1 CssParser::parseImport(): @import side-modules.css Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=2 CssParser::parseImport(): @import top-stories.css Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=3 CssParser::parseImport(): @import ../common/all-sites.css Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=4 CssParser::parseImport(): @import temp/election2010.css Capi_filters_test: ALLOW from 'www.politico.com' to 'www.politico.com' NumPendingStyleSheets=5 CssParser::parseImport(): @import base.css CssParser::parseImport(): @import side-modules.css CssParser::parseImport(): @import top-stories.css CssParser::parseImport(): @import ../common/all-sites.css CssParser::parseImport(): @import temp/election2010.css Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'pixel.quantserve.com' >>>> a_Nav_repush <<<< Nav_open_url: new url='http://www.politico.com' a_Nav_expect_done: repush! CssParser::parseImport(): @import base.css CssParser::parseImport(): @import side-modules.css CssParser::parseImport(): @import top-stories.css CssParser::parseImport(): @import ../common/all-sites.css CssParser::parseImport(): @import temp/election2010.css CssParser::parseImport(): @import base.css CssParser::parseImport(): @import side-modules.css CssParser::parseImport(): @import top-stories.css CssParser::parseImport(): @import ../common/all-sites.css CssParser::parseImport(): @import temp/election2010.css Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: DENY from 'www.politico.com' to 'www.adobe.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: DENY from 'www.politico.com' to 'ad.doubleclick.net' Capi_filters_test: ALLOW from 'www.politico.com' to 'images.politico.com' Capi_filters_test: DENY from 'www.politico.com' to 'pixel.quantserve.com' Dns_server [0]: images.politico.com is 208.44.23.64 208.44.23.80 etc Is the problem the fact that I am using Fedora which comes with its mindless SELinux? Best, T

Aug. 7, 2011

compile error

by itsme_410＠yahoo.com

----- Original Message ----- From: Walter Dnes <waltdnes(a)waltdnes.org> To: Dillo-dev <dillo-dev(a)dillo.org> Cc: Sent: Saturday, August 6, 2011 10:56 PM Subject: Re: [Dillo-dev] compile error On Sat, Aug 06, 2011 at 01:49:07PM -0700, Globe Trotter wrote > While trying make on the latest version of dillo3, I get the following: > > /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line > /usr/lib64/libX11.so.6: could not read symbols: Invalid operation ? First check that your system actually has file /usr/lib64/libX11.so.6 If it does, try following the suggestion to add it to the linker command line. Thanks! I removed the rpm and recompiled fltk1.3 by hand, and things went through after that.

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by rogerx.oss＠gmail.com

> On Sat, Aug 06, 2011 at 07:02:12PM -0400, Walter Dnes wrote: >> FYI: fltk-1.3 is already in Gentoo Portage. You can emerge it after doing: >> >> $ echo "=x11-libs/fltk-1.3*" >> /etc/portage/package.keywords >> $ echo "=x11-libs/fltk-2*" >> /etc/portage/package.mask >> >> However, sounds like users are still just pulling fltk hg because the in tree >> builds won't play nicely with fltk-2 installed. (... stupid fltk versioning >> screwup.) > > I blew away most of /home/waltdnes/local, keyworded fltk-1.3* as >~amd64 and masked fltk-2* as suggested, rebuilt dillo, and got the same >geometry (mis)behaviour. Another message here suggests that it's a >known fltk problem. > > Gentoo users will have to keep masking fltk-3 manually, until dillo-3 >is ready to go stable. At that time, we'll have to ask the maintainers >of the dillo ebuild and the fltk ebuild to *SIMULTANEOUSLY*... >- make a stable dillo3 ebuild >- mask fltk-3 > > That'll be "fun". Good luck. lol Me and another guy were working fltk-1.3 on bugs.gentoo.com and the bug maintainer(s) didn't seem to want to mess with the slotting, etc. As such, it's slotted along side fltk-1, which sucks if you need fltk-1.1.10 (ie. app-text/htmldoc requires fltk-1 and not fltk-1.3) (Sorry for hijacking the thread.) -- Roger http://rogerx.freeshell.org/

Aug. 7, 2011

compile error

by waltdnes＠waltdnes.org

On Sat, Aug 06, 2011 at 01:49:07PM -0700, Globe Trotter wrote > While trying make on the latest version of dillo3, I get the following: > > /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line > /usr/lib64/libX11.so.6: could not read symbols: Invalid operation First check that your system actually has file /usr/lib64/libX11.so.6 If it does, try following the suggestion to add it to the linker command line. -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 7, 2011

compile error

by itsme_410＠yahoo.com

----- Original Message ----- From: corvid <corvid(a)lavabit.com> To: dillo-dev(a)dillo.org Cc: Sent: Saturday, August 6, 2011 7:15 PM Subject: Re: [Dillo-dev] compile error T wrote: > While trying make on the latest version of dillo3, I get the following: > > g++ -I/usr/include/libpng12 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions? -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib64 -lpng12 -lpng12 -lfltk -lz -lpthread > /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' > /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line > /usr/lib64/libX11.so.6: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[3]: *** [dillo] Error 1 > > > How does one fix this?? When FLTK is being configured, does it complain about not finding X or something? FLTK2 did, but I used to use rpms of dillo to get around the problem. I was using the rpms from rawhide (fedora) to get fltk-1.3. I did not want to mess with that, but I guess I will do that now. Thanks for answering!! T _______________________________________________ Dillo-dev mailing list Dillo-dev(a)dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Aug. 7, 2011

compile error

by corvid＠lavabit.com

T wrote: > While trying make on the latest version of dillo3, I get the following: > > g++ -I/usr/include/libpng12 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions? -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib64 -lpng12 -lpng12 -lfltk -lz -lpthread > /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' > /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line > /usr/lib64/libX11.so.6: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[3]: *** [dillo] Error 1 > > > How does one fix this?? When FLTK is being configured, does it complain about not finding X or something?

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

> FYI: fltk-1.3 is already in Gentoo Portage. You can emerge it after doing: > > $ echo "=x11-libs/fltk-1.3*" >> /etc/portage/package.keywords > $ echo "=x11-libs/fltk-2*" >> /etc/portage/package.mask > > However, sounds like users are still just pulling fltk hg because the in tree > builds won't play nicely with fltk-2 installed. (... stupid fltk versioning > screwup.) I blew away most of /home/waltdnes/local, keyworded fltk-1.3* as ~amd64 and masked fltk-2* as suggested, rebuilt dillo, and got the same geometry (mis)behaviour. Another message here suggests that it's a known fltk problem. Gentoo users will have to keep masking fltk-3 manually, until dillo-3 is ready to go stable. At that time, we'll have to ask the maintainers of the dillo ebuild and the fltk ebuild to *SIMULTANEOUSLY*... - make a stable dillo3 ebuild - mask fltk-3 That'll be "fun". -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by corvid＠lavabit.com

Walter wrote: > On Sat, Aug 06, 2011 at 10:17:57PM +0000, corvid wrote > > > FLTK seems to have problems with geometry. If you go to the FLTK test/ > > directory and play with them, they misbehave similarly. > > (I use fvwm, incidentally.) > > Has a bug report been filed with upstream fltk developers? Umm... not that I'm aware of. You can look through http://fltk.org/roadmap.php (all of those 1.4 bugs were moved there to get them out of the way for the 1.3.0 release, but they're still really 1.3 bugs)

Aug. 7, 2011

fltk widget schemes

by corvid＠lavabit.com

Do you think any good could come from playing around with the different widget schemes? "none" is the default, and "plastic" and "gtk+" are the other choices. e.g.: diff -r 6fe817711ef4 src/dillo.cc --- a/src/dillo.cc Fri Aug 05 21:39:27 2011 -0400 +++ b/src/dillo.cc Sat Aug 06 22:34:28 2011 +0000 @@ -379,6 +379,8 @@ // only way to set the // default font in fltk1.3 + Fl::scheme("plastic"); + // Create a new UI/bw pair BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, xid, NULL);

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

On Sat, Aug 06, 2011 at 10:17:57PM +0000, corvid wrote > FLTK seems to have problems with geometry. If you go to the FLTK test/ > directory and play with them, they misbehave similarly. > (I use fvwm, incidentally.) Has a bug report been filed with upstream fltk developers? -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by corvid＠lavabit.com

Walter wrote: > I don't know if this is a problem with ICEWM on my machine or dillo. > I've only seen it with dillo, so I assume that's the source. I'm > running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as > the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under > /home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did > an "hg pull" last night, so this should be a recent version. > > In ~/.dillorc, I have... > geometry=950x1050+960+0 > but pressing {ALT}{LEFT-MOUSE} on the dillo window frame reports a > geometry of 850x949+956-24 > > Looking at the display, I see two separate problems... > > 1) Positioning > ============== > The URL is flush against the top of the display, and the title bar > is off the top of the display. Changing ~/.dillorc to... > geometry=950x1050+960+24 > results in the title bar being fully visible, like I expect. I don't > know whether it's a fixed offset of 24, or if dillo is ignoring the > height of the WM window decoration when positioning at startup. > > 2) Reporting size > ================= > When I click {ALT}{LEFT-MOUSE} on the frame, the reported size values > are too small. I specify size 950x1050 in the .dillorc geometry setting > but the reported size is 850x949. The *ACTUAL* size of the dillo window > appears to be correct, but the *REPORTED* size is wrong. I have an > Opera window open that's 950x1050, and the dillo window overlays it > almost exactly. I maximized the dillo window using the WM maximize > button on the upper right. {ALT}{LEFT-MOUSE} on the dillo window frame, > reports 1820x959-4-4 but my display is 1920x1080. The reported geometry > seems to have the x-coordinate consistently 100 pixels too small. The > y-coordinate is also too small, but I'm not sure of the exact amount, or > whether it's constant. My guess is that it's 101 pixels too small, > after counting the -24 offset. FLTK seems to have problems with geometry. If you go to the FLTK test/ directory and play with them, they misbehave similarly. (I use fvwm, incidentally.)

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by rogerx.oss＠gmail.com

> On Sat, Aug 06, 2011 at 04:45:46PM -0400, Walter Dnes wrote: > I don't know if this is a problem with ICEWM on my machine or dillo. >I've only seen it with dillo, so I assume that's the source. I'm >running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as >the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under >/home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did >an "hg pull" last night, so this should be a recent version. FYI: fltk-1.3 is already in Gentoo Portage. You can emerge it after doing: $ echo "=x11-libs/fltk-1.3*" >> /etc/portage/package.keywords $ echo "=x11-libs/fltk-2*" >> /etc/portage/package.mask However, sounds like users are still just pulling fltk hg because the in tree builds won't play nicely with fltk-2 installed. (... stupid fltk versioning screwup.) -- Roger http://rogerx.freeshell.org/

Aug. 6, 2011

compile error

by itsme_410＠yahoo.com

While trying make on the latest version of dillo3, I get the following: g++ -I/usr/include/libpng12 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions? -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib64 -lpng12 -lpng12 -lfltk -lz -lpthread /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line /usr/lib64/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[3]: *** [dillo] Error 1 How does one fix this?? Best! T

Aug. 6, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

I don't know if this is a problem with ICEWM on my machine or dillo. I've only seen it with dillo, so I assume that's the source. I'm running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under /home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did an "hg pull" last night, so this should be a recent version. In ~/.dillorc, I have... geometry=950x1050+960+0 but pressing {ALT}{LEFT-MOUSE} on the dillo window frame reports a geometry of 850x949+956-24 Looking at the display, I see two separate problems... 1) Positioning ============== The URL is flush against the top of the display, and the title bar is off the top of the display. Changing ~/.dillorc to... geometry=950x1050+960+24 results in the title bar being fully visible, like I expect. I don't know whether it's a fixed offset of 24, or if dillo is ignoring the height of the WM window decoration when positioning at startup. 2) Reporting size ================= When I click {ALT}{LEFT-MOUSE} on the frame, the reported size values are too small. I specify size 950x1050 in the .dillorc geometry setting but the reported size is 850x949. The *ACTUAL* size of the dillo window appears to be correct, but the *REPORTED* size is wrong. I have an Opera window open that's 950x1050, and the dillo window overlays it almost exactly. I maximized the dillo window using the WM maximize button on the upper right. {ALT}{LEFT-MOUSE} on the dillo window frame, reports 1820x959-4-4 but my display is 1920x1080. The reported geometry seems to have the x-coordinate consistently 100 pixels too small. The y-coordinate is also too small, but I'm not sure of the exact amount, or whether it's constant. My guess is that it's 101 pixels too small, after counting the -24 offset. -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by waltdnes＠waltdnes.org

On Sat, Aug 06, 2011 at 06:44:32PM +0300, Rogut??s Sparnuotos wrote > Jorge Arellano Cid (2011-08-06 11:17): > > > > I've found use for both, but now tend more to focusing the main area. > > > > Quick poll: what do you prefer? > > I wonder who would want to type another URL right after loading the first > one? > > I think that it is more convenient when focus is moved to content. I also want focus on main. I agree with the parent post that if you've just typed/selected a URL, you wouldn't normally want to input a new one. -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by abe＠deuxchevaux.org

Hi, On Sat, Aug 06, 2011 at 11:17:34AM -0400, Jorge Arellano Cid wrote: > I've found use for both, but now tend more to focusing the main area. > > Quick poll: what do you prefer? Focussing main to be able to immediately start scrolling with the keyboard after the page has loaded. I found it too often annoying when (in other browsers) some site sets the focus after loading to some input field like e.g. the search area and therefore prevents scrolling. Latest example was the online shop at galaxus.com. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by corvid＠lavabit.com

Jorge wrote: > On Sat, Aug 06, 2011 at 02:34:08PM +0900, furaisanjin wrote: > > Hi all. > > > > I tried dillo-3.0 pre and found that focus stays on address bar after > > I typed URL. This behavior was fixed on dillo-2.0 but it appears again > > on 3.0 pre. > > Good point. > > This is not a BUG, but AFAIR just lack of definition an what to do. > Some people prefer focus to stay on the location (to type for similar > URLs), and others to focus the main area. > > I've found use for both, but now tend more to focusing the main area. > > Quick poll: what do you prefer? Focusing main.

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by rogutes＠googlemail.com

Jorge Arellano Cid (2011-08-06 11:17): > On Sat, Aug 06, 2011 at 02:34:08PM +0900, furaisanjin wrote: > > Hi all. > > > > I tried dillo-3.0 pre and found that focus stays on address bar after > > I typed URL. This behavior was fixed on dillo-2.0 but it appears again > > on 3.0 pre. > > Good point. > > This is not a BUG, but AFAIR just lack of definition an what to do. > Some people prefer focus to stay on the location (to type for similar > URLs), and others to focus the main area. > > I've found use for both, but now tend more to focusing the main area. > > Quick poll: what do you prefer? I wonder who would want to type another URL right after loading the first one? I think that it is more convenient when focus is moved to content. -- -- Rogut?s Sparnuotos

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by obeythepenguin＠gmail.com

On Sat, 06 Aug 2011 11:17:34 -0400, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Sat, Aug 06, 2011 at 02:34:08PM +0900, furaisanjin wrote: >> Hi all. >> >> I tried dillo-3.0 pre and found that focus stays on address bar after >> I typed URL. This behavior was fixed on dillo-2.0 but it appears again >> on 3.0 pre. > > Good point. > > This is not a BUG, but AFAIR just lack of definition an what to do. > Some people prefer focus to stay on the location (to type for similar > URLs), and others to focus the main area. > > I've found use for both, but now tend more to focusing the main area. > > Quick poll: what do you prefer? I prefer focusing on the main area, like every browser's been doing since 1994. ;-) ~Benjamin

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by jcid＠dillo.org

On Sat, Aug 06, 2011 at 02:34:08PM +0900, furaisanjin wrote: > Hi all. > > I tried dillo-3.0 pre and found that focus stays on address bar after > I typed URL. This behavior was fixed on dillo-2.0 but it appears again > on 3.0 pre. Good point. This is not a BUG, but AFAIR just lack of definition an what to do. Some people prefer focus to stay on the location (to type for similar URLs), and others to focus the main area. I've found use for both, but now tend more to focusing the main area. Quick poll: what do you prefer? -- Cheers Jorge.-

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by furaisanjin＠gmail.com

Hi all. I tried dillo-3.0 pre and found that focus stays on address bar after I typed URL. This behavior was fixed on dillo-2.0 but it appears again on 3.0 pre. Regards, furaisanjin

Aug. 6, 2011