- Dillo-dev - lists.mailman3.com

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by akemnade＠tzi.de

Hi, On Tue, 24 Feb 2009 20:21:52 +0100 Detlef Riekenberg <wine.dev(a)web.de> wrote: > Hi. > Thanks for working on Dillo. > > I tried to update the Dillo Project Page on Ohloh, > but the the repository failed on the id command. > > ...$hd id http://hg.dillo.org/dillo > abort: cannot look up remote revision; remote repository does not > support the 'lookup' capability! > > Which Mercurial version is used to serve dillo? > It is Mercurial Distributed SCM (version 0.9.1) Thats the version coming with debian etch. The id command works differently in the newer versions. I plan to upgrade at the end of march at the latest to the just-released stable. Greetings Andreas Kemnade

Feb. 25, 2009

patches, bundles, etc

by Johannes.Hofmann＠gmx.de

On Tue, Feb 24, 2009 at 12:22:21PM -0700, Scott Scriven wrote: > * Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > > For Dillo, experimental per-feature repositories would be very > > useful ... > > Yes, I agree. I make feature branches all the time, and I think > they're great. But that's not really what I was getting at. > Basically, there are a few different ways to merge... > > - patch: send the output of 'hg diff' to the list, apply it via > 'patch', and commit one revision > > - bundle: send the output of 'hg bundle' to the list, apply it > via 'hg unbundle', and commit with full history > > - repository: send an URL to the list, apply via 'hg pull' and > 'hg merge', and commit with full history > > I've seen patch and repository methods used here, but haven't > really seen any bundles. So, I'm just wondering if that sort of > thing is acceptable. I think it's probably preferable to plain > patches, and easier than hosting repositories. We have been using bundles a few times. But this may have been off list. I would suggest to use plain patches for simple short changes, as they are easy to review and immediately viewable in the mail archives. For longer living feature branches a separate repository can be helpful. Check out http://freehg.org it's really simple to setup a repo there. Bundles can be used in some cases, but I wouldn't recommend them for general use on the mailling list. BTW: It seems mercurial itself also suggests patches according to: http://www.selenic.com/mercurial/wiki/index.cgi/ContributingChanges Cheers, Johannes

Feb. 25, 2009

[patch] Configurable key bindings

by itsme_410＠yahoo.com

Hi Is it possible to have keybindings in the locator bar such as (perhaps configurable) ctrl-enter for www. and .com, Shift-Ctrl-enter for www. and .org, alt-ctrl-enter for www. and .edu and so on? That would really help! Thanks very much!! T > --- On Tue, 2/24/09, Scott Scriven > <dillo-dev(a)toykeeper.net> wrote: > > > From: Scott Scriven <dillo-dev(a)toykeeper.net> > > Subject: Re: [Dillo-dev] [patch] Configurable key > bindings > > To: dillo-dev(a)dillo.org > > Date: Tuesday, February 24, 2009, 3:15 PM > > * Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > > > The other advantage of this implementation is > that > > we could > > > easily modify it to allow multiple key bindings > for > > one symbol. > > > > This is a good thing. > > > > > Therefore an "include" command for the > > dillorc should be > > > implemented. Then we could put something like > > "include > > > /usr/share/dillo/bindings/default" there, > as > > well as some > > > others. Now, if somebody wants to try different > key > > bindings, > > > you would just have to uncomment this particular > > line. There > > > is no need for replacing your local bindings just > to > > try others > > > out. > > > > An 'include' command would help me for other > > reasons, too. I > > split most of my config files into shared versus local > > portions, > > so I can have a base config on many hosts and tweak > > individual > > settings per host. > > > > > > Just my $0.02. > > > > > > -- Scott > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)dillo.org > > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 25, 2009

[PATCH] Update the FSF Adress

by corvid＠lavabit.com

Detlef wrote: > The copyright notice in source files use an outdated FSF Address Hmm...I see that the GPLv3 says "You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>." It might be good for us to change to that.

Feb. 25, 2009

[PATCH] Update the FSF Adress

by wine.dev＠web.de

The copyright notice in source files use an outdated FSF Address -- By by ... Detlef

Feb. 24, 2009

[patch] Configurable key bindings

by dillo-dev＠toykeeper.net

* Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > The other advantage of this implementation is that we could > easily modify it to allow multiple key bindings for one symbol. This is a good thing. > Therefore an "include" command for the dillorc should be > implemented. Then we could put something like "include > /usr/share/dillo/bindings/default" there, as well as some > others. Now, if somebody wants to try different key bindings, > you would just have to uncomment this particular line. There > is no need for replacing your local bindings just to try others > out. An 'include' command would help me for other reasons, too. I split most of my config files into shared versus local portions, so I can have a base config on many hosts and tweak individual settings per host. Just my $0.02. -- Scott

Feb. 24, 2009

[patch] Configurable key bindings

by dillo-dev＠toykeeper.net

* Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > > F10 through F20? > > You are right. I seem to have forgotten them. FLTK only supports F1 > through F12 though. But implementing further function keys should > not be that difficult. Does your keyboard have 20 function keys? I only have 12 labelled function keys, but I generally map the extra keys (such as "multimedia" or "internet" keys) to F13-F20. It looks like fltk allows up to F35 ('LastFunctionKey = F0Key+35', but has no actual names for 13 to 34. For now, I'd add F10-F12 and wait on the others. > > Keypad keys? > > You mean the arrows while having "Num Lock" disabled? I'm not sure how fltk handles it, but X11 sends different key codes for regular Enter versus KP_Enter, different codes for the keypad arrows, etc. Try pressing keys in a 'xev' window to see the exact differences. > > What about Meta, Hyper, Super, AltGr, and Modeshift? Or, > > more generally, Mod1 through Mod5? > > FLTK does not support all of them. I only added those modifiers I > thought to be most important. fltk/events.h contains a list of all > supported modifiers. Please tell me which ones you want me to add. Okay, looking through fltk/events.h, it appears that fltk's authors either don't understand or don't care about X11 modifier keys. So, I'd add Meta and forget the rest. If the toolkit doesn't support it, the app probably can't either. > > replaced by a table instead of a bunch of if/else statements. > > Great idea but how do we realize it best? Probably in a different changeset. It's just an idea for later. -- Scott

Feb. 24, 2009

patches, bundles, etc

by dillo-dev＠toykeeper.net

* Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > For Dillo, experimental per-feature repositories would be very > useful ... Yes, I agree. I make feature branches all the time, and I think they're great. But that's not really what I was getting at. Basically, there are a few different ways to merge... - patch: send the output of 'hg diff' to the list, apply it via 'patch', and commit one revision - bundle: send the output of 'hg bundle' to the list, apply it via 'hg unbundle', and commit with full history - repository: send an URL to the list, apply via 'hg pull' and 'hg merge', and commit with full history I've seen patch and repository methods used here, but haven't really seen any bundles. So, I'm just wondering if that sort of thing is acceptable. I think it's probably preferable to plain patches, and easier than hosting repositories. -- Scott

Feb. 24, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by wine.dev＠web.de

Hi. Thanks for working on Dillo. I tried to update the Dillo Project Page on Ohloh, but the the repository failed on the id command. ...$hd id http://hg.dillo.org/dillo abort: cannot look up remote revision; remote repository does not support the 'lookup' capability! Which Mercurial version is used to serve dillo? -- By by ... Detlef

Feb. 24, 2009

patches, bundles, etc

by onepoint＠starurchin.org

On Tue, Feb 24, 2009 at 06:35:50PM +0100, Tim Nieradzik wrote: > It is always difficult for users to track changes between larger > patches. I think Johannes did it right with his css-prototype > repository. +1. Forking a repository and merging changes in small pieces is the way to go. Regards, Jeremy Henty

Feb. 24, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> F10 through F20? You are right. I seem to have forgotten them. FLTK only supports F1 through F12 though. But implementing further function keys should not be that difficult. Does your keyboard have 20 function keys? > Keypad keys? You mean the arrows while having "Num Lock" disabled? > What about Meta, Hyper, Super, AltGr, and Modeshift? Or, more > generally, Mod1 through Mod5? FLTK does not support all of them. I only added those modifiers I thought to be most important. fltk/events.h contains a list of all supported modifiers. Please tell me which ones you want me to add. > BTW, I know it was like this before too, but something to think > about for later is that this section could probably be replaced > by a table instead of a bunch of if/else statements. Great idea but how do we realize it best? > And, if you want to have an easier time keeping the formatting > consistent, try this in your vimrc: > > " show tabs and trailing spaces > set listchars=tab:>-,trail:- > set list Thanks for the hint. I have added it to my vimrc. > It's a minor thing really, but I noticed some inconsistent > whitespace, and those config lines make it really easy to spot. > :) Okay, I try to pay attention on it the next time. --Tim

Feb. 24, 2009

libDw_fltk_a-fltk*.o naming

by corvid＠lavabit.com

Is there any reason not to shorten them to fltk*.o?

Feb. 24, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> enum { > KEYCMD_RELOAD, > ... > }; No, I thought of using constants: #define KEYCMD_RELOAD (0) #define KEYCMD_OPEN (1) ... > commands[] = { > {"reload", KEYCMD_RELOAD}, > ... > }; There are no mapping tables in my approach. commands[] is the same as symbols[] (like it is called in src/keys.cc) and contains all actions as well as their default key bindings. commands[] = { { "reload", { fltk::CTRL, 'r' } }, { "open" , { fltk::CTRL, 'o' } }, ... }; > isPressed(&bindings[KEYCMD_RELOAD]) The isPressed()-call should be as short as possible. I would prefer "isPressed(KEYCMD_RELOAD);". --Tim

Feb. 24, 2009

patches, bundles, etc

by tim.nieradzik＠gmx.de

It is always difficult for users to track changes between larger patches. I think Johannes did it right with his css-prototype repository. It is not the best thing to directly integrate bigger patches into mainline as they might be yet incomplete or lead to instabilities. Thus, having additional repositories is a good thing. If the features are stable enough and are thought to be useful, they can be simply merged into the main tree. In the Git world, where nearly everything is decentralized, it frequently happens that every core developer has an own repository for experimental changes. Of course this approach might not be always practical for smaller projects but we all can benefit from the fundamental idea of decentralisation. For Dillo, experimental per-feature repositories would be very useful before not well-tested patches go into mainline and risk the application's stability. Hence, I advocate that we make use of external repositories more frequently assuming it makes sense based on the changes' size. --Tim

Feb. 24, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Tim wrote: > > I think I'd feel better if it could be used like prefs, > > that is, isPressed testing bindings.reload instead of > > looking for the binding associated with the "reload" string. > > Personally, I also like this concept better as it reduces the risk > of misspellings (the compiler would throw an error). Furthermore, > the code looks much cleaner and it is likely that it become a bit > faster (because seeking the "symbols" array is not be necessary > anymore). > > But on the other hand there needs to be a large mapping table that > contains all symbol names twice for each entry (like it is done in > src/prefs.c). This was the main reason why I decided against a > "bindings" array because I simply wanted to avoid duplicate code. > > To find balance between these two approaches, I would suggest > altering isPressed() requiring only the position of the symbol in > the "symbols" array. Then we could create a constant for each > binding containing that ID. It works similar to prefs' concept > except that we only map integers. Hence, when adding new entries, we > have to repeat the symbol name less frequent. The only problem with > this approach is that it easily breaks when the items are > accidentally re-ordered. So something like enum { KEYCMD_RELOAD, ... }; commands[] = { {"reload", KEYCMD_RELOAD}, ... }; isPressed(&bindings[KEYCMD_RELOAD]) ?

Feb. 24, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> - This change is not backwards compatible. Do not read old dillorc > format and it is a big inconvenience for users. No, the new format is not backward compatible but it supports the equal signs which were used in the old format for associations. Dillo is mostly used by experienced Linux users who should not have any problems adding a simple "set " before each line. Backward compatibility should never be used as an argument against enhancements. Otherwise programs would just become larger and larger. They carry various compatibility layers without any real benefits. The more compatibility code an application contains, the more difficult it is to maintain it. > - Can delete some meta info stored in dillorc. Do you mean that the migration ``tool'' may delete comments? The dillorc is not migrated automatically (even though writing a small scrip would not be too difficult). As the user has to do this manually, it is one's choice whether to keep the comments or not. > - There are compatible ways to add this preferences (key_save = "...", > key_find = "CTRL + f", ...) Sure, but options were not initially thought of as being used for key bindings. When using a special keyword which is only valid for one preferences type (bindings), it is possible to add further parameters such as groups (useful when having lots of key bindings). The other advantage of this implementation is that we could easily modify it to allow multiple key bindings for one symbol. > - If the number of key bindings increase much another config file can > be convenient. With another config file some example files can be > suplied (vim keys, firefox keys, ...) and end user only need to copy > the prefered file. The idea of having several ``preset'' files for key bindings is well. In my opinion, we should give the user the right to decide whether to put everything into one file or to separate the configuration into multiple files. Therefore an "include" command for the dillorc should be implemented. Then we could put something like "include /usr/share/dillo/bindings/default" there, as well as some others. Now, if somebody wants to try different key bindings, you would just have to uncomment this particular line. There is no need for replacing your local bindings just to try others out. --Tim

Feb. 24, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> I think I'd feel better if it could be used like prefs, > that is, isPressed testing bindings.reload instead of > looking for the binding associated with the "reload" string. Personally, I also like this concept better as it reduces the risk of misspellings (the compiler would throw an error). Furthermore, the code looks much cleaner and it is likely that it become a bit faster (because seeking the "symbols" array is not be necessary anymore). But on the other hand there needs to be a large mapping table that contains all symbol names twice for each entry (like it is done in src/prefs.c). This was the main reason why I decided against a "bindings" array because I simply wanted to avoid duplicate code. To find balance between these two approaches, I would suggest altering isPressed() requiring only the position of the symbol in the "symbols" array. Then we could create a constant for each binding containing that ID. It works similar to prefs' concept except that we only map integers. Hence, when adding new entries, we have to repeat the symbol name less frequent. The only problem with this approach is that it easily breaks when the items are accidentally re-ordered. --Tim

Feb. 24, 2009

patches, bundles, etc

by dillo-dev＠toykeeper.net

BTW, what's the policy on submitting sizable changes with multiple revisions, such as the configurable keybindings? Is it okay to send a changeset bundle, or do the changes need to be flattened into a single patch? It probably doesn't matter for small changes, but it might be nice to include the history for large changes. -- Scott

Feb. 24, 2009

[patch] Configurable key bindings

by dillo-dev＠toykeeper.net

* Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > It took longer to write this patch than I expected. That really was quick! I'm excited to see this. I'm not very familiar with Dillo's code, so I only have superficial comments. Mostly, I see some keys missing... > +struct mapping_s keyNames[] = { > + { "Backspace", fltk::BackSpaceKey }, > + { "Delete", fltk::DeleteKey }, > + { "Down", fltk::DownKey }, > + { "End", fltk::EndKey }, > + { "Esc", fltk::EscapeKey }, > + { "F1", fltk::F1Key }, > + { "F2", fltk::F2Key }, > + { "F3", fltk::F3Key }, > + { "F4", fltk::F4Key }, > + { "F5", fltk::F5Key }, > + { "F6", fltk::F6Key }, > + { "F7", fltk::F7Key }, > + { "F8", fltk::F8Key }, > + { "F9", fltk::F9Key }, F10 through F20? > + { "Home", fltk::HomeKey }, > + { "Insert", fltk::InsertKey }, > + { "Left", fltk::LeftKey }, > + { "PageDown", fltk::PageDownKey }, > + { "PageUp", fltk::PageUpKey }, > + { "Print", fltk::PrintKey }, > + { "Return", fltk::ReturnKey }, > + { "Right", fltk::RightKey }, > + { "Space", fltk::SpaceKey }, > + { "Tab", fltk::TabKey }, > + { "Up", fltk::UpKey } > +}; Keypad keys? > +static struct mapping_s modifierNames[] = { > + { "Shift", fltk::SHIFT }, > + { "Ctrl", fltk::CTRL }, > + { "Alt", fltk::ALT }, > + { "Button1", fltk::BUTTON1 }, > + { "Button2", fltk::BUTTON2 }, > + { "Button3", fltk::BUTTON3 } > +}; What about Meta, Hyper, Super, AltGr, and Modeshift? Or, more generally, Mod1 through Mod5? BTW, I know it was like this before too, but something to think about for later is that this section could probably be replaced by a table instead of a bunch of if/else statements. > + if ((Keys::isPressed("hide-panels")) && (get_panelmode() == UI_TEMPORARILY_SHOW_PANELS)) { > + set_panelmode(UI_HIDDEN); > + ret = 1; > + } else if (Keys::isPressed("bookmarks")) { > + a_UIcmd_book(a_UIcmd_get_bw_by_widget(this)); > + ret = 1; > + } else if (Keys::isPressed("find")) { > + set_findbar_visibility(1); > + ret = 1; > + } else if (Keys::isPressed("goto")) { > ... > + } else if (Keys::isPressed("back")) { > + a_UIcmd_back(a_UIcmd_get_bw_by_widget(this)); > + ret = 1; > + } else if (Keys::isPressed("forward")) { > + a_UIcmd_forw(a_UIcmd_get_bw_by_widget(this)); > + ret = 1; > } And, if you want to have an easier time keeping the formatting consistent, try this in your vimrc: " show tabs and trailing spaces set listchars=tab:>-,trail:- set list It's a minor thing really, but I noticed some inconsistent whitespace, and those config lines make it really easy to spot. :) -- Scott

