- Dillo-dev - lists.mailman3.com

Opening new URL in same instance and -s option

by Rainer M Krug

Hi I have two questions first: I would like to be able to have only one instance of dillo open and when I try to open a new url (from outside dillo), that this url is opened in the old instance. Is this possible, and if yes, how? second: I have seen emails concerning running dillo in server mode (dillo -s server). I tried it, but dillo didn't know -s. Is this feature imp[lemented, and if yes, how can I access it? Thanks a lot for a brilliant lightning fast browser, Rainer -- Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology and Entomology University of Stellenbosch Matieland 7602 South Africa Tel: +27 - (0)72 808 2975 (w) Fax: +27 - (0)21 808 3304 Cell: +27 - (0)83 9479 042 email: RKrug(a)sun.ac.za Rainer(a)krugs.de

Sept. 21, 2006

[abc@ai1.anchorage.mtaonline.net: frames/fltk]

by Jorge Arellano Cid

-- Cheers Jorge.-

Sept. 14, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by Jorge Arellano Cid

On Thu, Sep 07, 2006 at 07:38:27PM -0500, R.L. Horn wrote: > On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: > > >>(Actually, this is functionality that would be nice in the main branch, > >>albeit with its own plugin and user-selectivity. If there's interest, > >>please let me know.) > > > > Yes, more or less this is the plan. > > Great! > > > OK, a good workaround is to check for huge filesizes while parsing the > >header and to set as if no Content-length was given in that case. This > >is simple and will work. > > That's kind of what I did. Actually, I just removed the code that had to do > with static buffers entirely (while still allowing for a Content-length > check). > > If the GTK branch weren't pretty well deprecated, I'd go ahead and do it > right: Add a boolean to the "entry" structure to indicate a fully allocated > buffer and complete the allocation (where reasonable) at dispatch time. The flag is already there: > if ( (Length = Cache_parse_field(header, "Content-Length")) != NULL ) { > entry->Flags |= CA_GotLength; /*** Here! ***/ > entry->TotalSize = strtol(Length, NULL, 10); > g_free(Length); > if (entry->TotalSize < entry->ValidSize) > entry->TotalSize = 0; > } -- Cheers Jorge.-

Sept. 8, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by R.L. Horn

On Thu, 7 Sep 2006, Jorge Arellano Cid wrote: >> (Actually, this is functionality that would be nice in the main branch, >> albeit with its own plugin and user-selectivity. If there's interest, >> please let me know.) > > Yes, more or less this is the plan. Great! > OK, a good workaround is to check for huge filesizes while parsing the > header and to set as if no Content-length was given in that case. This > is simple and will work. That's kind of what I did. Actually, I just removed the code that had to do with static buffers entirely (while still allowing for a Content-length check). If the GTK branch weren't pretty well deprecated, I'd go ahead and do it right: Add a boolean to the "entry" structure to indicate a fully allocated buffer and complete the allocation (where reasonable) at dispatch time.

Sept. 8, 2006

Re: [Dillo-dev] Serious Memory Allocation Strategy Problem in Cache_parse_header()

by Jorge Arellano Cid

Hi, On Wed, Sep 06, 2006 at 08:12:42PM -0500, R.L. Horn wrote: > I'm currently in the process of modifying dillo for use in browsing an http > media server (yeah, I know it's httpd abuse, but it's only for a local > network and I was running Apache anyhow). At present, this basically > involves sending a modified downloads plugin an "execute" command and the > MIME type when AbortEntry is true in Cache_process_queue() (the plugin then > executes an agent which deals with the URL entirely independent of dillo). > > (Actually, this is functionality that would be nice in the main branch, > albeit with its own plugin and user-selectivity. If there's interest, > please let me know.) Yes, more or less this is the plan. > > So far, so good -- it seems to work passably well and it only took a couple > of hours. Easy peasey. Unfortunately, the first time I click on a 700M > video stream, things go horribly wrong. > > Seems that Cache_parse_header() attempts to allocate memory for the entire > content *before* the header has been checked for viewability (since the > dispatcher isn't called until Cache_process_queue()). As it happens, this > has been reported as bug 726. Yes. I fixed this sometime ago in the FLTK2 branch... > > The upshot of all this is that when you click on a link, there had better > be room for the whole thing in heap even though the content may never be > read. Otherwise, glib just gives up and dumps core via g_malloc(). > > I think I can get around this by doing a Content-Type check in > Cache_parse_header(). I'd be happy to provide a patch provided I can come > up with a reasonably elegant solution. > > Any advice would be appreciated. OK, a good workaround is to check for huge filesizes while parsing the header and to set as if no Content-length was given in that case. This is simple and will work. (My FLTK2 source uses automatic buffers from a new library I made that also replaces glib). -- Cheers Jorge.-

Sept. 7, 2006

Serious Memory Allocation Strategy Problem in Cache_parse_header()

by R.L. Horn

I'm currently in the process of modifying dillo for use in browsing an http media server (yeah, I know it's httpd abuse, but it's only for a local network and I was running Apache anyhow). At present, this basically involves sending a modified downloads plugin an "execute" command and the MIME type when AbortEntry is true in Cache_process_queue() (the plugin then executes an agent which deals with the URL entirely independent of dillo). (Actually, this is functionality that would be nice in the main branch, albeit with its own plugin and user-selectivity. If there's interest, please let me know.) So far, so good -- it seems to work passably well and it only took a couple of hours. Easy peasey. Unfortunately, the first time I click on a 700M video stream, things go horribly wrong. Seems that Cache_parse_header() attempts to allocate memory for the entire content *before* the header has been checked for viewability (since the dispatcher isn't called until Cache_process_queue()). As it happens, this has been reported as bug 726. The upshot of all this is that when you click on a link, there had better be room for the whole thing in heap even though the content may never be read. Otherwise, glib just gives up and dumps core via g_malloc(). I think I can get around this by doing a Content-Type check in Cache_parse_header(). I'd be happy to provide a patch provided I can come up with a reasonably elegant solution. Any advice would be appreciated.

Sept. 7, 2006

Re: [Dillo-dev] Patches

by Jan Stary

On Sep 03 14:22:41, Rob Cherveny wrote: > I have freebsd and am using dillo. > Can someone help me install the patch > for using tabs? just use ports/www/dillo-i18n h.

Sept. 6, 2006

Re: [Dillo-dev] More signal :-)

by Jorge Arellano Cid

On Mon, Sep 04, 2006 at 08:57:14PM +0200, leslie.polzer(a)gmx.net wrote: > On Sun, Sep 03, 2006 at 10:50:21AM -0400, Jorge Arellano Cid wrote: > > > On Fri, Sep 01, 2006 at 02:03:42PM -0400, Roberto C. Sanchez wrote: > > > > > When will the transition to FLTK begin? > > > > ?? > > > > It started a long time ago, circa the beginning of 2005, with the > > rendering abstraction layer. Now we have a prototype that's very > > advanced and unreleased. > I suppose the OP wanted to know when the FLTK port will be released. I don't know; most probably when we have the funds. Otherwise we have yet to decide what to do. > One question and a comments: why is it unreleased at this time? Some companies want to have an advantage to justify investment (as a six month window for instance), some others not. This may be the case. Companies looking to reduce costs, just take whatever is there and don't give back. BTW, this happened most of the time with the GTK1 branch of Dillo. FWIW, our idea has always been to have a Free SW Dillo with a view to accomplish its goals. If we had aimed for selling Dillo as propietary SW, it would have happened already. > I'm one of the people waiting for the FLTK thing to show up before I > look whether I'm able and willing to contribute to Dillo. It's a great > browser, and I'd like to help, but not by working on code that's > obsolete. Good! Sure, I understand the point. BTW, do you have FLTK2 experience? How much time are you willing to contribute to development? -- Cheers Jorge.-

Sept. 4, 2006

Re: [Dillo-dev] More signal :-)

