DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2199 Version: 1.1.9 I see. I have no opinion on this one really, as I don't find myself making shortcuts for buttons, preferring tab keyboard nav. If native windows does this too, then I guess Firefox's behavior on windows might be aberrant..? In which case we'd change nothing I suppose. In cases where there's well defined behavior on platforms for certain keyboard functions (like cursor editing), it seems we're always 'wrong' to import behavior from other platforms. Compatibility modes might be nice, or confusing, not sure which. I *think* experience shows us we need to track the native behavior, otherwise an FLTK app behaves unlike any other on that platform. Maybe still debatable, but I think in the end, the native behavior wins. In some cases it's a hardware issue (Mac), where mac keyboards are physically different; CloverLeaf-C instead of Ctrl-C for copy, etc. Even though I use Windows very little, when I'm on that platform, I expect 'windows-like' behavior consistent with the other windows apps, cause it's madness if the FLTK app behaves differently for cursor editing than the other windows apps. I suppose in rare situations where the FLTK app is the *only* thing running (like an embedded app) it might make sense for consistency via a compatibility mode. eg. if someone writing an embedded controller switches from a windows-based OS to a linux-based OS, arguably text editing should be consistent between the two versions. Only reason I can think of. Link: http://www.fltk.org/str.php?L2199 Version: 1.1.9 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
