February 2010 - Dillo-dev - lists.mailman3.com

configure.in and libpng-1.4

by jcid＠dillo.org

On Fri, Feb 19, 2010 at 09:55:14PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Feb 19, 2010 at 09:41:54PM +0000, corvid wrote: > > > I would strongly prefer to rip out most of that `which` stuff and > > > just look for libpng-config. Does anyone know that this would be a > > > bad idea? Whatever libpng-config is symlinked to is presumably what > > > the user wants us to use... > > > > AFAIR this has been hard to get working for all cases. Libpng > > is quite tricky on different platforms. > > > > Beware of the sleeping dragon! > > Do you remember any details? I poked around in good old cvs and > the list archives, and there wasn't really any information preserved. I remember some OSes had the new version of libpng but no libpng-config. Other systems had both versions of libpng installed and an environment variable helped to choose which one to link against. Ah, almost forgot, different systems had different names for libpng-config (hence the which statements). If you want to try a different approach to png detection, people usually start complaining once the patch is committed, or later at release time. :) -- Cheers Jorge.-

Feb. 20, 2010

configure.in and libpng-1.4

by corvid＠lavabit.com

Jorge wrote: > On Fri, Feb 19, 2010 at 09:41:54PM +0000, corvid wrote: > > I would strongly prefer to rip out most of that `which` stuff and > > just look for libpng-config. Does anyone know that this would be a > > bad idea? Whatever libpng-config is symlinked to is presumably what > > the user wants us to use... > > AFAIR this has been hard to get working for all cases. Libpng > is quite tricky on different platforms. > > Beware of the sleeping dragon! Do you remember any details? I poked around in good old cvs and the list archives, and there wasn't really any information preserved.

Feb. 19, 2010

configure.in and libpng-1.4

by jcid＠dillo.org

On Fri, Feb 19, 2010 at 09:41:54PM +0000, corvid wrote: > I committed a safe fix for libpng-1.4, but it means that configure.in > currently has: > > dnl Check if the user hasn't set the variable $PNG_CONFIG > if test -z "$PNG_CONFIG"; then > PNG_CONFIG=`which libpng14-config` > if test -z "$PNG_CONFIG"; then > PNG_CONFIG=`which libpng12-config` > fi > if test -z "$PNG_CONFIG"; then > PNG_CONFIG=`which libpng-config` > fi > if test -z "$PNG_CONFIG"; then > PNG_CONFIG=`which libpng10-config` > fi > fi > > and > case $png_version in > 1.4.*) AC_MSG_RESULT([$png_version (newer version)]) ;; > 1.2.*) AC_MSG_RESULT([$png_version (newer version)]) ;; > 1.0.*) AC_MSG_RESULT([$png_version (older version)]) ;; > *) AC_MSG_RESULT([ERROR]) ;; > esac > > I would strongly prefer to rip out most of that `which` stuff and > just look for libpng-config. Does anyone know that this would be a > bad idea? Whatever libpng-config is symlinked to is presumably what > the user wants us to use... AFAIR this has been hard to get working for all cases. Libpng is quite tricky on different platforms. Beware of the sleeping dragon! -- Cheers Jorge.-

Feb. 19, 2010

configure.in and libpng-1.4

by corvid＠lavabit.com

I committed a safe fix for libpng-1.4, but it means that configure.in currently has: dnl Check if the user hasn't set the variable $PNG_CONFIG if test -z "$PNG_CONFIG"; then PNG_CONFIG=`which libpng14-config` if test -z "$PNG_CONFIG"; then PNG_CONFIG=`which libpng12-config` fi if test -z "$PNG_CONFIG"; then PNG_CONFIG=`which libpng-config` fi if test -z "$PNG_CONFIG"; then PNG_CONFIG=`which libpng10-config` fi fi and case $png_version in 1.4.*) AC_MSG_RESULT([$png_version (newer version)]) ;; 1.2.*) AC_MSG_RESULT([$png_version (newer version)]) ;; 1.0.*) AC_MSG_RESULT([$png_version (older version)]) ;; *) AC_MSG_RESULT([ERROR]) ;; esac I would strongly prefer to rip out most of that `which` stuff and just look for libpng-config. Does anyone know that this would be a bad idea? Whatever libpng-config is symlinked to is presumably what the user wants us to use...

