- Dillo-dev - lists.mailman3.com

slashdot site not rendered correctly...

by thestar

What's wrong with this site? http://yro.slashdot.org/yro/02/10/24/1335223.shtml?tid=141

April 14, 2003

Bookmarks menu?

by Lars Clausen

Whatever happened to my bookmarks menu in 0.7? I have the bookmarks button which opens the bookmarks page, but I really prefer the menu as it doesn't disturb my pages. Is there an option to turn it on somewhere? Some other way? I still see it in the screenshots on the Dillo pages, are they just too old? -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor "I do not agree with a word that you say, but I |---------------------------- will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?

April 11, 2003

dillo mailer ...

by Lars Segerlund

I am trying to make a mail plugin for dillo, and have started off looking at the bookmarks, would it be correct to assume that interface.c is the right place to start looking for getting the button into the menu ? Are there any things to look out for ? ( stumble on ). Am I correct to assume that plugins have to be compiled in as for now ? ( ie. there is no dynamically loaded plugins ? ) / Lars Segerlund.

April 11, 2003

Re: [Dillo-dev] Re: configuration patch - Fix for bugs 386, 407, 392, 412 and notes on bugs 349, 408

by Andreas Schweitzer

Hi, > Andreas, > (and /usr/local savvy guys!) Well, I hope somebody else knows more ... :-) > > > Please tell me how things have gone. Basically I'm waiting for > > > these issues to be solved to make the 0.7.2 release. > > > > With the current version it does no longer work *quite* out of > > the box on the BSD's. It will work when doing a > > CPPFLAGS=/usr/local/include LDFLAGS=/usr/local/lib ./configure > > but this is not what I call out of the box :-). > > I'm not an expert in tunning the system's directories, but I > wonder why if /usr/local has part of the system, it is not > included in the search path in BSDs. Doesn't make sense to me > (nut I don't know much here). All right, in terms of reasoning and well thought systems, I prefer OpenBSD, hence I did a google search and came across this lengthy discussion : http://www.netsys.com/openbsd-tech/1996/02/msg00019.html and follow-ups !!!! But other than that .... > OTOH, for instance, /usr/local is not a part of the system in > Slackware, and I can't find it with: `gcc -print-search-dirs`. Actually, I think gcc -print-search-dirs is not the way to find out about the inclusion of /usr/local - it doesn't show on any system I have. Try cpp -v </dev/null instead. In fact, I think, that should be used in the test instead of what I submitted earlier ... oh well ;-) I just tested ---- start patch ---- $ cvs diff -c configure.in cvs diff: failed to open /home/darkstar/andy/.cvspass for reading: No such file or directory Index: configure.in =================================================================== RCS file: /sfhome/cvs/dillo/dillo/configure.in,v retrieving revision 1.49 diff -c -r1.49 configure.in *** configure.in 10 Apr 2003 20:12:44 -0000 1.49 --- configure.in 10 Apr 2003 23:47:08 -0000 *************** *** 28,33 **** --- 28,38 ---- AC_PROG_CC AM_PROG_CC_STDC AC_PROG_RANLIB + AC_PROG_CPP + if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`" ; then + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + LDFLAGS="$LDFLAGS -L/usr/local/lib" + fi dnl ----------------------------------- dnl Check for Gtk+ (it checks glib too) ---- end patch ---- to work correctly so far. I hope that patch in the middle of the e-mail is ok ... > Doubts started when I received this mail, from Manuel Menal: > [mmenal at hurdfr.org] <snip> > output. If there is some output, then it assumes there is no > jpeglib.h. Which is not true in this case: the output is just warning > of cpp, which complains about the -I/usr/local/include (cpp 3.1 > already has /usr/local/include it its system directories). I think the problem there is a mixup of stdout and stderr. On one Linux system (Suse), I do get the warning, but it still detects jpeglib.h Another system does include /usr/local by default, as well (Archlinux), but does not give any warning in config.log .... beats me. > Thinking that /usr/local was for extensions, I decided to > remove the forced include from configure.in. > > Can anyone shed some light on this topic? Not more that my google results from above. Personally, I think we should indeed check if /usr/local is in the gcc definition or not and react accordingly. > > > The png.h stuff is more or less my original solution :-) ... > > there was a reason for that convoluted approach ... :-) > > Yes, I added the break clause because it tested libpng twice > and added two "-lpng" in my system. > > I'll commit the patch as you sent here (which BTW, includes the > "break"). Yes, I did leave the "break" intentionally ! I just wasn't quite clear about the usage of "break". BTW, in my previous mail I promised to test on OpenBSD : success. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

