- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] fltk2 on the ps2

by robert w hall

In article <20060406123034.GG13477(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Yes, try in xutf8.cxx:897 > >- const char* inbuf = mb_buffer; >+ char* inbuf = mb_buffer; > > Good call - but now it collapses in a set of link-time errors (unresolved refs) in fluid.... -- robert w hall

April 6, 2006

Re: [Dillo-dev] fltk2 on the ps2

by Jorge Arellano Cid

On Thu, Apr 06, 2006 at 09:00:24AM +0100, robert w hall wrote: > I'm still trying to get a clean compilation of fltk2 on the > playstation2. > > Switching compilers (the default is 2.95.2 IIRC) to the slightly > experimental package of gcc3.0.3 has allowed me to get everything to > compile 'as is' apart from run.cxx, which give the following 'error' > > In file included from x11/run.cxx:55, > from run.cxx:185: > x11/xutf8.cxx: In function `int Xutf8LookupString(_XIC*, XKeyPressedEvent*, > char*, int, KeySym*, int*)': > x11/xutf8.cxx:901: cannot convert `const char**' to `char**' for argument `2' > to `size_t iconv(void*, char**, size_t*, char**, size_t*)' > make[1]: *** [run.o] Error 1 > make: *** [all] Error 2 > > > Any advice?? Yes, try in xutf8.cxx:897 - const char* inbuf = mb_buffer; + char* inbuf = mb_buffer; -- Cheers Jorge.-

April 6, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Jorge Arellano Cid

Hi Bob, On Tue, Apr 04, 2006 at 07:18:40PM +0100, robert w hall wrote: > I > > > >OK this gets me by this one, thanks Martin. > >But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h > >and filename.h 'parse error before *' lines 100+ > >>______________ > Looks like I'm on my own :-( > - but there's a rather hairy ('experimental') gcc3.03 on the ps2-linux > site I see..... Don't stress yourself too much, after all there's the `./configure --disable-dlgui` option. It will be more important when all of Dillo becomes FLTK2-based. -- Cheers Jorge.-

April 6, 2006

Re: [Dillo-dev] fltk2 on the ps2

by Jeremy Henty

On Thu, Apr 06, 2006 at 09:00:24AM +0100, robert w hall wrote: > I'm still trying to get a clean compilation of fltk2 on the > playstation2. > > Any advice?? Um, ask the FLTK developers? http://www.fltk.org/newsgroups.php http://lists.easysw.com/mailman/listinfo Jeremy Henty

April 6, 2006

fltk2 on the ps2

by robert w hall

I'm still trying to get a clean compilation of fltk2 on the playstation2. Switching compilers (the default is 2.95.2 IIRC) to the slightly experimental package of gcc3.0.3 has allowed me to get everything to compile 'as is' apart from run.cxx, which give the following 'error' In file included from x11/run.cxx:55, from run.cxx:185: x11/xutf8.cxx: In function `int Xutf8LookupString(_XIC*, XKeyPressedEvent*, char*, int, KeySym*, int*)': x11/xutf8.cxx:901: cannot convert `const char**' to `char**' for argument `2' to `size_t iconv(void*, char**, size_t*, char**, size_t*)' make[1]: *** [run.o] Error 1 make: *** [all] Error 2 Any advice?? -- robert w hall

April 6, 2006

Re: [Dillo-dev] dillo-0.8.6-rc4.tar.bz2

by Jeremy Henty

On Wed, Apr 05, 2006 at 06:52:22PM -0400, Jorge Arellano Cid wrote: > http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 Works correctly with all the problem pages I found with -rc3. Haven't used it on MP3s yet. Cheers, Jeremy Henty

April 6, 2006

dillo-0.8.6-rc4.tar.bz2

by Jorge Arellano Cid

Hi there! The new rc4 tarball is ready: http://www.dillo.org/download/dillo-0.8.6-rc4.tar.bz2 This is complex stuff... From the solutions list: 1.- Keep it as is 2.- Do Content-type sniffing and follow the SPEC. i.e. as stated above, to take the right of ignoring the offending contents. 3.- Do Content-type sniffing and take actions (like mozilla). rc4 implements solution number 2. Specifically: /* * A mismatch happens when receiving a binary stream as * "text/plain" or "text/html", or an image that's not an image of its kind. */ It was tested against all the test cases sent so far. Please test it throughly. Note: It would be nice to popup a dialog window with a warning in some cases (user friendliness). Now, as it is now it is much better than 0.8.5, because binaries are never downloaded into main memory and there're some warning messages. Maybe the dialog warning can wait for the next release, or if testing finds it's necessary, the release can be procrastinated some more. Subtle Note: as it is, it follows the SPEC. The only action taken is to ignore offending contents. A dialog with a warning and offering download/cancel options would be in the gray line between the SPEC and taking actions. -- Cheers Jorge.-

April 5, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

I > >OK this gets me by this one, thanks Martin. >But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h >and filename.h 'parse error before *' lines 100+ >>______________ Looks like I'm on my own :-( - but there's a rather hairy ('experimental') gcc3.03 on the ps2-linux site I see..... -- robert w hall

April 4, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by robert w hall

In article <20060402101918.GA1052(a)hardy.tmseck.homedns.org>, Thomas- Martin Seck <tmseck-lists(a)netcologne.de> writes >Could you try this patch? It is stolen from fltk's bug database, >STR#1124. It enables me to compile fltk2 r4825 with gcc 2.95.4 on >FreeBSD. > >--- fltk/ComboBox.h.orig Sun Apr 2 12:05:31 2006 >+++ fltk/ComboBox.h Sun Apr 2 12:07:16 2006 >@@ -103,7 +103,7 @@ > ComboBox *combo_; > }; > ComboInput *input_; >-#ifdef _WIN32 >+#if defined ( _WIN32 ) || defined ( __GNUC__ ) && __GNUC__ < 3 > public: > #endif > static void input_callback_(Widget*,void*); > >__ OK this gets me by this one, thanks Martin. But now there's a flood of errors in FileChooser.cxx :37, FileBrowser.h and filename.h 'parse error before *' lines 100+ >_____________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- robert w hall

April 3, 2006

Re: [Dillo-dev] dillo-0.8.6-rc3.tar.bz2

by Kelly Price

On 4/2/06, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > 1.- Keep it as is > 2.- Do Content-type sniffing and follow the SPEC. i.e. as > stated above, to take the right of ignoring the offending > contents. > 3.- Do Content-type sniffing and take actions (like mozilla). > > > I like best the second one. Basically this is, If I get a > binary stream as "text/plain" or "text/html", or an image that's > not an image, then issue a warning and ignore it (abort). Note: > this is a basic security procedure. > > This has the advantege of protecting the browser against > attacks and following the SPEC. The user is left to decide (for > instance to retry with "save link as"). > > The third option looks more "user friendly" but it goes against > the SPEC. > Just to delurk and make a note here. The second one would be spec, but third one is both user friendly and server friendly in limited cases. Take for example VCL and Comic Genesis (which I admin). To prevent inlining of images on outside servers and general bandwith wastage, we've programmed the server to check the Referer: header. CG's a bit stricter than VCL is with broken browsers and proxies that don't send (or worse, strip) a Referer: header, but both check to see if the request for an image is for a page it just served. If the check fails, CG sends out a 403 and shoots out a HTML page saying so. VCL redirects to a HTML page which shows the image itself. In ether case, Mozilla/IE/Konqueror/Safari just say that the image is broken in the non-VCL/CG webpage it pulled. If it was directly requested, VCL pulls the HTML/IMG up. CG 403's. If I remember correctly, Mozilla actually asks for an image MIME type first, and then a */* MIME type as a catchall. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com

April 2, 2006