Feb. 24, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Diego wrote: > - If the number of key bindings increase much another config file can > be convenient. With another config file some example files can be > suplied (vim keys, firefox keys, ...) and end user only need to copy > the prefered file. That's a good point.

Feb. 24, 2009

[patch] Configurable key bindings

by darkspirit5000＠gmail.com

I disagree about changing the dillorc format: - This change is not backwards compatible. Do not read old dillorc format and it is a big inconvenience for users. - Can delete some meta info stored in dillorc. - There are compatible ways to add this preferences (key_save = "...", key_find = "CTRL + f", ...) - If the number of key bindings increase much another config file can be convenient. With another config file some example files can be suplied (vim keys, firefox keys, ...) and end user only need to copy the prefered file. I do not known what other option is best, but i think that this format change is not needed. Diego. 2009/2/24, corvid <corvid(a)lavabit.com>: > I think I'd feel better if it could be used like prefs, > that is, isPressed testing bindings.reload instead of > looking for the binding associated with the "reload" string. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 24, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

I think I'd feel better if it could be used like prefs, that is, isPressed testing bindings.reload instead of looking for the binding associated with the "reload" string.

Feb. 24, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Tim wrote: > > looking in events.h, I think > > (event_state() & (SHIFT | CTRL)) would work. > > Good idea. It does not work as expected though. But this does: > ((event_state() & (SHIFT | CTRL)) == (SHIFT + CTRL)) err, yes :) or probably event_state() == (SHIFT | CTRL) in this case. > Now that we know how to check for multiple modifiers, does somebody > want to implement it? I lean toward not adding features to this patch yet. (Continuing to add features before getting anything into the tree caused dillo not to get frames support, and that was an unfortunate incident all around.)

