- Dillo-dev - lists.mailman3.com

configure.in -Wno-unused-parameter

by jcid＠dillo.org

On Sun, May 15, 2011 at 10:34:00PM +0000, corvid wrote: > > if eval "test x$GCC = xyes"; then > .. > if test "`echo $CFLAGS | grep '\-W[^a]' 2> /dev/null`" = ""; then > if test "`$CC -v 2>&1 | grep 'version 3'`" != ""; then > CFLAGS="$CFLAGS -W -Wno-unused-parameter" > fi > fi > .. > fi > > It checks for 3.x specifically. > 3.0 came out on June 18, 2001. > > And of course 4.x has been out since...let's see...April 20, 2005. > > 2.95 was still apparently around back in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-December/001565.html , > which prompted this code at the time. > > Can I rip out the version-checking and make it into an ordinary > case of adding the argument if it isn't already in CFLAGS? Sure. -- Cheers Jorge.-

May 16, 2011

What's currently broken in... (Re: [Dillo-dev] 1.3 port)

by jcid＠dillo.org

On Sun, May 15, 2011 at 09:04:43PM +0200, Johannes Hofmann wrote: > On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote: > > > > - the preferred font code in dillo.cc. Necessary. > > - drawing with nested layouts Just managed to make the complex button draw right. I'm testing now. > > - page/tab titles Simple. > > - When scrolling with the keyboard, with buffered_drawing 0 or 1, > > tooltips leave grey boxes. Also in dillo2. > > - OSX. I believe Johannes tried it once, and there was something going > > wrong with iowatch. > > Yes, somehow the add_fd() and add_idle() stuff doesn't seem to work > on OSX. Either it's an fltk bug or we use it ways that are not > expected. FWIW, sometime ago I compiled and run dillo-2 in OSX with no such problem. > Here are my current issues with the fltk-1.3 port: > > - The toolbar in the initial tab is too high (with dwm in tiling > mode). Further tabs have correctly sized toolbars. This puzzles me. > - Ctrl-Tab doesn't cycle through tabs. I really miss that. Simple enough to fix. ;) > - There is a tab title even if there is only one tab. Yeah, this could take a few days. > - The keyboard shortcuts for text input fields have changed (I use > Ctrl-A (jump to beginning) Ctrl-K (kill until end of line) and > Ctrl-E (jump to end of line). > This seems to be intentional from fltk side. > Any opinions whether we should change this back to the fltk2 > behaviour? I miss them badly and several times have considered re-adding those keybindings. :-) Maybe next week. > - There are still a bit more redraws than with fltk2 dillo. Yes. BTW, have the last patches made a difference for you? -- Cheers Jorge.-

May 16, 2011

configure.in -Wno-unused-parameter

by corvid＠lavabit.com

if eval "test x$GCC = xyes"; then .. if test "`echo $CFLAGS | grep '\-W[^a]' 2> /dev/null`" = ""; then if test "`$CC -v 2>&1 | grep 'version 3'`" != ""; then CFLAGS="$CFLAGS -W -Wno-unused-parameter" fi fi .. fi It checks for 3.x specifically. 3.0 came out on June 18, 2001. And of course 4.x has been out since...let's see...April 20, 2005. 2.95 was still apparently around back in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-December/001565.html , which prompted this code at the time. Can I rip out the version-checking and make it into an ordinary case of adding the argument if it isn't already in CFLAGS?

May 16, 2011

What's currently broken in... (Re: [Dillo-dev] 1.3 port)

by Johannes.Hofmann＠gmx.de

On Sun, May 15, 2011 at 06:15:35PM +0000, corvid wrote: > > - the preferred font code in dillo.cc. > - drawing with nested layouts > - page/tab titles > - When scrolling with the keyboard, with buffered_drawing 0 or 1, > tooltips leave grey boxes. > > - OSX. I believe Johannes tried it once, and there was something going > wrong with iowatch. Yes, somehow the add_fd() and add_idle() stuff doesn't seem to work on OSX. Either it's an fltk bug or we use it ways that are not expected. Here are my current issues with the fltk-1.3 port: - The toolbar in the initial tab is too high (with dwm in tiling mode). Further tabs have correctly sized toolbars. - Ctrl-Tab doesn't cycle through tabs. I really miss that. - There is a tab title even if there is only one tab. - The keyboard shortcuts for text input fields have changed (I use Ctrl-A (jump to beginning) Ctrl-K (kill until end of line) and Ctrl-E (jump to end of line). This seems to be intentional from fltk side. Any opinions whether we should change this back to the fltk2 behaviour? - There are still a bit more redraws than with fltk2 dillo. Cheers, Johannes

May 15, 2011

What's currently broken in... (Re: [Dillo-dev] 1.3 port)

by corvid＠lavabit.com

- the preferred font code in dillo.cc. - drawing with nested layouts - page/tab titles - When scrolling with the keyboard, with buffered_drawing 0 or 1, tooltips leave grey boxes. - OSX. I believe Johannes tried it once, and there was something going wrong with iowatch.

