- Dillo-dev - lists.mailman3.com

dillo 2.2 rpms?

by Johannes.Hofmann＠gmx.de

On Fri, Feb 19, 2010 at 08:31:14PM -0800, Globe Trotter wrote: > --- On Thu, 2/18/10, corvid <corvid(a)lavabit.com> wrote: > > > From: corvid <corvid(a)lavabit.com> > > Subject: Re: [Dillo-dev] dillo 2.2 rpms? > > To: dillo-dev(a)dillo.org > > Date: Thursday, February 18, 2010, 12:25 AM > > 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... > > > > So, will there be rpms or .debs for Fedora 12/Ubuntu/Debian and the like soon? Until now rpms, .debs and so on were built by volunteers running these systems. Also some distros have dillo in their official packages - but it usually takes time to get new versions in. For this release we did not get any feedback from our usual packagers, so no packages are on the horizon. I might setup something on http://de.opensuse.org/Build_Service but only if I get working spec files. Cheers, Johannes

Feb. 21, 2010

fltk font issue

by Johannes.Hofmann＠gmx.de

On Thu, Feb 18, 2010 at 04:20:40PM +0000, corvid 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. > > 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. I don't understand all the details especially whether it is ok to return without assigning anything to current. But it might be good to suggest the fix on the fltk list.

Feb. 21, 2010

View source

by Johannes.Hofmann＠gmx.de

On Sat, Feb 20, 2010 at 04:35:01PM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 18, 2010 at 07:08:50PM +0100, Johannes Hofmann wrote: > > 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. > > Yes, storing the viewed URI in the viewsource URI helps. > > > * 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. > > I don't know. > > The trick to make line numbers follow wrapped lines is to have > a shared the row, which OTOH includes line numbers in copy/paste. Ah ok. > > > > * 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 > > A common style (or colors at least) sounds sensible. > > I'm happy with bookmarks as they are, but is no surprise as I > coded them. Mine is very fast and < 28 KB, I assume yours is much > bigger. In that case I'd prefer to have both options in the same > dpi code (like viewsource, but configurable with an rc file). The point is not rendering speed. It's fast enough :) I was rather thinking about reducing complexity by separating content and style using CSS. The look could be basically the same as currently, but of course there might be some differences regarding wrapping and so on. Perhaps some web designer could help here? > > > > * Can we change "View Stylesheets" to also use the new DPI? > > Yes, and also "page bugs", and then get rid of FLTK's > TextDisplay widget. Yes, that would be cool. Maybe even links from page bugs to the corresponding line in view source. Cheers, Johannes

Feb. 21, 2010

View source

by jcid＠dillo.org

On Thu, Feb 18, 2010 at 07:08:50PM +0100, Johannes Hofmann wrote: > 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. Yes, storing the viewed URI in the viewsource URI helps. > * 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. I don't know. The trick to make line numbers follow wrapped lines is to have a shared the row, which OTOH includes line numbers in copy/paste. > * 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 A common style (or colors at least) sounds sensible. I'm happy with bookmarks as they are, but is no surprise as I coded them. Mine is very fast and < 28 KB, I assume yours is much bigger. In that case I'd prefer to have both options in the same dpi code (like viewsource, but configurable with an rc file). > * Can we change "View Stylesheets" to also use the new DPI? Yes, and also "page bugs", and then get rid of FLTK's TextDisplay widget. -- Cheers Jorge.-

Feb. 20, 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. Committed an interim patch that shows how it could feel. Additionally disabled view source's source and view source reload. The latter one may be necessary; I'm not sure. -- Cheers Jorge.-

Feb. 20, 2010

dillo 2.2 rpms?

by itsme_410＠yahoo.com

--- On Thu, 2/18/10, corvid <corvid(a)lavabit.com> wrote: > From: corvid <corvid(a)lavabit.com> > Subject: Re: [Dillo-dev] dillo 2.2 rpms? > To: dillo-dev(a)dillo.org > Date: Thursday, February 18, 2010, 12:25 AM > 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... > So, will there be rpms or .debs for Fedora 12/Ubuntu/Debian and the like soon? Best, T

Feb. 20, 2010

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