Feb. 23, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> looking in events.h, I think > (event_state() & (SHIFT | CTRL)) would work. Good idea. It does not work as expected though. But this does: ((event_state() & (SHIFT | CTRL)) == (SHIFT + CTRL)) Now that we know how to check for multiple modifiers, does somebody want to implement it? --Tim

Feb. 23, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Tim wrote: > > - I'm sure that Jorge isn't going to want exception handling. > > Why not? Exceptions are more flexible when it comes to longer and > more complicated functions. Of course, we could also return an > integer status code but sometimes it is necessary to return > non-integer values. My Jorge-simulator might be imperfect, but we'll see. (When I did most of my C++, the compiler didn't even have exceptions yet, so I can't claim bitter experience, but they've always looked a bit like gotos to me when it comes to maintainability.) > > PS Are you sure that fltk doesn't allow modifiers to be combined? > > Grepping through fltk/test, it looks like they're combining them > > in menubar.cxx. > > It looks like this is possible indeed. However, I used > event_state(SHIFT & CTRL) to check whether it recognizes a combined > Shift and Ctrl but this did not work for me. Any ideas? looking in events.h, I think (event_state() & (SHIFT | CTRL)) would work.

Feb. 23, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> - I haven't looked at this in any detail yet -- this is just my > paging-through-the-patch response -- but I notice a_Nav_push_forced > in there. Patches should be kept separate. The smaller they are, > the better for review. Yes, it contains my other three patches partially because they were related. > - Lines should not be longer than 79 chars. Okay, I configured VIM appropriately. > - I'm sure that Jorge isn't going to want exception handling. Why not? Exceptions are more flexible when it comes to longer and more complicated functions. Of course, we could also return an integer status code but sometimes it is necessary to return non-integer values. > PS Are you sure that fltk doesn't allow modifiers to be combined? > Grepping through fltk/test, it looks like they're combining them > in menubar.cxx. It looks like this is possible indeed. However, I used event_state(SHIFT & CTRL) to check whether it recognizes a combined Shift and Ctrl but this did not work for me. Any ideas? --Tim

