On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote:
Jorge wrote:
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature.
If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work.
Time to ask or to STR?
I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.
OK, it's clear it was deactivated by some reason... From: 1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu. We have: 1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo. What do we do? a) Contact FLTK developers and wait for a patched release, then workaround the rest (if any) in dillo and release. b) Workaround in dillo and release. Comments? -- Cheers Jorge.-