- Dillo-dev - lists.mailman3.com

suggest next page feature

by itsme_410＠yahoo.com

midori has a nice feature which really would be a nice addition to dillo. From the midori webpage: "Many people don't know about a nitfy feature in Midori, which is going Forward to the next page. From now on you can hit Space at the bottom of a page to go to the next page, just like in a mail client. Note that this depends on the page. Pages with links labelled "Next" or similar will be recognized. Ideally ?rel="next"? is used in the HTML so Midori knows what the next page is." It would be nice if dillo had it too, on low-end systems where using mouse is at a premium. Alternatively, can keybindings be made to mimic this (and similar features)? Many thanks, T

Oct. 27, 2011

[test]: Am I getting through?

by onepoint＠starurchin.org

Test, please ignore. I thought I emailed the list on Monday and nothing has appeared so I am just checking it still works for me. Regards, Jeremy Henty

Oct. 26, 2011

view src

by jcid＠dillo.org

On Thu, Oct 20, 2011 at 06:41:17PM +0000, corvid wrote: > Jorge wrote: > > A quick trick to avoid viewing source of the "view source" page. > > A proper solution would be appreciatted. > > Does that break things, or do you just dislike it? I don't remember exactly what the problem was (man I'm getting old). There were two issues (AFAIR): 1) avoiding "always reload" (through dpi even on Back/Fwd). 2) avoid recursive URL expansion on reload. The current URL scheme helps with 2) and allows handling of 1) in the canonical way. Please test the attached patch. So far I see no problem with it. In other words: maybe I forgot to re-enable it after solving the problem, or forgot what the problem was afterwards! -- Cheers Jorge.-

Oct. 25, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by onepoint＠starurchin.org

Bump! It's a simple patch that should be easy to review. Regards, Jeremy Henty Jeremy Henty wrote: > > Another case of "let's be like the other browsers". See: > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > This will require an update to the help page on the web site. > > Congratulations on the keysrc code, it was very easy to understand and > modify. > > Next I was going to look at binding Ctrl-[1-8] to "go to the <n>-th > tab" and Ctrl-9 to "go to the rightmost tab" for the same reasons as > this patch - the other browsers do it. Comments? > > Regards, > > Jeremy Henty

Oct. 24, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

Hi Johannes, On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > [...] > Independent of this problem I think we should decide on the layering > of our base libraries (lout and dlib) to avoid code duplication. > My favorite option would be basing dlib on lout. > Any opinions? Historically: * the reason for using C++ (partly) in Dillo was FLTK (to be able to use its C++ API). * Sebastian and I worked independently (Dw/rest respectively) and ended with two libs. * This approach allowed for Dw and Dlib to be standalone. (thus helping Sebastian with other Dw projects and me/others to reuse Dlib in other pure C projects). Which is a good thing! One way to keep the advanges is to base lout on dlib. Mixing C/C++ for lout; this may be uglier/less-convenient than current status quo, so it would be a trade off. OTOH basing dlib on lout would force using C++ in pure C programs. :-P -- Cheers Jorge.-

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > > > Here's an idea of what we'd get: > > > > http://www.dillo.org/test/ascii_strcasecmp.diff > > > > - The naming is clear but kind of ugly. > > - I haven't added explanatory comments yet. > > - For the moment, it just #defines dStr(n)casecmp to the > > ASCII version because there are a bunch of them, but I'd > > go through and change the calls. > > > > Thoughts? > > I think it's nasty, but the right way to fix this. Yeah. Ater all locales/utf-8 is seldom a simple thing to handle right. If we'd have to: s/dStrcasecmp/dStrASCIIcasecmp/g s/dStrncasecmp/dStrnASCIIcasecmp/g then I'd keep the old function name and explain in the function's comment why it is restricted to, or handled in the new way. From a distance this global change looks to me like exposing ourselves to more troubles. In other words, why not: int dStrcasecmp(...) { if (locale has special rules) special treatment else strcasecmp(...) } Disclaimer: I haven't studied the problem in detail. -- Cheers Jorge.-

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > Did you find any cases where the localized version actually makes sense? I left the findtext code alone, since neither case will work well anyway. > Independent of this problem I think we should decide on the layering > of our base libraries (lout and dlib) to avoid code duplication. > My favorite option would be basing dlib on lout. > Any opinions? It would make sense. Speaking of lout, we still have #define prefs_show_msg 1 in lout/msg.h. Oh, and there's the BitSet/Bitvec duplication...

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > Here's an idea of what we'd get: > > http://www.dillo.org/test/ascii_strcasecmp.diff > > - The naming is clear but kind of ugly. > - I haven't added explanatory comments yet. > - For the moment, it just #defines dStr(n)casecmp to the > ASCII version because there are a bunch of them, but I'd > go through and change the calls. > > Thoughts? I think it's nasty, but the right way to fix this. Did you find any cases where the localized version actually makes sense? Not sure how a lowercase roman 2 should look like in tr_TR :-) > > Skimming through the diff now, I'm noticing the cases like > if (dASCIItolower(attrbuf[0]) == 'j') > and thinking maybe > if (attrbuf[0] == 'j' || attrbuf[0] == 'J') > would be better, but then this issue is probably too tiny to waste > precious seconds of my life in noticing. I would guess that you end up with pretty much the same assembler code in both cases. > (Whereas continuing to use tolower() because we know that 'j' > is safe would be bad practice, in my opinion.) right. Independent of this problem I think we should decide on the layering of our base libraries (lout and dlib) to avoid code duplication. My favorite option would be basing dlib on lout. Any opinions? Cheers, Johannes

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Here's an idea of what we'd get: http://www.dillo.org/test/ascii_strcasecmp.diff - The naming is clear but kind of ugly. - I haven't added explanatory comments yet. - For the moment, it just #defines dStr(n)casecmp to the ASCII version because there are a bunch of them, but I'd go through and change the calls. Thoughts? Skimming through the diff now, I'm noticing the cases like if (dASCIItolower(attrbuf[0]) == 'j') and thinking maybe if (attrbuf[0] == 'j' || attrbuf[0] == 'J') would be better, but then this issue is probably too tiny to waste precious seconds of my life in noticing. (Whereas continuing to use tolower() because we know that 'j' is safe would be bad practice, in my opinion.)

Oct. 23, 2011

use C locale for LC_CTYPE

by corvid＠lavabit.com

furaisanjin wrote: > Could you add locale setting on preference to make dillo use the > preference locale rather than default "C" at start up? I'll back out the change and look into handling this the usual way....

Oct. 23, 2011