May 15, 2011

next release of dillo?

by corvid＠lavabit.com

Globe Trotter wrote: > --- On Sun, 5/1/11, corvid <corvid(a)lavabit.com> wrote: > > > From: corvid <corvid(a)lavabit.com> > > Subject: Re: [Dillo-dev] next release of dillo? > > To: Dillo-dev(a)dillo.org > > Date: Sunday, May 1, 2011, 1:18 AM > > Globe Trotter wrote: > > > just wondering when the next release of dillo will be, > > i.e. if there is a planned timeline? we appear to be at > > dillo2.2 for a while now? > > > > IIRC, maybe a month or two ago, Jorge wanted to wait until > > FLTK 1.3 > > was released before making any Dillo releases at all, but > > it seems > > that users find fltk bugs at the same rate that developers > > fix them > > ( http://fltk.org/roadmap.php#1.3 ), so... > > > > so it appears that there are now no bugs listed on that webpage, so perhaps the releases of fltk1.3 and dillo 1.3 are imminent? They just put rc 5 out (discussion at http://fltk.org/newsgroups.php?gfltk.general+T , code at http://fltk.org/software.php ). All are encouraged to test it out! I'm not sure that anyone could promise dillo3 being _imminent_, exactly, but it suddenly seems like something that will happen in the foreseeable future, at least :)

May 15, 2011

next release of dillo?

by itsme_410＠yahoo.com

--- On Sun, 5/1/11, corvid <corvid(a)lavabit.com> wrote: > From: corvid <corvid(a)lavabit.com> > Subject: Re: [Dillo-dev] next release of dillo? > To: Dillo-dev(a)dillo.org > Date: Sunday, May 1, 2011, 1:18 AM > Globe Trotter wrote: > > just wondering when the next release of dillo will be, > i.e. if there is a planned timeline? we appear to be at > dillo2.2 for a while now? > > IIRC, maybe a month or two ago, Jorge wanted to wait until > FLTK 1.3 > was released before making any Dillo releases at all, but > it seems > that users find fltk bugs at the same rate that developers > fix them > ( http://fltk.org/roadmap.php#1.3 ), so... > so it appears that there are now no bugs listed on that webpage, so perhaps the releases of fltk1.3 and dillo 1.3 are imminent?

May 15, 2011

What's currently broken in... (Re: [Dillo-dev] 1.3 port)

by jcid＠dillo.org

On Thu, May 12, 2011 at 01:53:48PM -0400, Jorge Arellano Cid wrote: > On Thu, May 12, 2011 at 05:28:51PM +0000, corvid wrote: > > Jorge wrote: > > > BTW, this patches also contain scrollbar bugfixes. > > > > I see that the setSizeHints bug is also in dillo2. > > I wonder whether it had any effect that I just don't remember now. > > FWIW I'm working on a patch that reduces redraw flicker > dramatically. Committed now. -- Cheers Jorge.-

May 13, 2011

dillo_port1.3 - dpid not starting

by darkspirit5000＠gmail.com

Sorry for my english. dpid uses the dpi_dir line at dpidrc file to find system wide DPIs dir. It try ~/.dillo/dpi/ for user wide DPIs.(after or before system wide ones. I do not remember) I have this start line in dpidrc: dpi_dir=/usr/local/lib/dillo/dpi I agree dpid should use the correct prefix for system wide DPIs, but i do not know configure enough. For reference: To bind a service with a DPI dpid uses dpidrc and for backward compatibility ~/.dillo/dpi/<service>/*.[filter].dpi or <dpi_dir>/<service>/*.[filter].dpi (If i remember right) the servicces that dillo ask to dpid (currently) are: - "bm" or "bookmarks" for bookmarks - "cookies" for cookies - "vsource" for view source - "proto.%p" for unhandled protocol - etc The lines at dpidrc have this format: <service_name>[*]=<relative or parcial (last part) path to DPI/>DPI_name.[filter].dpi '*' have special meaning after service name and match not handled services that start with service_name i have some lines like this in my dpidrc: ---------------------------------- proto.ftp=ftp.filter.dpi proto.https=https.filter.dpi proto.file=file.dpi proto.data=datauri.filter.dpi proto.abc=hello.filter.dpi # debug prefs DPI fast with p: proto.p=prefs.dpi # handler for not handled protocols #proto.*=hello.filter.dpi # handler for dpi:/@/ #(a)=hello.filter.dpi # someone forgot the start slash in dpi:foo/ (only at url bar) #proto.dpi=hello.filter.dpi # default handler for dpi:/without_ending_slash #?=hello.filter.dpi # never use or all services will be handled whith this dpi # *=hello.filter.dpi ---------------------------------- If some one write a gopher DPI (only implement open_url DPIP command) only need to add this to dpidrc file: proto.gopher=[path/]<gopher>.[filter].dpi If some one write another bookmarks DPI use: bookmarks=[path/]<new_bm>.[filter].dpi etc for downloads, etc ... I personally think about DPI infrastructure that: - need better docs (part my fault) - is fragile - dpid is too big and have legacy code - infrastructure simplification will be good But unknown how and it currently works Diego. 2011/5/13, Roger <rogerx.oss(a)gmail.com>: >> On Fri, May 13, 2011 at 08:12:40AM -0400, Jorge Arellano Cid wrote: >>Hi, >> >>>On Thu, May 12, 2011 at 07:56:32PM -0800, Roger wrote: > >>> (EMail seems to be being blocked. Resending.) >> >> It arrived here with more than a hundred of whitespace trailing >>most text lines... > > Sorry. I copy/pasted using screen and vi editor (within Mutt). It looked > fine > here -- so first I've heard/seen this. Quite possible it was because I was > using Mutt for GMail. > > >>> dpi_read_comm_keys file not found is likely the problem. >>> >>> After dpid is started: >>> >>> ~/src/dillo $ install/bin/dillo >>> dillo_dns_init: Here we go! (threaded) >>> Enabling cookies as from cookiesrc... >>> Nav_open_url: new url='dpi:/bm/' >>> ** ERROR **: [Dpi_read_comm_keys] No such file or directory >> >> This is not a show-stopper. If dillo can't read the file, most >>probably there's no dpid running, so dillo tries to start it... >> >>> Dpi_blocking_start_dpid: try 1 >> >> this is dillo's try to start dpid. >> >>> [dpid]: a_Misc_mksecret: 1423de10 >>> >>> >>> dpid started >>> >>> >> >> and it starts. >> >>> Dpi_get_server_port: can't read server port from dpid. >>> >>> >>> ** ERROR **: dpi.c: can't start dpi daemon >> >> This happens when dpid can't either start the requested dpi nor >>get an answer from it (bookmarks.dpi in this case). >> >> I was able to reproduce it by deleting the bookmarks.dpi >>binary. >> >> dpid checks both: >> >> 1) ~/.dillo/dpi/file/ >> 2) /usr/local/lib/dillo/dpi/<dpiname>/<dpiname>.dpi >> >> so you should check what's going on there. > > Dillo should pickup /usr/local/lib/dillo/dpi from ${PREFIX}/lib/dillo/dpi > via > "./configure --prefix=/blah/blah". Correct? > > (I've prefixed /home/roger/src/dillo/install, to keep CVS/SVN installs > separate > from the system packages to prevent unowned files on the system. I've never > run into a program that didn't obey the --prefix assignment yet. I have yet > to > verify Dillo is missing /lib/dillo/dpi here. When I do, I'll follow-up to > this.) > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 13, 2011

dillo_port1.3 - dpid not starting

by rogerx.oss＠gmail.com

> On Fri, May 13, 2011 at 08:12:40AM -0400, Jorge Arellano Cid wrote: >Hi, > >>On Thu, May 12, 2011 at 07:56:32PM -0800, Roger wrote: >> (EMail seems to be being blocked. Resending.) > > It arrived here with more than a hundred of whitespace trailing >most text lines... Sorry. I copy/pasted using screen and vi editor (within Mutt). It looked fine here -- so first I've heard/seen this. Quite possible it was because I was using Mutt for GMail. >> dpi_read_comm_keys file not found is likely the problem. >> >> After dpid is started: >> >> ~/src/dillo $ install/bin/dillo >> dillo_dns_init: Here we go! (threaded) >> Enabling cookies as from cookiesrc... >> Nav_open_url: new url='dpi:/bm/' >> ** ERROR **: [Dpi_read_comm_keys] No such file or directory > > This is not a show-stopper. If dillo can't read the file, most >probably there's no dpid running, so dillo tries to start it... > >> Dpi_blocking_start_dpid: try 1 > > this is dillo's try to start dpid. > >> [dpid]: a_Misc_mksecret: 1423de10 >> dpid started > > and it starts. > >> Dpi_get_server_port: can't read server port from dpid. >> ** ERROR **: dpi.c: can't start dpi daemon > > This happens when dpid can't either start the requested dpi nor >get an answer from it (bookmarks.dpi in this case). > > I was able to reproduce it by deleting the bookmarks.dpi >binary. > > dpid checks both: > > 1) ~/.dillo/dpi/file/ > 2) /usr/local/lib/dillo/dpi/<dpiname>/<dpiname>.dpi > > so you should check what's going on there. Dillo should pickup /usr/local/lib/dillo/dpi from ${PREFIX}/lib/dillo/dpi via "./configure --prefix=/blah/blah". Correct? (I've prefixed /home/roger/src/dillo/install, to keep CVS/SVN installs separate from the system packages to prevent unowned files on the system. I've never run into a program that didn't obey the --prefix assignment yet. I have yet to verify Dillo is missing /lib/dillo/dpi here. When I do, I'll follow-up to this.)

May 13, 2011