August 2009 - Dillo-dev - lists.mailman3.com

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) > [...] > Now after dns resolution times out, retrying in a new window/tab > doesn't seem to work. Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.-

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.-

Aug. 6, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > As said in CCCwork.txt it would be good to build the > > whole chain in one single step (for simplicity) and to > > define a standard way to end/abort the CCC (which I've > > given some thought). If muses decide to pay me a visit, > > I may develop a patch for this soon. :-) > > Good news. > > I already have dillo running on CCCs that build in one step > (both for HTTP and DPI), and also updated the documentation. It's > quite stable and behaves very well. Now I have to think what to > do with the gained simplicity. :) Something isn't working right in the new code for Abort. If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault. (interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)

Aug. 6, 2009

Re: patch: media_type pref

by jcid＠dillo.org

On Wed, Aug 05, 2009 at 03:07:54AM +0000, corvid wrote: > I wrote, some months ago: > > Jorge wrote: > > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > > It makes more sense to have a pref that the user can > > > > control than for us to guess what they might like > > > > based on screen size or whatever, I think. > > > > > > I hesitate on this. For instance: if media_type is defined to > > > "handheld" and there's no such remote CSS, at least it should > > > fallback to "screen". > > > > If there is a handheld style sheet available and dillo is running > > on a handheld, it would be a shame not to use it. I'm hoping that > > the page author would have the sense to supply something for type "all". > > > > > Maybe it's more practical to provide custom stylesheets (as the > > > current "style.css". e.g. small_screen.css, print.css) and to > > > allow switching among them from the "Tools" menu. > > > > > > What do you think? > > > > I think someone using handheld would want to use both the page > > author's handheld-specific code and a user style suitable for > > their device. > > > > I'll send this to the list in case anyone with experience using > > such devices with the web has opinions to share. > > I never was able to talk Jorge into this one, but I > might as well make the code available so that people > with handhelds can have it if they wish. I don't have a handheld and seldom use one. Despite my efforts, my attempts to try to give good advice on it in the past have proved clumsy and of no much use, so I prefer to follow the advice from the ones using them all the time (e.g. Andreas Kemnade). -- Cheers Jorge.-

Aug. 5, 2009

Re: patch: media_type pref

by corvid＠lavabit.com

I wrote, some months ago: > Jorge wrote: > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > It makes more sense to have a pref that the user can > > > control than for us to guess what they might like > > > based on screen size or whatever, I think. > > > > I hesitate on this. For instance: if media_type is defined to > > "handheld" and there's no such remote CSS, at least it should > > fallback to "screen". > > If there is a handheld style sheet available and dillo is running > on a handheld, it would be a shame not to use it. I'm hoping that > the page author would have the sense to supply something for type "all". > > > Maybe it's more practical to provide custom stylesheets (as the > > current "style.css". e.g. small_screen.css, print.css) and to > > allow switching among them from the "Tools" menu. > > > > What do you think? > > I think someone using handheld would want to use both the page > author's handheld-specific code and a user style suitable for > their device. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. I never was able to talk Jorge into this one, but I might as well make the code available so that people with handhelds can have it if they wish.

Aug. 5, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > As said in CCCwork.txt it would be good to build the > whole chain in one single step (for simplicity) and to > define a standard way to end/abort the CCC (which I've > given some thought). If muses decide to pay me a visit, > I may develop a patch for this soon. :-) Good news. I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :) Bottom line: don't waste much time with the CCC and its docs in current repo, most probably they will be replaced soon. -- Cheers Jorge.-

Aug. 5, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Jorge wrote: > On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > > Scott wrote: > > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > > > Scott had reported: > > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > > of letting the window manager do its job. > > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > > Apps should not try to do their own window management." > > > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > > that a partially hidden Dillo window raises upon clicking it. > > > > > I hesitate because Firefox and even terminals here behave that > > > > > way. Please explain. > > > > > > > > Other windows don't for me. Dillo does if it's > > > > a new window/new tab or if I'm clicking below the bottom > > > > of the text when the page is very short. > > > > I imagine your WM must be set to do it... > > > > > > Oh, now I see it (with TWM). > > > Please commit. > > > > Yes, but we should mark it as a workaround for an FLTK issue and > > report it to FLTK. > > Exactly! > > (even though I have more hope for their 1.3 branch). Judging from the comment I mentioned: > fltk's Window::handle() has: > #if USE_X11 > case PUSH: > // Unused clicks should raise the window. Windows unfortunatly > // raises the window on *all* clicks so we don't bother except on X. > if (shown()) XMapRaised(xdisplay, i->xid); > #endif they seem to view it as correct, although it seems strangely arbitrary to me.

Aug. 3, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > Scott wrote: > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > Scott had reported: > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > of letting the window manager do its job. > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > Apps should not try to do their own window management." > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > that a partially hidden Dillo window raises upon clicking it. > > > > I hesitate because Firefox and even terminals here behave that > > > > way. Please explain. > > > > > > Other windows don't for me. Dillo does if it's > > > a new window/new tab or if I'm clicking below the bottom > > > of the text when the page is very short. > > > I imagine your WM must be set to do it... > > > > Oh, now I see it (with TWM). > > Please commit. > > Yes, but we should mark it as a workaround for an FLTK issue and > report it to FLTK. Exactly! (even though I have more hope for their 1.3 branch). -- Cheers Jorge.-

Aug. 3, 2009

Re: dillo bug 916

by Johannes.Hofmann＠gmx.de

On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > Scott wrote: > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > Scott had reported: > > > > "Dillo sometimes raises its window when clicked, instead > > > > of letting the window manager do its job. > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > Apps should not try to do their own window management." > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > that a partially hidden Dillo window raises upon clicking it. > > > I hesitate because Firefox and even terminals here behave that > > > way. Please explain. > > > > Other windows don't for me. Dillo does if it's > > a new window/new tab or if I'm clicking below the bottom > > of the text when the page is very short. > > I imagine your WM must be set to do it... > > Oh, now I see it (with TWM). > Please commit. Yes, but we should mark it as a workaround for an FLTK issue and report it to FLTK.

Aug. 3, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > Scott wrote: > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > Scott had reported: > > > "Dillo sometimes raises its window when clicked, instead > > > of letting the window manager do its job. > > > Usually if I have a window partially hidden, I don't want it raised... > > > Apps should not try to do their own window management." > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > that a partially hidden Dillo window raises upon clicking it. > > I hesitate because Firefox and even terminals here behave that > > way. Please explain. > > Other windows don't for me. Dillo does if it's > a new window/new tab or if I'm clicking below the bottom > of the text when the page is very short. > I imagine your WM must be set to do it... Oh, now I see it (with TWM). Please commit. -- Cheers Jorge.-

Aug. 3, 2009