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

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Thu, Dec 17, 2009 at 12:37:36AM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > > > Any opinions? Does this solve the problem? > > > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > > > Looks good to me. Is this ok for all? > > > > If there are no complaints I would commit a slightly modified version (attached). > > > > > > I think I like having Location lose focus after I press enter. > > > > but the patch I had proposed originally doesn't seem to fix all of > > furaisanjin's issues. E.g. when starting dillo with an URL on > > the commandline, the location bar will have the focus. > > > > Are there cases where my furaisanjin's patch causes unexpected > > switches of focus, i.e. not triggered directly by a user action? > > I've completely lost track of what various versions do; > I'm just saying that typing in an address, pressing enter, and > having focus switch from Location to Main is nice. Ah ok. I just committed furaisanjin's patch with a minor change. I there should be unexpected focus switches please report them, so we can look it this again. Cheers, Johannes

Dec. 17, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > > Any opinions? Does this solve the problem? > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > Looks good to me. Is this ok for all? > > > If there are no complaints I would commit a slightly modified version (attached). > > > > I think I like having Location lose focus after I press enter. > > but the patch I had proposed originally doesn't seem to fix all of > furaisanjin's issues. E.g. when starting dillo with an URL on > the commandline, the location bar will have the focus. > > Are there cases where my furaisanjin's patch causes unexpected > switches of focus, i.e. not triggered directly by a user action? I've completely lost track of what various versions do; I'm just saying that typing in an address, pressing enter, and having focus switch from Location to Main is nice.

Dec. 17, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > > Any opinions? Does this solve the problem? > > > > > > Could you consider this patch? This solves both problems I reported. > > > > Looks good to me. Is this ok for all? > > If there are no complaints I would commit a slightly modified version (attached). > > I think I like having Location lose focus after I press enter. but the patch I had proposed originally doesn't seem to fix all of furaisanjin's issues. E.g. when starting dillo with an URL on the commandline, the location bar will have the focus. Are there cases where my furaisanjin's patch causes unexpected switches of focus, i.e. not triggered directly by a user action? Cheers, Johannes

Dec. 16, 2009

take_focus on a new tab

by tim.nieradzik＠gmx.de

> I think I like having Location lose focus after I press enter. I agree. This would be nice. --Tim

Dec. 15, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > > Any opinions? Does this solve the problem? > > > > Could you consider this patch? This solves both problems I reported. > > Looks good to me. Is this ok for all? > If there are no complaints I would commit a slightly modified version (attached). I think I like having Location lose focus after I press enter.

Dec. 15, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > 2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > Any opinions? Does this solve the problem? > > Could you consider this patch? This solves both problems I reported. Looks good to me. Is this ok for all? If there are no complaints I would commit a slightly modified version (attached). Cheers, Johannes

Dec. 15, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/15 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Any opinions? Does this solve the problem? Could you consider this patch? This solves both problems I reported. diff -r c38e7c577023 src/uicmd.cc --- a/src/uicmd.cc Thu Dec 10 21:50:17 2009 +0000 +++ b/src/uicmd.cc Tue Dec 15 21:17:49 2009 +0900 @@ -604,6 +604,7 @@ if (url) { a_Nav_push(bw, url); a_Url_free(url); + a_UIcmd_focus_main_area(bw); } } @@ -617,6 +618,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) { a_Nav_push(bw, url); + a_UIcmd_focus_main_area(bw); } static void UIcmd_open_url_nbw(BrowserWindow *new_bw, const DilloUrl *url) Regards, furaisanjin

Dec. 15, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > > furaisanjin wrote: > > > > 2. When URL is given on address bar, cursor stays on address bar after > > > > the page rendering finishes. This isn't side effect. This may be > > > > matter of taste but I don't like this behavior. > > > > > > We'll need to be careful if changing focus in this case, since > > > the user may be in the middle of typing something somewhere. > > > > > > (My local public library's site, if used in firefox, likes to reset > > > form fields with javascript when a page finishes loading, and it's > > > irritating.) > > > > What do all think about attached patch. It switches the focus when > > the user hits return. > > So the focus switch does not happen at some random time when the > > page has loaded which might be irritating. > > Any opinions? Does this solve the problem? I like it.

