- Dillo-dev - lists.mailman3.com

focus after closing tab

by jcid＠dillo.org

On Thu, Jan 15, 2009 at 04:34:10PM +0100, Hofmann Johannes wrote: > On Thu, Jan 15, 2009 at 08:42:22AM -0300, Jorge Arellano Cid wrote: > > On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > > > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > > > > > What do you think, which page should be focused when closing a tab: > > > > > > > * the most recently opened one? > > > > > > +1 . It would certainly be better than the current behaviour. > > > > Current behaviour is a bug. Without experience on the subject I'd > > say let's follow firefox bahaviour on this. > > As far as I can tell firefox always switches to the right most tab > which should for us be equivalent to the most recently opened one > (as we do not allow to reorder tabs). > > Attached patchlet implements this behaviour for dillo. Committed. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 15, 2009

Re: A couple of patches

by Johannes.Hofmann＠gmx.de

On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: * snip* > > BTW, I have a question. How can a minimal font size be specified? > Currently I have: > > body {font-size: 18px !important} > > in style.css, but often pages come with smaller fonts. e.g. > http://www.linux.org.uk/Portaloo.cs > > For me is important because I have a problems reading tiny fonts, > and my working laptop has a high screen resolution. I've just made a change that uses the existing prefs.font_factor value to scale the base font. However this only applies to relative font sizes. If someone specifies "font-size: 10px" you will still get 10px, but I think this is correct anyway. In addition we can add some minimal_fontsize option in the future. Cheers, Johannes

Jan. 15, 2009

focus after closing tab

by Johannes.Hofmann＠gmx.de

On Thu, Jan 15, 2009 at 08:42:22AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > > > What do you think, which page should be focused when closing a tab: > > > > > * the most recently opened one? > > > > +1 . It would certainly be better than the current behaviour. > > Current behaviour is a bug. Without experience on the subject I'd > say let's follow firefox bahaviour on this. As far as I can tell firefox always switches to the right most tab which should for us be equivalent to the most recently opened one (as we do not allow to reorder tabs). Attached patchlet implements this behaviour for dillo. Cheers, Johannes

Jan. 15, 2009

Re: A couple of patches

by Johannes.Hofmann＠gmx.de

On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > > Hi Jorge, > > > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > Here go couple of patches. Please test and apply. > > > > Thanks, applied. > > > > > > > > Note: the image background support is partial. It works well > > > when coming back to a page. AFAIS the right solution is to decode > > > transparent images to RGBA and let FLTK handle it. > > > > Yes, I think that would be the correct way to do it. > > > > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > > What do you think? > > > > Yes, it feels pretty stable and now that there is an option to > > disable remote stylesheet loading, I think we can consider making > > css-prototype the main branch of dillo. > > However I'd like to have some issues fixed: > > > > * should load_stylesheets=NO only disable remote style-sheet loading > > (as it does now), or should it disable all remote style processing > > (e.g. style given in <style type="text/css"> </style>)? > > We can add a "parse_embedded_css" option. That way there's no > ambiguity. > > My next task is to add the toolbox button mentioned in: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html > > It may hold CSS options akin to: > > [Tb Icon] > .-------------------. .---------. > | Change charset >|--------------------------------->| UTF-8 | > | CSS >|-->.---------------. | Cp 1250 | > | Free memory >|-. |* remote CSS | | ... | > '-------------------' | |* embedded CSS | '---------' > | |* use my CSS | > | |* no CSS at all| > | '---------------' > | .------------------. > '->| Images | > | Local Files | > | Everything unused | > '-------------------' > > Note: '*' means a toggle option > Note2: "use my CSS" replaces "Force my colors" > > We can polish from there. Ok, but I think we can reduce the CSS part to * remote CSS - meaning separate stylesheets * embedded CSS - meaning CSS in <style></style> or style="" attribute I think we should always use "my CSS" if it exists. "no CSS at all" would be the same as no .dillo/style.css and "remote CSS" and "embedded CSS" switched off. > > > > * form.cc is not yet converted to the new style handling and widget > > coloring is broken. > > OK. > > > * css-prototype displays e.g. table borders in the current color not > > in shaded background-color as dillo-main does. > > This is because CSS 2.1 states: > > "If an element's border color is not specified with a border > > property, user agents must use the value of the element's 'color' > > property as the computed value for the border color. " > > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > > firefox however also uses a shaded background color. > > I'd don't know how to deal with that at the moment. > > I'd say leave it as the standard says until it becomes an issue. > In that case we can follow FF or decide better. The problem is that I'm not sure I understand the standard properly. Firefox is generally pretty standard compliant. But it's not a big issue anyway. > > > > Then there is of course tons of issues with CSS, but we can improve > > on that gradually. > > That's the idea. > > > BTW, I have a question. How can a minimal font size be specified? > Currently I have: > > body {font-size: 18px !important} The problem is that this can be overridden e.g. by later <font size=10> elements. * {font-size: 18px !important} should fix the font size to 18px. However we probabely want an non-CSS option in dillorc to set a minimum font size. > > in style.css, but often pages come with smaller fonts. e.g. > http://www.linux.org.uk/Portaloo.cs > > For me is important because I have a problems reading tiny fonts, > and my working laptop has a high screen resolution. css-prototype seems to use pretty small fonts generally. This may be a bug. Cheers, Johannes