Feb. 19, 2010

View source

by Johannes.Hofmann＠gmx.de

Hi, On Wed, Feb 17, 2010 at 02:33:26PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Just committed a patch for "view source" as a filter dpi. The > source is simple and is well commented. There're three modes: > plain text, numbered plain text, numbered html. The latter one is > the default. Just give the source a look to change modes. > > It is very simple to tweak and improve. I remember somebody > asked for "view source" in a favorite editor. From the dpi is > simple. e.g. save to /tmp/source.txt and execl your editor. > > Comments, patches, cool styles, etc are welcomed. Very nice indeed! Here come some random thoughts: * Some time ago we thought about using a common URI scheme for view source: http://en.wikipedia.org/wiki/View-source_URI_scheme Maybe it's worth a look again. * Would it be possible to use a table in HTML so that one can cut/paste source without the line numbers? Not sure how that affects the rendering performance. * It would be nice to unify the look'n feel of the various autogenerated HTML in dillo: * splash screen * directory listings * bookmarks * and now view source I would propose to simplify the HTML as much as possible (e.g. just <ul>'s for bookmarks and have a single common CSS snipplet in a single header file that is included by the various DPIs. Hopefully some webdesigner could then adapt this CSS to make things look nice. Also it would be handy to have some "id=dillo_bla" attribute in each of the pages so that users can change the look of bookmarks or view source individually in their ~/.dillo/style.css * Can we change "View Stylesheets" to also use the new DPI? Cheers, Johannes

Feb. 18, 2010

fltk font issue

by corvid＠lavabit.com

I wrote: > A few weeks ago, bug 940 was added. A segfault. The submitter gets > it with Tiny Core. I don't see it with my non-TC setup, so I asked > Colin about it. He suspected that it had to do with TC's dearth of > fonts. Just remembered Colin reproduced the crash with xft disabled. So this might still be a fltk font problem, but if so, not the same exact one.

Feb. 18, 2010

View source

by jcid＠dillo.org

On Thu, Feb 18, 2010 at 05:21:53AM +0000, corvid wrote: > In the new tab opened by view source, I pasted in a new URL, > clicked some link in it, then pressed back twice. > Dillo was actively trying to load, but apparently not receiving anything. > Then I clicked forward and got a segfault in the dpi. > The core file says it died in the strtol(). > > Repeated my steps and got the same result. Yes, this is an interesting problem... I'm thinking of the alternatives. -- Cheers Jorge.-

Feb. 18, 2010

fltk font issue

by corvid＠lavabit.com

A few weeks ago, bug 940 was added. A segfault. The submitter gets it with Tiny Core. I don't see it with my non-TC setup, so I asked Colin about it. He suspected that it had to do with TC's dearth of fonts. http://www.fltk.org/str.php?L2319 was added yesterday, and is about someone with dillo-2.2 getting font crashes. fltk::setfont() calling fontopen(), which gets NULL from XftFontOpen() (as the manpage says can happen). Since this is a fltk2 thing, I think this will fall to us to fix. As for whether we simply want to stick something like if (!xftfont) return; after the fontopen() call, or we want to try harder in some way, I don't know yet.

Feb. 18, 2010

dillo 2.2 rpms?

by corvid＠lavabit.com

T wrote: > Any plan to release 32-bit and 64-bit RPMs of dillo 2.2 for Fedora 12? I haven't heard anything about packages from anyone at all yet, which surprises me...

Feb. 18, 2010

View source

by corvid＠lavabit.com

In the new tab opened by view source, I pasted in a new URL, clicked some link in it, then pressed back twice. Dillo was actively trying to load, but apparently not receiving anything. Then I clicked forward and got a segfault in the dpi. The core file says it died in the strtol(). Repeated my steps and got the same result.

Feb. 18, 2010