- Dillo-dev - lists.mailman3.com

findbar behaviour

by corvid＠lavabit.com

Here's what resulted, but it seems relatively inelegant:

Dec. 26, 2012

findbar behaviour

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 05:24:27PM +0000, corvid wrote: > Jorge wrote: > > IIRC, a relatively clean way to hook this shortcuts is to let the > > event get to the parent group, which in this case should focus its > > next child. > > I'm not quite sure what you're saying here... FLTK tries to deliver events in similar but different ways. AFAIR, for keystrokes, when a leaf widget is focused, it tries to deliver there first, and if not handled, then it goes upwards to its parent. If not handled all the way up, fltk tries "harder" to deliver it. Depending on the particular widget tree of the application and the internal algorithm used by fltk, is hard to predict exactly how this sequence goes. So a simple way to resolve the problem, is to code the handler in the common parent that encloses a closely related widget set (e.g. Findbar may do it in this case). e.g. let the event travel upwards to Findbar::handle(), do what's necessary there and return non zero (i.e. "handled"). (CustInput::handle() is a good example of this technique). -- Cheers Jorge.-

Dec. 26, 2012

findbar behaviour

by corvid＠lavabit.com

Jorge wrote: > IIRC, a relatively clean way to hook this shortcuts is to let the > event get to the parent group, which in this case should focus its > next child. I'm not quite sure what you're saying here...

Dec. 26, 2012

show_tooltip=NO

by jcid＠dillo.org

On Tue, Dec 25, 2012 at 12:42:52AM +0000, corvid wrote: > > tipwin still shows tooltips when show_tooltip=NO. Patch committed. -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 03:06:36AM +0000, corvid wrote: > > I have a recentish version of the html5 working draft as one page, and > it's over 6 megs. If I view source on it, this is rather slow and gives > me time to hit Escape and Ctrl-W. Then top shows vsource using all of > the processor until I kill it. > > (gdb) bt > #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) > at dpip.c:455 > #1 0x080491f9 in send_html_text (sh=0x9e7ae18, > url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) > at vsource.c:121 > #2 0x08049460 in main () at vsource.c:219 Patch committed. -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 03:06:36AM +0000, corvid wrote: > > I have a recentish version of the html5 working draft as one page, and > it's over 6 megs. If I view source on it, this is rather slow and gives > me time to hit Escape and Ctrl-W. Then top shows vsource using all of > the processor until I kill it. > > (gdb) bt > #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) > at dpip.c:455 > #1 0x080491f9 in send_html_text (sh=0x9e7ae18, > url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) > at vsource.c:121 > #2 0x08049460 in main () at vsource.c:219 Ah, yes. I'm testing a little patch for this now... -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by corvid＠lavabit.com

I have a recentish version of the html5 working draft as one page, and it's over 6 megs. If I view source on it, this is rather slow and gives me time to hit Escape and Ctrl-W. Then top shows vsource using all of the processor until I kill it. (gdb) bt #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) at dpip.c:455 #1 0x080491f9 in send_html_text (sh=0x9e7ae18, url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) at vsource.c:121 #2 0x08049460 in main () at vsource.c:219

Dec. 26, 2012

findbar behaviour

by jcid＠dillo.org

On Tue, Dec 25, 2012 at 07:08:26PM +0000, corvid wrote: > > When I want to change the case-sensitivity of a search, I don't like > having to switch to the mouse and aim it toward the little checkbox. > > So I looked up why we disable tabbing to the other widgets (and found > nothing). Then a little experimentation showed that triggering shortcuts > causes widgets to get focus, which we don't want. > > With that answered, I tried letting the input do its own callbacks upon > Enter or Shift-Enter, and letting everything accept focus. > > This isn't heavily tested, but I wanted to see how the idea goes over > first... Beware, this is tricky. I remember having worked on this simplifying a lot the UI, by trying to avoid custom code/classes for each widget. IIRC, a relatively clean way to hook this shortcuts is to let the event get to the parent group, which in this case should focus its next child. -- Cheers Jorge.-

Dec. 25, 2012

findbar behaviour

by corvid＠lavabit.com

When I want to change the case-sensitivity of a search, I don't like having to switch to the mouse and aim it toward the little checkbox. So I looked up why we disable tabbing to the other widgets (and found nothing). Then a little experimentation showed that triggering shortcuts causes widgets to get focus, which we don't want. With that answered, I tried letting the input do its own callbacks upon Enter or Shift-Enter, and letting everything accept focus. This isn't heavily tested, but I wanted to see how the idea goes over first...

Dec. 25, 2012

show_tooltip=NO

by corvid＠lavabit.com

tipwin still shows tooltips when show_tooltip=NO.

Dec. 25, 2012