Jan. 15, 2009

Re: A couple of patches

by jcid＠dillo.org

Hi Johannes, On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here go couple of patches. Please test and apply. > > Thanks, applied. > > > > > Note: the image background support is partial. It works well > > when coming back to a page. AFAIS the right solution is to decode > > transparent images to RGBA and let FLTK handle it. > > Yes, I think that would be the correct way to do it. > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > What do you think? > > Yes, it feels pretty stable and now that there is an option to > disable remote stylesheet loading, I think we can consider making > css-prototype the main branch of dillo. > However I'd like to have some issues fixed: > > * should load_stylesheets=NO only disable remote style-sheet loading > (as it does now), or should it disable all remote style processing > (e.g. style given in <style type="text/css"> </style>)? We can add a "parse_embedded_css" option. That way there's no ambiguity. My next task is to add the toolbox button mentioned in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html It may hold CSS options akin to: [Tb Icon] .-------------------. .---------. | Change charset >|--------------------------------->| UTF-8 | | CSS >|-->.---------------. | Cp 1250 | | Free memory >|-. |* remote CSS | | ... | '-------------------' | |* embedded CSS | '---------' | |* use my CSS | | |* no CSS at all| | '---------------' | .------------------. '->| Images | | Local Files | | Everything unused | '-------------------' Note: '*' means a toggle option Note2: "use my CSS" replaces "Force my colors" We can polish from there. > * form.cc is not yet converted to the new style handling and widget > coloring is broken. OK. > * css-prototype displays e.g. table borders in the current color not > in shaded background-color as dillo-main does. > This is because CSS 2.1 states: > "If an element's border color is not specified with a border > property, user agents must use the value of the element's 'color' > property as the computed value for the border color. " > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > firefox however also uses a shaded background color. > I'd don't know how to deal with that at the moment. I'd say leave it as the standard says until it becomes an issue. In that case we can follow FF or decide better. > Then there is of course tons of issues with CSS, but we can improve > on that gradually. That's the idea. BTW, I have a question. How can a minimal font size be specified? Currently I have: body {font-size: 18px !important} in style.css, but often pages come with smaller fonts. e.g. http://www.linux.org.uk/Portaloo.cs For me is important because I have a problems reading tiny fonts, and my working laptop has a high screen resolution. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 15, 2009

Re: focus after closing tab

by sandshrew＠gmail.com

I would vote for "the most recently opened one" too. -- Brain: an apparatus with which we think we think. - A. Bierce

Jan. 15, 2009

focus after closing tab

by jcid＠dillo.org

On Thu, Jan 15, 2009 at 06:03:28AM +0000, Jeremy Henty wrote: > On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > > > What do you think, which page should be focused when closing a tab: > > > * the most recently opened one? > > +1 . It would certainly be better than the current behaviour. Current behaviour is a bug. Without experience on the subject I'd say let's follow firefox bahaviour on this. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 15, 2009

CSS speed

by Johannes.Hofmann＠gmx.de

On Wed, Jan 14, 2009 at 03:40:23PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 13, 2009 at 08:00:37PM +0000, corvid wrote: > > > Johannes wrote: > > > > pages with complex CSS feel a bit slow with the current css-prototype > > > > and gprof shows a huge number of CssSelector::match() calls. > > > > Attached is a patch that tries to improve that by: > > > > > > > > * putting CssSelectors into hashtables so that we only need to match > > > > against a small subset of CssSelectors. > > > > > > > > * avoiding repeated matches of CssSimpleSelectors against the same > > > > part of the doctree. > > > > > > > > Please test and report if there is a real world speedup. > > > > > > Wow! > > > > > > In the past, my best example had been pages on reddit.com that had > > > at least maybe 300 comments. They had been unusably slow--although > > > this would encourage a person not to waste time looking at reddit. > > > > > > Quite usable now. > > > > Great. reddit.com is looking strange though. There is this weird > > blue circle... > > I think it's an iframe's bullet hypertrophied by > > #ad-frame { > border: 0px; > overflow: hidden; > width: 300px; > height: 300px; > } > > <iframe id="ad-frame" frameborder="0" scrolling="no" name="ad-frame" src="/static/ad_default.html"></iframe> Ah right. We should probabely disable style processing for content that dillo generates on its own (e.g. <object> or <(i)frame> replacements). Cheers, Johannes

Jan. 15, 2009

focus after closing tab

by onepoint＠starurchin.org

On Tue, Jan 13, 2009 at 02:03:33PM +0100, Hofmann Johannes wrote: > What do you think, which page should be focused when closing a tab: > * the most recently opened one? +1 . It would certainly be better than the current behaviour. Regards, Jeremy Henty

Jan. 15, 2009

Dillo 2 in Tiny Core Linux

by corvid＠lavabit.com

Colin wrote: > Dillo 2 doesn't use any OpenGL does it? I compiled FLTK 2 without OpenGL > support, and I didn't know if that would be a problem. Nope. I normally configure fltk without gl. It's a little bit annoying that fltk2 still tries to compile its tests that use OpenGL, but not a big deal... PS I was trying to list my idea of dependencies in the FAQ recently because one of my pet peeves is when I want to try some software but it turns out that it won't compile unless I get a ton of libraries...which in turn each require a ton of libraries...and then I typically cut my losses and delete it all.

Jan. 15, 2009