- Dillo-dev - lists.mailman3.com

[patch] Configurable key bindings

by corvid＠lavabit.com

Jorge wrote: > - Removed a_Prefs_freeall because it was not used anywhere. Should we rip out all of the *_freeall()s?

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

Hi Tim, On Mon, Mar 09, 2009 at 04:54:57PM +0100, Tim Nieradzik wrote: > Here is an updated version of the patch. It aims to be fully > backward compatible. You do not need to change anything in your > dillorc (put the key bindings into ~/.dillo/keysrc). Good. > Changes: > - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). > - Split src/prefs.c (parser is now in src/prefsparser.c). > - Changed method names in src/dillo.cc to use camel case. > - Added meta-modifier and function keys F10-F12. > - Fixed some inconsistent white spaces. > - Shortened some license headers. > - Key bindings are to be defined in keysrc (previously dillorc). > - Minor code cleanups such as using "TODO:" instead of "\todo". > - Removed a_Prefs_freeall because it was not used anywhere. After giving a couple of read-passes to the patch, and considering that we still have some time before April (when I'll have time to focus on the release), we can merge this long patch in small independent chunks. Please separate them into different patch files. For instance: Simple ones: - Changed method names in src/dillo.cc to use camel case. - Fixed some inconsistent white spaces. - Shortened some license headers. - Minor code cleanups such as using "TODO:" instead of "\todo". - Removed a_Prefs_freeall because it was not used anywhere. Refactors: - Split src/prefs.c (parser is now in src/prefsparser.c). Core of it: - Key bindings are to be defined in keysrc (previously dillorc). - Added meta-modifier and function keys F10-F12. > PS: I would like to port some C files to C++ in order to achieve > more consistency. What is your opinion on this? As explained before. Not unless we're forced or there's a compelling reason. For instance I'd decline this: - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). (unless there's a strong reason I've not seen). -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > Jorge wrote: > > Skimming the code it looks like the cast to long for int is > > the way to go. If a: > > > > - URL_DATA(url)->len, content_type->str, > > + (long)URL_DATA(url)->len, content_type->str, > > > > solves it. I'd commit it and let the explanation come after > > the patch. > > I was thinking of adding long casts for the Content-Length headers > in file.c as well. Sound good? Sure, but after the test is known to work OK. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > Jorge wrote: > > > Skimming the code it looks like the cast to long for int is > > > the way to go. If a: > > > > > > - URL_DATA(url)->len, content_type->str, > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > solves it. I'd commit it and let the explanation come after > > > the patch. > > > > I was thinking of adding long casts for the Content-Length headers > > in file.c as well. Sound good? > > Shouldn't that be (s)size_t? The parameter is specified as %ld, so long seems OK. Now the number of parameters is relevant (quite irregular). > At least one vendor was smart enough to > produce a 64bit platform with long != ssize_t and support for files > larger than 32bit sounds highly useful... I'd like to have the result of the suggested test. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Joerg wrote: > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > Jorge wrote: > > > Skimming the code it looks like the cast to long for int is > > > the way to go. If a: > > > > > > - URL_DATA(url)->len, content_type->str, > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > solves it. I'd commit it and let the explanation come after > > > the patch. > > > > I was thinking of adding long casts for the Content-Length headers > > in file.c as well. Sound good? > > Shouldn't that be (s)size_t? At least one vendor was smart enough to > produce a 64bit platform with long != ssize_t and support for files > larger than 32bit sounds highly useful... Well, you know these issues better than I do. These two cases use %ld currently. One is given a size_t, and one is given an off_t.

March 25, 2009

bug tracker doesn't work with dillo?

by joerg.sonnenberger＠web.de

On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > Jorge wrote: > > Skimming the code it looks like the cast to long for int is > > the way to go. If a: > > > > - URL_DATA(url)->len, content_type->str, > > + (long)URL_DATA(url)->len, content_type->str, > > > > solves it. I'd commit it and let the explanation come after > > the patch. > > I was thinking of adding long casts for the Content-Length headers > in file.c as well. Sound good? Shouldn't that be (s)size_t? At least one vendor was smart enough to produce a 64bit platform with long != ssize_t and support for files larger than 32bit sounds highly useful... Joerg

March 25, 2009

Re: Mac OS X Developer

by corvid＠lavabit.com

That would be terrific to get OS X straightened out...

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Jorge wrote: > Skimming the code it looks like the cast to long for int is > the way to go. If a: > > - URL_DATA(url)->len, content_type->str, > + (long)URL_DATA(url)->len, content_type->str, > > solves it. I'd commit it and let the explanation come after > the patch. I was thinking of adding long casts for the Content-Length headers in file.c as well. Sound good?

March 25, 2009

bug tracker doesn't work with dillo?

by jcid＠dillo.org

On Mon, Mar 23, 2009 at 11:04:45PM -0600, Scott Scriven wrote: > * Scott Scriven <dillo-dev(a)toykeeper.net> wrote: > > The first bad revision is: > > changeset: 491:96a14e974cfb > > Some extra details... when I enable the MSG() call, this is what > I get: > > r490: > Query: {POST /paste/paste.php HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: rafb.net\x0D > Referer: http://rafb.net/\x0D > User-Agent: Dillo/2.0\x0D > Content-Length: 53\x0D > Content-Type: application/x-www-form-urlencoded\x0D > Cookie2: $Version="1"\x0D > Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D > \x0D > lang=C%2B%2B&nick=foo&desc=r490+works&text=r490+works} > > r491: > Query: {POST /paste/paste.php HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: rafb.net\x0D > Referer: http://rafb.net/\x0D > User-Agent: Dillo/2.0\x0D > Content-Length: 47966194761781\x0D > Content-Type: application/x-www-form-urlencoded\x0D > Cookie2: $Version="1"\x0D > Cookie: uid=foo; $Path=/paste/; $Domain=rafb.net\x0D > \x0D > lang=C%2B%2B&nick=foo&desc=r491+fails&text=r491+fails} > > So, it looks like the content-length is definitely the issue. I > just don't see how it's getting changed. Skimming the code it looks like the cast to long for int is the way to go. If a: - URL_DATA(url)->len, content_type->str, + (long)URL_DATA(url)->len, content_type->str, solves it. I'd commit it and let the explanation come after the patch. -- Cheers Jorge.-

March 24, 2009

Re: Mac OS X Developer

by jcid＠dillo.org

On Sun, Mar 22, 2009 at 04:10:15PM -0300, Nicol?s Manuel Luna wrote: > Hello! My name is Nicolas Luna and I'm from Argentina. I was reading in > your website that you need Mac OS X Developer. Well, I've recently > migrated to this system and I use dillo for a long time (I used it in > Slackware). > I want to contribute anything as posible. I know how to compile, install > dependencies and I know some of C. > If you want me, say me what can I do. I love this browser :D. Great! Currently Dillo works in OSX but with some glitches. For instance, sometimes it is necessary to move the mouse over the rendering area to get a refresh. Sometimes buttons don't draw. I don't know what may be fixed/workarounded in Dillo and what may be FLTK2's fault. So the first you can do is to get it to run in OSX and to start investigating the problems. If you get stuck, you can ask in fltk general or dillo-dev (BTW, please subscribe to dillo-dev). Help is very welcomed. -- Cheers Jorge.-

March 24, 2009