by leslie.polzer＠gmx.net

On Sun, Sep 03, 2006 at 10:50:21AM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 01, 2006 at 02:03:42PM -0400, Roberto C. Sanchez wrote: > > > When will the transition to FLTK begin? > > ?? > > It started a long time ago, circa the beginning of 2005, with the > rendering abstraction layer. Now we have a prototype that's very > advanced and unreleased. I suppose the OP wanted to know when the FLTK port will be released. One question and a comments: why is it unreleased at this time? I'm one of the people waiting for the FLTK thing to show up before I look whether I'm able and willing to contribute to Dillo. It's a great browser, and I'd like to help, but not by working on code that's obsolete. Leslie -- gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 http://nic-nac-project.de/~skypher/

Sept. 4, 2006

Re: [Dillo-dev] Patches

by Rob Funky

Perfect! Thankyou! I could not locate that page with google! Rob On 9/3/06, Tito <farmatito(a)tiscali.it> wrote: > > On Sunday 3 September 2006 20:22, Rob Cherveny wrote: > > I have freebsd and am using dillo. Can someone help me install the > patch > > for using tabs? > > http://teki.jpn.ph/pc/software/index-e.shtml > > > Thank you > > rob > > > > _______________________________________________ > Dillo-dev mailing list > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 3, 2006