- Dillo-dev - lists.mailman3.com

[PATCH] fix dillorc path

by jcid＠dillo.org

On Sun, Jun 07, 2009 at 06:43:25PM +0200, Johannes Hofmann wrote: > On Sun, Jun 07, 2009 at 12:34:31PM -0400, Jorge Arellano Cid wrote: > > On Sun, Jun 07, 2009 at 02:08:22AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > > > > Paul wrote: > > > > > > When opening dillo from the CLI I noticed the following message: > > > > > > > > > > > > paths: Cannot open file '/home/user/.dillo/dillorc' > > > > > > paths: Cannot open file '/etc/dillo/dillorc' > > > > > > paths: Using internal defaults... > > > > > > > > > > > > Checked my system and saw that dillorc had been installed > > > > > > in /usr/etc/dillorc > > > > > > > > > > > > Checking config.log showed sysconfdir='${prefix}/etc', so no > > > > > > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > > > > > > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > > > > > > as specified in src/Makefile.am, instead. Now all is fine! > > > > > > > > > > In addition, perhaps we should make sysconfdir have '/dillo' at the end. > > > > > If I look in an etc dir and see dillorc, I'd know what it's for, > > > > > but I wouldn't know what uses keysrc. > > > > > > > > Yes, a '/dillo' suffix looks OK. > > > > Please merge both ideas and commit. > > > > > > I defined a DILLO_SYSCONF instead of DILLORC_SYS > > > so that a system keysrc will work someday. > > > Please test. > > > > dillorc and dpidrc got into "/usr/local/etc". > > (I was expecting them in "/usr/local/etc/dillo"). > > Works fine for me. Did you call ./autogen.sh before configuring/ > compiling? Sorry, my mistake. I run autoreconf before the "hg up". It works fine now. -- Cheers Jorge.-

June 7, 2009

keyboard shortcuts non-functioning under KDE 3.5.10

by corvid＠lavabit.com

Rogutes wrote: > Johannes Hofmann (2009-06-04 16:58): > > On Thu, Jun 04, 2009 at 06:22:34AM +0100, Paul wrote: > > > Hi, > > > > > > I've got recent code from mercurial, June 1st. > > > No keyboard shortcuts are working for me using KDE 3.5.10. > > > > > > I was speaking to Johannes Hofmann about this problem, he asked me > > > what my locale was (it's en-GB.UTF-8) and also asked me to report > > > the problem here. > > > > Thanks for reporting. > > > > > > > > Do you need more information from me? > > > > Is anyone else seeing this? dillo shortcuts don't seem to work at > > all for Paul. Shortcuts in test/editor from fltk2 seem to work > > though. > > I can't reproduce the problem so far. > > Paul, > > Does anything change when you save the keysrc file attached to this > e-mail to ~/.dillo/keysrc ? I think I had something similar, but > I didn't have time to report...and now I forgot what it was :/ Did it have anything to do with your earlier mail (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-May/006378.html) for restricting the modifiers?

June 7, 2009

[PATCH] fix dillorc path

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jun 07, 2009 at 02:08:22AM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > > > Paul wrote: > > > > > When opening dillo from the CLI I noticed the following message: > > > > > > > > > > paths: Cannot open file '/home/user/.dillo/dillorc' > > > > > paths: Cannot open file '/etc/dillo/dillorc' > > > > > paths: Using internal defaults... > > > > > > > > > > Checked my system and saw that dillorc had been installed > > > > > in /usr/etc/dillorc > > > > > > > > > > Checking config.log showed sysconfdir='${prefix}/etc', so no > > > > > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > > > > > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > > > > > as specified in src/Makefile.am, instead. Now all is fine! > > > > > > > > In addition, perhaps we should make sysconfdir have '/dillo' at the end. > > > > If I look in an etc dir and see dillorc, I'd know what it's for, > > > > but I wouldn't know what uses keysrc. > > > > > > Yes, a '/dillo' suffix looks OK. > > > Please merge both ideas and commit. > > > > I defined a DILLO_SYSCONF instead of DILLORC_SYS > > so that a system keysrc will work someday. > > Please test. > > dillorc and dpidrc got into "/usr/local/etc". > (I was expecting them in "/usr/local/etc/dillo"). Was a new 'configure' generated? I get: test -z "/usr/local/etc/dillo" || mkdir -p -- "/usr/local/etc/dillo" list='dillorc'; for p in $list; do \ if test -f "$p"; then d=; else d="./"; fi; \ f=`echo $p | sed -e 's|^.*/||'`; \ echo " /usr/bin/ginstall -c -m 644 '$d$p' '/usr/local/etc/dillo/$f'"; \ /usr/bin/ginstall -c -m 644 "$d$p" "/usr/local/etc/dillo/$f"; \ done

