- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Fixing bug in parsing HTML 4.01 comments

by Michal Nowak

Sam Trenholme wrote: > You know, I would actually prefer it if Dillo does *not* fix this bug. > It would be nice to have a "hide from Dillo" HTML trick up my sleeve > for doing web design. For example, Dillo renders tables differently > than how Netscape/Firefox/MSIE renders tables. It would be nice to > be ale to make HTML code like this: > >  > > If Dillo fixes this bug, I will have to figure out some other way to hide > my HTML from Dillo (or be unable to make my web pages look good in Dillo-- > MSIE's CSS is just too primitive for me to completely get rid of tables) > > - Sam > Hello Sam, you are right - it's useful, but it is a hack. It's just hiding Dillo's style of table rendering (which is now being rewriten). I think we should follow specs. Maybe this tiny CSS hacks will help you: http://wellstyled.com/css-underscore-hack.html #item { color: black; /* style for all browsers */ _color: red; /* style for all IE/Win browsers */ _color/**/: orange; /* style for IE/Win 5.5+ browsers */ _co\lor: yellow; /* style for IE/Win 6.0+ browsers */ } I found that comment bug when I was passing by Acid2 test with dillo (http://webstandards.org/act/acid2/) Michal Nowak

Jan. 5, 2006

Re: [Dillo-dev] Fixing bug in parsing HTML 4.01 comments

by Sam Trenholme

You know, I would actually prefer it if Dillo does *not* fix this bug. It would be nice to have a "hide from Dillo" HTML trick up my sleeve for doing web design. For example, Dillo renders tables differently than how Netscape/Firefox/MSIE renders tables. It would be nice to be ale to make HTML code like this:  If Dillo fixes this bug, I will have to figure out some other way to hide my HTML from Dillo (or be unable to make my web pages look good in Dillo-- MSIE's CSS is just too primitive for me to completely get rid of tables) - Sam

Jan. 5, 2006

Fixing bug in parsing HTML 4.01 comments

by Michal Nowak

Hi developers there, I found (hope so) a bug in parsing HTML comments. Acording to HTML 4.01 spec it is possible to make such a comment: " tag. */ while ( (p = memchr(buf + buf_index, '>', bufsize - buf_index)) ){ buf_index = p - buf + 1; - if ( p[-1] == '-' && p[-2] == '-' ) break; + gint counter = -1; + while (isspace(p[counter])) + counter--; + if ( p[counter] == '-' && p[counter-1] == '-' ) break; } if ( p ) { /* Got the whole comment. Let's throw it away! :) */ It's hackish and ugly. I know. From: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4 "White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments." Michal Nowak

Jan. 5, 2006

Re: [Dillo-dev] Size of the new downloads.dpi

by Jorge Arellano Cid

Hi Michal, On Tue, Jan 03, 2006 at 08:08:30PM +0100, Michal Nowak wrote: > Hi dillo developers, > > I just compiled the CVS version of dillo (0.86-pre) with the FLTK based > downloads.dpi. I see it's statically linked against FLTK, but it's now > 450 KiB (here). I think it's quite big. > > When the whole dillo will be FLTK based, will it be staticaly linked > too? Or dynamically, like now with the GTK+ 1.2? > > Thank you all for great work you do. Don't Panic! strip downloads.dpi and it'll get near 310KB. Now, that's a _statically linked_ binary. This is something like linking statically the whole GTK1 library to dillo. Statical and shared FLTK2 can be done. For instance, in the future, it can be built an all shared FLTK2 dillo and dl dpi. Or both static. The advantage of static at this point is you don't need to include the library as a dependency in a package. -- Cheers Jorge.-

Jan. 3, 2006

Size of the new downloads.dpi

by Michal Nowak

Hi dillo developers, I just compiled the CVS version of dillo (0.86-pre) with the FLTK based downloads.dpi. I see it's statically linked against FLTK, but it's now 450 KiB (here). I think it's quite big. When the whole dillo will be FLTK based, will it be staticaly linked too? Or dynamically, like now with the GTK+ 1.2? Thank you all for great work you do. Michal Nowak

Jan. 3, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi There, > OK, tried this on FreeBSD 6 and ran into the following minor issues: > > - I needed to move dpi/downloads.c out of the way; otherwise > something(tm) always tried to build downloads.o using downloads.c > (Makefile and Makefile.in were correctly generated but > .deps/downloads.Po was wrong - could someone enlighten me what goes on > there?) > > - I needed to patch dpi/downloads.cc to make it build, I hope this fix > is correct: > [...] OK, the CVS now has FLTK2 GUI dpi for downloads as _default_. If you don't have FLTK2, you can: ./configure --disable-dlgui and get the old one. So far, the current HOWTO for FLTK2-GUI-dpi for downloads is: 1.- Get the latest CVS (it has dpi/downloads.cc) 2.- Go to http://www.fltk.org/software.php and get the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). __you need FLTK 2.0.x, FLTK 1.1.x won't work___ 3.- Install FLTK2 4.- Build Dillo, install & enjoy! e.g. ./configure; make; make install-strip For old (non GUI) downloads: 1.- Get the latest CVS (it has dpi/downloads.cc) 2.- Build Dillo, install & enjoy! e.g. ./configure --disable-dlgui; make; make install-strip -- Cheers Jorge.-

Jan. 3, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi, On Mon, Jan 02, 2006 at 10:45:03PM +0000, Glyn Kennington wrote: > Jorge Arellano Cid wrote: > > Hi Glyn, > > > > On Mon, Jan 02, 2006 at 09:36:05PM +0000, Glyn Kennington wrote: > > > [...] > > > downloads.cc: In function 'void read_req_cb(int, void*)': > > > downloads.cc:915: error: jump to label 'end' > > > downloads.cc:901: error: from here > > > downloads.cc:907: error: crosses initialization of 'DLAction action' > > > [...] > > > > > > Putting the DlAction block within its own scope solves the problem, but I'm > > > sure it's not as simple as that. > > > > Really weird. What compiler are you using? > > gcc 4.0.3, in Debian testing. I get the same result with gcc 3.3.6. I'm using gcc version 3.4.5. No problem with this one. > > > From a distance look like the compiler gets confused trying to > > catch uninitialized variables. > > There's an entry about it in the g++ FAQ: > > http://theory.uwinnipeg.ca/gnu/libg++/g++FAQ_42.html > > The draft standard does not allow a goto or a jump to a case label to > skip over an initialization of a variable or a class object. > > I'm quite surprised that nobody else has got this error, though. Thanks for the information. I commited a patch to avoid this problem. -- Cheers Jorge.-

Jan. 3, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Glyn Kennington

Jorge Arellano Cid wrote: > Hi Glyn, > > On Mon, Jan 02, 2006 at 09:36:05PM +0000, Glyn Kennington wrote: > > [...] > > downloads.cc: In function 'void read_req_cb(int, void*)': > > downloads.cc:915: error: jump to label 'end' > > downloads.cc:901: error: from here > > downloads.cc:907: error: crosses initialization of 'DLAction action' > > [...] > > > > Putting the DlAction block within its own scope solves the problem, but I'm > > sure it's not as simple as that. > > Really weird. What compiler are you using? gcc 4.0.3, in Debian testing. I get the same result with gcc 3.3.6. > From a distance look like the compiler gets confused trying to > catch uninitialized variables. There's an entry about it in the g++ FAQ: http://theory.uwinnipeg.ca/gnu/libg++/g++FAQ_42.html The draft standard does not allow a goto or a jump to a case label to skip over an initialization of a variable or a class object. I'm quite surprised that nobody else has got this error, though. > Try declaring 'action' with the other vars with a value: > > char *cmd = NULL, *url = NULL, *dl_dest = NULL; > + DLAction action = DL_ABORT; > > > - DLAction action = dl_win->check_filename(&dl_dest); > + action = dl_win->check_filename(&dl_dest); That compiles and runs OK. > Did you get it to work right? Yes, thanks - with either your suggestion, or the extra set of braces, it works correctly. Glyn

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi Glyn, On Mon, Jan 02, 2006 at 09:36:05PM +0000, Glyn Kennington wrote: > if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 -MT downloads.o -MD -MP -MF ".deps/downloads.Tpo" \ > -c -o downloads.o `test -f 'downloads.cc' || echo './'`downloads.cc; \ > then mv -f ".deps/downloads.Tpo" ".deps/downloads.Po"; \ > else rm -f ".deps/downloads.Tpo"; exit 1; \ > fi > downloads.cc: In function 'void read_req_cb(int, void*)': > downloads.cc:915: error: jump to label 'end' > downloads.cc:901: error: from here > downloads.cc:907: error: crosses initialization of 'DLAction action' > downloads.cc:915: error: jump to label 'end' > downloads.cc:897: error: from here > downloads.cc:907: error: crosses initialization of 'DLAction action' > downloads.cc:915: error: jump to label 'end' > downloads.cc:893: error: from here > downloads.cc:907: error: crosses initialization of 'DLAction action' > downloads.cc:915: error: jump to label 'end' > downloads.cc:889: error: from here > downloads.cc:907: error: crosses initialization of 'DLAction action' > downloads.cc:915: error: jump to label 'end' > downloads.cc:885: error: from here > downloads.cc:907: error: crosses initialization of 'DLAction action' > > Putting the DlAction block within its own scope solves the problem, but I'm > sure it's not as simple as that. Really weird. What compiler are you using? From a distance look like the compiler gets confused trying to catch uninitialized variables. Try declaring 'action' with the other vars with a value: char *cmd = NULL, *url = NULL, *dl_dest = NULL; + DLAction action = DL_ABORT; - DLAction action = dl_win->check_filename(&dl_dest); + action = dl_win->check_filename(&dl_dest); Did you get it to work right? -- Cheers Jorge.-

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

On Mon, Jan 02, 2006 at 09:45:46PM +0100, Johannes Hofmann wrote: > On Mon, Jan 02, 2006 at 05:32:24PM -0300, Jorge Arellano Cid wrote: > > > > > - For some reason, downloads.dpi got built from downloads.c until I > > > manually compiled downloads.cc. > > > > After patching, autoconf/automake files are modified so a: > > > > make distclean > > ./autogen > > ./configure > > make > > > > cycle is required (otherwise dependencies may linger). > > Had done that... Perhaps it's a problem with my aclocal/automake > installation... Well the updated HOWTO is: 1.- Get the latest CVS (it has dpi/downloads.cc) 2.- Get http://www.dillo.org/test/dl_GUI.diff cd dillo; patch -p1 < dl_GUI.diff 3.- cd dillo/dpi; mv downloads.c downloads.c.old; rm -r .deps 4.- Go to http://www.fltk.org/software.php and get the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). __you need FLTK 2.0.x, FLTK 1.1.x won't work___ 5.- Install FLTK2 6.- Build Dillo, install & enjoy! -- Cheers Jorge.-

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Glyn Kennington

Thomas-Martin Seck wrote: > - I needed to move dpi/downloads.c out of the way; otherwise > something(tm) always tried to build downloads.o using downloads.c > (Makefile and Makefile.in were correctly generated but > .deps/downloads.Po was wrong - could someone enlighten me what goes on > there?) Thanks for the pointer - this allowed me to get as far as: if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 -MT downloads.o -MD -MP -MF ".deps/downloads.Tpo" \ -c -o downloads.o `test -f 'downloads.cc' || echo './'`downloads.cc; \ then mv -f ".deps/downloads.Tpo" ".deps/downloads.Po"; \ else rm -f ".deps/downloads.Tpo"; exit 1; \ fi downloads.cc: In function 'void read_req_cb(int, void*)': downloads.cc:915: error: jump to label 'end' downloads.cc:901: error: from here downloads.cc:907: error: crosses initialization of 'DLAction action' downloads.cc:915: error: jump to label 'end' downloads.cc:897: error: from here downloads.cc:907: error: crosses initialization of 'DLAction action' downloads.cc:915: error: jump to label 'end' downloads.cc:893: error: from here downloads.cc:907: error: crosses initialization of 'DLAction action' downloads.cc:915: error: jump to label 'end' downloads.cc:889: error: from here downloads.cc:907: error: crosses initialization of 'DLAction action' downloads.cc:915: error: jump to label 'end' downloads.cc:885: error: from here downloads.cc:907: error: crosses initialization of 'DLAction action' Putting the DlAction block within its own scope solves the problem, but I'm sure it's not as simple as that. Glyn

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Johannes Hofmann

On Mon, Jan 02, 2006 at 05:32:24PM -0300, Jorge Arellano Cid wrote: > > > > - strndup() seems not to be availably on DragonFly. Don't know about > > other BSDs. > > Ok, it's patched now in CVS (beware of the g_free instead of plain free). Works fine now. > > > - For some reason, downloads.dpi got built from downloads.c until I > > manually compiled downloads.cc. > > After patching, autoconf/automake files are modified so a: > > make distclean > ./autogen > ./configure > make > > cycle is required (otherwise dependencies may linger). Had done that... Perhaps it's a problem with my aclocal/automake installation... > > > -- > Cheers > Jorge.- > > PS: No need to CC' me. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > Here's a HOWTO fo the FLTK2-based GUI-dpi for downloads: > > * Get the latest CVS (it has dpi/downloads.cc) > * Get http://www.dillo.org/test/dl_GUI.diff > cd dillo; patch -p1 < dl_GUI.diff > * Go to http://www.fltk.org/software.php and get > the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). > __you need FLTK 2.0.x, FLTK 1.1.x won't work___ > * Install FLTK2 > * Build Dillo, install & enjoy! OK, tried this on FreeBSD 6 and ran into the following minor issues: - I needed to move dpi/downloads.c out of the way; otherwise something(tm) always tried to build downloads.o using downloads.c (Makefile and Makefile.in were correctly generated but .deps/downloads.Po was wrong - could someone enlighten me what goes on there?) - I needed to patch dpi/downloads.cc to make it build, I hope this fix is correct: Index: downloads.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo/dpi/downloads.cc,v retrieving revision 1.1 diff -u -r1.1 downloads.cc --- downloads.cc 2 Jan 2006 14:08:45 -0000 1.1 +++ downloads.cc 2 Jan 2006 20:26:43 -0000 @@ -306,7 +306,7 @@ p = strrchr(fullname, '/'); shortname = (p) ? strdup(p + 1) : strdup("??"); p = strrchr(full_filename, '/'); - target_dir = (p) ? strndup(full_filename,p-full_filename+1) : strdup("??"); + target_dir = (p) ? g_strndup(full_filename,p-full_filename+1) : strdup("??"); log_len = 0; log_max = 0; - Did I mention I did get a nice gui after all (it is intended to get visible after the directory selection dialog has finished?) :-) > Note to packagers: Don't worry about FLTK2. The resulting dpi > binary is statically linked so there're no new dependencies for a > package that ships the new GUI-dpi for downloads, and as you'll > soon understand, this new dpi is the recommended choice! :-) > The idea is to ship this GUI-dpi when Dillo-0.8.6 is released. I have a FreeBSD port for FLTK-2-snap ready for inclusion in the FreeBSD ports tree (we build everything from source in FreeBSD ports land). So building an FLTK-2 dillo should not be a problem. Best regards and thanks for keeping up the good work on dillo -- Thomas-Martin Seck (current dillo maintainer on FreeBSD)

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi Johannes, On Mon, Jan 02, 2006 at 09:15:44PM +0100, Johannes Hofmann wrote: > Hi, > > just tried it on DragonFly BSD. Now it works (nice!) Good! > just a couple > of things I noticed: > > - strndup() seems not to be availably on DragonFly. Don't know about > other BSDs. Ok, it's patched now in CVS (beware of the g_free instead of plain free). > - For some reason, downloads.dpi got built from downloads.c until I > manually compiled downloads.cc. After patching, autoconf/automake files are modified so a: make distclean ./autogen ./configure make cycle is required (otherwise dependencies may linger). -- Cheers Jorge.- PS: No need to CC' me.

Jan. 2, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Johannes Hofmann

Hi, just tried it on DragonFly BSD. Now it works (nice!) just a couple of things I noticed: - strndup() seems not to be availably on DragonFly. Don't know about other BSDs. - For some reason, downloads.dpi got built from downloads.c until I manually compiled downloads.cc. Thanks, Johannes On Mon, Jan 02, 2006 at 11:30:43AM -0300, Jorge Arellano Cid wrote: > Hi there, > > Let's start 2006 with a nice addition to Dillo. > > Here's a HOWTO fo the FLTK2-based GUI-dpi for downloads: > > * Get the latest CVS (it has dpi/downloads.cc) > * Get http://www.dillo.org/test/dl_GUI.diff > cd dillo; patch -p1 < dl_GUI.diff > * Go to http://www.fltk.org/software.php and get > the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). > __you need FLTK 2.0.x, FLTK 1.1.x won't work___ > * Install FLTK2 > * Build Dillo, install & enjoy! > > Note to packagers: Don't worry about FLTK2. The resulting dpi > binary is statically linked so there're no new dependencies for a > package that ships the new GUI-dpi for downloads, and as you'll > soon understand, this new dpi is the recommended choice! :-) > The idea is to ship this GUI-dpi when Dillo-0.8.6 is released. > > All: Please test it and let me know to the list you succeeded > in the installation process (just to be sure I didn't forget a > step in the above instructions). Feedback is welcomed. > > Tips: The GUI is compact, but has plenty of information. Look > at the tooltips (place the mouse cursor over the widgets wait and > see; e.g. the filename widget shows the wget log). > > BTW, I also prepared some XPM Icons for window managers. These > are in the Icons page. My Icewm looks very nice with the new > 16x16 and 32x32 pair! > > Enjoy, and have a great 2006! > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 2, 2006

FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi there, Let's start 2006 with a nice addition to Dillo. Here's a HOWTO fo the FLTK2-based GUI-dpi for downloads: * Get the latest CVS (it has dpi/downloads.cc) * Get http://www.dillo.org/test/dl_GUI.diff cd dillo; patch -p1 < dl_GUI.diff * Go to http://www.fltk.org/software.php and get the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). __you need FLTK 2.0.x, FLTK 1.1.x won't work___ * Install FLTK2 * Build Dillo, install & enjoy! Note to packagers: Don't worry about FLTK2. The resulting dpi binary is statically linked so there're no new dependencies for a package that ships the new GUI-dpi for downloads, and as you'll soon understand, this new dpi is the recommended choice! :-) The idea is to ship this GUI-dpi when Dillo-0.8.6 is released. All: Please test it and let me know to the list you succeeded in the installation process (just to be sure I didn't forget a step in the above instructions). Feedback is welcomed. Tips: The GUI is compact, but has plenty of information. Look at the tooltips (place the mouse cursor over the widgets wait and see; e.g. the filename widget shows the wget log). BTW, I also prepared some XPM Icons for window managers. These are in the Icons page. My Icewm looks very nice with the new 16x16 and 32x32 pair! Enjoy, and have a great 2006! -- Cheers Jorge.-

Jan. 2, 2006

Re: [Dillo-dev] Font Problm with max width Forms

by Wilhelm Korrengk

Thank you for your reply! > width in ~/.dillo/dillorc on the rendering section.(vw_fontname, > fw_fontname, font_factor) playing with those parameter didn`t change anything! But you might be right with .gtkrc as far as those form-text-sizes are as big as the menu texts (File -> Exit) and URL texts... Because no .gtkrc existed i tried to build my own looking the following: -- style "user-font" { font="Helvetica 18" } widget_class "*" style "user-font" -- Which did not work... Any other ideas? Thank You so far mfG Wilhelm K.

Dec. 30, 2005

Re: [Dillo-dev] Font Problm with max width Forms

by Diego Sáenz

I have had similar problem in sarge with url entry box and interface text using old gtk config. Try to rename ~/.gtkrc to other name(if it exist) and restart the GUI and GUI apps. If it do not work rename ~/.gtkrc to the original name. You can try to select a diferent font for fixed and variable width in ~/.dillo/dillorc on the rendering section.(vw_fontname, fw_fontname, font_factor) I hope this help. Please, send more data if it do not work. Diego. El Fri, 30 Dec 2005 20:08:01 +0100 Wilhelm Korrengk <DerBadejunge(a)web.de> escribio: > Hello and Thank You! > Dillo is great. > But on my new PC the "Submit" buttons and textfields of forms are too small. > On all of my other machines it runs great (kde) but now on windowmaker it > doesnt... I run x and xfs packages from debian sarge. > > Thanks for Help! > Wilhelm Korrengk > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 30, 2005

Font Problm with max width Forms

by Wilhelm Korrengk

Hello and Thank You! Dillo is great. But on my new PC the "Submit" buttons and textfields of forms are too small. On all of my other machines it runs great (kde) but now on windowmaker it doesnt... I run x and xfs packages from debian sarge. Thanks for Help! Wilhelm Korrengk

Dec. 30, 2005

Re: [Dillo-dev] Re: patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Jorge Arellano Cid

Hi Ben, Sorry for the late answer. I was way busy w/paper-work. :-P On Mon, Dec 05, 2005 at 03:43:07PM -0800, Ben Wiley Sittler wrote: > One more update (this should be the last for awhile) -- this fixes > crashes caused by stalled incomplete reads (due to EAGAIN on the C > side.) > > I've attached the updated python filter in addition to the full patch > since only the python changed. Thanks, I gave the script a review. Probably I'll rewrite it in C and keep the python codebase as a starting point for other dpis. OTOH, It's good to have a python dpi example that shows it's easy to develop dpis. > > On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > > This updated copy of the patch corrects Content-Type defaulting > > (text/plain;charset=US-ASCII if empty, text/plain if empty but charset > > given.) > > > > This appears to work with all the Mozilla data: URL test-cases except > > the JavaScript, CSS, XUL and MP3 ones (the MP3 one deserves further > > investigation.) See: > > > > http://www.mozilla.org/quality/networking/testing/datatests.html Hmmm, I'll try to upload a C translation soon. Can you continue from there? -- Cheers Jorge.-

Dec. 30, 2005

6 Years: some goodies and expecting more!

by Jorge Arellano Cid

Hi there, Somewhere this December, Dillo turned 6 years old. As sort of a present to it I'll be uploading the FLTK2-based GUI downloads plugin I've been working on, for everyone to try, and a bunch of related bug fixes too (this almost makes it for 0.8.6 release). Stay tuned. :) As you know since back from France I've been working on the funding side, and coding on the free timeslices. I'm expecting good news in mid January. I hope the whole effort proves more than worth. Best wishes and an excellent 2006 year! :-) -- Cheers Jorge.-

Dec. 30, 2005

Re: [Dillo-dev] tables break forms??

by higuita

On Sat, 10 Dec 2005 16:49:47 +0100, Wim De Smet <kromagg(a)gmail.com> wrote: > > it's improper and extremely common – that pattern is used to avoid > > extra whitespace before and after a form. one shouldnt make bad html code just to make a browser look better, it the browser is broken, it their fault, not html fault. its things like this that made the web so hard for other browsers > the previous behaviour is that the parser ignores the </table> and > forces a close tag a bit further down the page (what it's doing in my > version) while in your version it's forcing the form tag to close. still there is a easy fix... install privoxy and put it to fix broken html, search the bad code and replace it with the correct form, then apply this to the bad webpages (and notify the webmaster also) its not perfect, but dillo shoudnt have all sort of hacks to render bad html, it would grow big and slower and reward bad html writers higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Dec. 10, 2005

Re: [Dillo-dev] tables break forms??

by Jorge Arellano Cid

On Sat, Dec 10, 2005 at 04:49:47PM +0100, Wim De Smet wrote: > I think you meant to send this to the list? Anyway, > > On 12/10/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > > it's improper and extremely common ? that pattern is used to avoid > > extra whitespace before and after a form. > > The dillo parser is often a bit picky on broken html. The correct way > of going about this would be using CSS of course. Your example does > render in my version of dillo (which is debian-specific 0.8.5). Not > sure why, since I thought they mostly added i18n patches. FWIW I think > the previous behaviour is that the parser ignores the </table> and > forces a close tag a bit further down the page (what it's doing in my > version) while in your version it's forcing the form tag to close. > > greets, > Wim Just for completeness: http://www.cs.tut.fi/~jkorpela/forms/extraspace.html -- Cheers Jorge.-

Dec. 10, 2005

Re: [Dillo-dev] tables break forms??

by Wim De Smet

I think you meant to send this to the list? Anyway, On 12/10/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > it's improper and extremely common – that pattern is used to avoid > extra whitespace before and after a form. The dillo parser is often a bit picky on broken html. The correct way of going about this would be using CSS of course. Your example does render in my version of dillo (which is debian-specific 0.8.5). Not sure why, since I thought they mostly added i18n patches. FWIW I think the previous behaviour is that the parser ignores the </table> and forces a close tag a bit further down the page (what it's doing in my version) while in your version it's forcing the form tag to close. greets, Wim

Dec. 10, 2005

Re: [Dillo-dev] tables break forms??

by Wim De Smet

Hi, On 12/9/05, fred <dillolist(a)ubyte.net> wrote: > Hello all. Please forgive me if this has already been discussed at > length, I check the last 2months of archives and the bug track and didn't > find any mention, but I might've just over-looked it. In dillo 0.8.3 > there is no problem when a form begins inside a table but ends outside of > it, but when my dillo 0.8.5 sees a the table close, it forces the form > closed too and truncates (and consequently discards) the rest of the form. > Here is an example (I think this a culprit too > [http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev] > > <HTML> <table><form method="post" action="null"> > > <input type="text" name="proper"><br> > </table>  > <input type="text" name="cut_off"> > > </form></HTML> This looks like improper html. Note that you open the form AFTER starting the table, but close the table BEFORE closing the form. I think your problem is improper nesting here. greets, Wim

Dec. 9, 2005

Re: [Dillo-dev] patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Diego Sáenz

Well, you choose to use it or not. And you choose to give an alternative(show me the code :P). It is not a complex task: cp IO/about.c IO/data.c and start with that. Diego Sáenz/DarkSpirit El Tue, 6 Dec 2005 03:41:33 +0100 Thorben Thuermer <r00t(a)informatik.uni-bremen.de> escribio: > On Mon, 5 Dec 2005 07:58:11 -0800 Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > > and found that there was one crucial URI scheme missing: "data:", > > defined in RFC 2397. I used the simple filter DPI model and had > > something working fairly quickly (thank you all for making that easy!) > > nifty! something i've been looking for before. > > but... i love how firing up a python interpreter (/compiler/vm/...) (or any > external process) and passing it the data just to decode it fits with the > general efficiency of data: (which i'd consider the main argument for using > it)... > > > Enjoy, > > -ben > > Thorben > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 9, 2005

Re: [Dillo-dev] locked cookie file

by Diego Sáenz

Try current cvs. Cvs version uses a Dillo Plug-In to manage cookies to solve this. More info in the doc/Cookies.txt file. Diego Sáenz. El Thu, 8 Dec 2005 19:06:27 -0500 (EST) "fred" <dillolist(a)ubyte.net> escribio: > Is there a good work around for using multiple instance of dillo at once, > as it locks the cookie file and disables cookies for the all instances > started after the first one? > Thanks in advance all; Cheers! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 9, 2005

locked cookie file

by fred

Is there a good work around for using multiple instance of dillo at once, as it locks the cookie file and disables cookies for the all instances started after the first one? Thanks in advance all; Cheers!

Dec. 9, 2005

tables break forms??

by fred

Hello all. Please forgive me if this has already been discussed at length, I check the last 2months of archives and the bug track and didn't find any mention, but I might've just over-looked it. In dillo 0.8.3 there is no problem when a form begins inside a table but ends outside of it, but when my dillo 0.8.5 sees a the table close, it forces the form closed too and truncates (and consequently discards) the rest of the form. Here is an example (I think this a culprit too [http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev] <HTML> <table><form method="post" action="null"> <input type="text" name="proper"><br> </table>  <input type="text" name="cut_off"> </form></HTML> I don't know if this is the proper diagnosis, a known issue, or uncompliant HTML, just wondering if others have been having problems with it. PS: what about calling an executable on "View Source"? vim colors are pretty.

Dec. 9, 2005

Re: [Dillo-dev] Dillo Support for Flash plugins

by Thorben Thuermer

On Wed, 7 Dec 2005 18:13:37 +0800 Xyber Blue <xyberblue(a)gmail.com> wrote: > Is there anyone here who tested the dillo with flash plugins??? I just want > to know if dillo is already supporting this kind of plugins. > If not, is there any plan to support flash player plugins for dillo??? http://www.dillo.org/Plans.html >Low priority >[-] Graphical plugins framework. http://www.dillo.org/dpi1.html > Hopefully, dillo will have two types of plugins: one of a >simple nature (described in this document), that operates in a >similar way of CGIs (with some extensions), and another that >integrates interaction with the rendering engine and its widgets. > > The fact is that our current rendering system, and its >associated internal layers is still under construction, makes >almost impossible to begin working on dpi2, and on the other >hand, gives an excellent oportunity to focus on dpi1 (that's also >expected to be easier to program with). - Thorben

Dec. 8, 2005

Dillo Support for Flash plugins

by Xyber Blue

Hello poeple, Good day, Is there anyone here who tested the dillo with flash plugins??? I just want to know if dillo is already supporting this kind of plugins. If not, is there any plan to support flash player plugins for dillo???

Dec. 7, 2005

Re: [Dillo-dev] patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Diego Sáenz

El Mon, 5 Dec 2005 07:58:11 -0800 Ben Wiley Sittler <bsittler(a)gmail.com> escribio: > Hi! I've been using dillo a bit since the i18n patch became usable, > and found that there was one crucial URI scheme missing: "data:", > defined in RFC 2397. I used the simple filter DPI model and had > something working fairly quickly (thank you all for making that easy!) Great, i try to do the same for the xproto patch with a shell script, but only support base 64 and forget it. > > This works by adding a filter for dpi:/dataurl/... and rewriting > data:... to use it, in a fashion similar to the one used by the https > filter. > > The data: URI scheme allows image data (and other linked resources) to > be embedded in a web page, so (for example) your DPIs can now > trivially embed images, even dynamically-generated ones. It is also > supported by the Mozilla family (it's used heavily in GreaseMonkey > plugins) and in Konqueror and Safari. I think i will use this feature for the prefs plug-in. > > Here's an example data: URI (an image) from the RFC: > > <IMG > SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw > AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz > ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp > a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl > ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis > F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH > hhx4dbgYKAAA7" > ALT="Larry"> > > The ";base64" is optional, and indicates Base-64 encoded data. The > default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 > conversion of the same data: > > <img > src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 > %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB > %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 > %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD > qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% > 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C > 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 > 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC > wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 > D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC > %F1%E1%87%1E%1Dn%06%0A%00%00%3B" > alt="Larry" > /> > > So far this DPI has only been tested with the i18n-patched version of > dillo (I use it to load small test texts in different charsets), but > it should theoretically work in regular dillo too. > > Enjoy, > -ben Goodbye Diego

Dec. 7, 2005

Re: [Dillo-dev] Mac Classic Dillo

by Bryan Waters

By Mac Classic i'm referring to the older Mac OS'es (pre-OSX)...Mac OS 8 or 9 for example. The chips are 68k or PowerMac i think...regardless, it must run on the Mac OS and not a compatible linux flavor that runs on the hardware. I don't know much about but let me research that a little...still the code i've seen is very clean so maybe i can use it as a base for a browser widget on these older systems. -bryanw Diego Sáenz wrote: >Can you give more info about the port? CPU=680?0 MMU=? OperativeSystem(OS)=? ... > >OS is the most important one. If it is *BSD or linux(is there a linux for MacClasic?) you do not need port (http://www.dillo.org/Compatibility.html) So i think it is other OS. >If it is MacOS you can wait the work-in-progress dillo port to FLTK(I think it will be easier than now) before port to Mac Toolbox(was it so?) or do not wait and help to the port of dillo to FLTK. > >FLTK works in current Macs but i unknown if run on Classics ones. > >I hoppe that this help you. > >Diego. > > >El Tue, 06 Dec 2005 10:51:56 -0600 >Bryan Waters <bryanw(a)abwaters.com> escribio: > > > >>Has anyone ever ported Dillo to the Mac Classic? Any suggestions on >>where to start if I wanted to do so? >> >>-bryanw >> >> >>_______________________________________________ >>Dillo-dev mailing list >>Dillo-dev(a)dillo.org >>http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Dillo-dev mailing list >>Dillo-dev(a)dillo.org >>http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> >>

Dec. 6, 2005

Re: [Dillo-dev] Mac Classic Dillo

by Diego Sáenz

Can you give more info about the port? CPU=680?0 MMU=? OperativeSystem(OS)=? ... OS is the most important one. If it is *BSD or linux(is there a linux for MacClasic?) you do not need port (http://www.dillo.org/Compatibility.html) So i think it is other OS. If it is MacOS you can wait the work-in-progress dillo port to FLTK(I think it will be easier than now) before port to Mac Toolbox(was it so?) or do not wait and help to the port of dillo to FLTK. FLTK works in current Macs but i unknown if run on Classics ones. I hoppe that this help you. Diego. El Tue, 06 Dec 2005 10:51:56 -0600 Bryan Waters <bryanw(a)abwaters.com> escribio: > Has anyone ever ported Dillo to the Mac Classic? Any suggestions on > where to start if I wanted to do so? > > -bryanw > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 6, 2005

Mac Classic Dillo

by Bryan Waters

Has anyone ever ported Dillo to the Mac Classic? Any suggestions on where to start if I wanted to do so? -bryanw

Dec. 6, 2005

Re: [Dillo-dev] patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Thorben Thuermer

On Mon, 5 Dec 2005 07:58:11 -0800 Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > and found that there was one crucial URI scheme missing: "data:", > defined in RFC 2397. I used the simple filter DPI model and had > something working fairly quickly (thank you all for making that easy!) nifty! something i've been looking for before. but... i love how firing up a python interpreter (/compiler/vm/...) (or any external process) and passing it the data just to decode it fits with the general efficiency of data: (which i'd consider the main argument for using it)... > Enjoy, > -ben Thorben

Dec. 6, 2005

Re: patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Ben Wiley Sittler

One more update (this should be the last for awhile) -- this fixes crashes caused by stalled incomplete reads (due to EAGAIN on the C side.) I've attached the updated python filter in addition to the full patch since only the python changed. On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > This updated copy of the patch corrects Content-Type defaulting > (text/plain;charset=US-ASCII if empty, text/plain if empty but charset > given.) > > This appears to work with all the Mozilla data: URL test-cases except > the JavaScript, CSS, XUL and MP3 ones (the MP3 one deserves further > investigation.) See: > > http://www.mozilla.org/quality/networking/testing/datatests.html > > On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > > Hi! I've been using dillo a bit since the i18n patch became usable, > > and found that there was one crucial URI scheme missing: "data:", > > defined in RFC 2397. I used the simple filter DPI model and had > > something working fairly quickly (thank you all for making that easy!) > > > > This works by adding a filter for dpi:/dataurl/... and rewriting > > data:... to use it, in a fashion similar to the one used by the https > > filter. > > > > The data: URI scheme allows image data (and other linked resources) to > > be embedded in a web page, so (for example) your DPIs can now > > trivially embed images, even dynamically-generated ones. It is also > > supported by the Mozilla family (it's used heavily in GreaseMonkey > > plugins) and in Konqueror and Safari. > > > > Here's an example data: URI (an image) from the RFC: > > > > <IMG > > SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw > > AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz > > ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp > > a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl > > ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis > > F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH > > hhx4dbgYKAAA7" > > ALT="Larry"> > > > > The ";base64" is optional, and indicates Base-64 encoded data. The > > default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 > > conversion of the same data: > > > > <img > > src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 > > %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB > > %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 > > %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD > > qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% > > 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C > > 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 > > 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC > > wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 > > D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC > > %F1%E1%87%1E%1Dn%06%0A%00%00%3B" > > alt="Larry" > > /> > > > > So far this DPI has only been tested with the i18n-patched version of > > dillo (I use it to load small test texts in different charsets), but > > it should theoretically work in regular dillo too. > > > > Enjoy, > > -ben > > > > > >

Dec. 5, 2005

Re: patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Ben Wiley Sittler

This updated copy of the patch corrects Content-Type defaulting (text/plain;charset=US-ASCII if empty, text/plain if empty but charset given.) This appears to work with all the Mozilla data: URL test-cases except the JavaScript, CSS, XUL and MP3 ones (the MP3 one deserves further investigation.) See: http://www.mozilla.org/quality/networking/testing/datatests.html On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > Hi! I've been using dillo a bit since the i18n patch became usable, > and found that there was one crucial URI scheme missing: "data:", > defined in RFC 2397. I used the simple filter DPI model and had > something working fairly quickly (thank you all for making that easy!) > > This works by adding a filter for dpi:/dataurl/... and rewriting > data:... to use it, in a fashion similar to the one used by the https > filter. > > The data: URI scheme allows image data (and other linked resources) to > be embedded in a web page, so (for example) your DPIs can now > trivially embed images, even dynamically-generated ones. It is also > supported by the Mozilla family (it's used heavily in GreaseMonkey > plugins) and in Konqueror and Safari. > > Here's an example data: URI (an image) from the RFC: > > <IMG > SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw > AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz > ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp > a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl > ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis > F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH > hhx4dbgYKAAA7" > ALT="Larry"> > > The ";base64" is optional, and indicates Base-64 encoded data. The > default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 > conversion of the same data: > > <img > src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 > %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB > %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 > %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD > qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% > 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C > 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 > 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC > wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 > D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC > %F1%E1%87%1E%1Dn%06%0A%00%00%3B" > alt="Larry" > /> > > So far this DPI has only been tested with the i18n-patched version of > dillo (I use it to load small test texts in different charsets), but > it should theoretically work in regular dillo too. > > Enjoy, > -ben > >

Dec. 5, 2005

patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Ben Wiley Sittler

Hi! I've been using dillo a bit since the i18n patch became usable, and found that there was one crucial URI scheme missing: "data:", defined in RFC 2397. I used the simple filter DPI model and had something working fairly quickly (thank you all for making that easy!) This works by adding a filter for dpi:/dataurl/... and rewriting data:... to use it, in a fashion similar to the one used by the https filter. The data: URI scheme allows image data (and other linked resources) to be embedded in a web page, so (for example) your DPIs can now trivially embed images, even dynamically-generated ones. It is also supported by the Mozilla family (it's used heavily in GreaseMonkey plugins) and in Konqueror and Safari. Here's an example data: URI (an image) from the RFC: <IMG SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7" ALT="Larry"> The ";base64" is optional, and indicates Base-64 encoded data. The default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 conversion of the same data: <img src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC %F1%E1%87%1E%1Dn%06%0A%00%00%3B" alt="Larry" /> So far this DPI has only been tested with the i18n-patched version of dillo (I use it to load small test texts in different charsets), but it should theoretically work in regular dillo too. Enjoy, -ben

Dec. 5, 2005

Re: [Dillo-dev] building Dillo 0.8.5 with Compaq's C Compiler on FreeBSD/Alpha

by Jorge Arellano Cid

On Sun, Nov 06, 2005 at 10:25:02AM +0100, Anders Gavare wrote: > Hi all! Hi. > > Dillo 0.8.5 doesn't compile "out-of-the-box" with Compaq's C Compiler on > FreeBSD/Alpha. The Dillo source code seems to be quite portable and clean > as it is, so only very minor changes were necessary to make it build and > run. It's probably a very uncommon compiler scenario, but I thought I'd > still share this with the list. Perhaps it is of interest to someone. > > 1. src/dw_embed_gtk.h, line 27: > > /*gboolean child_size_request_lock*/; > > CCC doesn't like the semi-colon being outside the comment. Moving > it inside allows the compilation to continue. Done. > > 2. Lines 379-380 in src/dw_widget.h do not work with CCC. > > #define a_Dw_iterator_unhighlight(it, l) ((it) ? \ > (it)->highlight(it, -1, -1, l) : FALSE) > > highlight() seems to return a void, which is not the same type as > FALSE. I am not sure what the correct solution would be, but changing > line 380 into the following will at least allow the compilation > continue: > > ((it)->highlight(it, -1, -1, l), TRUE) : FALSE) I changed it to: ((it)->highlight(it, -1, -1, l), TRUE) : (void)0) > > 3. Line 134 in src/html.c. CCC says 'The static declaration of "Tags" is a > tentative definition and specifies an incomplete type. (incompstat)' > Removing the 'static' so that the line reads just > > const TagInfo Tags[]; > > allows the compilation to continue. (Note that the actual definition > of static const TagInfo Tags further down in html.c does _not_ need > to be changed!) ... but gcc complains with that change: html.c:4318: error: static declaration of 'Tags' follows non-static declaration html.c:134: error: previous declaration of 'Tags' was here html.c:134: warning: array 'Tags' assumed to have one element so I left it unchanged. > > So far so good. With these modifications, LIBPTHREAD_LIBS="-lc_r" CC=ccc > CFLAGS="-mcpu=pca56 -fast -O4 -g3" ./configure; make builds everything. > > However, Dillo crashes when run. I spent some time trying to track down > what causes this, and it seems to be the debug macros. CCC gives about a > million warnings about these, looking like this: > > cc: Warning: file.c, line 42: This parameter is not preceded by a > comma. (missingcomma) > #define _MSG(fmt...) > ----------------^ > > cc: Warning: file.c, line 905: Too few actual parameters in the > invocation of the macro "MSG". (toofewactuals) > MSG("file.dpi:: Failed to parse 'url'\n"); > > and so on. Apparently, either CCC is flawed in this regard, or the MSG > macros were not written cleanly enough. Modifying src/msg.h and src/debug.h > so that all MSG and DEBUG_MSG macros simply become empty statements, also > changing the BW_MSG define in src/IO/http.c into an empty definition > "avoids" the problem, Dillo seems to run fine, but of course there will be > no debug output. :-/ The "fmt..." syntax is used to specify a function with a variable number of arguments. Try to find how it's done with CCC. > > The compiler version I used was "V6.4-005 on Linux 2.4.2 alpha", and the > host OS was FreeBSD/Alpha 4.9. Perhaps some of these modifications could > apply to the current CVS tree as well, and not just 0.8.5, but I haven't > had time to check. Please try the current CVS and tell me if at least what's changed works. If you find a portable way to solve the othe problems, just let me know. -- Cheers Jorge.-

Nov. 15, 2005

Re: [Dillo-dev] minor compilation problem with current cvs

by Jorge Arellano Cid

On Sat, Oct 29, 2005 at 03:04:12PM +0200, Johannes Hofmann wrote: > The new cookie dpi has a minor compilation problem in DragonFly-BSD > and probabely other BSDs as well. > The following modifictaion solves the problem. > > Index: dpi/cookies.c > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo/dpi/cookies.c,v > retrieving revision 1.3 > diff -u -r1.3 cookies.c > --- dpi/cookies.c 28 Oct 2005 14:12:32 -0000 1.3 > +++ dpi/cookies.c 29 Oct 2005 13:02:21 -0000 > @@ -35,8 +35,8 @@ > #else > > > -#include <sys/socket.h> > #include <sys/types.h> > +#include <sys/socket.h> > #include <sys/stat.h> > #include <sys/un.h> > #include <fcntl.h> Done! -- Cheers Jorge.-

Nov. 15, 2005

Re: [Dillo-dev] dillo to access yahoo mail

by Kelson Vibber

Charles Li wrote: > Hi, > I have dillo installed on cgywinX. When I try to > logon to the yahoo mail site, it errors out and > reports "can't start dpid daemon". I also see "dpid > tag is null" in the message. How do I fix this? Thanks. I believe Yahoo Mail requires SSL to log in. Dillo implements HTTPS through a plug-in -- a DPI -- and as far as I know the DPI system does not work under Cygwin. It's been a year since I tried, and I wrote up what I found here: http://www.hyperborea.org/software/dillo/cygwin.html http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-September/002201.ht… -- Kelson Vibber www.hyperborea.org

Nov. 15, 2005

Re: [Dillo-dev] Using Frames in dillo 0.8.6pre

by Diego Sáenz

I will work in a tabs DPI when i finished preferences DPI(i am working in it now, but have few time for coding). I hoppe it can be usefull. If someone have free time and want to start tabs DPI now, i can send his a patch and tabs DPI test code. Diego El Mon, 31 Oct 2005 08:19:25 +0100 hans353(a)gmail.com escribio: > Hello. > > First of all I want to thank everybody working on > dillo web browser, i really like it. > > Now my question. I remeber having tabbed browsing and > frame support within dillo 0.85 from the gentoo ebuild. > Now i'm trying 0.86pre from cvs and can't find any option > for this. Maybe i'm to blind to find it in the INSTALL > or ./configure --help. Is there any possibility to use > tabbed browsing and frame support within dillo 0.8.6pre. > > Thank you and best regards > > Hans > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 15, 2005

building Dillo 0.8.5 with Compaq's C Compiler on FreeBSD/Alpha

by Anders Gavare

Hi all! Dillo 0.8.5 doesn't compile "out-of-the-box" with Compaq's C Compiler on FreeBSD/Alpha. The Dillo source code seems to be quite portable and clean as it is, so only very minor changes were necessary to make it build and run. It's probably a very uncommon compiler scenario, but I thought I'd still share this with the list. Perhaps it is of interest to someone. 1. src/dw_embed_gtk.h, line 27: /*gboolean child_size_request_lock*/; CCC doesn't like the semi-colon being outside the comment. Moving it inside allows the compilation to continue. 2. Lines 379-380 in src/dw_widget.h do not work with CCC. #define a_Dw_iterator_unhighlight(it, l) ((it) ? \ (it)->highlight(it, -1, -1, l) : FALSE) highlight() seems to return a void, which is not the same type as FALSE. I am not sure what the correct solution would be, but changing line 380 into the following will at least allow the compilation continue: ((it)->highlight(it, -1, -1, l), TRUE) : FALSE) 3. Line 134 in src/html.c. CCC says 'The static declaration of "Tags" is a tentative definition and specifies an incomplete type. (incompstat)' Removing the 'static' so that the line reads just const TagInfo Tags[]; allows the compilation to continue. (Note that the actual definition of static const TagInfo Tags further down in html.c does _not_ need to be changed!) So far so good. With these modifications, LIBPTHREAD_LIBS="-lc_r" CC=ccc CFLAGS="-mcpu=pca56 -fast -O4 -g3" ./configure; make builds everything. However, Dillo crashes when run. I spent some time trying to track down what causes this, and it seems to be the debug macros. CCC gives about a million warnings about these, looking like this: cc: Warning: file.c, line 42: This parameter is not preceded by a comma. (missingcomma) #define _MSG(fmt...) ----------------^ cc: Warning: file.c, line 905: Too few actual parameters in the invocation of the macro "MSG". (toofewactuals) MSG("file.dpi:: Failed to parse 'url'\n"); and so on. Apparently, either CCC is flawed in this regard, or the MSG macros were not written cleanly enough. Modifying src/msg.h and src/debug.h so that all MSG and DEBUG_MSG macros simply become empty statements, also changing the BW_MSG define in src/IO/http.c into an empty definition "avoids" the problem, Dillo seems to run fine, but of course there will be no debug output. :-/ The compiler version I used was "V6.4-005 on Linux 2.4.2 alpha", and the host OS was FreeBSD/Alpha 4.9. Perhaps some of these modifications could apply to the current CVS tree as well, and not just 0.8.5, but I haven't had time to check. Anders

Nov. 6, 2005

My personal wish lists

by Jun OKAJIMA

Hello Dillo Developers. I tried dillo and found good. Thanks for your effort. Do you need my impression? No? umm.. Anyway, my wish list from just a few hours experience are ... 1. Integrate this -> http://teki.jpn.ph/pc/software/ Especially, - Internationalization - Frame support - Referer these are necessary. 2. Animated GIF!!! this is necessary. I felt Dillo is good for KIOSK use, but without animated gif, common web business model, in short, advertising, does not work. Nothing works without a business model, right? 3. FLTK and UTF-8 support. Among the stuff already on your wishlist, this is the most desired for me. 4. It is very difficult issue that you should add javascript or not. Despite of that I know the needs for JS is incresing because of ajax, but, atm, I feel not necessary. If you need such stuff, use firefox. --- Okajima, Jun. Tokyo, Japan.

Nov. 3, 2005

Using Frames in dillo 0.8.6pre

by hans353＠gmail.com

Hello. First of all I want to thank everybody working on dillo web browser, i really like it. Now my question. I remeber having tabbed browsing and frame support within dillo 0.85 from the gentoo ebuild. Now i'm trying 0.86pre from cvs and can't find any option for this. Maybe i'm to blind to find it in the INSTALL or ./configure --help. Is there any possibility to use tabbed browsing and frame support within dillo 0.8.6pre. Thank you and best regards Hans

Oct. 30, 2005

minor compilation problem with current cvs

by Johannes Hofmann

The new cookie dpi has a minor compilation problem in DragonFly-BSD and probabely other BSDs as well. The following modifictaion solves the problem. Index: dpi/cookies.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo/dpi/cookies.c,v retrieving revision 1.3 diff -u -r1.3 cookies.c --- dpi/cookies.c 28 Oct 2005 14:12:32 -0000 1.3 +++ dpi/cookies.c 29 Oct 2005 13:02:21 -0000 @@ -35,8 +35,8 @@ #else -#include <sys/socket.h> #include <sys/types.h> +#include <sys/socket.h> #include <sys/stat.h> #include <sys/un.h> #include <fcntl.h> Regards, Johannes Hofmann

Oct. 29, 2005

Re: Where could we find the gtk2 patch for dillo?

by palm topen

On 10/28/05, Michael Kropfberger <michael(a)kropfberger.com> wrote: > On Thursday 27 October 2005 23:39, palm topen wrote: > > Thanks! > > Thanks for your great job! > > Waiting for your new porting for newest dillo. > > No, no, I didn't port it!!! I just use it, and I've added various other > patches for eg. ipaq kiosk-mode (forced fullscreen, hidden cursor....) > > > I am working on a linux, gtk based smart phone platform. > > --> maemo on Nokia N770? No, it is my own smart phone platform which is advanced than maemo :)(Please let me say so:) ), because it has phone, sms, gprs etc functions. Have you seen the attached screen shot? It is it. > > > applications manager, phone, sms, contact, mediaplayer are ok now > > using ipaq and wireless pack. > > > > now I am working on gprs and dillo. > > > > maybe in the future, I will open source the code. > > When you are using GPL source code, you'd have to, anyway :) > so, go ahead! Sure, if have used GPL code, the whole source code will be published. :) It is interesting to talk with you in the mail list. Regards Tom > > > regards, > > > Mike > > > > On 10/27/05, Michael Kropfberger <michael(a)kropfberger.com> wrote: > > > On Thursday 27 October 2005 06:58, you wrote: > > > > We are porting dillo to gtk2. > > > > > > > > Dould you tell us where we could find gtk2 patch for dillo? > > > > > > I attach it, it comes from the familiar openembedded environment, but > > > it's based on dillo-0.6.6!!!!!! there is no newer port! > > > let me know, when you are done, I'd also like to use a gtk2 port with > the > > > newest dillo.... > > > > > > please also think about another gui-lib, wouldnt it be nice to have > dillo > > > on > > > > > > linux-ipaq and winCE-ipaq, too? I have no idea what graphical library > > > this could be, but at least think of portability... as far as I know, > > > dillo has very abstract rendering classes, which might be instatiated > by > > > different gui-libs on different OSs... (even Qt for OPIE?) > > > > > > > > > good luck! > > > > > > > > > > > > Michael > > > > > > > >

Oct. 28, 2005

Re: Where could we find the gtk2 patch for dillo?

by Michael Kropfberger

On Thursday 27 October 2005 23:39, palm topen wrote: > Thanks! > Thanks for your great job! > Waiting for your new porting for newest dillo. No, no, I didn't port it!!! I just use it, and I've added various other patches for eg. ipaq kiosk-mode (forced fullscreen, hidden cursor....) > I am working on a linux, gtk based smart phone platform. --> maemo on Nokia N770? > applications manager, phone, sms, contact, mediaplayer are ok now > using ipaq and wireless pack. > > now I am working on gprs and dillo. > > maybe in the future, I will open source the code. When you are using GPL source code, you'd have to, anyway :) so, go ahead! regards, Mike > On 10/27/05, Michael Kropfberger <michael(a)kropfberger.com> wrote: > > On Thursday 27 October 2005 06:58, you wrote: > > > We are porting dillo to gtk2. > > > > > > Dould you tell us where we could find gtk2 patch for dillo? > > > > I attach it, it comes from the familiar openembedded environment, but > > it's based on dillo-0.6.6!!!!!! there is no newer port! > > let me know, when you are done, I'd also like to use a gtk2 port with the > > newest dillo.... > > > > please also think about another gui-lib, wouldnt it be nice to have dillo > > on > > > > linux-ipaq and winCE-ipaq, too? I have no idea what graphical library > > this could be, but at least think of portability... as far as I know, > > dillo has very abstract rendering classes, which might be instatiated by > > different gui-libs on different OSs... (even Qt for OPIE?) > > > > > > good luck! > > > > > > > > Michael > > > >

Oct. 28, 2005

Re: Where could we find the gtk2 patch for dillo?

by palm topen

Hi Michael: Thanks! Thanks for your great job! Waiting for your new porting for newest dillo. I am working on a linux, gtk based smart phone platform. applications manager, phone, sms, contact, mediaplayer are ok now using ipaq and wireless pack. now I am working on gprs and dillo. maybe in the future, I will open source the code. this is the screen shot. Regards Tom On 10/27/05, Michael Kropfberger <michael(a)kropfberger.com> wrote: > On Thursday 27 October 2005 06:58, you wrote: > > We are porting dillo to gtk2. > > > > Dould you tell us where we could find gtk2 patch for dillo? > > I attach it, it comes from the familiar openembedded environment, but it's > based on dillo-0.6.6!!!!!! there is no newer port! > let me know, when you are done, I'd also like to use a gtk2 port with the > newest dillo.... > > please also think about another gui-lib, wouldnt it be nice to have dillo on > > linux-ipaq and winCE-ipaq, too? I have no idea what graphical library this > could be, but at least think of portability... as far as I know, dillo has > very abstract rendering classes, which might be instatiated by different > gui-libs on different OSs... (even Qt for OPIE?) > > > good luck! > > > > Michael > > > > -- > < When in doubt, THINK! > > <----------------------------------------------------------------------> > < DI Dr. Michael Kropfberger A-9073 Viktring, Kindergartenstr. 14/6 > > < +43(650)6996000 michael _A T_ kropfberger.com http://www.kropfberger.com > > > <----------------------------------------------------------------------> > >

Oct. 27, 2005