- Dillo-dev - lists.mailman3.com

[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