April 10, 2003

Re: [Dillo-dev] Missing favorite features

by Lars Clausen

On Thu, 10 Apr 2003, Niklas Höglund wrote: > I'd also like to "me too" on the issue of connecting dillo to external > applications for unknown filetypes and protocols. I don't think dillo > should handle ftp, for example, or PDF. gftp and xpdf should do that. > However, I think something more than "nothing" should happen when you > click on something unsupported... Me three. I recently checked out 0.7, and while the highlighting of selected text is cool, the external viewer patch I have on 0.6.7 is more important to me, so I'm sticking with that for now. It's somewhat of a hack, though, and has some strange effects on occasion. The way I'd handle it with the dpi structure is this: There should be a meta-plugin that handles all otherwise unhandled file types. This plugin should gather possible viewers from /etc/mailcap (or other places) and ask the user what he or she wants to use. The user should have the option of storing the choice, in which case a new specific handler should be installed (persistently) that handles that choice. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor "I do not agree with a word that you say, but I |---------------------------- will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?

April 10, 2003

Re: [Dillo-dev] Re: configuration patch - Fix for bugs 386, 407, 392, 412 and notes on bugs 349, 408

by Jorge Arellano Cid

Andreas, (and /usr/local savvy guys!) > > Please tell me how things have gone. Basically I'm waiting for > > these issues to be solved to make the 0.7.2 release. > > With the current version it does no longer work *quite* out of > the box on the BSD's. It will work when doing a > CPPFLAGS=/usr/local/include LDFLAGS=/usr/local/lib ./configure > but this is not what I call out of the box :-). I'm not an expert in tunning the system's directories, but I wonder why if /usr/local has part of the system, it is not included in the search path in BSDs. Doesn't make sense to me (nut I don't know much here). OTOH, for instance, /usr/local is not a part of the system in Slackware, and I can't find it with: `gcc -print-search-dirs`. Doubts started when I received this mail, from Manuel Menal: [mmenal at hurdfr.org] <q> Hey, While porting Dillo to the new implementation of POSIX threads for GNU/Hurd (code name: "Rubbish, I asked for mine with Minced Garlic, Please Take this back"), I found some minor bugs in the Dillo "installation system". The first bug I found out was a bug that was already reported as #349 in the Dillo bug report system. It seems a quite simple and not so annoying bug, but in fact it is quite pervert, as it makes the configure misdetect what is installed in the system: when it checks for jpeglib.h (& others), it tries to preprocess a simple C file which only includes jpeglib.h, and check if there is some output. If there is some output, then it assumes there is no jpeglib.h. Which is not true in this case: the output is just warning of cpp, which complains about the -I/usr/local/include (cpp 3.1 already has /usr/local/include it its system directories). [...] </q> Thinking that /usr/local was for extensions, I decided to remove the forced include from configure.in. Can anyone shed some light on this topic? > Also, if png.h is on libpng/png.h and NOT as well in png.h, > it will complain, it does not find png.h. However, this warning > is misleading, since configure will find everything just fine > and dillo compiles and works just fine. I understand. > I attach a patch which fixes both problems. > > The /usr/local stuff really only is an issue for gcc3.x since > gcc3.x already has /usr/local as default directories, so I test > for that case. That *should* be ok. (explained above) > The png.h stuff is more or less my original solution :-) ... > there was a reason for that convoluted approach ... :-) Yes, I added the break clause because it tested libpng twice and added two "-lpng" in my system. I'll commit the patch as you sent here (which BTW, includes the "break"). Cheers Jorge.-

