- Dillo-dev - lists.mailman3.com

[PATCH] Toolbar button to control zoom level

by a1ex＠dismail.de

Hi, Here is an updated patch with a better icon and fixed tooltip. Hopefully somebody finds it useful :) diff -u ./pixmaps.h mod/pixmaps.h --- ./pixmaps.h Sat Jul 6 18:03:43 2024 +++ mod/pixmaps.h Sat Jul 6 18:23:27 2024 @@ -1410,6 +1410,28 @@ }; /* XPM */ +static const char *const zoom_xpm[] = { +"16 16 2 1", +" c None", +"@ c gray70", +" ", +" @@@@@@ ", +" @ @ ", +" @ @ ", +" @ @@ @ ", +" @ @@ @ ", +" @ @@ @ ", +" @ @@@@@@@@ @ ", +" @ @@@@@@@@ @ ", +" @ @@ @ ", +" @ @@ @ ", +" @ @@ @ ", +" @ @@@@ ", +" @@@@@@ @@@", +" @@", +" "}; + +/* XPM */ static const char *const new_s_xpm[] = { "11 11 35 1", " c None", diff -u ./ui.cc mod/ui.cc --- ./ui.cc Sat Jul 6 18:26:52 2024 +++ mod/ui.cc Sat Jul 6 18:03:57 2024 @@ -38,7 +38,7 @@ struct iconset { Fl_Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, *ImgZoom, *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; }; @@ -51,6 +51,7 @@ new Fl_Pixmap(save_xpm), new Fl_Pixmap(bm_xpm), new Fl_Pixmap(tools_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), new Fl_Pixmap(search_xpm), new Fl_Pixmap(help_xpm), @@ -70,6 +71,7 @@ new Fl_Pixmap(save_s_xpm), new Fl_Pixmap(bm_s_xpm), new Fl_Pixmap(tools_s_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), standard_icons.ImgSearch, standard_icons.ImgHelp, @@ -356,6 +358,13 @@ wid->y() + wid->h()); } break; + case UI_ZOOM: + if (b == FL_LEFT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); + } + break; default: break; } @@ -433,6 +442,7 @@ Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); Tools = make_button("Tools", icons->ImgTools, NULL, UI_TOOLS); + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); Back->set_tooltip("Previous page"); Forw->set_tooltip("Next page"); @@ -442,6 +452,7 @@ Stop->set_tooltip("Stop loading"); Bookmarks->set_tooltip("View bookmarks"); Tools->set_tooltip("Settings"); + Zoom->set_tooltip("Zoom in: left-click, Zoom out: right-click"); } /** diff -u ./ui.hh mod/ui.hh --- ./ui.hh Sat Jul 6 18:03:43 2024 +++ mod/ui.hh Sat Jul 6 18:03:57 2024 @@ -23,6 +23,7 @@ UI_STOP, UI_BOOK, UI_TOOLS, + UI_ZOOM, UI_CLEAR, UI_SEARCH } UIButton; @@ -125,7 +126,7 @@ CustGroupVertical *TopGroup; CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, - *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; + *Tools, *Zoom, *Clear, *Search, *Help, *BugMeter, *FileButton; CustGroupHorizontal *LocBar, *NavBar, *StatusBar; Fl_Input *Location; CustProgressBox *PProg, *IProg; -Alex

July 7, 2024

RFC repository

by Rodrigo Arias

Hi, I've decided to open a RFC-like repository for Dillo here: https://github.com/dillo-browser/rfc So we can have a centralized place to propose and discuss non-arbitrary changes or other topics regarding Dillo. For now they are just Markdown files so they are easy to read and write from any editor and we don't rely much on GitHub. This also allows contributions by sending patches via email. I'll be collecting more thoughts about the rule-based mechanism I was talking about in other threads in the RFC-002: Rule-based content manipulation, here: https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… I may also add the PEC proposal I did the other day to classify how broken are pages when you disable JS, although it not very Dillo specific: https://dillo-browser.github.io/pec/ Best, Rodrigo.

July 7, 2024

Re: dillo mouse cursor

by a1ex＠dismail.de

On Sun, 7 Jul 2024 11:47:37 -0600 pastebin(a)gmx.com wrote: > Hi > > this is my original mouse pointer > xsetroot -cursor_name left_ptr > > when playing around with mouse cursors (i like this size) > xsetroot -xcf /usr/share/icons/DMZ-Black/cursors/left_ptr 48 > > when i go into a text box on a site or move mouse to dillo's buttons > on top the cursor changes to the original mouse pointer > > if i load a new dillo the large cursor comes back - until i pass the > mouse cursor over a text box or dillo's top buttons again > > the large cursor isn't affected by text boxes on other program I don't know what type of system you are running, but you could try putting the following in your ~/.Xdefaults file: Xcursor.theme: DMZ-Black Xcursor.size: 48 Regards, Alex

July 7, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi besides changing the rc = chdir("/tmp"); in src/paths.c to rc = chdir("/html"); i also changed the rc = chdir("/tmp"); to rc = chdir("/html"); in dpi/datauri.c and dpi/ftp.c everything seems okay but if these are 'wrong' please let me know On Sun, 7 Jul 2024 19:15:57 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jul 06, 2024 at 09:56:17AM -0600, pastebin(a)gmx.com wrote: > >Hi, > > > >Thanks Rodrigo for working with Albrecht-S > > > >i think this issue is now resolved for me > > > >when saving an html > > > >1. if i like the highlightd name given in the Filename: box i just click 'ok' > > > >2. if i want to add more text or suffix to the highlighted name given in the Filename: box i just hit 'end' key (easier then using mouse click in filename box) and enter what i want > > > >3, if i want to enter a completely new name to save in save_dir (problem being dillo enters /tmp now) > > > >i don't know if changing rc = chdir("/tmp"); to rc = chdir("/html"); in src/paths.cc is what you meant by your suggestion : > > > >> One option to work around it is to chdir() to the save_dir, so at least > >> it would make a bit more sense. > > > >but by doing so now > > > >it now puts /html/'firstkeypressed' an i can put the name i want there > >(i didn't know how to put the save_dir variable there instead of my > >hardcoded "/html" which would be better) (i get make error ->? > >save_dir not defined in this scope) > > > >so all seems fixed - for me anyway > > Yeah, that's what I meant, but instead of hard-coding the "/html" we > pick it from the preferences as `pref.save_dir` (should be an easy > patch). > > > > >thank Albrecht-S for his work and interesting posts in the > >https://github.com/fltk/fltk/issues/1004#issuecomment-2210810570 > > > >i think the only issue left here is Albrecht-S saying that hitting '/' leaves a '/' there > >my hitting the '/' key just erases highlight and leaves nothing in the filename box :) > > Yeah, I'll try to find where it is coming from, but I want finish other > things first. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 7, 2024

Re: dillo mouse cursor

by pastebin＠gmx.com

Hi this is my original mouse pointer xsetroot -cursor_name left_ptr when playing around with mouse cursors (i like this size) xsetroot -xcf /usr/share/icons/DMZ-Black/cursors/left_ptr 48 when i go into a text box on a site or move mouse to dillo's buttons on top the cursor changes to the original mouse pointer if i load a new dillo the large cursor comes back - until i pass the mouse cursor over a text box or dillo's top buttons again the large cursor isn't affected by text boxes on other programs

July 7, 2024

Re: extra /tmp on file name line when save html

by Rodrigo Arias

Hi, On Sat, Jul 06, 2024 at 09:56:17AM -0600, pastebin(a)gmx.com wrote: >Hi, > >Thanks Rodrigo for working with Albrecht-S > >i think this issue is now resolved for me > >when saving an html > >1. if i like the highlightd name given in the Filename: box i just click 'ok' > >2. if i want to add more text or suffix to the highlighted name given in the Filename: box i just hit 'end' key (easier then using mouse click in filename box) and enter what i want > >3, if i want to enter a completely new name to save in save_dir (problem being dillo enters /tmp now) > >i don't know if changing rc = chdir("/tmp"); to rc = chdir("/html"); in src/paths.cc is what you meant by your suggestion : > >> One option to work around it is to chdir() to the save_dir, so at least >> it would make a bit more sense. > >but by doing so now > >it now puts /html/'firstkeypressed' an i can put the name i want there >(i didn't know how to put the save_dir variable there instead of my >hardcoded "/html" which would be better) (i get make error ->? >save_dir not defined in this scope) > >so all seems fixed - for me anyway Yeah, that's what I meant, but instead of hard-coding the "/html" we pick it from the preferences as `pref.save_dir` (should be an easy patch). > >thank Albrecht-S for his work and interesting posts in the >https://github.com/fltk/fltk/issues/1004#issuecomment-2210810570 > >i think the only issue left here is Albrecht-S saying that hitting '/' leaves a '/' there >my hitting the '/' key just erases highlight and leaves nothing in the filename box :) Yeah, I'll try to find where it is coming from, but I want finish other things first. Best, Rodrigo.

July 7, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Kevin, On Sun, Jul 07, 2024 at 10:21:05AM +1000, Kevin Koster wrote: >Rodrigo Arias wrote: >> Working on these examples is very helpful to design the rule system, so >> feel free to mention more cases. > >In addition to HTTP header feilds, it would be handy to assign >rewrite rules according to HTTP status codes. I spend a lot of time >browsing dead/dying websites so I'm always using the Wayback >Machine. I'd like to use this system to process 404 (500, etc.) >error pages through a program/script that adds a link at the top to >look up the URL at the Wayback Machine. It might also check for a >copy I've archived locally, if I get my website archives more >organised, and link to that as well. Good idea, this should be doable with the rule mechanism. An important consideration is to be able to quickly forward good requests or responses, so we reduce the overhead in overall browsing. We could probably just hook it to >= 400 and then you handle those broken responses as you want, while quickly forwarding 200 to Dillo: match http-status-code >= 400 action broken-page I think we may need to define several "tables" like in iptables so we can have rules that handle the traffic at different stages. This one doesn't require decoding the compressed content. >I've already got the Wayback Machine set up as a search option >in dillorc which returns the latest archived copy of a URL: >search_url="w Wayback Machine http://web.archive.org/web/%s" > >But I use it so much that the ease of just clicking a link would be >a real advantage, especially after opening multiple broken links >from a page. I might even try to write something that detects >archived error pages and works back to the last actual copy of the >page. I think this is a very good addition to the default set of search engines. Thanks, Rodrigo.

July 7, 2024

Re: Option to define external link handler

by Kevin Koster

Rodrigo Arias wrote: > Working on these examples is very helpful to design the rule system, so > feel free to mention more cases. In addition to HTTP header feilds, it would be handy to assign rewrite rules according to HTTP status codes. I spend a lot of time browsing dead/dying websites so I'm always using the Wayback Machine. I'd like to use this system to process 404 (500, etc.) error pages through a program/script that adds a link at the top to look up the URL at the Wayback Machine. It might also check for a copy I've archived locally, if I get my website archives more organised, and link to that as well. I've already got the Wayback Machine set up as a search option in dillorc which returns the latest archived copy of a URL: search_url="w Wayback Machine http://web.archive.org/web/%s" But I use it so much that the ease of just clicking a link would be a real advantage, especially after opening multiple broken links from a page. I might even try to write something that detects archived error pages and works back to the last actual copy of the page.

July 7, 2024

Re: dillo mouse cursor

by a1ex＠dismail.de

On Sat, 6 Jul 2024 11:23:48 -0600 pastebin(a)gmx.com wrote: > Hi > > anyone have any interesting mouse cursor pointers? I've been using "Alkano All In One" recently and am quite happy with it. Since my desktop has a dark theme, I chose the scarlet variant, which I think is the most eye-catching. https://www.gnome-look.org/p/999933/ Regards, Alex

July 6, 2024

dillo mouse cursor

by pastebin＠gmx.com

Hi anyone have any interesting mouse cursor pointers? i'm using a left arrow pointer - then over a link becomes left pointing hand xsetroot -cursor_name left_ptr

July 6, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

On Sat, 6 Jul 2024 14:30:01 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi Alex, > > >Here is a patch which allows zooming in and out using the Refresh > >button. Right clicking on it zooms the page in. Middle clicking zooms > >out. It's not especially intuitive, but it's simple and it works. > > I agree is not very intuitive, maybe using the scroll wheel may be > more clear. But still, tying it to the refresh button is weird to me. > > On the other hand, I like that you can see the whole page while > changing the zoom level using the mouse (which doesn't happen in > other browsers). I'm thinking if it could make sense to add another > "appearance" bar (usually hidden) like the "find text" where we can > put some knobs to change the page appearance, like the zoom buttons > or sliders but also maybe some of the CSS options too. > > I think this would also make more sense if we can select multiple > "user" styles to implement some king of reader mode, as you will want > to see the effect without covering the canvas. Your idea of an "appearance" bar sounds interesting. I was originally thinking it would be neat to have the zoom buttons on the bottom next to the bugmeter, similar to what you are suggesting. Since that sounds more like a long-term goal, I have come up with a patch to create a dedicated zoom button on the toolbar. Left-click zooms in, right-click zooms out. Its just a proof of concept, but if you like the idea, maybe I could polish it up and make an optional setting for it, etc. Here you go: diff -u ./pixmaps.h mod/pixmaps.h --- ./pixmaps.h Sat Jul 6 18:03:43 2024 +++ mod/pixmaps.h Sat Jul 6 18:23:27 2024 @@ -1410,6 +1410,28 @@ }; /* XPM */ +static const char *const zoom_xpm[] = { +"16 16 2 1", +" c None", +"@ c gray70", +" ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@@@@@@@@@@@@ ", +" @@@@@@@@@@@@@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" @@ ", +" "}; + +/* XPM */ static const char *const new_s_xpm[] = { "11 11 35 1", " c None", diff -u ./ui.cc mod/ui.cc --- ./ui.cc Sat Jul 6 18:26:52 2024 +++ mod/ui.cc Sat Jul 6 18:03:57 2024 @@ -38,7 +38,7 @@ struct iconset { Fl_Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, *ImgZoom, *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; }; @@ -51,6 +51,7 @@ new Fl_Pixmap(save_xpm), new Fl_Pixmap(bm_xpm), new Fl_Pixmap(tools_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), new Fl_Pixmap(search_xpm), new Fl_Pixmap(help_xpm), @@ -70,6 +71,7 @@ new Fl_Pixmap(save_s_xpm), new Fl_Pixmap(bm_s_xpm), new Fl_Pixmap(tools_s_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(new_s_xpm), standard_icons.ImgSearch, standard_icons.ImgHelp, @@ -356,6 +358,13 @@ wid->y() + wid->h()); } break; + case UI_ZOOM: + if (b == FL_LEFT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); + } + break; default: break; } @@ -433,6 +442,7 @@ Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); Tools = make_button("Tools", icons->ImgTools, NULL, UI_TOOLS); + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); Back->set_tooltip("Previous page"); Forw->set_tooltip("Next page"); @@ -442,6 +452,7 @@ Stop->set_tooltip("Stop loading"); Bookmarks->set_tooltip("View bookmarks"); Tools->set_tooltip("Settings"); + Tools->set_tooltip("Zoom"); } /** diff -u ./ui.hh mod/ui.hh --- ./ui.hh Sat Jul 6 18:03:43 2024 +++ mod/ui.hh Sat Jul 6 18:03:57 2024 @@ -23,6 +23,7 @@ UI_STOP, UI_BOOK, UI_TOOLS, + UI_ZOOM, UI_CLEAR, UI_SEARCH } UIButton; @@ -125,7 +126,7 @@ CustGroupVertical *TopGroup; CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, - *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; + *Tools, *Zoom, *Clear, *Search, *Help, *BugMeter, *FileButton; CustGroupHorizontal *LocBar, *NavBar, *StatusBar; Fl_Input *Location; CustProgressBox *PProg, *IProg; Regards, Alex

July 6, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi, Thanks Rodrigo for working with Albrecht-S i think this issue is now resolved for me when saving an html 1. if i like the highlightd name given in the Filename: box i just click 'ok' 2. if i want to add more text or suffix to the highlighted name given in the Filename: box i just hit 'end' key (easier then using mouse click in filename box) and enter what i want 3, if i want to enter a completely new name to save in save_dir (problem being dillo enters /tmp now) i don't know if changing rc = chdir("/tmp"); to rc = chdir("/html"); in src/paths.cc is what you meant by your suggestion : > One option to work around it is to chdir() to the save_dir, so at least > it would make a bit more sense. but by doing so now it now puts /html/'firstkeypressed' an i can put the name i want there (i didn't know how to put the save_dir variable there instead of my hardcoded "/html" which would be better) (i get make error ->? save_dir not defined in this scope) so all seems fixed - for me anyway thank Albrecht-S for his work and interesting posts in the https://github.com/fltk/fltk/issues/1004#issuecomment-2210810570 i think the only issue left here is Albrecht-S saying that hitting '/' leaves a '/' there my hitting the '/' key just erases highlight and leaves nothing in the filename box :) On Sat, 6 Jul 2024 14:10:22 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > >the problem is 2 parts > >in dillo - switching from the savedir to /tmp dir when first 'd' > >pressed and then repeating /tmp/d/tmp/d when another 'd' is pressed > > > >the fix only fixes the repeat to /tmp/d/tmp/d when a second d is > >pressed but the changing from savedir to /tmp/d still happens when > >first d is pressed > > > >your program only shows the second part of the problem (and that part > >is fixed) since it does the chdir("/tmp") itself and not what happens > >with dillo when the first 'd' is pressed > > > >the fix only fixes the repeat not the initial change to /tmp dir from > >the savedir > > This is a "design" decision by FLTK[1], as when a non-/ character is > added it is considered as a relative path *to the current directory* > which is always set to /tmp in Dillo (regardless of the save_dir) and it > gets prefixed. > > [1]: https://github.com/fltk/fltk/issues/1004#issuecomment-2210810570 > > One option to work around it is to chdir() to the save_dir, so at least > it would make a bit more sense. yes i edited src/paths.cc rc = chdir("/html"); // rc = chdir("/tmp"); > Another good idea is to switch to the native file chooser which also > comes with other niceties (but this problem will continue there if the > native file chooser is not available). what source is the 'native file chooser' in? > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 6, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi Alex, >Here is a patch which allows zooming in and out using the Refresh >button. Right clicking on it zooms the page in. Middle clicking zooms >out. It's not especially intuitive, but it's simple and it works. I agree is not very intuitive, maybe using the scroll wheel may be more clear. But still, tying it to the refresh button is weird to me. On the other hand, I like that you can see the whole page while changing the zoom level using the mouse (which doesn't happen in other browsers). I'm thinking if it could make sense to add another "appearance" bar (usually hidden) like the "find text" where we can put some knobs to change the page appearance, like the zoom buttons or sliders but also maybe some of the CSS options too. I think this would also make more sense if we can select multiple "user" styles to implement some king of reader mode, as you will want to see the effect without covering the canvas. Rodrigo.

