- Dillo-dev - lists.mailman3.com

saving files under recent fltk snapshots?

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? The same happened to me! Now I'm using fltk-2.0.x-r5990 plus this patch: ------------------------------------------------------------------------------ diff -pru fltk-2.0.x-r5990/src/message.cxx fltk-2.0.x-r6059/src/message.cxx --- fltk-2.0.x-r5990/src/message.cxx 2007-11-28 16:42:30.000000000 -0300 +++ fltk-2.0.x-r6059/src/message.cxx 2008-02-22 20:00:05.000000000 -0300 @@ -1,5 +1,5 @@ // -// "$Id: message.cxx 5990 2007-11-28 19:42:30Z dejan $" +// "$Id: message.cxx 6041 2008-02-22 23:00:05Z fabien $" // // Copyright 1998-2006 by Bill Spitzak and others. // @@ -429,7 +429,7 @@ static const char* input_innards(const c const char* defstr, uchar type) { int r = innards("?", defstr ? defstr : "", type, fmt, ap, fltk::cancel, fltk::ok, 0); - return r>=0 ? textfield->text() : 0; + return r>0 ? textfield->text() : 0; } /*! ------------------------------------------------------------------------------ -- Cheers Jorge.-

March 18, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > I made a dStr_dstrcat(). > What's the main advantage of it, over dStr_append_l() ? I see the convenience and clarity of passing two parameters instead of three, but on the other hand, keeping APIs reduced to a functional minimum, helps to remember and to choose the right function call. There may be a point I don't yet see... -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Mon, Mar 17, 2008 at 09:09:04PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is a small optinization to Html_parse_entities (). > > > > Committed. > > Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. > See my patch below: > > Kind Regards, Ooops, committed. -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > Hi, > > > > below is a small optinization to Html_parse_entities (). > > Committed. Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. See my patch below: Kind Regards, Christian Index: src/html.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v retrieving revision 1.53 diff -b -u -r1.53 html.cc --- src/html.cc 17 Mar 2008 19:04:11 -0000 1.53 +++ src/html.cc 17 Mar 2008 20:19:21 -0000 @@ -3844,7 +3844,8 @@ int rc = 0; Dstr *output; const int bufsize = 128; - char *buffer, *inPtr, *outPtr; + inbuf_t *inPtr; + char *buffer, *outPtr; size_t inLeft, outRoom; bool bad_chars = false; -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 17, 2008

patch: multipart/form-data CRLF

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:29:32PM +0000, place wrote: > Happened to notice in the RFC that multipart types must use CRLF between > body parts. Committed. > PS It was a bit annoying to figure out that http.c needed to be changed, > which suggests that it would have been better for me to store the boundary > string in DilloUrl somewhere after all. It happens. A long time ago I dedicated a long time to generate a minimal perfect hash function for finding HTML tags. It turned out that asimple binary search was simpler and with the same performance... -- Cheers Jorge.-

March 17, 2008

saving files under recent fltk snapshots?

by place＠gobigwest.com

I moved to snapshot 6066 (I'd been on 5990) the other day, and now I notice that dillo is unresponsive after I save a file. Seen in the 6059 announcement (http://fltk.org/articles.php?L791) "+ Changed the modal event loop of file_chooser() and dir_chooser() to use a new exec() method that delegates to Window::exec() internally. This exec() method should handle unpleasant side effects with other modal windows when closing the file_chooser dialog window. + Updated FileChooser.fl to reflect modifications made in the cxx/h files. Please do not edit these files directly (except the include header) Thanks." If anybody's tried a recent snapshot: Does it work for you?

March 17, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > Hi, > > below is a small optinization to Html_parse_entities (). Committed. -- Cheers Jorge.-

March 17, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. Garret wrote a good part of the certificate handling, you will find that code inside the plugin. > The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. Yes. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again. > > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar. > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. > > But on the other hand couldn't this be done by dpid for all filter > plugins? For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that. > Dpid can keep them alive as long as the following requests > belong to the same URL, then closing the connection after a timeout? > > I am sorry if this has been already decided on before. These thoughts > were rumaging aroung my head all day now... I hope these lines help. -- Cheers Jorge.-

March 17, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > [Jeremey wrote] > > Getting https working would greatly reduce the number of times I > > run Firefox! > > I thought many https sites needed javascript to work. _Please_ > correct me if I'm wrong. :-) Well, I can surf my ISPs forums with dillo-fltk now that https is working. That's something! Regards, Jeremy Henty

March 17, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by place＠gobigwest.com

> Your patch below works great for me. :) Here's a proper patch with proper comments. PS If anybody happens to have deep knowledge of various sorts of networking, maybe they'll know an optimal value for a BufSize test. All I know is that modem mtu is 15xx.

March 16, 2008