On Mon, Nov 19, 2007 at 07:08:38PM +0100, Johannes Hofmann wrote:

On Mon, Nov 19, 2007 at 03:01:08PM -0300, Jorge Arellano Cid wrote:

...

Hi,

On Fri, Nov 16, 2007 at 04:22:01AM +0000, place wrote:

...

I'm not much of a drawing/gui person, but it's hard not being able to search pages, so I gave it a try (attached).

- If you hit ^Q on this window or the page source or page bugs windows, dillo will crash because it assumes it's closing a bw.

Already fixed.

...

- I didn't want a title bar, and I didn't want it to be able to outlive its bw, but I didn't know what to do about it.

- If searching scrolls the window, highlighting isn't undone properly. (If you search for something like "a", the last instance on each line will remain highlighted)

Well, my idea was to make the Find-text widget similar to what Firefox has (a row above the status bar that appears on request). With Enter bound to "search next", Shift-Enter to "search prev" and a few buttons/widgets for the usual "case insensitive" option & friends.

As it was taking too much time (and I didn't find a way to do it either with or without Johannes patch), I decided to commit the patch "as is", and not to delay anymore.

The above-status-bar widget solves some problems, for instance:

- the dialog window covering the highlighted word. - dependencies (as including uicmd.hh and bw.hh from dialog)

It looks like the FltkViewport is not behaving as a native FLTK widget and that either some ad-hoc bindings are required, or to make it behave as native FLTK, at least for parent Group resizes.

BTW, formerly "full screen" was bound to Ctrl-F (which is the shortcut for find text), now it's bound to Ctrl-Space. Why? Because I haven't found how to detect and handle the double-click event, cleanly from the UI. :-)

Any help is appreciatted! :)

have you tried something like

if (event == PUSH && event_clicks() >= 1) { fprintf(stderr, "===> double click\n"); }

in UI::handle() already?

Yes, lots of combinations of PUSH/RELEASE tests, return values, event_is_click(), event_clicks(), event_clicks(0)... I got confused bacause to get a RELEASE event you need to return non zero from PUSH, and then you can capture double-click from RELEASE, but that way fast clicks over Back or Forward buttons are seen as double-click. With other combinations, sometimes the event is not passed to the child widgets, etc. So I tried to cpture from PUSH alone... Finally, I thought that if after: ret = Window::handle(event); ret was zero, it was safe to make the PUSH/RELEASE dance, but, to my surprise, ret was non zero from double-click event though it wasn't handled. What I got, was a lot of ways to make it half-work. :-P but, maybe it's just me being tired. -- Cheers Jorge.-