- Dillo-dev - lists.mailman3.com

dpid

by Jorge Arellano Cid

Hi there! Just made a big commit on dpid (a work we're advancing with Ferdi). It includes the first version of automatical launch; pretty alpha but it should work while we polish. Just be sure to drop the dpid binary in ~/.dillo/ (or whithin PATH), and not to linger with an older version (same applies for the dpis). Cheers Jorge.-

Oct. 9, 2003

Re: OpenSSH authentication password problem with dillo

by Jorge Arellano Cid

Hi Mark, > Dear Jorge, > > thank you for dillo, I use it mostly on OpenBSD for fast > browsing from my 266 Mhz computer. However I have an udentified > problem, for which I am not 100% sure that it comes from dillo. > > I have typed in the location bar: http://www. and then I by > mistake pressed ENTER or maybe some other key as well. A > graphical window poped up: > > OpenSSH authentication password for butterfly(a)mock-up.kosmos: > > [X] [X] [X] [ ] [ ] [ ] [ ] [ ] > > > and I was watching this window what it is and where did it come > from because I know dillo does not have any authentication so > far. When I pressed some keys, they were shown like FULL BOX and > in the above example as "X". They were small boxes, filled with > the green color when I pressed keys and they were representing > the password without letting anyone else see it. > > Do you know what it is? > > grep OpenSSH /usr/local/bin/dillo > > did not give results. I did not yet take any source to > investigate and I am not sure if it comes from dillo. > > > Let me know if you know something. Well, if you're using dillo 0.7.3, you have a big problem: that version is SSL unaware. If you're using current CVS, https URLs may be started by dpid, but not with the procedure you describe. It may be that a delayed connection from a previous page could have made it happen. If you can reproduce the window-popup right after the splash, you're probably under attack or something akin. Cheers Jorge.-

Oct. 9, 2003

Keybindings

by Ian McDonald

Is there an easy way of breaking the ctrl-<whichever> and right mouse button bindings? I'd rather ask before scratching about in the code. -- ian (building a kiosk)

Oct. 8, 2003

Re: [Dillo-dev] [RFC] Keyboard navigation

by Patrick Shanahan

* Kelson Vibber <kelson(a)pobox.com> [10-07-03 15:30]: > At 09:09 AM 10/7/2003, Patrick Shanahan wrote: > >* Frank de Lange <frank(a)unternet.org> [10-07-03 08:45]: > > [snip ...] > >> Should this feature be optional? On devices without a keyboard (many > >> PDA's) keyboard navigation does not help much after all... On the > >> other hand, the generalised 'focus' mechanism I've added to the > >> viewport can be used for other purposes as well. > > > >Possibly selectable via .dillorc. [more snip ...] > Maybe the actual keybindings, or a choice of navigation styles > (cursor keys vs. vi-keys, for instance) should be configurable, but I > don't see a reason to make the feature itself optional unless it adds > a lot of unused code to space-starved PDAs. I agree with this. I will be very happy with the added functionality. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Oct. 7, 2003

Re: [Dillo-dev] [RFC] Keyboard navigation

by Kelson Vibber

At 09:09 AM 10/7/2003, Patrick Shanahan wrote: >* Frank de Lange <frank(a)unternet.org> [10-07-03 08:45]: > [snip ...] > > Should this feature be optional? On devices without a keyboard (many > > PDA's) keyboard navigation does not help much after all... On the > > other hand, the generalised 'focus' mechanism I've added to the > > viewport can be used for other purposes as well. > >Possibly selectable via .dillorc. Of course if there's no keyboard, the keyboard navigation shouldn't cause any problems even when enabled. Like being able to display GIF on a site that only uses PNG. I don't see a reason to make it optional. The only keyboard functionality that's caused me frequent headaches in any other browser is type-ahead find, and that only when focus isn't where I think it is. Maybe the actual keybindings, or a choice of navigation styles (cursor keys vs. vi-keys, for instance) should be configurable, but I don't see a reason to make the feature itself optional unless it adds a lot of unused code to space-starved PDAs. Kelson Vibber www.hyperborea.org

Oct. 7, 2003

Re: [Dillo-dev] [RFC] Keyboard navigation

by Frank de Lange

Patrick Shanahan wrote: >* Frank de Lange <frank(a)unternet.org> [10-07-03 08:45]: > [snip ...] > > >>Should this feature be optional? On devices without a keyboard (many >>PDA's) keyboard navigation does not help much after all... On the >>other hand, the generalised 'focus' mechanism I've added to the >>viewport can be used for other purposes as well. >> >> > >Possibly selectable via .dillorc. > > Possible... But that would not lead to any space savings, which are important for exactly those devices which do not benefit from keyboard navigation... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 7, 2003

Re: [Dillo-dev] [RFC] Keyboard navigation

by Glyn Kennington

Frank de Lange wrote: > I'm currently adding keyboard navigation to Dillo. Fantastic! Keyboard navigation is the main reason why I still do most of my browsing in lynx, so if it becomes available in dillo, I'd probably use it a lot more, and get involved in the development. I did have a look at how I might go about implementing it, about a week ago, but I got put off when I realised that it would require considerably more than a 10-line hack, just to indicate which link was currently `selected'. The more I have to change, the more I fear I can mess it up. > If you have any suggestions on this subject, send them to the list. Well, here's some rambling thoughts: I'm very fond of lynx's "vi-keys" setting, and find that hjkl (with b and space for pageup/down) make for much faster navigation than cursor keys and PgUp/PgDown keys, especially as those may be missing, or poorly placed, on anything other than a full-size keyboard. However, the precise choice of keys should be easily configurable, and setting the defaults to be like any one text editor would be asking for trouble... Comparison with lynx also brings up the issue of whether to navigate in one or two dimensions. That is, either to go through all links in order (which will take a lot more key presses, especially in tables), or to be able to move left and right as well as up and down - this is far more intuitive, but requires another two keys, which could easily have been used for "Follow Link" and "Back" under the first method. Glyn

Oct. 7, 2003

Re: [Dillo-dev] [RFC] Keyboard navigation

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [10-07-03 08:45]: [snip ...] > Should this feature be optional? On devices without a keyboard (many > PDA's) keyboard navigation does not help much after all... On the > other hand, the generalised 'focus' mechanism I've added to the > viewport can be used for other purposes as well. Possibly selectable via .dillorc. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Oct. 7, 2003

[RFC] Keyboard navigation

by Frank de Lange

Hi'all, I'm currently adding keyboard navigation to Dillo. A quick search on the web produces loads of opinions on which keys to use for what purpose, how to navigate using the keyboard, etc. The w3c has produced some guidelines for 'accessibility' (http://www.w3.org/WAI/UA/sect508-UAAG.html#keyboard) which I will take into account for this feature, and the Mozilla project has done quite a bit of brainstorming on the subject. This is a request for some comments from current Dillo users/developers on what you would like Dillo to be like in this respect. My plan is to implement basic keyboard navigation for links and other content which can be activated (input fields, checkboxes, buttons, etc). For this I already have a working implementation. I will probably add accesskey support as well. Currently I use the cursor keys plus a modifier (now CTRL, will probably switch to ALT/META) to navigate to the nearest link (up/down/left/right), while the TAB key navigates sequentially through all 'activatable' content. Shift-TAB should do the same in reverse, but this is currently not working as it should. Enter activates the current link (embedded GTK+ widgets have their own conventions for this, eg. radiobuttons can *also* be selected using the spacebar, etc...). The find feature will be able to set the current focused link (not implemented yet). If you have any suggestions on this subject, send them to the list. Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 7, 2003

Patch to allow pricewatch.com to work

by rcooley

This is a quick and simple patch to address Bug #463. All I did was to _remove_ the 'if' statement in html.c , which ignored the BASE HREF= tag if it was not within HEAD. Does removing that restriction really cause any problems? Just about every other browser handles a BASE tag in the body. Even the w3c.org HTML validator doesn't complain about BASE not being in HEAD. diff -ur /tmp/dillo-0.7.3/src/html.c dillo-0.7.3/src/html.c --- /tmp/dillo-0.7.3/src/html.c Sat Jul 19 16:05:28 2003 +++ dillo-0.7.3/src/html.c Mon Oct 6 20:02:31 2003 @@ -3651,7 +3651,6 @@ const char *attrbuf; DilloUrl *BaseUrl; - if (html->InFlags & IN_HEAD) { if ((attrbuf = Html_get_attr(html, tag, tagsize, "href"))) { BaseUrl = a_Url_new(attrbuf, "", 0, 0); if (URL_SCHEME_(BaseUrl)) { @@ -3665,9 +3664,6 @@ a_Url_free(BaseUrl); } } - } else { - DEBUG_HTML_MSG("the BASE element must appear in the HEAD section\n"); - } } /*

Oct. 7, 2003