Dec. 15, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > furaisanjin wrote: > > > 2. When URL is given on address bar, cursor stays on address bar after > > > the page rendering finishes. This isn't side effect. This may be > > > matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > > > (My local public library's site, if used in firefox, likes to reset > > form fields with javascript when a page finishes loading, and it's > > irritating.) > > What do all think about attached patch. It switches the focus when > the user hits return. > So the focus switch does not happen at some random time when the > page has loaded which might be irritating. Any opinions? Does this solve the problem? Cheers, Johannes > > Cheers, > Johannes > diff -r a41372a38f02 src/ui.cc > --- a/src/ui.cc Wed Dec 02 17:40:33 2009 +0100 > +++ b/src/ui.cc Wed Dec 02 18:42:15 2009 +0100 > @@ -267,6 +267,7 @@ > * page. BUG: this must be investigated and reported to FLTK2 team */ > if (event_key() == ReturnKey) { > a_UIcmd_open_urlstr(a_UIcmd_get_bw_by_widget(i), i->value()); > + ui->focus_main(); > } > if (ui->get_panelmode() == UI_TEMPORARILY_SHOW_PANELS) { > ui->set_panelmode(UI_HIDDEN);

Dec. 14, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi Tim, On Sun, Dec 13, 2009 at 03:21:23AM +0100, Tim Nieradzik wrote: > I am still uncertain whether doing the display:none handling in > src/Html.cc is really superior. What I liked about corvid's approach is > the simplicity of the changes. It did not really involve any fundamental > changes. I'm not 100% sure yet either. > > Furthermore, I think handling of hidden elements is generally better > suited in dw/ because it's design-related. It would make the whole > separation useless, if we mixed parsing code with complex > evaluation-logic. Moreover, it should be possible to use the dw-stack > completely independent from Dillo's parsing code. Otherwise, this isn't > necessarily the case as the developer needs to implement hiding > manually. Well, I'm not sure if a independent widget library absolutely needs hiding / unhiding to be useful. > > We could also apply display:none to hidden form elements (what I've > tried in my patch). This is an advantage because dw's focus is not only > HTML and CSS. It should be usable for any other markup as well. > Therefore, I'd propose to introduce a general 'hidden' attribute > applicable to any element. In the parsing code, hidden HTML form fields > are simply converted and internally represented by an ordinary text > field which, however, is not displayed. I would agree if we would just have display:none and display:true or so. But to implement e.g. display:block, we need to add a new textblock or for tables we have to add a table widget. And this has to be done in html.cc as the complete structure of the widget tree is affected. But if we handle all values of display: other than "none" in html.cc, then why not handle "none" there as well? Also using display:none to hide form elements is a bit problematic, because then we loose the original value of display. When the user clicks "show hiddens", should we switch to display:block, or display:inline? > > I haven't done any benchmarks but I guess this approach is more > efficient in terms of memory usage and rendering speed. It doesn't > require to render the whole page repeatedly from scratch when hidden > elements are made visible as only a flag needs to be set. It's not > required to add new widgets to the dw-layout as with the other approach. > As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply > that the entire dw-tree in memory is freed and then reallocated > afterwards - just because one was made visible! For now we might simply not imlement a show display:none option. And for form elements we have it in place already. If we would implement changing the value of display: in place, then we would also have to support a change from e.g. inline to block. Additionally, I don't see a reason why we would have to through away the entire dw-tree in that case. We could just modify it in place and request a redraw. > > Would the code be really shorter if done in src/Html.cc? I doubt that as > we'd still need to check for the "display" value. Actually the patch > doesn't do any more than that. So the benefits wouldn't be that > striking. > > While I really like the idea of a DOM, I am somewhat concerned about the > performance. A DOM is great when it comes to manipulating the design at > runtime. It can be also useful for debugging purposes. However, as Dillo > does not aim to support JavaScript there is virtually no need for a DOM. > dw seems pretty flexible already and I guess it wouldn't be very > difficult to do minor contents manipulation stuff. We already have a DOM tree - though a degenerated one. It is needed for CSS (see styleengine.cc and doctree.hh). It would be pretty simple to expand it to a real tree (it's a stack atm). As you said, this would be needed for manipulating the layout at runtime (e.g. for :hover), for CSS adjacent sibling matching, and for JavaScript. > > If understood your DocTree concept correctly, we won't end up with > duplication as the DocTree represents both the contents and the style > whereas dw only takes care about rendering, right? This sounds > interesting but wouldn't it also mean that partial changes to the layout > (or contents) would result in re-rendering the whole page? > > Therefore, I'd endorse the DocTree concept if there were some kind of > 'change stack'. Changes can be 'reverted' and 'committed'. A commit then > leads to only render the changes. (This idea might also come in handy > with slow connections because we can make the 'commit'-rate dependent on > the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require > only one 'commit' whereas with slower connections there might be more. > How is this currently realized in Dillo, by the way?) You can already modify the widget tree and only the modified stuff will be redrawn. It's implemented in dw/*. Cheers, Johannes

Dec. 13, 2009