June 7, 2009

[PATCH] fix dillorc path

by Johannes.Hofmann＠gmx.de

On Sun, Jun 07, 2009 at 12:34:31PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 07, 2009 at 02:08:22AM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > > > Paul wrote: > > > > > When opening dillo from the CLI I noticed the following message: > > > > > > > > > > paths: Cannot open file '/home/user/.dillo/dillorc' > > > > > paths: Cannot open file '/etc/dillo/dillorc' > > > > > paths: Using internal defaults... > > > > > > > > > > Checked my system and saw that dillorc had been installed > > > > > in /usr/etc/dillorc > > > > > > > > > > Checking config.log showed sysconfdir='${prefix}/etc', so no > > > > > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > > > > > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > > > > > as specified in src/Makefile.am, instead. Now all is fine! > > > > > > > > In addition, perhaps we should make sysconfdir have '/dillo' at the end. > > > > If I look in an etc dir and see dillorc, I'd know what it's for, > > > > but I wouldn't know what uses keysrc. > > > > > > Yes, a '/dillo' suffix looks OK. > > > Please merge both ideas and commit. > > > > I defined a DILLO_SYSCONF instead of DILLORC_SYS > > so that a system keysrc will work someday. > > Please test. > > dillorc and dpidrc got into "/usr/local/etc". > (I was expecting them in "/usr/local/etc/dillo"). Works fine for me. Did you call ./autogen.sh before configuring/ compiling? Cheers, Johannes

June 7, 2009

