- Dillo-dev - lists.mailman3.com

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

Re: dillo bug 916

by corvid＠lavabit.com

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...

Aug. 2, 2009

Re: dillo bug 916

by jcid＠dillo.org

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. -- Cheers Jorge.-

Aug. 2, 2009