July 6, 2024

Re: Nice work

by Rodrigo Arias

Hi, On Sat, Jul 06, 2024 at 06:45:51AM -0400, Kate Draven wrote: >Just started playing with Dillo. Nice work. Can't wait to see where >it's going. > >Keep up the good work. I have a feeling I and soon, many people will >be using it to get away from the bloat rubbish that most browsers have >become. > >Again, nice work. Thanks Kate, it is good to see more people interested in Dillo :-) Rodrigo.

July 6, 2024

Re: extra /tmp on file name line when save html

by Rodrigo Arias

Hi, >the problem is 2 parts >in dillo - switching from the savedir to /tmp dir when first 'd' >pressed and then repeating /tmp/d/tmp/d when another 'd' is pressed > >the fix only fixes the repeat to /tmp/d/tmp/d when a second d is >pressed but the changing from savedir to /tmp/d still happens when >first d is pressed > >your program only shows the second part of the problem (and that part >is fixed) since it does the chdir("/tmp") itself and not what happens >with dillo when the first 'd' is pressed > >the fix only fixes the repeat not the initial change to /tmp dir from >the savedir This is a "design" decision by FLTK[1], as when a non-/ character is added it is considered as a relative path *to the current directory* which is always set to /tmp in Dillo (regardless of the save_dir) and it gets prefixed. [1]: https://github.com/fltk/fltk/issues/1004#issuecomment-2210810570 One option to work around it is to chdir() to the save_dir, so at least it would make a bit more sense. Another good idea is to switch to the native file chooser which also comes with other niceties (but this problem will continue there if the native file chooser is not available). Rodrigo.