two image problems

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Some websites seems to send images with a charset set in the header, > > e.g: Content-Type: image/jpeg;charset=ISO-8859-1 > > In that case dillo seems to decode the data resulting in: > > Not a JPEG file: starts with 0xc3 0xbf > > Not sure whether we can/want to do anything about that. > > It seems like it would make sense to restrict decoding to text/*. > I'll look in the rfc to see whether it says something relevant. Fix committed. RFC 2046 defines a charset parameter for text/* (and it's also mentioned in the RFCs for text/html and text/css media types). Nothing mentions any parameters defined for image/*, or for the specific image types that dillo displays. Interestingly, I learned of RFC 5147, which is a proposed standard involving URI fragments and text/plain: http://tools.ietf.org/html/rfc5147#section-5

June 7, 2009

[PATCH] fix dillorc path

by jcid＠dillo.org

On Sun, Jun 07, 2009 at 02:08:22AM +0000, corvid wrote: > Jorge wrote: > > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > > Paul wrote: > > > > When opening dillo from the CLI I noticed the following message: > > > > > > > > paths: Cannot open file '/home/user/.dillo/dillorc' > > > > paths: Cannot open file '/etc/dillo/dillorc' > > > > paths: Using internal defaults... > > > > > > > > Checked my system and saw that dillorc had been installed > > > > in /usr/etc/dillorc > > > > > > > > Checking config.log showed sysconfdir='${prefix}/etc', so no > > > > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > > > > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > > > > as specified in src/Makefile.am, instead. Now all is fine! > > > > > > In addition, perhaps we should make sysconfdir have '/dillo' at the end. > > > If I look in an etc dir and see dillorc, I'd know what it's for, > > > but I wouldn't know what uses keysrc. > > > > Yes, a '/dillo' suffix looks OK. > > Please merge both ideas and commit. > > I defined a DILLO_SYSCONF instead of DILLORC_SYS > so that a system keysrc will work someday. > Please test. dillorc and dpidrc got into "/usr/local/etc". (I was expecting them in "/usr/local/etc/dillo"). -- Cheers Jorge.-

June 7, 2009

two image problems

by corvid＠lavabit.com

Johannes wrote: > I noticed two problems related to images: > > Some websites seems to send images with a charset set in the header, > e.g: Content-Type: image/jpeg;charset=ISO-8859-1 > In that case dillo seems to decode the data resulting in: > Not a JPEG file: starts with 0xc3 0xbf > Not sure whether we can/want to do anything about that. It seems like it would make sense to restrict decoding to text/*. I'll look in the rfc to see whether it says something relevant. It might be good to have text decoded outside of cache to UTF-8 in the same way that images are decoded outside of cache to RGB. (Right now that would be a problem with view src using getbuf, and perhaps for text/css following @charset="..." eventually, but still it would be nice to have one way of doing things.) Speaking of the rfc, I noticed just recently that it says "The value of Content-Location also defines the base URI for the entity." and I wonder whether that's ever a problem in practice because dillo makes no use of this header. > I don't understand the other problem: > http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg > loads and displays fine. > from html however it doesn't work > <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" /> When you load it by itself, dillo follows the redirection to http://szmimg.sueddeutsche.de/upl/images/user/8059/17337.jpg

June 7, 2009

two image problems

by Johannes.Hofmann＠gmx.de

Hi, I noticed two problems related to images: Some websites seems to send images with a charset set in the header, e.g: Content-Type: image/jpeg;charset=ISO-8859-1 In that case dillo seems to decode the data resulting in: Not a JPEG file: starts with 0xc3 0xbf Not sure whether we can/want to do anything about that. I don't understand the other problem: http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg loads and displays fine. from html however it doesn't work <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" /> Cheers, Johannes

June 7, 2009

[PATCH] fix dillorc path

by corvid＠lavabit.com

Jorge wrote: > On Thu, Jun 04, 2009 at 06:26:40PM +0000, corvid wrote: > > Paul wrote: > > > When opening dillo from the CLI I noticed the following message: > > > > > > paths: Cannot open file '/home/user/.dillo/dillorc' > > > paths: Cannot open file '/etc/dillo/dillorc' > > > paths: Using internal defaults... > > > > > > Checked my system and saw that dillorc had been installed > > > in /usr/etc/dillorc > > > > > > Checking config.log showed sysconfdir='${prefix}/etc', so no > > > surprises there. But Paths::getPrefsFP() in src/paths.cc uses > > > PATHS_RC_SYS, which is "/etc/dillo/", so my patch uses DILLORC_SYS, > > > as specified in src/Makefile.am, instead. Now all is fine! > > > > In addition, perhaps we should make sysconfdir have '/dillo' at the end. > > If I look in an etc dir and see dillorc, I'd know what it's for, > > but I wouldn't know what uses keysrc. > > Yes, a '/dillo' suffix looks OK. > Please merge both ideas and commit. I defined a DILLO_SYSCONF instead of DILLORC_SYS so that a system keysrc will work someday. Please test.

June 7, 2009

form widgets, ascent/descent

by jcid＠dillo.org

On Thu, Jun 04, 2009 at 06:11:43PM +0000, corvid wrote: > I was playing around in dw, and noticed that, > whereas form widgets normally like to put > much of their height into descent, when style > sets the height, Textblock::calcWidgetSize() > puts it all into ascent. > > I checked firefox and saw that their form widgets ascend. > > If we made everything ascend and just put font->descent > into the descent, it would make life simpler. > Or, nearly. I guess there is RELIEF_Y_THICKNESS, but I > could almost ignore that... Not knowing exactly about the details, I'd be very careful in changing ascents, descents and friends because the may interfere with correct handling of CSS. If you're sure it's OK to do it, even considering the "details" (e.g. reliefs, spacings, paddings), then why not. -- Cheers Jorge.-

June 7, 2009