October 2003 - Dillo-dev - lists.mailman3.com

table-layour revisited

by Ralph Slooten

Hi there all, I posted a while back a bug-report to which I got no reply. This may have been due to me not making myself clear. I'll try again When making a table with a specific width all GUI browsers render this the same, like: <table cellpadding="0" cellspacing="0" width="800"> This gives a table looking like this <--- 800px ---> ------------------------------------------ |table contents | ------------------------------------------ This is no problem with Dillo and other browsers, as they are exactly the same. However when cellpadding and cellspacing are used, like: <table cellpadding="10" cellspacing="10" width="800"> the table should look like this <--- 800px ---> ------------------------------------------ | | | table contents | | | ------------------------------------------ Dillo renders this still incorrectly, by _expending_ the table in width looking like this <--- 820px ---> ---------------------------------------------- | | | table contents | | | ---------------------------------------------- Why is this? Many sites use tables to gain a specific layout in all browsers which I credit them for, but this page layout is altered by this (what I believe to be a) bug. Or am I incorrect as to the specs of html and tables? Greetings Ralph -- http://axljab.homelinux.org/ "...the software said Win95 or better, so I installed Linux"

Oct. 10, 2003

[RFC] Configurable keybindings

by Frank de Lange

Hi'all, In my quest for keyboard navigation (which works quite well by now btw) I have come upon Dillo's current inability to define custom keyboard bindings (except for menu bindings). GTK+ offers a mechanism to implement user-configurable keyboard mappings (Bindings) which could be used to add this feature to Dillo. I have made a sample implementation using bindings for GtkDwScrolledFrame, which shows the mechanism to work as it should. The resulting object code is slightly smaller than in the current CVS version, but the source is larger (mainly because of the huge list of 'gtk_binding_entry_add_signal9...0 calls for every key combination). To use the mechanism, widgets need to have signals defined for all user actions. In GtkDwScrolledFrame's case this meant adding "viewport_move" (which replaces the unused user_hchanged and user_vchanged signals), "cursor_move", "cursor_hide" and "cursor_activate" (the latter three for keyboard navigation; it is debatable whether these signals belong in GtkDwScrolledFrame or should move to GtkDwViewport). Keybindings are assigned through GTK+ rc-files or through the dillorc. As an example, this configuration (in gtkrc) uses the numerical keypad for link navigation: binding "keypad-keys" { bind "KP_Add" { "cursor_move" (0) } bind "KP_Subtract" { "cursor_move" (1) } bind "KP_8" { "cursor_move" (2) } bind "KP_2" { "cursor_move" (3) } bind "KP_4" { "cursor_move" (4) } bind "KP_6" { "cursor_move" (5) } bind "KP_Enter" { "cursor_activate" () } } class "GtkDwScrolledFrame" binding "keypad-keys" This one (in dillorc, note the enclosing double quotes and the preference name key_bindings) makes Dillo behave like the vi editor when it comes to link navigation: key_bindings = "binding 'vi-keys' { bind 'k' { 'cursor_move' (2) } bind 'j' { 'cursor_move' (3) } bind 'h' { 'cursor_move' (4) } bind 'l' { 'cursor_move' (5) } } class 'GtkDwScrolledFrame' binding 'vi-keys'" (numerical values after "cursor_move" are actually GTK enumeration values, but the current implementation does not support this. It would of course look much better to be able to write "cursor_move" (GTK_DIR_DOWN) instead of "cursor_move" (3)...) Now I could just add this functionality to the keyboard_navigation patch, or put it in a separate patch. However, since there seems to be some animosity against adding yet even more configuration options, I'd like to know if there is any interest in this feature. If not, I'll just keep things as they are and hardcode some sane defaults (ie. something I like...). In that case, those who want to change keyboard bindings can do it the way they have always done by hacking the source. Any suggestions? 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. 10, 2003

Re: [Dillo-dev] dpid

by Jorge Arellano Cid

Hi Nicolas and David! On Fri, 10 Oct 2003, Nicolas Pouillon wrote: > Hi Jorge, > > Le Thu, 9 Oct 2003 13:57:48 -0400 (CLT) > Jorge Arellano Cid <jcid(a)dillo.org> eut le bonheur d'ecrire: > > > Hi there! > > > > Just made a big commit on dpid > > I just wanted to try it out but... > > dpid/Makefile.am references a bin_SCRIPT named dpidc, which is nowhere > to be found, am I getting some point wrong ? My fault, I forgot to add "dpidc" (a tiny PERL script that soon will become a C program). Sorry, and thanks for the report. I hope this time it works! Cheers Jorge.- PS: There's no need to CC' me. I read dillo-dev! :)

Oct. 9, 2003

Re: [Dillo-dev] dpid

by Nicolas Pouillon

Hi Jorge, Le Thu, 9 Oct 2003 13:57:48 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> eut le bonheur d'ecrire: > Hi there! > > Just made a big commit on dpid I just wanted to try it out but... dpid/Makefile.am references a bin_SCRIPT named dpidc, which is nowhere to be found, am I getting some point wrong ? -- Nipo

Oct. 9, 2003

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