July 6, 2024

Nice work

by Kate Draven

Just started playing with Dillo. Nice work. Can't wait to see where it's going. Keep up the good work. I have a feeling I and soon, many people will be using it to get away from the bloat rubbish that most browsers have become. Again, nice work. Cheers, Kate Draven

July 6, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi it is the highlight that is the problem when removed by clicking in the filename location all is good when any 'key' but '/' is done it puts /tmp/'key' there with '/' it just clears the box and nothing is put there fltk knows about the save_dir because it puts it there in the first place but loses site of it when highlight is cleared and (i guess) default dir '/tmp' is used just not using the hightlight would probably solve the problem cosmetically but not algorithmically wise whoever is putting '/tmp/key' there should put the 'save_dir/key' there instead On Thu, 4 Jul 2024 19:57:59 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > > A fix was provided by FLTK developer Albrecht Schlosser: > > https://github.com/fltk/fltk/issues/1004#issuecomment-2209144366 > > You can take the "branch-1.3" branch which also contains the fix (f34719). > > $ git clone https://github.com/fltk/fltk > $ cd fltk > $ git checkout branch-1.3 > ... > > Can you check it solves your issue? They are waiting for confirmation to > close the issue on their side. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 5, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

On Wed, 26 Jun 2024 21:16:47 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >One thing which I would suggest is also having optional toolbar > >buttons to control this. > > Yeah, I thought about adding three new menu items in the main menu or > under a sub-menu, but I like the idea of Firefox and Chromium where > they placed both the [-] [+] buttons inside a main menu item. > > Not sure how hard it would be to do with FLTK. I briefly looked at adding this to the Page menu, it certainly looks possible, but it's a little beyond me at the moment. Same with toolbar buttons. So, right now I just tried to find the least complicated way to zoom with the mouse. Here is a patch which allows zooming in and out using the Refresh button. Right clicking on it zooms the page in. Middle clicking zooms out. It's not especially intuitive, but it's simple and it works. $ diff -u ui.cc.orig ui.cc.mod --- ui.cc.orig Fri Jul 5 15:04:00 2024 +++ ui.cc.mod Fri Jul 5 16:07:48 2024 @@ -333,6 +333,10 @@ case UI_RELOAD: if (b == FL_LEFT_MOUSE) { a_UIcmd_reload(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); } break; case UI_SAVE: Regards, Alex

July 5, 2024

Re: use remote css unchecked

by pastebin＠gmx.com