Feb. 23, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Wow that was quick! - I personally am open to the idea of changing the dillorc format for existing options, but we'll see what the consensus is. - I haven't looked at this in any detail yet -- this is just my paging-through-the-patch response -- but I notice a_Nav_push_forced in there. Patches should be kept separate. The smaller they are, the better for review. - Lines should not be longer than 79 chars. - I'm sure that Jorge isn't going to want exception handling. I'll add something about that last point to the website, since it's not mentioned currently. PS Are you sure that fltk doesn't allow modifiers to be combined? Grepping through fltk/test, it looks like they're combining them in menubar.cxx.

Feb. 23, 2009

Holiday week

by Hole.destructor＠gmx.de

Hello Jorge, > [ ] https dialog bombing issue. BUG#868 > When enabled, multiple https requests to the same site result > in dialog bombing. The https dpi is disabled by default in > Dillo. Anyway, in Debian, there's a security warning against > dillo for not checking certificates (I don't know what > version of dillo they use, nor why they enable https.) Debian (and Ubuntu) uses a strongly modified version of Dillo-0.8.6, which one can get officially from http://teki.jpn.ph/pc/software/index-e.shtml On the splash screen of debians Dillo it says, that Kiyo <webmaster[at]teki.jpn.ph> is the one to report problems to, so I guess he is the package maintainer or so. Best, Alexander.

Feb. 23, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

