- Dillo-dev - lists.mailman3.com

view src
by obeythepenguin＠gmail.com Oct. 20, 2011

Oct. 20, 2011

Jeremy wrote: > corvid wrote: > >> I viewed source, edited the page, reloaded, and view source keeps >> showing me the old source. >> >> I thought this used to work. > > It may have worked once but my impression is that it has been like > this for quite a while. I have certainly had a note about it in my > TO-DO list for a long time. > > Regards, > Jeremy Henty Funny, the old view source dialog doesn't have that problem at all... ;-) ~Benjamin

1 0

No subject
by bogus＠does.not.exist.com Oct. 20, 2011

Oct. 20, 2011

worked around the Window's issues with mouse copy & pasting. --- Roger http://rogerx.freeshell.org/

1 0

Dillo 3 on OpenBSD
by obeythepenguin＠gmail.com Oct. 20, 2011

Oct. 20, 2011

Just wanted to let you know that dillo-3.0 runs quite nicely on OpenBSD (tested with both mainline and Dillo-Win32, on OpenBSD 4.9/i386). Here are some quick build instructions for mainline if anyone wants to try it out. Note that I like to install things to my home directory, but you can remove the --prefix= and --bindir= options if you want to install it system-wide. 1. Download the Dillo and FLTK 1.3 sources to a convenient location -- I use ~/download. Note that OpenBSD doesn't currently have an FLTK 1.3 package. 2. Install some dependencies from OpenBSD's packages: $ sudo pkg_add -i bzip2 jpeg png 3. Build and install FLTK: $ cd /tmp $ tar -xzvf ~/download/fltk-1.3.0-source.tar.gz $ cd fltk-1.3.0 $ CFLAGS='-Os' CXXFLAGS='-Os' ./configure \ --prefix=$HOME/download/fltk --bindir=$HOME/bin --enable-xft $ make && make install 4. Build and install Dillo: $ cd /tmp $ tar -xjvf ~/download/dillo-*.tar.bz2 $ cd dillo-* $ CFLAGS='-Os' CXXFLAGS='-Os' ./configure \ --prefix=$HOME/download/dillo --bindir=$HOME/bin \ --disable-threaded-dns $ make && make install && strip $HOME/bin/dillo Dillo should be installed and ready to go. By the way, I don't know if you *need* --disable-threaded-dns in step 4. I usually add it, and I'm sure there's a reason, but I don't remember exactly why. So if you try it, let me know if Dillo runs without that option. :-) Cheers, ~Benjamin

1 0

Address bar keys (bug #1012)
by obeythepenguin＠gmail.com Oct. 19, 2011

Oct. 19, 2011

Hi again, I was just wondering, could we add an option to control the address bar key bindings? I know they're set to behave like a Unix command line, which can be convenient, but it also interferes with some custom key bindings (as one of my users mentioned in bug #1012). I've also noticed that the address bar bindings confuse a lot of people, since they're not used to the Unix behavior. Conventionally, Ctrl-A is "select all," and other input boxes in Dillo follow that, so they aren't expecting it to go to the beginning of the line instead. I'll be happy to write the patch, I just wanted to see if anyone would be willing to commit it first. :-) Cheers, ~Benjamin

2 1

text-transform
by corvid＠lavabit.com Oct. 19, 2011

Oct. 19, 2011

I guess I must've gotten bored... http://www.dillo.org/test/text-transform.diff http://www.dillo.org/css_compat/tests/text-transform.html

2 1

Dillo Win32 Thoughts
by obeythepenguin＠gmail.com Oct. 18, 2011

Oct. 18, 2011

Just as an update to my earlier post: I've just uploaded a new dillo-win32-3.0p2 release that fixes the dFcntl() bug on Unix, among other small changes. Sorry again for any inconvenience. ~Benjamin

1 0

Dillo Win32 Thoughts
by obeythepenguin＠gmail.com Oct. 18, 2011

Oct. 18, 2011

By the way, if you want to try Dillo-Win32 on Linux/Unix, download and apply this patch before you compile it: http://dillo-win32.sourceforge.net/TODO/dfcntl.diff This fixes the dFcntl implementation on Unix, so nonblocking I/O works correctly and the browser won't lock up. I only noticed this bug today, but I'm going to put up an updated release with the fix included when I get a chance. Apologies for any inconvenience, ~Benjamin

1 0

Dillo Win32 Thoughts
by obeythepenguin＠gmail.com Oct. 18, 2011

Oct. 18, 2011

Georg wrote: > Benjamin, > you mention that your Win32 version will also compile with Linux. I > tried to compile it on Linux and did not have much success. Your source > code package does not include a configure file for that such as the main > version does. I have doubts too that you frequently test if your version > still works on Linux. You can generate the configure script yourself by running autogen.sh (requires autoconf and automake). I don't include a pregenerated configure script mainly because I build my source tarballs using 'hg archive', and Mercurial is set not to track those files. I may change my release process in future versions to make installation from source easier. Technically, you're correct that I don't test Dillo-Win32 on *Linux*. I do, however, use it quite often on OpenBSD, as you can see in this (quite large) screenshot from my development machine: http://obeythepenguin.users.sourceforge.net/openbsd/files/screenshot.png > Will this version when compiled for Linux also use the sockets > abstraction layer and not use the dpi parts? > Georg The sockets abstraction layer and DPI are two entirely separate things. The sockets layer is just some low-level network code that lets Dillo connect whether it's on Unix or Windows. Dillo doesn't know the difference, and that's the entire point -- it behaves exactly the same on both systems. As far as DPI, it's a little more complicated. In a nutshell: - Bookmarks, cookies, and HTTPS are built into the browser, and don't use DPI. - Downloads are built in by default, but you can disable the built-in downloader and use the DPI. - Everything else will fall back on DPI if it's available. Dillo-Win32 doesn't build dpid and DPI programs by default, but it will use mainline's DPIs if they're installed on the system. I haven't removed DPI support from Dillo -- I just moved most of their functionality into the browser. Hope this helps, ~Benjamin

1 0

Fwd: RE: keysrc broken in dillo 3?
by obeythepenguin＠gmail.com Oct. 18, 2011

Oct. 18, 2011

Here's an interesting one for you guys... I had a user email me this morning saying his keysrc file stopped working after he upgraded from Dillo 2.2 to 3.0. Neither his existing keysrc nor a fresh one would work on his machine, while I couldn't reproduce the problem on mine. We just now discovered by chance it wasn't his keysrc that was the problem, but -- strangely enough -- that he had set start_page=about:blank in his dillorc. I've forwarded his original message below (with names and headers removed for privacy), which includes a more detailed explanation. I was just curious if anyone could reproduce this in mainline before I filed a bug report, or if this behavior was specific to Dillo-Win32. I don't have a Unix system handy now, or else I'd just test it myself. :-) Cheers, ~Benjamin ------- Forwarded message ------- I tracked down the source of the behavior and I think it should be reproducible now. In dillorc I had the following line: start_page=about:blank (By now you've probably figured out I'm a Firefox user..) Apparently Dillo 3 does not like for start_page to have this value, and will only load keysrc after a non-blank page is loaded?! This doesn't happen in Dillo 2.2 (20110630) but I'm not sure if this is an intentional change in behavior; probably not, considering the following weirdness: These values allow keysrc to be loaded without having to load a non-blank page: start_page=about:blank#any comment start_page= Sorry, I haven't had a chance to try any of this out in Linux, so still not sure whether this is an upstream regression.. For completeness my old cookiesrc, dillorc, and keysrc files are all attached (files that reproduce the artifact).

1 0

[patch]: download window resizes its contents to its width
by onepoint＠starurchin.org Oct. 17, 2011

Oct. 17, 2011

Purely cosmetic, but I dislike it when the contents ignore their container, even in only one out of two dimensions. Comments? Regards, Jeremy Henty

2 4