Hi thanks - that works perfectly On Thu, 4 Jul 2024 20:08:49 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Thu, Jul 04, 2024 at 10:11:12AM -0600, pastebin(a)gmx.com wrote: > >Hi, > > > >shouldn't the lines wrap with > >https://packetstormsecurity.com/files/179337/Red-Hat-Security-Advisory-2024… > >with 'tools/use remote css' unchecked? > > > >with 'tools/use remote css' checked the lines wrap but their css looks horrible (to me) > > This is the default behavior when no other CSS rules are applied. If you > want to break the lines by default, you can add this rule to break long > lines at word boundary: > > $ echo 'pre { white-space: pre-wrap; }' >> ~/.dillo/style.css > > Then reload the page. See also: > > https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#content > > Note that it will affect any page that has a pre tag an no other rules > override that value. > > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 4, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi with the git clone https://github.com/fltk/fltk i get Cloning into 'fltk'... warning: templates not found in /usr/share/git-core/templates remote: Enumerating objects: 92570, done. remote: Counting objects: 100% (2620/2620), done. remote: Compressing objects: 100% (1123/1123), done. remote: Total 92570 (delta 1721), reused 2113 (delta 1485), pack-reused 89950 Receiving objects: 100% (92570/92570), 42.09 MiB | 1.28 MiB/s, done. Resolving deltas: 100% (75407/75407), done. /usr/src/fltk > cd fltk /usr/src/fltk/fltk > git checkout branch-1.3 branch 'branch-1.3' set up to track 'origin/branch-1.3'. Switched to a new branch 'branch-1.3' autogen.sh configure --enable-shared make make install /usr/local/lib -rw-r--r-- 1 root root 48325 Jul 04 2024 14:21:52 Fl_File_Chooser2.cxx -rw-r--r-- 1 root root 15407 Jul 04 2024 14:21:52 Fl_File_Chooser.cxx -rw-r--r-- 1 root root 15000 Jul 04 2024 14:21:52 Fl_File_Chooser.fl the problem is 2 parts in dillo - switching from the savedir to /tmp dir when first 'd' pressed and then repeating /tmp/d/tmp/d when another 'd' is pressed the fix only fixes the repeat to /tmp/d/tmp/d when a second d is pressed but the changing from savedir to /tmp/d still happens when first d is pressed your program only shows the second part of the problem (and that part is fixed) since it does the chdir("/tmp") itself and not what happens with dillo when the first 'd' is pressed the fix only fixes the repeat not the initial change to /tmp dir from the savedir On Thu, 4 Jul 2024 19:57:59 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Wed, Jul 03, 2024 at 12:01:47PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >a little contribution to your code in case someone wants to make a huge statically compiled version of the program :) > > > >g++ -O2 test.cpp-static -o test /usr/local/lib/libfltk.a /usr/local/lib/libX11.a /usr/local/lib/libxcb.a /usr/local/lib/libXft.a /usr/local/lib/libfontconfig.a /lib/libdl.a /usr/local/lib/libXfixes.a /usr/local/lib/libXrender.a /usr/local/lib/libXcursor.a /usr/local/lib/libXinerama.a /usr/local/lib/libXext.a /usr/local/lib/libXau.a /usr/local/lib/libXdmcp.a /usr/local/lib/libfreetype.a /usr/local/lib/libexpat.a /usr/local/lib/libXrender.a /usr/local/lib/libX11.a /usr/local/lib/libXfixes.a /usr/local/lib/libpng.a /lib/libz.a /usr/local/lib/libharfbuzz.a /lib/libbz2.a /lib/libpthread.a > > Thanks. > > A fix was provided by FLTK developer Albrecht Schlosser: > > https://github.com/fltk/fltk/issues/1004#issuecomment-2209144366 > > You can take the "branch-1.3" branch which also contains the fix (f34719). > > $ git clone https://github.com/fltk/fltk > $ cd fltk > $ git checkout branch-1.3 > ... > > Can you check it solves your issue? They are waiting for confirmation to > close the issue on their side. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 4, 2024

Re: use remote css unchecked

by Rodrigo Arias

Hi, On Thu, Jul 04, 2024 at 10:11:12AM -0600, pastebin(a)gmx.com wrote: >Hi, > >shouldn't the lines wrap with >https://packetstormsecurity.com/files/179337/Red-Hat-Security-Advisory-2024… >with 'tools/use remote css' unchecked? > >with 'tools/use remote css' checked the lines wrap but their css looks horrible (to me) This is the default behavior when no other CSS rules are applied. If you want to break the lines by default, you can add this rule to break long lines at word boundary: $ echo 'pre { white-space: pre-wrap; }' >> ~/.dillo/style.css Then reload the page. See also: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#content Note that it will affect any page that has a pre tag an no other rules override that value. Rodrigo.

July 4, 2024

Re: extra /tmp on file name line when save html

by Rodrigo Arias

On Wed, Jul 03, 2024 at 12:01:47PM -0600, pastebin(a)gmx.com wrote: >Hi > >a little contribution to your code in case someone wants to make a huge statically compiled version of the program :) > >g++ -O2 test.cpp-static -o test /usr/local/lib/libfltk.a /usr/local/lib/libX11.a /usr/local/lib/libxcb.a /usr/local/lib/libXft.a /usr/local/lib/libfontconfig.a /lib/libdl.a /usr/local/lib/libXfixes.a /usr/local/lib/libXrender.a /usr/local/lib/libXcursor.a /usr/local/lib/libXinerama.a /usr/local/lib/libXext.a /usr/local/lib/libXau.a /usr/local/lib/libXdmcp.a /usr/local/lib/libfreetype.a /usr/local/lib/libexpat.a /usr/local/lib/libXrender.a /usr/local/lib/libX11.a /usr/local/lib/libXfixes.a /usr/local/lib/libpng.a /lib/libz.a /usr/local/lib/libharfbuzz.a /lib/libbz2.a /lib/libpthread.a Thanks. A fix was provided by FLTK developer Albrecht Schlosser: https://github.com/fltk/fltk/issues/1004#issuecomment-2209144366 You can take the "branch-1.3" branch which also contains the fix (f34719). $ git clone https://github.com/fltk/fltk $ cd fltk $ git checkout branch-1.3 ... Can you check it solves your issue? They are waiting for confirmation to close the issue on their side. Best, Rodrigo.

July 4, 2024

use remote css unchecked

by pastebin＠gmx.com

Hi, shouldn't the lines wrap with https://packetstormsecurity.com/files/179337/Red-Hat-Security-Advisory-2024… with 'tools/use remote css' unchecked? with 'tools/use remote css' checked the lines wrap but their css looks horrible (to me)

July 4, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi a little contribution to your code in case someone wants to make a huge statically compiled version of the program :) g++ -O2 test.cpp-static -o test /usr/local/lib/libfltk.a /usr/local/lib/libX11.a /usr/local/lib/libxcb.a /usr/local/lib/libXft.a /usr/local/lib/libfontconfig.a /lib/libdl.a /usr/local/lib/libXfixes.a /usr/local/lib/libXrender.a /usr/local/lib/libXcursor.a /usr/local/lib/libXinerama.a /usr/local/lib/libXext.a /usr/local/lib/libXau.a /usr/local/lib/libXdmcp.a /usr/local/lib/libfreetype.a /usr/local/lib/libexpat.a /usr/local/lib/libXrender.a /usr/local/lib/libX11.a /usr/local/lib/libXfixes.a /usr/local/lib/libpng.a /lib/libz.a /usr/local/lib/libharfbuzz.a /lib/libbz2.a /lib/libpthread.a On Tue, 2 Jul 2024 20:55:10 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Mon, Jul 01, 2024 at 03:31:40PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >i got it to reproduce > > > >dillo any url > > > >right click mouse -> 'save page as' in the Filename: text box it shows /html/ highlighted in blue > > > >/html is my default save dir from dillorc save_dir=/html > > > >the i just type r (or any key) and it now shows /tmp/r hitting any key now just dups the /tmp/r on an on > > > >if the blue highlight is erased by clicking mouse in text box then it is normal > > > >it is the highlighting that is the problem > > Thanks!, I can reproduce it now. > > This is a FLTK bug, here is a small program that reproduces. I will > report it to the FLTK project. > > /* Build with: g++ test.cpp -o test -lfltk */ > #include <cstdlib> > #include <unistd.h> > > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/Fl_Button.H> > #include <FL/Fl_File_Chooser.H> > > void cb_file_select(Fl_Widget *o, void *v) > { > char msg[256]; > char *newfile = fl_file_chooser("Choose a file", NULL, NULL); > > if (newfile != NULL) { > sprintf(msg, "You choose %s", newfile); > fl_message(msg); > } > } > > int main (int argc, char ** argv) > { > chdir("/tmp"); > Fl_Window *window = new Fl_Window(300, 300, 200, 200, "Foo"); > > Fl_Button *button = new Fl_Button(60, 40, 80, 40, "Select file"); > button->callback(cb_file_select); > window->end(); > > window->show(argc, argv); > > return(Fl::run()); > } > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 3, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi i'm actually glad you were able to reproduce it - i've got so much custom source on this machine i was afraid it was me :) thanks for your work on this - and thanks for this fltk program On Tue, 2 Jul 2024 20:55:10 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Mon, Jul 01, 2024 at 03:31:40PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >i got it to reproduce > > > >dillo any url > > > >right click mouse -> 'save page as' in the Filename: text box it shows /html/ highlighted in blue > > > >/html is my default save dir from dillorc save_dir=/html > > > >the i just type r (or any key) and it now shows /tmp/r hitting any key now just dups the /tmp/r on an on > > > >if the blue highlight is erased by clicking mouse in text box then it is normal > > > >it is the highlighting that is the problem > > Thanks!, I can reproduce it now. > > This is a FLTK bug, here is a small program that reproduces. I will > report it to the FLTK project. > > /* Build with: g++ test.cpp -o test -lfltk */ > #include <cstdlib> > #include <unistd.h> > > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/Fl_Button.H> > #include <FL/Fl_File_Chooser.H> > > void cb_file_select(Fl_Widget *o, void *v) > { > char msg[256]; > char *newfile = fl_file_chooser("Choose a file", NULL, NULL); > > if (newfile != NULL) { > sprintf(msg, "You choose %s", newfile); > fl_message(msg); > } > } > > int main (int argc, char ** argv) > { > chdir("/tmp"); > Fl_Window *window = new Fl_Window(300, 300, 200, 200, "Foo"); > > Fl_Button *button = new Fl_Button(60, 40, 80, 40, "Select file"); > button->callback(cb_file_select); > window->end(); > > window->show(argc, argv); > > return(Fl::run()); > } > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 2, 2024