April 10, 2003

Missing favorite features

by Niklas Höglund

One feature that's available in the Gecko-based browsers that I like a lot is to be able to select a link by typing the first letters of it. This enables completely "rodent-free" navigation. (In dillo I can't even find a key to go "back".) I just thought I'd check if this is on the radar. I'd also like to "me too" on the issue of connecting dillo to external applications for unknown filetypes and protocols. I don't think dillo should handle ftp, for example, or PDF. gftp and xpdf should do that. However, I think something more than "nothing" should happen when you click on something unsupported... Anyway, nice work making a light-weight browser. I use dillo a lot on my handheld, and even sometimes on my desktop machine. -- Niklas

April 10, 2003

Re: [Dillo-dev] OpenBSD-3.3 and -current and G_DNS_THREADED

by Dan Weeks

>>>>> "CP" == "Chris Palmer" <chris(a)nodewarrior.org>: CP> On Thu, 10 Apr 2003, Jorge Arellano Cid wrote: CP> CP> [Threading problem on OpenBSD] CP> >> Is this a problem with _all_ OpenBSD? CP> CP> No, it's new. I'm using OBSD 3.1-stable with Dillo and did not have the CP> problem Dan reported. Indeed this is the case. Threads underwent an overhaul on 3.2-current and what will be the 3.3 release will have this issue. I'd be fine with the configure option as it's probably cleaner and easier to maintain. -dan

April 10, 2003

Re: [Dillo-dev] Re: configuration patch - Fix for bugs 386, 407, 392, 412 and notes on bugs 349, 408

by Andreas Schweitzer

Hi, > > > I just commited a minor change to the new configure.in. It > > > avoids running AC_CHECK_LIB twice when testing png headers. I > > > hope it is the right thing to do! :) Well, sort of. See below. > > I'll check it out and test it on a bunch of systems. The testing will > > probably take a while, but I won't be able to do it on the weekend :-) > > *Maybe* before. > > Please tell me how things have gone. Basically I'm waiting for > these issues to be solved to make the 0.7.2 release. With the current version it does no longer work *quite* out of the box on the BSD's. It will work when doing a CPPFLAGS=/usr/local/include LDFLAGS=/usr/local/lib ./configure but this is not what I call out of the box :-). Also, if png.h is on libpng/png.h and NOT as well in png.h, it will complain, it does not find png.h. However, this warning is misleading, since configure will find everything just fine and dillo compiles and works just fine. I attach a patch which fixes both problems. The /usr/local stuff really only is an issue for gcc3.x since gcc3.x already has /usr/local as default directories, so I test for that case. That *should* be ok. The png.h stuff is more or less my original solution :-) ... there was a reason for that convoluted approach ... :-) > Has anyone else tested the changes this mail's subject alludes? Yes, please, so far I tested on FreeBSD 4.7 with gcc2.95 and some Linux variants. I'll test OpenBSD later (but that should be ok ...). But if somebody has some other systems, do test ! FreeBSD 5.0 anyone ? Cheers Andreas P.S.: "full-screen" may indeed be misleading - maybe all of us got used to what it means :-) -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

April 10, 2003

Re: [Dillo-dev] OpenBSD-3.3 and -current and G_DNS_THREADED

by Andreas Schweitzer

On Thu, Apr 10, 2003 at 07:27:37PM +0200, Victor Sahlstedt wrote: > On Thu, 10 Apr 2003 12:06:26 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > Is this a problem with _all_ OpenBSD? > > Well, no. It only applies to 3.3 and -current, as he stated. > I'm running OpenBSD 3.2 without any problems. I recall the same for 3.2 > 3.3 will be officially released on May 1 though and as the > majority of users most likely will upgrade it'll be a problem. Well, yes and no. It will not be a problem for users of the ports version, since the ports version disables threaded DNS lookups. This has to be done since not all architectures are as thread safe as i386 (and now even i386 fails here ;-) ). Thanks to Damien for pointing this out to me some weeks ago ! So, it will only be a problem for OpenBSD users of the CVS version. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

April 10, 2003