It took longer to write this patch than I expected. You will find it in the attachment but I do not recommend using it before somebody else has verified it (I am new to C/C++). I had to re-implement the parsing routine. This is mainly because a new line format was introduced which allows you to configure key bindings in your dillorc. Otherwise we would have needed unnecessarily a second file. This is the only thing that changes for the user. The new format looks like this: "set option value" For backward compatibility you can also use an equal sign before the value: "set option=value" so that you only have to put a ``set'' to the beginning of each line in your old dillorc. But more interesting is the support for configurable keys. The corresponding keyword for bindings is called ``bind''. The second parameter of a binding line represents the key combination and the third one its action. Thus, to allow reloading with a single `r' (instead of Ctrl-r), you can simply write: "bind r reload" But you can also do more complex things like setting modifiers (Ctrl, Alt, Left mouse click, etc.). A line mapping the backward action to Ctrl-p looks like this: "bind <Ctrl>p backward" There are some limitations, though: Unfortunately, FLTK does not enable us to combine modifiers in order to set even more key combinations. Because FLTK is C++-only and we need one of its header files, I had to realize this part of the parser in C++, as well. The line parser is written in C because there are too many functions which access an array in which it puts the parsed preferences. We should port everything to C++ as this would help us keeping the code clean. Note that not only alpha-numeric characters but also ``special characters'' such as "Backspace", "Enter", "Tab" and a few others are supported. To get a full list, please refer to src/keys.cc which also contains all modifiers and the default key bindings. I have not figured out yet how to implement scrolling hooks. Hence, it would be nice if someone could implement the symbols "scroll-top", "scroll-bottom", "scroll-left", "scroll-right", "scroll-up" and "scroll-down" as I want to use VIM-like key bindings (h, j, k, l for movement) in Dillo. The downside of this patch is that currently there is an issue with the line parser, which claims to find syntax errors even though the lines look alright for me. This needs to be fixed before this patch can go into mainline. --Tim

Feb. 23, 2009

[patch] Improving keyboard shortcuts for tab navigation

by dillo-dev＠toykeeper.net

* corvid <corvid(a)lavabit.com> wrote: > I wonder whether you'd be interested in > implementing configurable key bindings... Yes, please do! :) It would be so much nicer than what I've had to do so far... either custom builds with source changes, or per-app key remapping in sawfish. For example, I have meta-left/right mapped to "back" and "forward" by emitting fake backspace and shift-backspace events, but this doesn't work when the address entry is focused... -- Scott

Feb. 23, 2009

Holiday week

by jcid＠dillo.org

Hi there, I happen to be enjoying a much needed holiday week! :-) The plan is to come back around near wednesday 25. In the meanwhile, I leave you with the following issues lurking in my list to be considered. Maybe all of them can be left to the release after 2.1, but maybe not: [ ] https dialog bombing issue. BUG#868 When enabled, multiple https requests to the same site result in dialog bombing. The https dpi is disabled by default in Dillo. Anyway, in Debian, there's a security warning against dillo for not checking certificates (I don't know what version of dillo they use, nor why they enable https.) [ ] Jump to #anchor doesn't work correctly. The idle timeout doesn't work reliably (an old bug). [ ] Implement @import statement in STYLE element. [ ] What will we do with xhtml? FF doesn't validate. BUG#732 This would be interesting to define. (already suggested as discussion material in another thread). [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. Enabling this switches reduces the binary size. [ ] dpi for "view page source" (it re-uses search capability). Waiting since a long time... [-] BUG#892 prefs bg_color is not working Johannes was working on related things... [ ] META refresh: "instant client-side redirect". [ ] META refresh: URL='<URI>' case. I plan to implement both when I'm back (and to include them in dillo-2.1). BTW, I want to welcome Tim Nieradzik as a new developer and to tell Joao that the bug in the find-text iterator is not that much important. Just focus on something more urgent. -- Cheers Jorge.-

Feb. 21, 2009

[patch] Improving keyboard shortcuts for tab navigation

by corvid＠lavabit.com

I wonder whether you'd be interested in implementing configurable key bindings...

Feb. 21, 2009

[patch] Improving keyboard shortcuts for tab navigation

by tim.nieradzik＠gmx.de

This patch adds keyboard shortcuts for the tabs 0 - 9. You can reach them by pressing Ctrl concurrently with the number number of the tab you would like to see. Thus, for the first tab this is Ctrl-0. Alternatively, you can press Ctrl-Home. To get to the last tab, simply press Ctrl-End. In addition the modifier for moving left and right between tabs has been changed from Shift to Ctrl because it makes sense to have an unified modifier for all tab movement operations. --Tim

Feb. 21, 2009

[patch] Hiding panels by pressing "Escape"

by tim.nieradzik＠gmx.de

This small patch allows you to press the "Escape" key in order to hide the panels. It assumes that you are in the UI mode "UI_TEMPORARILY_SHOW_PANELS". --Tim

Feb. 20, 2009

[patch] Reloading page by pressing "Enter" in the location box (bug #890)

by tim.nieradzik＠gmx.de

To whom it may concern, I have signed up on the dillo-dev mailing list and would like to introduce myself. My name is Tim Nieradzik. I am new to this mailing list, and I would like to contribute some patches. In the included attachment you will find my first contribution to the Dillo project. It allows users to reload the current page by pressing "Enter" in the location box (bug #890). Sincerely, Tim

Feb. 20, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 03:32:54PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > > > Johannes wrote: > > > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > > > I tried > > > > > font-size: .6in > > > > > (we still love archaic measurements here) > > > > > and it didn't work. > > > > > > > > > > The grammar says > > > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > > > float... > > > > > > Attached. > > > Looks good to me so far. The only thing I'm wooried about is the > > hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and > > interprets them as class selectors. > > After looking at the CSS syntax I think this is not necessary, as > > class names must not start with numbers. > > Can you please have look at the spec too, to confirm this? > > In that case we could just remove the hack in > > Css_parse_simple_selector(). > > I did happen to see: > In CSS1, a class name could start with a digit (".55ft"), unless > it was a dimension (".55in"). In CSS2, such classes are parsed as > unknown dimensions (to allow for future additions of new units). > To make ".55ft" a valid class, CSS2 requires the first digit to be > escaped (".\35 5ft") Ah ok. That explains the current implementation. For CSS 2.1 must not support class selectors like '.1'. http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/by-section.htm has some nice test cases on this subject. I also noticed, that we need to discard the whole ruleset in case of an invalid selector. Cheers, Johannes PS: I haven't looked at escaped chars at all yet. There seems to be some code for it in cssparser.cc.

Feb. 19, 2009

Re: css parsing numbers

by corvid＠lavabit.com

Johannes wrote: > On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > > Johannes wrote: > > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > > I tried > > > > font-size: .6in > > > > (we still love archaic measurements here) > > > > and it didn't work. > > > > > > > > The grammar says > > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > > float... > > > > Attached. > Looks good to me so far. The only thing I'm wooried about is the > hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and > interprets them as class selectors. > After looking at the CSS syntax I think this is not necessary, as > class names must not start with numbers. > Can you please have look at the spec too, to confirm this? > In that case we could just remove the hack in > Css_parse_simple_selector(). I did happen to see: In CSS1, a class name could start with a digit (".55ft"), unless it was a dimension (".55in"). In CSS2, such classes are parsed as unknown dimensions (to allow for future additions of new units). To make ".55ft" a valid class, CSS2 requires the first digit to be escaped (".\35 5ft")

Feb. 19, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > I tried > > > font-size: .6in > > > (we still love archaic measurements here) > > > and it didn't work. > > > > > > The grammar says > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > float... > > Attached. > > I'm too much of a css newbie to promise great testing, but I did cobble together > the following and the right things seemed to happen: > > <html> > <head> > <style type="text/css"> > hr.aaaaa {width: 1.5in} > bbbbb {width: 2 in} > </style> > </head> > <body> > <hr style="width: 0.3in"> > <hr style="width: .6in"> > <hr style="width: 1 in"> > <hr class="aaaaa"> > <hr class="bbbbb"> > </body > </html> Looks good to me so far. The only thing I'm wooried about is the hack where Css_parse_simple_selector() checks for CSS_TK_FLOAT and interprets them as class selectors. After looking at the CSS syntax I think this is not necessary, as class names must not start with numbers. Can you please have look at the spec too, to confirm this? In that case we could just remove the hack in Css_parse_simple_selector(). Cheers, Johannes

Feb. 19, 2009

Re: css parsing numbers

by corvid＠lavabit.com

Johannes wrote: > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > I tried > > font-size: .6in > > (we still love archaic measurements here) > > and it didn't work. > > > > The grammar says > > num [0-9]+|[0-9]*"."[0-9]+ > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > float... Attached. I'm too much of a css newbie to promise great testing, but I did cobble together the following and the right things seemed to happen: <html> <head> <style type="text/css"> hr.aaaaa {width: 1.5in} bbbbb {width: 2 in} </style> </head> <body> <hr style="width: 0.3in"> <hr style="width: .6in"> <hr style="width: 1 in"> <hr class="aaaaa"> <hr class="bbbbb"> </body </html>

Feb. 19, 2009

Leaking image structures

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 05:06:16PM +0100, Hofmann Johannes wrote: > Yes. Updated patch attached. OK, I'm running with this patch. Since I don't have reproducible test cases I can't say right away whether it works. Keep an eye on my valgrind log page (it updates every night). http://starurchin.org/dillo/valgrind.html BTW, it seems that the CSS leaks stopped about three days ago. Yay! Regards, Jeremy Henty

Feb. 18, 2009

Leaking image structures

by Johannes.Hofmann＠gmx.de

On Wed, Feb 18, 2009 at 09:13:57AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 18, 2009 at 08:26:52AM +0000, corvid wrote: > > > > On Wed, Feb 18, 2009 at 12:40:57AM +0000, corvid wrote: > > > > > > Can you please try attached patch with valgrind and image loading on > > > > > > and off. > > > > > > > > > > Is this a proposed patch for the tree or an experiment in leak-finding? > > > > > > > > For the tree, if it proofs to fix the leaks and doesn't cause > > > > others. > > > > > > If we always add Image, the code that loads images manually will think > > > it hasn't been loaded yet. > > > > > > > Ah ok. I guess I misunderstood Html_add_new_linkimage() completely. > > Please check the updated patch. > > > > Thanks, > > Johannes > > > > PS: The point of the patch is to actually do reference counting: > > Whenever we create a new reference (pointer) to an image, we call > > a_Image_ref(), when such a pointer is deleted we call > > a_Image_unref(). > > If I see it correctly, the permanent pointers to Image > > structures are in html->images and in the DilloWeb structure. > > It's bedtime now, so I haven't looked at this carefully yet, > but you might need an unref in DilloHtml::loadImages() then. Yes. Updated patch attached.

Feb. 18, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 02:44:15PM +0100, Joerg Sonnenberger wrote: > On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > > > > BTW: the autoconf documentation frowns on this sort of thing, > > This only applies for checking things in the host filesystem. Yes, I realised after posting that since the code I am adding is intended to reflect the build system, no matter what the host system is, cross-compilation issues just do not arise. > > +#if HG > > + printf("HG current: %s\n", HG_CURRENT); > > + printf("HG qparent: %s\n", HG_QPARENT); > > +#endif > > + > > Any reason why this are two lines? No specific reason, but on general principle I usually write one line per record of information to make it easier to process the results with grep/sed etc. Regards, Jeremy Henty

Feb. 18, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > I'm completely convinced that this really adds any safety, but it's > easy enough to do. Revised patch attached. Looks good. > BTW: the autoconf documentation frowns on this sort of thing, from > (autoconf.info)Limitations of Builtins: > > `test' (files) > To enable `configure' scripts to support cross-compilation, > they shouldn't do anything that tests features of the build > system instead of the host system. This only applies for checking things in the host filesystem. E.g. testing for the existance of /etc/passwd would be bad for cross-compilation. > --- a/src/dillo.cc > +++ b/src/dillo.cc > @@ -211,6 +211,11 @@ > int width = D_GEOMETRY_DEFAULT_WIDTH, height = D_GEOMETRY_DEFAULT_HEIGHT; > char **opt_argv; > > +#if HG > + printf("HG current: %s\n", HG_CURRENT); > + printf("HG qparent: %s\n", HG_QPARENT); > +#endif > + Any reason why this are two lines? Joerg

