Hi all. I'm wondering if "BW2UI(new_bw)->tabs()->selected_child()->take_focus()" is really needed in a_UIcmd_open_url_nt. I usually hit space bar to scroll down but I can't do this when I open a new tab by clicking middle mouse button. The reason is that cursor stays on address bar so that I just add space at the end of url if I hit space bar. Regards, furaisanjin
On Sat, Nov 21, 2009 at 05:33:24PM +0900, furaisanjin wrote:
Hi all.
I'm wondering if "BW2UI(new_bw)->tabs()->selected_child()->take_focus()" is really needed in a_UIcmd_open_url_nt. I usually hit space bar to scroll down but I can't do this when I open a new tab by clicking middle mouse button. The reason is that cursor stays on address bar so that I just add space at the end of url if I hit space bar.
Good point. I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab. Cheers, Johannes
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well. Regards, furaisanjin
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing. -- Cheers Jorge.-
On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing.
does anybody know, why BW2UI(new_bw)->tabs()->selected_child()->take_focus(); focusses the location text input? Cheers, Johannes
Johannes wrote:
On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing.
does anybody know, why BW2UI(new_bw)->tabs()->selected_child()->take_focus(); focusses the location text input?
I wouldn't be surprised if fltk chooses it because it's the UI's first child.
On Thu, Nov 26, 2009 at 08:56:52PM +0000, corvid wrote:
Johannes wrote:
On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
> I would propose something as in attached patch to ensure that > Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing.
does anybody know, why BW2UI(new_bw)->tabs()->selected_child()->take_focus(); focusses the location text input?
I wouldn't be surprised if fltk chooses it because it's the UI's first child.
Indeed! With below patch, the dummy CustInput get's the focus. diff -r 90fabbb4077b src/ui.cc --- a/src/ui.ccSun Nov 22 18:35:48 2009 +0100 +++ b/src/ui.ccThu Nov 26 22:06:51 2009 +0100 @@ -444,6 +444,7 @@ b->callback(clear_cb, this); b->clear_tab_to_focus(); + new CustInput(0,0,100,0,0); Input *i = Location = new CustInput(0,0,0,0,0); i->color(CuteColor); i->when(WHEN_ENTER_KEY);
On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing.
I committed a slightly different patch to also cover the case when middle_click_opens_new_tab=NO Please test, Johannes
Johannes wrote:
On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote:
2009/11/26, Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote:
On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote:
I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab.
+1
+1
I hope the patch will be part of dillo soon. The patch works very well.
@Johannes, please comment what the change is for before committing.
I committed a slightly different patch to also cover the case when middle_click_opens_new_tab=NO
This is a good improvement. Having the Location focused in a new window == :) I notice that, after shift-button2 on a link, shift-right_arrow doesn't work until I click on things a bit.
2009/11/28 Johannes Hofmann <Johannes.Hofmann@gmx.de>:
I committed a slightly different patch to also cover the case when middle_click_opens_new_tab=NO
Please test,
I tested but I found still there were cases where cursor stayed on address bar. Could you consider this patch? diff -r 292c1755001c src/web.cc --- a/src/web.cc Sat Nov 28 09:56:57 2009 +0900 +++ b/src/web.cc Sat Nov 28 12:59:41 2009 +0900 @@ -87,6 +87,7 @@ /* Let the Nav module know... */ a_Nav_expect_done(Web->bw); + a_UIcmd_focus_main_area (Web->bw); } else { /* A non-RootUrl. At this moment we only handle image-children */ After page rendering finishes, focus is changed to main area so that cursor doesn't stay on address bar. Regards, furaisanjin
On Sat, Nov 28, 2009 at 01:06:21PM +0900, furaisanjin wrote:
2009/11/28 Johannes Hofmann <Johannes.Hofmann@gmx.de>:
I committed a slightly different patch to also cover the case when middle_click_opens_new_tab=NO
Please test,
I tested but I found still there were cases where cursor stayed on address bar. Could you consider this patch?
Can you please describe the situation where it happens? I'm a bit reluctant to sprinkle focus handling code all over the place. Regards, Johannes
2009/12/2 Johannes Hofmann <Johannes.Hofmann@gmx.de>:
Can you please describe the situation where it happens?
There are 2 cases. 1. When dillo starts, cursor stays on address bar and this is the side effect of the updated codes. 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. Regards, furaisanjin
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.)
2009/12/2 corvid <corvid@lavabit.com>:
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.
I agree but current dillo behavior isn't good either. If I type something on address bar before a page rendering finishes, typed characters are appended after URL when URL is pushed on address bar. I think only typed characters should remain there when the page rendering finishes. Regards, furaisanjin
On Wed, Dec 02, 2009 at 09:33:45PM +0900, furaisanjin wrote:
2009/12/2 corvid <corvid@lavabit.com>:
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.
I agree but current dillo behavior isn't good either. If I type something on address bar before a page rendering finishes, typed characters are appended after URL when URL is pushed on address bar. I think only typed characters should remain there when the page rendering finishes.
Yes, that's annoying, but I think it's a separate issue. Regards, Johannes
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. Cheers, Johannes
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);
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.
2009/12/15 Johannes Hofmann <Johannes.Hofmann@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
On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote:
2009/12/15 Johannes Hofmann <Johannes.Hofmann@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
Johannes wrote:
On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote:
2009/12/15 Johannes Hofmann <Johannes.Hofmann@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.
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@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
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@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.
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@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
Johannes wrote:
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@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.
Oh, I see the confusion now. I must have misapplied that last version somehow, because it wasn't changing focus for me, but now using that same patch from tip seems to be working fine. Sorry about that.
participants (6)
-
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org -
tim.nieradzik＠gmx.de