[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-openjfx-dev
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
From: Martin Fox <martin () martinfox ! com>
Date: 2023-10-31 23:20:51
Message-ID: FA66C21A-FBF2-4A7F-8C55-6F13FE64F7CA () martinfox ! com
[Download RAW message or body]
Andy,
I should have been clearer on why I wrote this up. I think once you've identified the \
minimum API surface that's probably all you should implement.
More important to me is whether reducing the API to a bunch of function tags and two \
API calls does everything that needs to be done. For example, that reduction means \
you can't enumerate the list of function tags a control supports or the full set of \
key bindings. Is that an issue? Is there a use case for these enumerations?
> 3) Provide an API that asks a control to map an Event to a FunctionTag. This \
> enables blocking existing mappings; if a user wants to block the default mappings \
> for, say, COPY they can simply discard/consume any events that the control would \
> map to COPY.
> Supported via InputMap.registerFunction(FunctionTag, Runnable). Just do \
> registerFunction(COPY, () -> { }).
Sorry I didn't make myself clear. Say I want Ctrl-J to be Copy instead of whatever \
it's default binding is. The flow would be:
if the event is Ctrl-J
ask the control to perform the COPY operation
else if the control maps this event to COPY
discard the event (it's the default binding)
> They are not. There is no SELECT_ALL in Button control, for example. Where the \
> hierarchy exists, so does the hierarchy of tags, for example \
> TextInputControl.SELECT_ALL which is applicable/used in TextField and TextArea. \
> But we can't extend it to TableView, for example, as there is no common ancestor - \
> unless we invent one (an interface).
Any control will need to ensure that it ignore tags it doesn't understand. Who cares \
if Ctrl-A maps to SELECT_ALL for a button? It will just ignore it.
But I do get your point. If we ask a Control to map an event to an operation we \
should ensure that the control actually supports that operation. So we don't need \
multiple SELECT_ALL tags, just a verification step so we don't return bogus tags.
>
> What do you think?
>
> Thank you
> -andy
>
>
>
> From: Martin Fox <martin@martinfox.com>
> Date: Monday, October 30, 2023 at 17:24
> To: Andy Goryachev <andy.goryachev@oracle.com>
> Cc: Kevin Rushforth <kevin.rushforth@oracle.com>, openjfx-dev \
> <openjfx-dev@openjdk.org>
> Subject: [External] : Re: [Request for Comments] Behavior / InputMap
>
> I was looking over the InputMap proposal with an eye toward paring it down to the \
> bare minimum.
> From the perspective of a user who wants to manipulate a control without \
> subclassing it I think there are only a few essential components.
> 1) Ensure the user gets events before the control does. That's a topic for a \
> different thread.
> 2) Provide an API that asks a control to perform the operation identified by a \
> FunctionTag. This is the only way to access operations like COPY and MOVE_RIGHT \
> that are implemented behind the scenes.
> 3) Provide an API that asks a control to map an Event to a FunctionTag. This \
> enables blocking existing mappings; if a user wants to block the default mappings \
> for, say, COPY they can simply discard/consume any events that the control would \
> map to COPY.
> If a user wants to subclass an existing control they could also use these API's to \
> do full customization but only if they can guarantee that their subclass will \
> process events before the superclass. That, too, might be a separate discussion.
> I would like to discuss these API's without getting too deep into implementation \
> details. With that said, I do have one implementation suggestion: since most of the \
> event => FunctionTag mappings are common (SELECT_ALL is always Shortcut+A) there \
> should be an internal shared object containing the common mappings.
> Martin
>
>
> On Oct 30, 2023, at 3:11 PM, Andy Goryachev <andy.goryachev@oracle.com> wrote:
>
> Dear Kevin:
>
> Thank you for providing a summary to our (lively) discussion. Even though I think \
> I answered these concerns, I don't mind to have another go at it.
> Please find the updated proposal here (same link):
>
> https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09 \
> <https://urldefense.com/v3/__https:/gist.github.com/andy-goryachev-oracle/294d8e4b30 \
> 94fe16f8d55f6dd8b21c09__;!!ACWV5N9M2RV99hQ!MAhFywXruyvFlvk6whGVWBb9fTI-f1D-16YuJbRGdJe52rX503CFBK8S6IamyzPVzQBcJZmg6c_Jh1CfsDxVFw$>
>
> Let me first define what I mean by "behavior" in the context of this proposal. A \
> behavior is a translation layer between input events - coming either from the \
> control, or from some nodes contained in the skin, or from the platform itself - \
> into some actions. These translation mappings are maintained by a new property in \
> Control - the InputMap. The InputMap has two sides - one for the user application, \
> and another - for the skins/behaviors. Both are "public APIs" but the latter is \
> represented as protected methods of BehaviorBase class which forms a foundation of \
> the behavior part of the skins that want to use the InputMap paradigm.
> Back to individual concerns.
>
> * We should not make anything related to Behaviors public without a full design of \
> how Behaviors should work, what their responsibilities are, how they interact with \
> Skins
>
> And we don't. We recommend to use BehaviorBase, but it's still possible to use \
> event handlers or any other home-grown mechanism to implement skins/behaviors and \
> suffer from the lack of functionality as a result. If BehaviorBase is not the \
> right name, we can call it InputMapAccessorForSkinUse any other name.
> * This proposal doesn't solve the coupling of Skins and behaviors
>
> The skins and behaviors are tightly coupled in some cases. It is possible that a \
> simple control such as Button does not require tight coupling, but a complex \
> control such as TextArea does (see TextAreaSkin:1214).
> With the InputMap, we now can separate user mappings from skin mappings and \
> handlers. Changing a skin will unregister all of the handlers added by the \
> associated behavior, leaving the user mappings intact.
> * Function tags are defined in control class, but don't match the functionality of \
> control class
> NOTE: this begs the question of whether there should always be a method on control \
> for each such function (even if the implementation just delegates to the behavior
>
> May be it was not described extensively, but it is being suggested to have one \
> public method for each function tag, which does invoke the said tag. This enabled \
> indirection via InputMap which in turn allows the app- or skin- developer to \
> redefine the functionality (in effect, allowing for changing the behavior without \
> subclassing the behavior).
> So, for example, SomeControl.copy() would invoke execute(TAG_COPY), which by \
> default would invoke SomeControlBehavior.copy().
> This proposal did not make this change for the subset of controls - intentionally - \
> because it can be done later in a separate PR.
> * An input map should not refer to the node and be stateless and sharable among all \
> (or some) instances of the same class; this would mean mapping input events to \
> Control::method rather than to instance::method or to some \
> arbitrary lambda
> NOTE: this would depend on the previous being resolved
>
> I think we are confusing two things. The InputMap allows for per-control mapping, \
> so it cannot be shareable or static. Period.
> Now, the other thing is a possible requirement to allow for changing the mapping on \
> per-control-type basis, to overwrite the behavior for each instance of a particular \
> control. This I did not address because it's an implementation detail for that \
> control type. I did not want to add child maps, but perhaps we could add another \
> API to the skin/behavior side of InputMap to allow for such a static map.
> Personally, I don't like the idea as it basically adds nothing: event handlers \
> still need to be added to each control and each Node in the skin (if any) and there \
> is an extra complexity added. A better solution would be to subclass the control \
> class and add the mappings for each instance just like we do today.
> * Arbitrary key mapping seems out of scope for the core of JavaFX; this sort of \
> mapping could be done by the application if the event order problem was solved, and \
> if we had public API on control for all functions that are called by the behavior.
> Arbitrary (user) key bindings are enabled by the proposed InputMap. Any \
> alternative proposal, in my opinion, should support this function out of the box.
> * Should Input map be immutable?
>
> The value of InputMap is ability to change the mapping, so I don't understand where \
> this requirement is coming from. Perhaps an example or a use case could be \
> provided?
> * Changes to the Behavior system should focus on replacing complete behaviors, and \
> being able to use these by default for a certain subset of controls (like -fx-skin \
> provide in CSS)
>
> As I mentioned earlier, the skin and its behavior might be tightly coupled. So if \
> a use case exists for changing the behavior, we already have a solution - a custom \
> skin. May be a use case or an example of why we can't do that with the existing \
> architecture would help here.
> And finally, I would like to emphasize that even though the InputMap proposal is \
> fairly well developed and validated using a number of non-trivial controls and some \
> new controls (RichTextArea https://github.com/andy-goryachev-oracle/jfx/pull/1 \
> <https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/jfx/pull/1__;!! \
> ACWV5N9M2RV99hQ!MAhFywXruyvFlvk6whGVWBb9fTI-f1D-16YuJbRGdJe52rX503CFBK8S6IamyzPVzQBcJZmg6c_Jh1ACM9EGvA$> \
> ), I am not against modifying/enhancing it based on the community feedback. I hope \
> we can get to a good solution in a reasonable time frame, or we all would have to \
> learn react and program in javascript.
> Cheers,
> -andy
>
>
>
>
>
> From: openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of Kevin Rushforth \
> <kevin.rushforth@oracle.com>
> Date: Friday, October 27, 2023 at 16:34
> To: openjfx-dev <openjfx-dev@openjdk.org>
> Subject: Re: [Request for Comments] Behavior / InputMap
>
> I've mostly caught up on the (lively) discussion surrounding this feature request.
>
> It is clear that we do not yet have general agreement on the direction this \
> proposal should take, so let's continue to discuss the proposal, its shortcomings, \
> and any alternative approaches.
> We should start by making sure that the motivation for doing this -- what problem \
> is being solved -- is well understood. Andy will rework the initial sections of the \
> proposal to make it more clear.
> If I can summarize what I see are the main concerns that have been raised:
>
> * We should not make anything related to Behaviors public without a full design of \
> how Behaviors should work, what their responsibilities are, how they interact with \
> Skins
> * This proposal doesn't solve the coupling of Skins and behaviors
>
> * Function tags are defined in control class, but don't match the functionality of \
> control class
> NOTE: this begs the question of whether there should always be a method on control \
> for each such function (even if the implementation just delegates to the behavior
> * An input map should not refer to the node and be stateless and sharable among all \
> (or some) instances of the same class; this would mean mapping input events to \
> Control::method rather than to instance::method or to some \
> arbitrary lambda
> NOTE: this would depend on the previous being resolved
>
> * Arbitrary key mapping seems out of scope for the core of JavaFX; this sort of \
> mapping could be done by the application if the event order problem was solved, and \
> if we had public API on control for all functions that are called by the behavior.
> * Should Input map be immutable?
>
> * Changes to the Behavior system should focus on replacing complete behaviors, and \
> being able to use these by default for a certain subset of controls (like -fx-skin \
> provide in CSS)
> There are probably other concerns as well.
>
> Finally, one of the comments made, which I completely agree with, is that API \
> design needs to come first. It needs to be fully fleshed out, and needs to be \
> forward-looking. We should only expose as public API what is needed to solve the \
> problem and no more.
> Let's continue the discussion with this in mind.
>
> -- Kevin
>
>
>
> On 9/29/2023 3:44 PM, Andy Goryachev wrote:
> Dear fellow JavaFX developers:
>
> For some time now, we've been working to identify missing features in JavaFX that \
> hinder application development. We've been working on adding some of the missing \
> features (for which we'll have a separate announcement), but I feel that engaging \
> wider community is a rather important part of the process.
> I would like to share with you one such missing feature - ability to extend \
> behavior of the existing components (and make the task of creating new components \
> easier) by adding a public InputMap and BehaviorBase.
> Please find the actual proposal here
> https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09 \
> <https://urldefense.com/v3/__https:/gist.github.com/andy-goryachev-oracle/294d8e4b30 \
> 94fe16f8d55f6dd8b21c09__;!!ACWV5N9M2RV99hQ!MAhFywXruyvFlvk6whGVWBb9fTI-f1D-16YuJbRGdJe52rX503CFBK8S6IamyzPVzQBcJZmg6c_Jh1CfsDxVFw$>
>
> We are very much interested in your feedback. Thank you in advance.
>
> -andy
[Attachment #3 (unknown)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: \
space; line-break: after-white-space;">Andy,<div><br></div><div>I should have been \
clearer on why I wrote this up. I think once you've identified the minimum API \
surface that's probably all you should implement.</div><div><br></div><div>More \
important to me is whether reducing the API to a bunch of function tags and two API \
calls does everything that needs to be done. For example, that reduction means you \
can't enumerate the list of function tags a control supports or the full set of key \
bindings. Is that an issue? Is there a use case for these \
enumerations?</div><div><br></div><div><div><blockquote type="cite"><div \
class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); \
font-family: Optima-Regular; font-size: 14px; font-style: normal; font-variant-caps: \
normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: \
0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;"><p style="margin-right: 0in; \
margin-bottom: 0in; margin-left: 0.5in;"><span style="font-size: 9pt; font-family: \
Helvetica;">3) Provide an API that asks a control to map an Event to a FunctionTag. \
This enables blocking existing mappings; if a user wants to block the default \
mappings for, say, COPY they can simply discard/consume any events that the control \
would map to COPY.<o:p></o:p></span></p><div style="margin: 0in; font-size: 10pt; \
font-family: Calibri, sans-serif; font-variant-caps: normal; font-stretch: normal; \
font-size-adjust: none; font-kerning: auto; font-variant-alternates: normal; \
font-variant-ligatures: normal; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-variant-position: normal; \
font-feature-settings: normal; font-optical-sizing: auto; font-variation-settings: \
normal; min-height: 14px;"><span style="font-size: 11pt; font-family: "Iosevka \
Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: \
10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: \
"Iosevka Fixed SS16";">Supported via InputMap.registerFunction(FunctionTag, \
Runnable). Just do registerFunction(COPY, () -> { \
}). </span></div></div></blockquote><div><br></div>Sorry I didn't make myself \
clear. Say I want Ctrl-J to be Copy instead of whatever it's default binding is. The \
flow would be:</div><div><br></div><div><span class="Apple-tab-span" \
style="white-space:pre"> </span>if the event is Ctrl-J</div><div><span \
class="Apple-tab-span" style="white-space:pre"> </span>ask the control to perform \
the COPY operation</div><div><span class="Apple-tab-span" \
style="white-space:pre"> </span>else if the control maps this event to \
COPY</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>discard \
the event (it's the default binding)</div><div><span style="font-family: \
"Iosevka Fixed SS16"; font-size: 11pt;"> </span></div><div><blockquote \
type="cite"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, \
0, 0); font-family: Optima-Regular; font-size: 14px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; \
font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt; \
font-family: "Iosevka Fixed SS16";">They are not. There is no \
SELECT_ALL in Button control, for example. Where the hierarchy exists, so does \
the hierarchy of tags, for example TextInputControl.SELECT_ALL which is \
applicable/used in TextField and TextArea. But we can't extend it to TableView, \
for example, as there is no common ancestor - unless we invent one (an \
interface).</span></div></div></blockquote><div><br></div>Any control will need to \
ensure that it ignore tags it doesn't understand. Who cares if Ctrl-A maps to \
SELECT_ALL for a button? It will just ignore it.</div><div><br></div><div>But I do \
get your point. If we ask a Control to map an event to an operation we should ensure \
that the control actually supports that operation. So we don't need multiple \
SELECT_ALL tags, just a verification step so we don't return bogus \
tags.</div><div><br><blockquote type="cite"><div class="WordSection1" style="page: \
WordSection1; caret-color: rgb(0, 0, 0); font-family: Optima-Regular; font-size: \
14px; font-style: normal; font-variant-caps: normal; font-weight: 400; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: \
Calibri, sans-serif;"><span style="font-family: "Iosevka Fixed SS16"; \
font-size: 11pt;"> </span></div><div style="margin: 0in; font-size: 10pt; \
font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: \
"Iosevka Fixed SS16";">What do you think?<o:p></o:p></span></div><div \
style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span \
style="font-size: 11pt; font-family: "Iosevka Fixed \
SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; \
font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: \
"Iosevka Fixed SS16";">Thank you<o:p></o:p></span></div><div style="margin: \
0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: \
11pt; font-family: "Iosevka Fixed SS16";">-andy<o:p></o:p></span></div><div \
style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span \
style="font-size: 11pt; font-family: "Iosevka Fixed \
SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; \
font-family: Calibri, sans-serif;"><span style="font-size: 11pt; font-family: \
"Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: \
0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: \
11pt; font-family: "Iosevka Fixed \
SS16";"><o:p> </o:p></span></div><div \
id="mail-editor-reference-message-container"><div><div style="border-width: 1pt \
medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) \
currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;"><p \
class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 10pt; font-family: Calibri, \
sans-serif;"><b><span style="font-size: 12pt;">From:<span \
class="Apple-converted-space"> </span></span></b><span style="font-size: \
12pt;">Martin Fox <martin@martinfox.com><br><b>Date:<span \
class="Apple-converted-space"> </span></b>Monday, October 30, 2023 at \
17:24<br><b>To:<span class="Apple-converted-space"> </span></b>Andy Goryachev \
<andy.goryachev@oracle.com><br><b>Cc:<span \
class="Apple-converted-space"> </span></b>Kevin Rushforth \
<kevin.rushforth@oracle.com>, openjfx-dev \
<openjfx-dev@openjdk.org><br><b>Subject:<span \
class="Apple-converted-space"> </span></b>[External] : Re: [Request for \
Comments] Behavior / InputMap<o:p></o:p></span></p></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">I was looking over the InputMap proposal with an eye toward paring it \
down to the bare minimum.<o:p></o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; font-variant-caps: \
normal; font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">From the perspective of a user who wants to manipulate a control without \
subclassing it I think there are only a few essential \
components.<o:p></o:p></span></div><div style="margin: 0in; font-variant-caps: \
normal; font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal; min-height: 14px;"><span style="font-size: 9pt; \
font-family: Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">1) Ensure the user gets events before the control does. That's a topic \
for a different thread.<o:p></o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal; min-height: 14px;"><span style="font-size: 9pt; \
font-family: Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">2) Provide an API that asks a control to perform the operation identified \
by a FunctionTag. This is the only way to access operations like COPY and MOVE_RIGHT \
that are implemented behind the scenes.<o:p></o:p></span></div><div style="margin: \
0in; font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal; min-height: 14px;"><span style="font-size: 9pt; \
font-family: Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">3) Provide an API that asks a control to map an Event to a FunctionTag. \
This enables blocking existing mappings; if a user wants to block the default \
mappings for, say, COPY they can simply discard/consume any events that the control \
would map to COPY.<o:p></o:p></span></div><div style="margin: 0in; font-variant-caps: \
normal; font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal; min-height: 14px;"><span style="font-size: 9pt; \
font-family: Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">If a user wants to subclass an existing control they could also use these \
API's to do full customization but only if they can guarantee that their subclass \
will process events before the superclass. That, too, might be a separate \
discussion.<o:p></o:p></span></div><div style="margin: 0in; font-variant-caps: \
normal; font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal; min-height: 14px;"><span style="font-size: 9pt; \
font-family: Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; \
font-variant-caps: normal; font-stretch: normal; font-size-adjust: none; \
font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;">I would like to discuss these API's without getting too deep into \
implementation details. With that said, I do have one implementation suggestion: \
since most of the event => FunctionTag mappings are common (SELECT_ALL is always \
Shortcut+A) there should be an internal shared object containing the common \
mappings.<o:p></o:p></span></div><div style="margin: 0in; font-variant-caps: normal; \
font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
Helvetica;"><o:p> </o:p></span></div><div style="margin: 0in; font-variant-caps: \
normal; font-stretch: normal; font-size-adjust: none; font-kerning: auto; \
font-variant-alternates: normal; font-variant-ligatures: normal; \
font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: \
normal; font-feature-settings: normal; font-optical-sizing: auto; \
font-variation-settings: normal;"><span style="font-size: 9pt; font-family: \
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic