- Dillo-dev - lists.mailman3.com

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