Re: Dark mode screenshot and tutorial

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Tue, Jul 02, 2024 at 08:24:59PM +0200, Rodrigo Arias wrote: >>The background color of the image is being assigned from the color of >>the <html> background. Try this patch to override it from the current >>element: >> >>diff --git a/src/html.cc b/src/html.cc >>index a55fd2a8..649e7556 100644 >>--- a/src/html.cc >>+++ b/src/html.cc >>@@ -2156,6 +2156,9 @@ DilloImage *a_Html_image_new(DilloHtml *html, const char *tag, int tagsize) >> if (HT2TB(html)->getBgColor()) >> image->bg_color = HT2TB(html)->getBgColor()->getColor(); >> >>+ if (html->styleEngine->backgroundColor()) >>+ image->bg_color = html->styleEngine->backgroundColor()->getColor(); >>+ >> DilloHtmlImage *hi = dNew(DilloHtmlImage, 1); >> hi->url = url; >> html->images->increase(); > > And this extra rule in style.css: > > html {background-color: gray !important} Thanks, yes together those changes work to set the PNG background colour.

July 2, 2024

Re: extra /tmp on file name line when save html

by Rodrigo Arias

>This is a FLTK bug, here is a small program that reproduces. I will >report it to the FLTK project. Reported here: https://github.com/fltk/fltk/issues/1004

July 2, 2024

Re: extra /tmp on file name line when save html

by Rodrigo Arias

Hi, On Mon, Jul 01, 2024 at 03:31:40PM -0600, pastebin(a)gmx.com wrote: >Hi > >i got it to reproduce > >dillo any url > >right click mouse -> 'save page as' in the Filename: text box it shows /html/ highlighted in blue > >/html is my default save dir from dillorc save_dir=/html > >the i just type r (or any key) and it now shows /tmp/r hitting any key now just dups the /tmp/r on an on > >if the blue highlight is erased by clicking mouse in text box then it is normal > >it is the highlighting that is the problem Thanks!, I can reproduce it now. This is a FLTK bug, here is a small program that reproduces. I will report it to the FLTK project. /* Build with: g++ test.cpp -o test -lfltk */ #include <cstdlib> #include <unistd.h> #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Button.H> #include <FL/Fl_File_Chooser.H> void cb_file_select(Fl_Widget *o, void *v) { char msg[256]; char *newfile = fl_file_chooser("Choose a file", NULL, NULL); if (newfile != NULL) { sprintf(msg, "You choose %s", newfile); fl_message(msg); } } int main (int argc, char ** argv) { chdir("/tmp"); Fl_Window *window = new Fl_Window(300, 300, 200, 200, "Foo"); Fl_Button *button = new Fl_Button(60, 40, 80, 40, "Select file"); button->callback(cb_file_select); window->end(); window->show(argc, argv); return(Fl::run()); }

July 2, 2024

Re: Dark mode screenshot and tutorial

by Rodrigo Arias

On Tue, Jul 02, 2024 at 08:24:59PM +0200, Rodrigo Arias wrote: >The implementation seems to be incomplete: > >https://github.com/dillo-browser/dillo/blob/8c97be233a600f414952e458f59768e… > >The background color of the image is being assigned from the color of >the <html> background. Try this patch to override it from the current >element: > >diff --git a/src/html.cc b/src/html.cc >index a55fd2a8..649e7556 100644 >--- a/src/html.cc >+++ b/src/html.cc >@@ -2156,6 +2156,9 @@ DilloImage *a_Html_image_new(DilloHtml *html, const char *tag, int tagsize) > if (HT2TB(html)->getBgColor()) > image->bg_color = HT2TB(html)->getBgColor()->getColor(); > >+ if (html->styleEngine->backgroundColor()) >+ image->bg_color = html->styleEngine->backgroundColor()->getColor(); >+ > DilloHtmlImage *hi = dNew(DilloHtmlImage, 1); > hi->url = url; > html->images->increase(); And this extra rule in style.css: html {background-color: gray !important} (I need to check it in more detail)

July 2, 2024

Re: Dark mode screenshot and tutorial

by Rodrigo Arias

Hi, On Tue, Jul 02, 2024 at 11:28:01AM +1000, Kevin Koster wrote: >One issue with dark background colours is that PNG/GIF images with >transparent backgrounds often have text in black and therefore become >unreadable, such as this image on Wikipedia: >https://en.wikipedia.org/wiki/File:Unix_timeline.en.svg > >I'm not good at CSS, but I just made an attempt to work around this by >not setting img elements to black in my version of a dark-theme >style.css, but it doesn't work, images backgrounds are still black: > >* {color: #00f400} > body, div, span, nav, p, a, form, h1, h2, h3, h4, h5, h6, ul, ol, li, table, tr, td {background-color: black} > img, map {background-color: gray !important} > :link {text-decoration: none !important; color: #00f5e8 !important} > :visited {text-decoration: none !important; color: #a020f0 !important} > >I don't know whether my CSS is invalid or if it's a bug in Dillo, but >hints for applying black background-color to everything except images >would be welcome. The image background is also black when I open it on >its own with "isolate image" from the right-click menu, even though >there it's on a light-colour background due to the 'bg_color' setting >in dillorc being set to default. Presumably that's because the image >in the cache already, loading a new PNG image URL the background is >bg_color: >https://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Unix_timeline.en.… The implementation seems to be incomplete: https://github.com/dillo-browser/dillo/blob/8c97be233a600f414952e458f59768e… The background color of the image is being assigned from the color of the <html> background. Try this patch to override it from the current element: diff --git a/src/html.cc b/src/html.cc index a55fd2a8..649e7556 100644 --- a/src/html.cc +++ b/src/html.cc @@ -2156,6 +2156,9 @@ DilloImage *a_Html_image_new(DilloHtml *html, const char *tag, int tagsize) if (HT2TB(html)->getBgColor()) image->bg_color = HT2TB(html)->getBgColor()->getColor(); + if (html->styleEngine->backgroundColor()) + image->bg_color = html->styleEngine->backgroundColor()->getColor(); + DilloHtmlImage *hi = dNew(DilloHtmlImage, 1); hi->url = url; html->images->increase();

July 2, 2024

Re: Dark mode screenshot and tutorial

by Kevin Koster