Feb. 18, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Wed, Feb 18, 2009 at 10:49:36AM +0000, Jeremy Henty wrote: > I'm completely convinced that this really adds any safety, D'oh: I meant to write "I'm *not* completely convinced...". Regards, Jeremy Henty

Feb. 18, 2009

Leaking image structures

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 08:39:04PM +0100, Hofmann Johannes wrote: > I guess there is a leak when image loading is off. Not the leaks in my valgrind logs: I always have image loading on. Regards, Jeremy Henty

Feb. 18, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 09:08:33PM +0100, Joerg Sonnenberger wrote: > On Tue, Feb 17, 2009 at 07:52:13PM +0000, Jeremy Henty wrote: > > Do you mean that we should worry that there might be an hg in > > $PATH that is not Mercurial? Is it really necessary to be that > > cautious? > > It would be nice, yes. What about just wrapping this into > if [ -d .hg ]; ... fi or something like that? I'm completely convinced that this really adds any safety, but it's easy enough to do. Revised patch attached. BTW: the autoconf documentation frowns on this sort of thing, from (autoconf.info)Limitations of Builtins: `test' (files) To enable `configure' scripts to support cross-compilation, they shouldn't do anything that tests features of the build system instead of the host system. So I guess if we want to be truly GNU-ly correct we should disable this code unless the builder specifies some enable-* configure flag. However, the code won't break any cross-compilation so it's not critical. Regards, Jeremy Henty

