On Wed, Jun 29, 2011 at 04:29:49PM +0000, corvid wrote:

Jorge wrote:

...

Fltk-1.3 is out there, and we've worked our pending issues list. What's still pending?

BTW, I'm working on a focus bug (recently discovered): loading [1], and scrolling down with the down arrow key, makes the rendering area lose focus (taken by the selection list when it becomes visible), and mouse-clicking doesn't recover it.

[1] http://www.dillo.org/test/form-select-multiple.html

- KEYS_HIDE_PANELS and KEYS_FULLSCREEN perform the same action.

Yes. BTW, this looks much simpler thant the focus thing.

- Hidden inputs. 1.3 won't show labels inside Fl_Inputs (which wasn't always nice with long labels, anyway). I may try making room for the label to the left of the widget, unless that makes the code too messy. Not terribly important, though.

-- Cheers Jorge.-

On Wed, Jun 29, 2011 at 04:29:49PM +0000, corvid wrote:

- KEYS_HIDE_PANELS and KEYS_FULLSCREEN perform the same action.

OK, this needs a semantic definition. I like the way Escape cancels dialogs in dillo, and also during these months enjoyed Escape hiding panels too. So, more or less, I'd like to keep it that way. Bug: currently Escape hides the findbar only when it has focus. I'd remove KEYS_FULLSCREEN, and redefine KEYS_HIDE_PANELS to close the findbar if it's visible, and all the panels when the findbar is not visible. Comments? -- Cheers Jorge.-

On Sat, Jul 09, 2011 at 04:21:15PM +0000, corvid wrote:

Jorge wrote:

...

On Wed, Jun 29, 2011 at 04:29:49PM +0000, corvid wrote:

...

- KEYS_HIDE_PANELS and KEYS_FULLSCREEN perform the same action.

OK, this needs a semantic definition.

I like the way Escape cancels dialogs in dillo, and also during these months enjoyed Escape hiding panels too. So, more or less, I'd like to keep it that way.

Bug: currently Escape hides the findbar only when it has focus.

I'd remove KEYS_FULLSCREEN, and redefine KEYS_HIDE_PANELS to close the findbar if it's visible, and all the panels when the findbar is not visible.

Patch committed. -- Cheers Jorge.-

On Fri, 29 Jul 2011 16:12:12 -0400, Jorge Arellano Cid <jcid@dillo.org> wrote:

This avoids the dialog bombing that stems from loading multiple https images/resources in a single page. A proper fix would take either to implement the https-dpi as a server (with state), or to move back https handling into dillo.

As both paths would take considerable effort, and taking into account that even deciding which approach/library to use is non trivial, the workaround looks like a good compromise.

Actually, the second one's already done -- I implemented it as part of Dillo-Win32. The patches of interest are: http://dillo-win32.sourceforge.net/files/03-dillo-r1819.dsock.diff http://dillo-win32.sourceforge.net/files/22-dillo-r1819.https.diff http://dillo-win32.sourceforge.net/files/24-dillo-r1819.sslconfig.diff The first one introduces dsock, a sockets abstraction layer patterned on dlib, which I originally wrote to add Windows networking support. The next one extends dsock to provide SSL support: all you need to do is tell it to "go secure," then dsock handles read/write operations transparently. So you get both portability *and* security, with only minimal modification to the existing Dillo code. The last patch is optional -- it just modifies the ./configure script so it can link against CyaSSL[1], an embedded SSL library. It's probably not as useful on Unix, since every distro these days ships OpenSSL, but it's nice on Windows since it dramatically reduces the binary's download size. There are a couple caveats: the HTTP CONNECT code is a mess right now, because I couldn't figure how to hook that through the CCC's, and I haven't yet added the SSL dialogs. But both of those should be relatively easy to fix. [1] http://www.yassl.com/yaSSL/Home.html Just thought I'd share, ~Benjamin