On Sun, 5 May 2024 18:00:26 +0200 <a1ex(a)dismail.de> wrote: > Attached is a screenshot of Dillo with a simple "Dark Mode" theme. > > For those interested in how to do this, here is a small tutorial: > > > Put this in ~/.dillo/style.css: > > * { background-color: #000000 !important; color: #999999 ! important; } > :link { color: #ffffff !important; text-decoration: none !important; } > :visited { color: #ffffff !important; text-decoration: underline !important; } One issue with dark background colours is that PNG/GIF images with transparent backgrounds often have text in black and therefore become unreadable, such as this image on Wikipedia: https://en.wikipedia.org/wiki/File:Unix_timeline.en.svg I'm not good at CSS, but I just made an attempt to work around this by not setting img elements to black in my version of a dark-theme style.css, but it doesn't work, images backgrounds are still black: * {color: #00f400} body, div, span, nav, p, a, form, h1, h2, h3, h4, h5, h6, ul, ol, li, table, tr, td {background-color: black} img, map {background-color: gray !important} :link {text-decoration: none !important; color: #00f5e8 !important} :visited {text-decoration: none !important; color: #a020f0 !important} I don't know whether my CSS is invalid or if it's a bug in Dillo, but hints for applying black background-color to everything except images would be welcome. The image background is also black when I open it on its own with "isolate image" from the right-click menu, even though there it's on a light-colour background due to the 'bg_color' setting in dillorc being set to default. Presumably that's because the image in the cache already, loading a new PNG image URL the background is bg_color: https://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Unix_timeline.en.…

July 2, 2024

Re: extra /tmp on file name line when save html

by pastebin＠gmx.com

Hi i got it to reproduce dillo any url right click mouse -> 'save page as' in the Filename: text box it shows /html/ highlighted in blue /html is my default save dir from dillorc save_dir=/html the i just type r (or any key) and it now shows /tmp/r hitting any key now just dups the /tmp/r on an on if the blue highlight is erased by clicking mouse in text box then it is normal it is the highlighting that is the problem Mon, 3 Jun 2024 16:35:03 -0600 pastebin(a)gmx.com wrote: > Hi > > i save html files in a dir called /html (dillo saves them correctly there 99.99% of the time) > > i have a dir /html/tmp (dir named tmp in /html) > > but sometimes and i can't pin down what causes it the file line becomes /tmp and if i try to backspace it just adds more /tmp/tmp/tmp etc so i have to cancel the file save and redo the dialog > i can click on tmp and the dir changes to /html/tmp and saving file there is no problem > > any one experiencing something similar or any ideas? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 1, 2024

Re: Unexpected behaviour.

by D

2024-06-26 22:26:13 (+0200), Rodrigo Arias wrote: > On Wed, Jun 26, 2024 at 12:47:08AM +0300, D wrote: > > html tag <caption> makes the table wider. > > The caption tag is not supported yet. Do you have a test case? Any <table> with <caption> may serve as test case. --

June 27, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias wrote: > On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote: >>Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg(a)public.gmane.org> wrote: >>This is why I now think it best to avoid the 'https_proxy' name, >>because the behaviour with it will never be consistent with other >>software without changing how Dillo already handles the >>'http_proxy' variable/setting. > > I undertand, but I think this is a good moment to plan how to change how > Dillo handles the http_proxy variable, so it only affects HTTP traffic > and not HTTPS too. > > What about this: > > Setting the env vars as: > http_proxy=http://localhost:1234 > https_proxy= > > Now causes a warning (maybe also in the UI): > > $ dillo https://www.google.com > WARNING: Setting http_proxy to specify the HTTPS proxy is deprecated, > use https_proxy to define it instead. > > But still makes Dillo use the http_proxy both for HTTP and HTTPS for > now. > > Also: > > http_proxy=http://localhost:1234 > https_proxy=http://localhost:1235 > > No warning: > > $ dillo https://www.google.com > > But Dillo uses both proxies independently (like curl or wget), instead > of the current implementation that would use http_proxy for HTTP and > HTTPS. > > Same with the dillorc options http_proxy and https_proxy (new), keeping > the preference for the env vars if defined. Yes that sounds like a good way to bring Dillo into line with other software, and also means that the environment variables apply consistently to downloads since they use Wget. > The only unexpected change may be for a user that had previously set > https_proxy that was not being used by Dillo, and now it would be. But I > think that 1) is unlikely they use a different value for HTTP and HTTPS > and 2) it is probably intended to use the https_proxy for HTTPS anyway. > We could emit a warning about this too, but maybe not needed if we > explain that Dillo will handle now the https_proxy variable. Affected users would have already been seeing inconsistent behaviour with file downloads since Wget is already using https_proxy. > In any case, this should be properly explained in the release notes, > leaving one release with the deprecation warning for users to take time > to change the behavior, before we stop using http_proxy as the HTTPS > proxy. Yep, and obviously in the changelog too, to be better than Wget and its undocumented past switch to tunneling HTTPS connections through https_proxy. > I think this has the benefit of being the implementation most users > would expect, as it is consisten with other tools, while having the > least amount of pain for current users of proxies as they would have > time to realize the deprecation notice. Yes I agree. > That would allow you to specify *only* the https_proxy like this: > > http_proxy= > https_proxy=http://localhost:1235 > > $ dillo https://www.google.com > > No warning and Dillo uses https_proxy for HTTPS and HTTP doesn't use a > proxy. > > And over this change, you can add your specific option in dillorc only > to change the way Dillo communicates with the HTTPS proxy to avoid the > CONNECT, with the "https_proxy_use_http=TRUE" or similar option. That would be fine. > Lastly, a similar option was mentioned by Daniel (curl lead developer) > some time ago: https://stackoverflow.com/a/34268925 It doesn't appear that anyone implemented it in Curl though.

June 26, 2024

Re: dillorc long line word wrap

by pastebin＠gmx.com

Hi, yes i see : the text in the alt is treated differently from the text in the html - i can't cut n paste the alt text but can the html text --- Just for completeness i have the images from this site blocked in /etc/hosts but have the tools/load images checked the result is the same appearance wise On Wed, 26 Jun 2024 23:57:05 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Wed, Jun 26, 2024 at 03:22:57PM -0600, pastebin(a)gmx.com wrote: > >2 attached pngs > >first with no cursor movement to right > >second with cursor movement to right > > Thanks, it seems to be caused by the long alt text when images are > disabled. I have opened an issue here: > > https://github.com/dillo-browser/dillo/issues/207 > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 26, 2024

Re: dillorc long line word wrap

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 03:22:57PM -0600, pastebin(a)gmx.com wrote: >2 attached pngs >first with no cursor movement to right >second with cursor movement to right Thanks, it seems to be caused by the long alt text when images are disabled. I have opened an issue here: https://github.com/dillo-browser/dillo/issues/207 Best, Rodrigo.

June 26, 2024

Re: dillorc long line word wrap

by pastebin＠gmx.com

2 attached pngs first with no cursor movement to right second with cursor movement to right On Wed, 26 Jun 2024 22:23:20 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Tue, Jun 25, 2024 at 02:05:33PM -0600, pastebin(a)gmx.com wrote: > >Hi, > > > >doesn't this dillorc option make 'long text lines' wrap properly in the dillo display area? > > > ># Set this to YES to limit the word wrap width to the viewport width > >#limit_text_width=NO > >limit_text_width=YES > > > >https://hosted.ap.org/article/e5ac7de893189c11c88137fe9b81829e/shot-16-seco… > > Seems to be rendering fine for me, can you send a screenshot? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 26, 2024

Re: Unexpected behaviour.

by Rodrigo Arias

On Wed, Jun 26, 2024 at 12:47:08AM +0300, D wrote: >html tag <caption> makes the table wider. The caption tag is not supported yet. Do you have a test case?

June 26, 2024

Re: dillorc long line word wrap

by Rodrigo Arias

On Tue, Jun 25, 2024 at 02:05:33PM -0600, pastebin(a)gmx.com wrote: >Hi, > >doesn't this dillorc option make 'long text lines' wrap properly in the dillo display area? > ># Set this to YES to limit the word wrap width to the viewport width >#limit_text_width=NO >limit_text_width=YES > >https://hosted.ap.org/article/e5ac7de893189c11c88137fe9b81829e/shot-16-seco… Seems to be rendering fine for me, can you send a screenshot?

June 26, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote: >Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >>>Also I don't think that 'https_endpoint' actually needs to be set >>>from an environment variable, just a dillorc setting would do. >> >> I also think is good if it is only a dillorc option. I'm not sure if I >> like more something like: >> >> https_proxy=http://localhost:1234 > >Ahh, that's what I was doing wrong with Lynx! I didn't include the >"http://" part (which Wget doesn't require, though I see now that >the Wget manual does say it should be set to a URL, not a >hostname). I really do make a meal of this proxy stuff. Yeah, it is a bit confusing :-) >> # Setting this to TRUE sends HTTPS traffic unencrypted to the proxy. >> # Don't change unless you know what you are doing. >> #https_proxy_use_http=FALSE (default) >> https_proxy_use_http=TRUE >> >> For normal uses, setting the https proxy with https_proxy would make >> more sense than using http_proxy for HTTPS traffic anyway. > >If the 'http_proxy' behaviour changes to only apply to HTTP like >in other software, everyone using the 'http_proxy' setting will >have to change their configuration to set 'https_proxy' as well. >That'd be an annoying behaviour change. > >But otherwise using the setting name 'https_proxy' makes it unclear >how that relates to the 'http_proxy' setting that applies to both >HTTP and HTTPS. Sadly, there is no standard (AFAIK) that specifies how to use those variables, but most software tools seem to use them in a more or less coherent way. And I think new users would expect it to follow the same usage than curl, wget or other browsers. It doesn't have to be annoying, we can slowly deprecate the current mechanism by displaying a warning when only http_proxy is set that https_proxy should be set too, and change the behavior in a new release that is clearly documented in the release notes. >If I set: > >http_proxy=http://localhost:1234 >https_proxy=http://localhost:5678 > >It at least needs a comment explaining the difference between the >settings, if indeed you intend there to be one and the second >setting doesn't override the first entirely. > >Since the 'http_proxy' environment variable overrides the dillorc >'http_proxy' setting, 'https_proxy' implies that the same will >apply to that, and it's anyone's guess which will apply if both >are set since other software (Wget, Lynx) doesn't apply the >'http_proxy' environment variable to https. Exactly, I think the logical behavior makes sense. Having both http_proxy and https_proxy as environment variables *and* dillorc options. Each controlling the HTTP and HTTPS proxy independently. The same in the future for ftp_proxy to route FTP traffic. >This is why I now think it best to avoid the 'https_proxy' name, >because the behaviour with it will never be consistent with other >software without changing how Dillo already handles the >'http_proxy' variable/setting. I undertand, but I think this is a good moment to plan how to change how Dillo handles the http_proxy variable, so it only affects HTTP traffic and not HTTPS too. What about this: Setting the env vars as: http_proxy=http://localhost:1234 https_proxy= Now causes a warning (maybe also in the UI): $ dillo https://www.google.com WARNING: Setting http_proxy to specify the HTTPS proxy is deprecated, use https_proxy to define it instead. But still makes Dillo use the http_proxy both for HTTP and HTTPS for now. Also: http_proxy=http://localhost:1234 https_proxy=http://localhost:1235 No warning: $ dillo https://www.google.com But Dillo uses both proxies independently (like curl or wget), instead of the current implementation that would use http_proxy for HTTP and HTTPS. Same with the dillorc options http_proxy and https_proxy (new), keeping the preference for the env vars if defined. The only unexpected change may be for a user that had previously set https_proxy that was not being used by Dillo, and now it would be. But I think that 1) is unlikely they use a different value for HTTP and HTTPS and 2) it is probably intended to use the https_proxy for HTTPS anyway. We could emit a warning about this too, but maybe not needed if we explain that Dillo will handle now the https_proxy variable. In any case, this should be properly explained in the release notes, leaving one release with the deprecation warning for users to take time to change the behavior, before we stop using http_proxy as the HTTPS proxy. I think this has the benefit of being the implementation most users would expect, as it is consisten with other tools, while having the least amount of pain for current users of proxies as they would have time to realize the deprecation notice. That would allow you to specify *only* the https_proxy like this: http_proxy= https_proxy=http://localhost:1235 $ dillo https://www.google.com No warning and Dillo uses https_proxy for HTTPS and HTTP doesn't use a proxy. And over this change, you can add your specific option in dillorc only to change the way Dillo communicates with the HTTPS proxy to avoid the CONNECT, with the "https_proxy_use_http=TRUE" or similar option. Lastly, a similar option was mentioned by Daniel (curl lead developer) some time ago: https://stackoverflow.com/a/34268925 Best, Rodrigo

June 26, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, On Wed, Jun 26, 2024 at 03:26:59PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Tue, 25 Jun 2024 21:33:54 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> I just merged support for zoom control: >> >> https://github.com/dillo-browser/dillo/pull/156 > >Thanks very much for making this feature happen! > >One thing which I would suggest is also having optional toolbar buttons >to control this. Yeah, I thought about adding three new menu items in the main menu or under a sub-menu, but I like the idea of Firefox and Chromium where they placed both the [-] [+] buttons inside a main menu item. Not sure how hard it would be to do with FLTK. >I would like to think that the Dillo project strives for maximum >accessibility whenever possible, since pretty much all of the other >features are available with mouse controls. There are a variety of >scenerios where this can be desirable. I would like to make Dillo more accessible, but we would need more developers to help. I checked a bit how to integrate it with orca or other text readers but I don't have much experience on that area. >Maybe I could attempt to kludge together a patch at some point, if >there are no other more qualified takers, of course. Thanks, that would be nice. Best, Rodrigo.

June 26, 2024

Re: Feature idea: zoom buttons

by a1ex＠dismail.de

Hi Rodrigo, On Tue, 25 Jun 2024 21:33:54 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I just merged support for zoom control: > > https://github.com/dillo-browser/dillo/pull/156 Thanks very much for making this feature happen! One thing which I would suggest is also having optional toolbar buttons to control this. I would like to think that the Dillo project strives for maximum accessibility whenever possible, since pretty much all of the other features are available with mouse controls. There are a variety of scenerios where this can be desirable. Maybe I could attempt to kludge together a patch at some point, if there are no other more qualified takers, of course. Regards, Alex

June 26, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >>Also I don't think that 'https_endpoint' actually needs to be set >>from an environment variable, just a dillorc setting would do. > > I also think is good if it is only a dillorc option. I'm not sure if I > like more something like: > > https_proxy=http://localhost:1234 Ahh, that's what I was doing wrong with Lynx! I didn't include the "http://" part (which Wget doesn't require, though I see now that the Wget manual does say it should be set to a URL, not a hostname). I really do make a meal of this proxy stuff. > # Setting this to TRUE sends HTTPS traffic unencrypted to the proxy. > # Don't change unless you know what you are doing. > #https_proxy_use_http=FALSE (default) > https_proxy_use_http=TRUE > > For normal uses, setting the https proxy with https_proxy would make > more sense than using http_proxy for HTTPS traffic anyway. If the 'http_proxy' behaviour changes to only apply to HTTP like in other software, everyone using the 'http_proxy' setting will have to change their configuration to set 'https_proxy' as well. That'd be an annoying behaviour change. But otherwise using the setting name 'https_proxy' makes it unclear how that relates to the 'http_proxy' setting that applies to both HTTP and HTTPS. If I set: http_proxy=http://localhost:1234 https_proxy=http://localhost:5678 It at least needs a comment explaining the difference between the settings, if indeed you intend there to be one and the second setting doesn't override the first entirely. Since the 'http_proxy' environment variable overrides the dillorc 'http_proxy' setting, 'https_proxy' implies that the same will apply to that, and it's anyone's guess which will apply if both are set since other software (Wget, Lynx) doesn't apply the 'http_proxy' environment variable to https. This is why I now think it best to avoid the 'https_proxy' name, because the behaviour with it will never be consistent with other software without changing how Dillo already handles the 'http_proxy' variable/setting.

June 25, 2024

Unexpected behaviour.

by D

html tag <caption> makes the table wider. --

June 25, 2024

dillorc long line word wrap

by pastebin＠gmx.com

Hi, doesn't this dillorc option make 'long text lines' wrap properly in the dillo display area? # Set this to YES to limit the word wrap width to the viewport width #limit_text_width=NO limit_text_width=YES https://hosted.ap.org/article/e5ac7de893189c11c88137fe9b81829e/shot-16-seco…

June 25, 2024

Re: 'Dillo Downloads' box cutnpaste

by Rodrigo Arias

On Sat, Jun 22, 2024 at 01:05:53PM -0600, pastebin(a)gmx.com wrote: >Hi > >any chance that the 'mouse exit from file name location' in the >'Dillo Downloads' dialog box (where 'target file tooltip' disappears) >to 'mouse exist from 'Dillo Downloads' dialog box itself? i think >this would allow cutnpaste of the information in the tooltip > >or could you tell me where the code might be for 'mouse exit from file >name location' action? The code that handles the downloads dialog is at dpi/downloads.cc but not sure how to do that. Rodrigo.

June 25, 2024

Re: HTTPS Proxy Support

by Rodrigo Arias

Hi, On Sun, Jun 23, 2024 at 11:02:54AM +1000, Kevin Koster wrote: >Or at least based on looking at Squid and Nginx, internet-wide >"reverse" proxy isage isn't documented clearly enough for me to >spot the easy way of doing it (while also manipulating the >content being retrieved). I did see a very hard way to do it with >Squid and an abandoned 3rd-party library that wouldn't even compile >for me. Yeah, probably using carl is much easier to setup. >Also I don't think that 'https_endpoint' actually needs to be set >from an environment variable, just a dillorc setting would do. I also think is good if it is only a dillorc option. I'm not sure if I like more something like: https_proxy=http://localhost:1234 # Setting this to TRUE sends HTTPS traffic unencrypted to the proxy. # Don't change unless you know what you are doing. #https_proxy_use_http=FALSE (default) https_proxy_use_http=TRUE For normal uses, setting the https proxy with https_proxy would make more sense than using http_proxy for HTTPS traffic anyway. Best, Rodrigo.

June 25, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, On Sat, May 04, 2024 at 01:44:11PM +0200, Rodrigo Arias wrote: >>One thing I will note however, on a TKL (ten key less) keyboard, there >>is no dedicated '+' key, so zooming in doesn't work. On a US layout >>for example, the key is =/+, but pressing Ctrl-Shift-= doesn't have >>the expected result. I changed the mapping in keys.cc to Ctrl-= and it >>works for me, but would vary for other localizations. > >I choose the Ctrl + / Ctrl - as it is the default in other browsers, >but I mostly use Ctrl and the mouse wheel. I haven't been able to >figure it out how to make it work yet on Dillo, but maybe that would >help you too. I just merged support for zoom control: https://github.com/dillo-browser/dillo/pull/156 You can use both Ctrl-+ (non-US) or Ctrl-= (US) by default to zoom in. Best, Rodrigo.

June 25, 2024

Re: HTTPS Proxy Support

by Kevin Koster

Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > On Sat, Jun 22, 2024 at 09:43:00AM +1000, Kevin Koster wrote: >>But the proxy approach allows old versions/binaries to keep working >>too. If Dillo 3.0.5 had supported it, then the HTTPS issues from >>lacking SNI support could have been worked around by running an >>'old-style' HTTPS proxy with SNI support on localhost. > > A related term seems to be "reverse proxy": > > https://en.wikipedia.org/wiki/Reverse_proxy Yes, though in practice that tends to imply a caching proxy run by website operators, hence "reverse" because a normal proxy is run by the person accessing the content on other people's servers, but these are run by the server operators. But the mechanism is the same as my usage. Real-world "reverse proxies" just tend to be geared away from internet-wide usage to serve requests to any server, not least because HTTPS requires the proxy to have the target website's certificate. Or at least based on looking at Squid and Nginx, internet-wide "reverse" proxy isage isn't documented clearly enough for me to spot the easy way of doing it (while also manipulating the content being retrieved). I did see a very hard way to do it with Squid and an abandoned 3rd-party library that wouldn't even compile for me. > From the "Fun with Crypto Ancienne" post I understand that you want > Dillo to get a HTTP or HTTPS URL and always perform a HTTP GET towards > your proxy, as the Mosaic configuration suggests: > >> https 127.0.0.1 8765 http >> http 127.0.0.1 8765 http Yes. Which, if it helps to decode my earlier posts, is equivalent to this Wget command before they secretly changed its https_proxy behaviour: http_proxy=127.0.0.1:8765 https_proxy=127.0.0.1:8765 wget https://example.com > Other that those old browsers, I don't think you can do this with any > (relatively) modern tool. Which is annoying because I didn't need it until (relatively) recently. It looks like current Lynx is designed to use HTTPS tunneling through proxies now, based on use of the do_connect variable in WWW/Library/Implementation/HTTP.c of its source code. Though with Lynx 2.8.9rel.1 and 2.9.0dev.6 I can't actually get it to talk to anything (inc. Netcat on localhost) with http_proxy or https_proxy, even though setting each variable causes page loads to fail over the respective protocol. Not a firewall issue. > This is what Dillo is currently doing for https and http URLs: > > hop% http_proxy=http://localhost:1234 dillo http://www.google.com > hop% nc -l 1234 > GET http://www.google.com/ HTTP/1.1 > Host: www.google.com > User-Agent: Dillo/3.1.1 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Encoding: gzip, deflate > DNT: 1 > Referer: http://www.google.com/ > Connection: keep-alive > > hop% http_proxy=http://localhost:1234 dillo https://www.google.com > hop% nc -l 1234 > CONNECT www.google.com:443 HTTP/1.1 > Host: www.google.com:443 > > While for the latter you'll want: > > GET https://www.google.com/ HTTP/1.1 > Host: www.google.com > User-Agent: Dillo/3.1.1 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Encoding: gzip, deflate > DNT: 1 > Referer: https://www.google.com/ > Connection: keep-alive > > You'll need to instruct Dillo to ignore the HTTPS handling and just > treat it as an HTTP GET request to the proxy (using the HTTPS url), so > no CONNECT is used. Yes, though ideally like in Wget this behaviour wouldn't be caused by setting 'http_proxy'. You'd have a variable/setting like Wget's 'https_proxy' which only causes HTTPS connections to try and use the proxy, while HTTP connections go through directly. Then you could set 'http_proxy' as well if you wanted to use a proxy for HTTP connections too. For example (with 'https_endpoint' instead of the confusing 'https_proxy' variable/setting name I proposed earlier): http_proxy=127.0.0.1:1234 dillo http://www.google.com [ 127.0.0.1:1234 ] GET http://www.google.com/ HTTP/1.1 http_proxy=127.0.0.1:1234 dillo https://www.google.com [ 127.0.0.1:1234 ] CONNECT www.google.com:443 HTTP/1.1 https_endpoint=127.0.0.1:5678 dillo http://www.google.com [ www.google.com:80 ] GET http://www.google.com/ HTTP/1.1 https_endpoint=127.0.0.1:5678 dillo https://www.google.com [ 127.0.0.1:5678 ] GET https://www.google.com/ HTTP/1.1 http_proxy=127.0.0.1:1234 https_endpoint=127.0.0.1:5678 dillo http://www.google.com [ 127.0.0.1:1234 ] GET http://www.google.com/ HTTP/1.1 http_proxy=127.0.0.1:1234 https_endpoint=127.0.0.1:5678 dillo https://www.google.com [ 127.0.0.1:5678 ] GET https://www.google.com/ HTTP/1.1 So the behaviour of 'http_proxy' alone isn't changed. Also I don't think that 'https_endpoint' actually needs to be set from an environment variable, just a dillorc setting would do.

June 23, 2024

Re: 'Dillo Downloads' box cutnpaste

by pastebin＠gmx.com

Hi any chance that the 'mouse exit from file name location' in the 'Dillo Downloads' dialog box (where 'target file tooltip' disappears) to 'mouse exist from 'Dillo Downloads' dialog box itself? i think this would allow cutnpaste of the information in the tooltip or could you tell me where the code might be for 'mouse exit from file name location' action? On Sat, 8 Jun 2024 09:47:59 -0600 pastebin(a)gmx.com wrote: > Hi > > if i have a page of links > > i cab do a mouse-right-click on one of the url links and i get the 'link menu' and then i can click on 'save link as..' and it saves the html fine in the current directory in most cases and then there is now a 'Dillo Download' box with 'Done' on it on the screen and running the mouse over the filename causes a 'Target File: xxx' box to be displayed with all the files information displayed > > The problem is when after i run mouse over the saved file name on the 'Dillo Download' box the 'Target File: xxxx) information disappears from the screen when i attempt to cutnpaste the information there > > can this behavior be changed so that moving the mouse completely from the 'Dillo Download' box and not just the file name location removes the 'Target File: xxx' information from the screen so a cutnpaste can be performed on the information in the 'Target File: xxx' box? > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 22, 2024