Feb. 18, 2009

Leaking image structures

by corvid＠lavabit.com

Johannes wrote: > On Wed, Feb 18, 2009 at 08:26:52AM +0000, corvid wrote: > > > On Wed, Feb 18, 2009 at 12:40:57AM +0000, corvid wrote: > > > > > Can you please try attached patch with valgrind and image loading on > > > > > and off. > > > > > > > > Is this a proposed patch for the tree or an experiment in leak-finding? > > > > > > For the tree, if it proofs to fix the leaks and doesn't cause > > > others. > > > > If we always add Image, the code that loads images manually will think > > it hasn't been loaded yet. > > > > Ah ok. I guess I misunderstood Html_add_new_linkimage() completely. > Please check the updated patch. > > Thanks, > Johannes > > PS: The point of the patch is to actually do reference counting: > Whenever we create a new reference (pointer) to an image, we call > a_Image_ref(), when such a pointer is deleted we call > a_Image_unref(). > If I see it correctly, the permanent pointers to Image > structures are in html->images and in the DilloWeb structure. It's bedtime now, so I haven't looked at this carefully yet, but you might need an unref in DilloHtml::loadImages() then.

Feb. 18, 2009

Leaking image structures

by Johannes.Hofmann＠gmx.de

On Wed, Feb 18, 2009 at 08:26:52AM +0000, corvid wrote: > > On Wed, Feb 18, 2009 at 12:40:57AM +0000, corvid wrote: > > > > Can you please try attached patch with valgrind and image loading on > > > > and off. > > > > > > Is this a proposed patch for the tree or an experiment in leak-finding? > > > > For the tree, if it proofs to fix the leaks and doesn't cause > > others. > > If we always add Image, the code that loads images manually will think > it hasn't been loaded yet. > Ah ok. I guess I misunderstood Html_add_new_linkimage() completely. Please check the updated patch. Thanks, Johannes PS: The point of the patch is to actually do reference counting: Whenever we create a new reference (pointer) to an image, we call a_Image_ref(), when such a pointer is deleted we call a_Image_unref(). If I see it correctly, the permanent pointers to Image structures are in html->images and in the DilloWeb structure.

Feb. 18, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Tue, Feb 17, 2009 at 07:52:13PM +0000, Jeremy Henty wrote: > > I know that hg does the check internally, but that also depends on > > that no other hg binary can be found. > > Do you mean that we should worry that there might be an hg in $PATH > that is not Mercurial? Is it really necessary to be that cautious? It would be nice, yes. What about just wrapping this into if [ -d .hg ]; ... fi or something like that? Joerg

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 07:49:33PM +0100, Joerg Sonnenberger wrote: > Point is, release build should never differ whether hg is installed > or not. I absolutely agree, but if by "release build" you mean "a build not in a Mercurial repository" then that is already true of the current version of the patch. If you're not in a Mercurial repository then exactly the same code is compiled whether Mercurial is installed or not. > I know that hg does the check internally, but that also depends on > that no other hg binary can be found. Do you mean that we should worry that there might be an hg in $PATH that is not Mercurial? Is it really necessary to be that cautious? If we must handle host OSes that break our attempts to auto-detect hg then we will have to make the code conditional on a new configure flag (eg. --enable-hg-logging), with the proviso that if you supply the flag then the obligation is on you to ensure that your hg is a properly working Mercurial executable. That's easy to implement. I hope I don't seem obstinate, but I am finding it hard to see the scenario that supposedly breaks the current patch. (Unless the scenario is "hg might not be Mercurial" in which case I have already described what I think is the only sensible fix.) Regards, Jeremy Henty

Feb. 17, 2009