From duke at openjdk.org Wed Nov 1 00:02:11 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 1 Nov 2023 00:02:11 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). Yes, that's expected. The \ key on the U.S. layout is in the same position as the * key on the French layout (on Windows). Mac and Linux both have nice little keyboard viewing tools that you can pull up so you can see how all the keys change as you switch between layouts. I haven't found such a utility for Windows and it gets confusing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1264#issuecomment-1788193298 From andy.goryachev at oracle.com Wed Nov 1 00:07:05 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 1 Nov 2023 00:07:05 +0000 Subject: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) In-Reply-To: <3abab3e1-ec9d-bfef-80aa-4cad0aeb9f78@gmail.com> References: <4b7216a3-c8f3-1042-f279-71608fb6d9ef@gmail.com> <44ab3445-f6a3-db83-0922-6623001ea967@gmail.com> <8698a16a-06fc-8328-3fff-d2b725418995@gmail.com> <3abab3e1-ec9d-bfef-80aa-4cad0aeb9f78@gmail.com> Message-ID: Thank you, John. -andy From: John Hendrikx Date: Tuesday, October 31, 2023 at 16:13 To: Andy Goryachev , openjfx-dev at openjdk.org , Kevin Rushforth Subject: Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) Hi Andy, I'm sorry if you feel I blocked your proposal. Discussions better happen at a stage far before a PR is being reviewed, and instead of having these discussions here, we could have had them on the PR. I'll try and formalize my proposals. --John On 30/10/2023 20:32, Andy Goryachev wrote: Dear John: I'm unsure what the JEP format would contribute here The benefit of JEP format is a) to explicitly state the problem being solved (in the Motivation section) b) to enumerate the public APIs I have several proposals, and some are too big for a single proposal (IMHO) which would you like me to focus on? The main reason I am asking you to go through the process is because you effectively blocked by InputMap proposal. I keep hearing that my proposal is not good for various reasons, while there is a much better way for doing things, so let?s see it in full detail. It would be nice to have proof-of-concept code based on a complex control rather than a simple Button, but it is not a requirement, at least initially. I still want to see code examples (pseudo code is fine) for my questions: Q1. Changing an existing key binding from one key combination to another. Q2. Remapping an existing key binding to a different function. Q3. Unmapping an existing key binding. Q4. Adding a new key binding mapped to a new function. Q5. (Q1...Q4) scenarios, at run time. Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added. Q7. Once the key binding has been modified, is it possible to invoke the default functionality? Q8. How are the platform-specific key bindings created? Q9. How are the skin-specific (see Q6) handlers removed when changing the skins? Q10. When a key press happens, does it cause a linear search through listeners or just a map lookup? I think it is important to answer all questions during the discussion, as it helps all sides to understand how things work, and possibly make corrections. Since the bulk of my proposal deals with key bindings and user-/skin- installed handlers, I would like to see how you propose to deal with these problems. Another reason I asked you for a JEP is that you seem to brush aside my objections. For example, my objection to the stateless behavior was dealt with by inventing BehaviorContext, which I basically take as an acknowledgement that behaviors are not stateless. So let?s see exactly you envision things by describing the public API and perhaps the proof of concept code should also have two non-trivial controls, just to see whether BehaviorContext depends on the control class or not. How key bindings are done is IMHO more of an implementation detail of **specific** behaviors, I categorically disagree with this statement. As an application developer, I want to be able to set/modify/unmap key bindings via common public mechanism, make sure that the user mappings and handlers always take precedence over the skin ones, and make sure that skin changes leave the user mappings and handlers in place. It is certainly not an implementation detail and not a property of any specific behavior. Thank you, and I am looking forward to seeing answers to the questions posted earlier. -andy From: John Hendrikx Date: Saturday, October 28, 2023 at 12:55 To: Andy Goryachev , openjfx-dev at openjdk.org , Kevin Rushforth Subject: Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) Hi Andy, On 27/10/2023 19:10, Andy Goryachev wrote: Dear John: I think our goal is for all of us to agree on a solution which solves the problems. We are still talking, right? I have to say - it is very difficult to have a meaningful conversation when questions are not being answered. It is even more difficult to do over email and time zones, as the context can often be lost. I'm really a bit surprised, as I think I responded quite quickly to a lot of the posts surrounding the proposals, and also answered quite a lot of questions. The mailinglist format seems to have served Java quite well for this purpose for years now, and if memory serves, earlier FX proposals also were discussed here. I'm unsure what the JEP format would contribute here, given that it does not allow for inline comments or threads, but I'm not unwilling to try my hand at one. To reiterate, a proposal in a JEP format would be nice, so we can see the public API. Alright, this will take a bit of time. I have several proposals, and some are too big for a single proposal (IMHO) which would you like me to focus on? 1. A public Behavior API with the initial focus on being able to reuse and replace default behaviors This proposal would like to achieve a clear definition of a Behavior and clear separation (to aid in reusability and creation). It would define a Behavior interface, and a clean way of installing/uninstalling a behavior on controls. This would be primarily the Behavior/BehaviorContext part of my sample PR https://github.com/openjdk/jfx/pull/1265, leaving the more controversial event definition parts out for now 1.1. A possible extension of the above Behavior API to allow changing high level behavior I'm not sure yet what would be a good approach here. I would probably either lean towards reusing the Event system for this, or doing this with overridable methods; ie. in order to override a function, listen for its event and call different code or trigger a different event; or, ensure there is an overridable method so it can be overriden directly in code. 1.2. An extension to the above behavior API to allow for more user friendly key rebinding The idea here would be to create a custom behavior (allowed by 1.), call into a behavior you want to modify to install its defaults, and then make changes after. There is more than one possible approach here. One I raised earlier was offering more specific methods on BehaviorContext. Another possiblity is to make it specific to certain behaviors only (MappableBehavior), or behaviors that can somehow provide an InputMap (without entangling everything). 2. An improved event handling system (Michael Strauss already did some work there) that would allow users to override or disable default event processing This would be a low-level improvement that would allow 3rd parties to override large parts of JavaFX in a supported manner. It would open the way to a 3rd party behavior system or navigation system, but also simpler things like just changing a key mapping, even ones claimed by behaviors currently. As it is a low level API, this would be somewhat cumbersome for seemingly simple tasks, and the various platforms would need to be supported manually. In essence the above proposal would allow user installed event handlers to receive any event before a default handler can get to it, so that say remapping the LEFT_ARROW key is actualy possible and doesn't magically disappear (many new users, including me at the time were/are somewhat surprised that an event handler installed on the control is not receiving all events). The root cause of this is the sharing of the event handling lists on the control with (magically) installed behaviors. The above proposal would change this (in a backwards compatible way) to work more like how default exception handlers work -- only unconsumed events that bubble up to the root level are considered for default behavior actions. ------ As you can see, one my problems with answering the key rebinding questions is that IMHO this more of a later extension on a Behavior API; this means to get to the key remapping design, there first would need to be a Behavior API design. How key bindings are done is IMHO more of an implementation detail of **specific** behaviors, as there are probably more ways to do this. So for my proposals, a somewhat fleshed out Behavior API design is an important prerequisite before offering key rebinding. If we can advance this design far enough, we may see a way to do this without needing a Behavior API first; for example, we could have a Behavior interface, and a subtype, MappableBehavior; only behaviors of that sub type support key remapping, while general behaviors don't have to. This would make the key rebinding just something that **some** behaviors support, and not a general feature if it instead was added to say Control, Behavior or BehaviorContext. This may be a short cut that we could take to get to key rebinding quickly, without closing off a future behavior API. Again, thanks for reading, I look forward to some feedback, and as said, I will try put some time towards writing a JEP. I'm also happy to collaborate on this once a design direction becomes a bit more clear. --John Please, if you have time, answer these questions. A short pseudo-code example will be fine. Q1. Changing an existing key binding from one key combination to another. Q2. Remapping an existing key binding to a different function. Q3. Unmapping an existing key binding. Q4. Adding a new key binding mapped to a new function. Q5. (Q1...Q4) scenarios, at run time. Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added. Q7. Once the key binding has been modified, is it possible to invoke the default functionality? Q8. How are the platform-specific key bindings created? Q9. How are the skin-specific (see Q6) handlers removed when changing the skins? Q10. When a key press happens, does it cause a linear search through listeners or just a map lookup? Lastly, I do think prototyping the alternative proposal using simple control like Button is insufficient. TextArea would be much better, as it has a ton of key bindings, platform-specific logic, various handlers that do and do not consume events by default. Thank you -andy P.S. I noticed that I switched my PR to Open by mistake. Sorry, it?s back in Draft. From: John Hendrikx Date: Thursday, October 26, 2023 at 02:15 To: Andy Goryachev , openjfx-dev at openjdk.org , Kevin Rushforth Subject: Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) The normal procedure I think is also to first provide a JEP for review, before starting on the implementation... Given the doubts raised, feedback given and potential alternatives proposed, I don't see why you are still moving forward with your own proposal. The critiques I've given have been mostly hand waved with arguments that have no place in JEP evaluation (time restrictions, existing code already works this way, false equivalency with MVC pattern), and therefore have IMHO not been taken serious at all. This leaves me in the position of putting in a lot of work that will essentially be ignored as I feel an (internal) decision has already been reached, regardless of the feedback on the mailinglist. The (partial) proposal I've made, and also simpler proposals so that 3rd parties could do a keybinding implementation, should be sufficient to reconsider the current proposal that is being moved forward. I'll reiterate my problems with your proposal: - Introduces a lot of API for what is essentially the configuration of internal event handlers - The proposed API partially overlaps with the existing event handler API, meaning that some keys could be changed with just event handlers, while some can only be changed with the BaseBehavior API; it also provides for creating new functions and assigning them to keys, essentially a new (very limited) API for what was already possible in the much more flexible event handling API - Introduces the term "Behavior" in public API without clearly specifying what that is, nor showing enough forethought that may make it possible in the future to have public Behaviors - Introduces the term "InputMap" in public API, which is just an implementation detail of the internal event handlers - Doesn't address the real issue IMHO, which is that JavaFX Skins/Behaviors install their Event Handlers directly on Controls, mixing them with user event handlers leading to all sorts of unpredictable behavior due to call order and internal handlers essentially stealing and consuming events before the user has a chance to look at them (and thus blocking any 3rd party key alterations) which leads to the (false) need to change key bindings and Behaviors directly... So if you want me to work on such a proposal, fully fleshing it out, I would like to know if it will be given consideration. I would also like some more feedback on what is already there, as I think it is sufficient to decide if a full proposal is worth it or not. My proposals in short: 1. - Fix the issues with Events being stolen before users can get a them - Users should be able to have priority on Events, Michael Strauss already has a PR that fixes the issue in part - Events should not be consumed when not used (navigation does this) as this precludes the user being able to change their meaning - Even better would be if internal event handlers were isolated and did not mix themselves with user event handlers at all The above can be done separately, and should already make it possible to do a lot of things that were close to impossible before when it comes to changing key handling, but certainly not everything. - Building on top of the improved event handling system, introduce a flag to indicate an event is not to be consumed by internal event handlers These two together can form the basis for a 3rd party Behavior implementation as standard behavior can be prevented from occurring. It leaves platform dependent behavior to be addressed by such a 3rd party / user implementation as it is a very low level API. Any key remapping logic would be provided by the 3rd party API. 2. I also have a more fleshed out alternative proposal that attempts to introduce Behaviors into JavaFX as a first class concept, instead of a potential 3rd party add-on. Recap: - Introduce a Behavior interface with a single method "install" to be called by a Control - The "install" method is provided a context object, BehaviorContext. This indirects any changes the Behavior can make to a Control, so the Control is fully aware of all changes and can uninstall them without further co-operation from the behavior. - The BehaviorContext provides low level functions to add/remove event handlers and listeners, but can also provide higher level functions (in perhap a later PR) to allow for some kind of control provided input map system - Standard Behaviors can be made public and can be easily subclassed or composed as they need not have any state. State is tracked inside the behavorial installed listeners and handlers themselves (either directly or by referring to some shared State object). - Clear separation of concerns; Behaviors, a resuable concept that can be applied to a control; BehaviorContext, manages behavior lifecycle by abstracting away direct Control access; behavior state management left up to the implementation and created (on demand and as needed) when "install" is called. - Indirection from key mapping to semantic meaning is provided by introducing control specific events. These semantic events can be handled, filtered and consumed like all other events, allowing for changing/remapping/blocking or ignoring; this part can be left out from an initial implementation to further evaluate how such events might interact with Skins that need specific events (there is nothing stopping us from having some of these semantic events be handled by the Control directly, and some by the specific needs of the Skin) To get at the internal key mappings, you'd need to subclass or compose a Behavior. The Behaviors are setup to allow this easily. To modify the bindings of a Control, one would install such a modified Behavior as a whole; overkill perhaps for one binding change, but convenient when multiple bindings are changed, and reusable accross controls (the Behavior only need to be created once). The proposal also includes an indirection between Key/Mouse event and its semantic meaning. This is achieved by firing higher level more meaningful events, but that's not the only option; it could also be done with overridable methods on the Behavior, or a behavior specific interface if the Event based proposal is seen as too audacious. This proposal advocates a clear seperation of the Behavior from the Skin, essentially making them Controller and View, where the View has no knowledge of the Controller. I see no reason why this wouldn't be possible, given that it is a standard pattern. That existing controls may be difficult to untangle is IMHO irrelevant, especially when this can be done one at a time. I realize that Controllers (Behaviors) may have functions that are sort of View (Skin) specific; this is not an issue, as it should be fine to trigger a behavior without it being consumed; unconsumed behaviorial events just bubble up. This allows Behaviors to have events specific to a Skin without them interfering if they're unused by an alternative Skin. An alternative Skin that also needs new behavior will also need to create a new behavior to go along with it (or when paired with the standard one, accept that those new behaviors won't be triggered). Thanks for reading. --John On 26/10/2023 00:59, Andy Goryachev wrote: Dear John: It is difficult to review the alternative proposal for a number of reasons. A prototype is a good start, but for any proposal to go forward we need a bit more work. Let me enumerate the steps that we expect: 1. Provide an overview of the proposal following a JEP outline: Summary Goals Non-Goals Motivation Description Alternatives Risks and Assumptions Dependencies 2. A draft PR that provides a proof of concept, using, in this case, a few complex controls like TextArea, TableView, ComboBox. 3. Address the question raised earlier, perhaps by providing code examples (pseudo code is acceptable, I think). More specifically, I?d like to know how the following concerns will be addressed by the new proposal: Q1. Changing an existing key binding from one key combination to another. Q2. Remapping an existing key binding to a different function. Q3. Unmapping an existing key binding. Q4. Adding a new key binding mapped to a new function. Q5. (Q1...Q4) scenarios, at run time. Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added. Q7. Once the key binding has been modified, is it possible to invoke the default functionality? Q8. How are the platform-specific key bindings created? Q9. How are the skin-specific (see Q6) handlers removed when changing the skins? Q10. When a key press happens, does it cause a linear search or a map lookup? Thank you -andy From: John Hendrikx Date: Tuesday, October 24, 2023 at 04:58 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) On 23/10/2023 23:57, Andy Goryachev wrote: You'd create a new class, `MyBehavior`, By ?customizing? I also mean at run time. Creating new classes wouldn?t work. This would also work at runtime, as the class you create can be instantiated with parameters that control its key binding behavior. Even though the standard Behaviors should probably be singletons (so they can be reused and composed) or have public well documented constructors, a custom behavior created by the user has no such re-usability restrictions. coupling I don?t think it is our choice - it is up to the skin designed. If they add a node that needs to take input, or if the behavior is drastically different, it is almost impossible to create a common interface. So skin and behaviors are coupled, besides we have to design for the worst case (of a totally different skin). The division between S and B comes mostly from the division between V and C in MVC. From a distance, the user does not see it at all - all they see is a control. JavaFX is not doing MVC. In MVC, the 3 components are not entangled; Model refers View, Controller refers View and Model, View refers nothing; in JavaFX the View (Skin) creates the Controller (Behavior); the View especially normally can be created without any dependencies, and can be tested as such; with Skins being tightly coupled to both Behaviors and Controls, that doesn't even come close. For it to be MVC you'd need to: - Remove reference from Skin to Control - Do not let Skins create Behaviors - Instantation order should be, create a Skin first (with no Control reference), then create the Control (with Skin as parameter or setter), then create a Behavior (with Control as parameter, and one or more Views (Skins)) What JavaFX is exactly, I don't know. It doesn't follow MVC (even though it claims to) because in the current setup the Skin is both V and C; that's not MVC. At most it is MS (Model Skin), and so there is no reason to expose anything beyond the Skin then, as that would just be pretending to be something that it is not. This suggest another metric at judging the usefulness of a design - how easy it is to understand and perform 80% of most common tasks. Now that I explained how key remappings would work, I don't see how this would disqualify the alternative proposal. There are more interesting ideas at the end of the message I am replying to - fxml, css, global changes - these go far beyond the simple input map improvement. I did mention this already, but neither open source community, nor my employer might have the resources to make such drastic changes. I didn't mention FXML, but yes, I gave some other things to think about. As for how drastic any of those are, that remains to be seen. Certainly the global changes would not be that hard at all. The CSS proposal would need some research if there is some will to go there; it assumes that the information needed can be transported in a reasonable manner to the key binding system using the existing CSS infrastructure. So we have to be realistic, I think. We are travelling to a different planet in a small spaceship and we only have so much material and oxygen to play with. A simple improvement that helps 80% of use cases might be better than a major redesign (I still think the event proposal involves major redesign). I think that if that's the case that we'd better focus on making it possible for 3rd parties to deliver these features, and do the simplest thing that would allow them to do so. That would be prioritized event handlers (so a 3rd party can always intercept before the Skin/Behavior gets to it) + a flag to skip system event handlers (ala consumed) to allow bubbling up. On top of that any key remapping or behavior change system can be constructed already. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Wed Nov 1 00:06:40 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Nov 2023 00:06:40 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 20:35:47 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 214: > >> 212: >> 213: void fireValueChangedEvent(Map changedEntries) { >> 214: for (var listener : invalidationListeners) { > > minor: IMHO, don't use `var` when it is not clear from the same line what it represents. Can just use `invalidationListeners.forEach(listener -> listener.invalidated(this));` here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378270348 From angorya at openjdk.org Wed Nov 1 00:08:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 00:08:12 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). ? looks good to me ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1264#pullrequestreview-1707396077 From angorya at openjdk.org Wed Nov 1 00:12:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 00:12:10 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). not sure why it shows READY label with only one reviewer... cc @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1264#issuecomment-1788201354 From andy.goryachev at oracle.com Wed Nov 1 00:24:35 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 1 Nov 2023 00:24:35 +0000 Subject: [External] : Re: [Request for Comments] Behavior / InputMap In-Reply-To: References: <6433b131-f7cc-47aa-bee6-bd34d01ef96f@oracle.com> Message-ID: Dear Martin: This basically is the minimal API surface as far as InputMap is concerned. There are probably some methods still missing, such as ... Say I want Ctrl-J to be Copy instead of whatever it?s default binding is. InputMap.unbind(FunctionTag.COPY); ? missing method. Or we could add InputMap.getKeyBindingfor(FunctionTag) followed by InputMap.registerKey(KeyBinding.ctrl(KeyCode.J), COPY); So, basically, one or two methods are missing! 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. Well, if we try to think of a union of all possible functions, it is just not right. The functions have different semantics for different controls, even SELECT_ALL would be different, or there will be multiple flavors of SELECT_ALL or COPY. I just don?t think it?s necessary. Each control declares a bunch of public methods specific to that control, and also declares a method identifiers corresponding to these methods (that?s FunctionTags). If we try to add a key binding to a button passing a function tag from TextArea it will essentially be ignored because Button does not have the corresponding method. I don?t think there are methods that are common for *every* control. So we have control-specific tags that might be in the control or its base class such as TextInputControl. -andy P.S. thank you for uncovering a gap in the API! From: Martin Fox Date: Tuesday, October 31, 2023 at 16:21 To: Andy Goryachev Cc: Kevin Rushforth , openjfx-dev Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap 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 Date: Monday, October 30, 2023 at 17:24 To: Andy Goryachev Cc: Kevin Rushforth , openjfx-dev 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 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 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 ), 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 on behalf of Kevin Rushforth Date: Friday, October 27, 2023 at 16:34 To: openjfx-dev 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 We are very much interested in your feedback. Thank you in advance. -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Nov 1 00:37:11 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 00:37:11 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). (please do not integrate until we get the required # of reviewers. there seems to be a problem with SCARA bot) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1264#issuecomment-1788220718 From mstrauss at openjdk.org Wed Nov 1 01:24:36 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 01:24:36 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 20:13:11 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java line 479: > >> 477: "GTK.theme_bg_color", "backgroundColor" >> 478: ); >> 479: } > > Not sure how often these are called, but since the map returned is immutable, you could return the same map each time. Same applies for the other 2 application classes. It's only called once when QuantumToolkit is initialized, so there's no need to do that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378304357 From mstrauss at openjdk.org Wed Nov 1 02:19:36 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 02:19:36 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 20:19:42 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1094: > >> 1092: // This method will be removed when StyleThemes are added. >> 1093: private static void checkHighContrastThemeChanged(Map preferences) { >> 1094: if (preferences.get("Windows.SPI.HighContrastOn") == Boolean.TRUE) { > > It's better to not use reference equality here, as `new Boolean("true") != Boolean.TRUE`. > Suggestion: > > if (Boolean.TRUE.equals(preferences.get("Windows.SPI.HighContrastOn")) { This might not be an issue, considering that the Boolean(String) constructor is terminally deprecated anyway. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378327099 From mstrauss at openjdk.org Wed Nov 1 02:33:38 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 02:33:38 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 20:58:55 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 52: > >> 50: * by calling the {@link #update(Map)} method. >> 51: */ >> 52: public class PlatformPreferences extends AbstractMap implements Platform.Preferences { > > Is there a need for this class to be public? It seems to me that `Platform.Preferences` is public, and that in order to get the platform preferences you call `Platform.getPreferences()`, which returns the interface. > > Otherwise, you need to document all `public` methods (not from the interface), including the constructor. `PlatformPreferences` is in the `com.sun.javafx.application.preferences` package, but must be accessible from the `com.sun.javafx.application` package. That's why it needs to be public. The class doesn't have undocumented public methods (aside from the constructor), but then again this class is also not API. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 61: > >> 59: final Map effectivePreferences = new HashMap<>(); >> 60: final Map unmodifiableEffectivePreferences = Collections.unmodifiableMap(effectivePreferences); >> 61: final PreferenceProperties properties = new PreferenceProperties(this); > > minor: `this` escapes here before object is fully constructed Yes, but `PreferenceProperties` doesn't do anything with `this`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378332197 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378333037 From mstrauss at openjdk.org Wed Nov 1 02:56:38 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 02:56:38 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-HjK9MJg2-pTlls3AdQDjnzuqc3vRukdgv7MX6KimVA=.a15120d8-175c-470f-ba4c-341055e28bba@github.com> On Tue, 31 Oct 2023 21:05:23 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/javafx/application/Appearance.java line 31: > >> 29: * Defines the appearance of the user interface. >> 30: * >> 31: * @since 22 > > I would add an `@see javafx.application.Platform.Preferences#appearanceProperty()` tag (if I got the syntax right) because it's not clear how and where to use this class from the description. > > Can there be other uses for this enum outside of the current one in the above property? If so, it should be documented. Added the `@see` tag. There will be other uses coming in the future (window decorations and style themes). > modules/javafx.graphics/src/main/java/javafx/application/Appearance.java line 44: > >> 42: */ >> 43: DARK >> 44: > > Minor: > > I was told once that JavaFX uses a `;` after the last enum element. > > Also no need for the extra empty line. Almost no public enumerations in JavaFX use a semicolon after the last constant (not considering those that need it because they have additional methods). Some enumerations do use a comma, but many others don't. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378343052 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378342416 From mstrauss at openjdk.org Wed Nov 1 03:02:39 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 03:02:39 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 22:31:11 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 459: > >> 457: * Contains UI preferences of the current platform. >> 458: *

>> 459: * {@code Preferences} extends {@link ObservableMap} to expose platform preferences as key-value pairs. > > I would mentioned here (like in `getPreferences`) that this map is unmodifiable to the user, and that changes by the underlying platform can be tracked by listening on this map. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378345734 From mstrauss at openjdk.org Wed Nov 1 03:15:16 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 03:15:16 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/684f48bb..167d4e8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=17-18 Stats: 77 lines in 11 files changed: 15 ins; 20 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Wed Nov 1 03:15:20 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 03:15:20 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 21:04:15 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line 786: > >> 784: * @return a map of platform-specific keys to well-known keys >> 785: */ >> 786: public Map getWellKnownPlatformPreferenceKeys() { > > Not really liking the name. Aren't these keys that are mapped to FX keys? Perhaps `getPlatformSpecificMappings` I chose `getPlatformKeyMappings` to put more emphasis on the fact that this is a mapping of keys to keys. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 575: > >> 573: * >> 574: * @return the {@code appearance} property >> 575: */ > > Should this include `@defaultValue` ? Yes. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 607: > >> 605: * The accent color. >> 606: *

>> 607: * If the platform does not report an accent color, this property defaults to {@code #157EFB}. > > Perhaps include what that color represents (`vivid blue`)? Done. > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617: > >> 615: >> 616: /** >> 617: * Returns the {@code Integer} instance to which the specified key is mapped. > > I think the wording of all of these should be modified slightly. No integer instance is returned. When dealing with optional I usually word it as: > > Returns an optional {@code Integer} to which ... > > ... and I leave out the `Optional.empty` part. > > I'd also leave out all the `instance` suffixes. I reworded all of these methods, but added a clarification that the `IllegalArgumentException` is only thrown if a mapping exists, but the value is wrong. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378350039 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378350135 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378348626 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378349137 From mstrauss at openjdk.org Wed Nov 1 03:28:39 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 03:28:39 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Tue, 31 Oct 2023 22:33:00 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 636: > >> 634: * if no mapping exists for the specified key >> 635: */ >> 636: Optional getDouble(String key); > > I'm a bit confused about this and similar methods. Several points: > > 1. There is no value that is a `Double`, and also no `Paint`, so I'm not sure what these are for considering that list gives all possible valid entries. > > 2. If the list of keys in the table is fully known, wouldn't an enum make more sense and be more safe than of a `String`? 1. There is no `Double` value now, but there might be in the future. For exampe, the API may expose system-provided double-click times, or it may expose information about the dimensions of system decorations. As for `Paint`, it might be conceivable that a platform would expose color gradients. 2. The list is only fully known for the three listed platforms, but it's unknown for other platforms. Using an enum key instead of a string key is certainly possible, but then we'd be hard-coding platform-specific constants into the core of JavaFX. You might argue that providing a list of supported keys isn't really all that different from using a language feature like enums to represent the constants. Using platform-specific preferences requires a deep understanding of the platform in any case, and is not something application developers should rely on regularly. Instead, they should be using the common subset of well-known preferences, which is easily accessible via the properties on the `Platform` class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378356218 From psadhukhan at openjdk.org Wed Nov 1 05:30:17 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 1 Nov 2023 05:30:17 GMT Subject: Integrated: 8317836: FX nodes embedded in JFXPanel need to track component orientation In-Reply-To: References: Message-ID: On Thu, 26 Oct 2023 09:34:17 GMT, Prasanta Sadhukhan wrote: > FX Nodes embedded in a Swing JFXPanel does not track the component orientation and FX nodes remain unaffected when component orientation changes. > Fix made sure JavaFX scene embedded in a JFXPanel should inherit the value from the JFXPanel. This pull request has now been integrated. Changeset: 6104113f Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jfx/commit/6104113f3a8b6ef4de42952aec168ab2fe129594 Stats: 23 lines in 3 files changed: 23 ins; 0 del; 0 mod 8317836: FX nodes embedded in JFXPanel need to track component orientation Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1271 From jhendrikx at openjdk.org Wed Nov 1 08:27:41 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Nov 2023 08:27:41 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 02:16:23 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1094: >> >>> 1092: // This method will be removed when StyleThemes are added. >>> 1093: private static void checkHighContrastThemeChanged(Map preferences) { >>> 1094: if (preferences.get("Windows.SPI.HighContrastOn") == Boolean.TRUE) { >> >> It's better to not use reference equality here, as `new Boolean("true") != Boolean.TRUE`. >> Suggestion: >> >> if (Boolean.TRUE.equals(preferences.get("Windows.SPI.HighContrastOn")) { > > This might not be an issue, considering that the Boolean(String) constructor is terminally deprecated anyway. It might not be, or it may become a bigger issue than it is now. Why take the risk? The rule in Java is always the same, objects are compared with `equals` unless you specifically need reference equality. You don't do this with other primitive wrappers either (because you are probably aware of things like the integer cache, which is just an implementation detail and no guarantee). Same for these booleans, you're relying on implementation details for this to work correctly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378512740 From jhendrikx at openjdk.org Wed Nov 1 08:32:40 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Nov 2023 08:32:40 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 02:28:15 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 52: >> >>> 50: * by calling the {@link #update(Map)} method. >>> 51: */ >>> 52: public class PlatformPreferences extends AbstractMap implements Platform.Preferences { >> >> Is there a need for this class to be public? It seems to me that `Platform.Preferences` is public, and that in order to get the platform preferences you call `Platform.getPreferences()`, which returns the interface. >> >> Otherwise, you need to document all `public` methods (not from the interface), including the constructor. > > `PlatformPreferences` is in the `com.sun.javafx.application.preferences` package, but must be accessible from the `com.sun.javafx.application` package. That's why it needs to be public. The class doesn't have undocumented public methods (aside from the constructor), but then again this class is also not API. Sorry, I missed that it was in `com.sun.*`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378516914 From kcr at openjdk.org Wed Nov 1 12:57:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 12:57:13 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: <1qJ42cdhlWLYrDf0TjzmgCINnXKwnNpKqpwJsrZpQY4=.ec2e1f8f-d656-4f00-8db7-d056a3013fb9@github.com> On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). It looks like there is a recently-introduced bug in Skara's handling of the `/reviewers` command. I filed [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088) to track it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1264#issuecomment-1788907978 From nlisker at openjdk.org Wed Nov 1 13:03:46 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Nov 2023 13:03:46 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 03:25:50 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 636: >> >>> 634: * if no mapping exists for the specified key >>> 635: */ >>> 636: Optional getDouble(String key); >> >> I'm a bit confused about this and similar methods. Several points: >> >> 1. There is no value that is a `Double`, and also no `Paint`, so I'm not sure what these are for considering that list gives all possible valid entries. >> >> 2. If the list of keys in the table is fully known, wouldn't an enum make more sense and be more safe than of a `String`? > > 1. There is no `Double` value now, but there might be in the future. For exampe, the API may expose system-provided double-click times, or it may expose information about the dimensions of system decorations. As for `Paint`, it might be conceivable that a platform would expose color gradients. > > 2. The list is only fully known for the three listed platforms, but it's unknown for other platforms. Using an enum key instead of a string key is certainly possible, but then we'd be hard-coding platform-specific constants into the core of JavaFX. You might argue that providing a list of supported keys isn't really all that different from using a language feature like enums to represent the constants. Using platform-specific preferences requires a deep understanding of the platform in any case, and is not something application developers should rely on regularly. Instead, they should be using the common subset of well-known preferences, which is easily accessible via the properties on the `Platform` class. Alright, my assumption that the listed keys are complete is wrong then. I thought that "The following list contains all preferences that are potentially available on the specified platforms" was a good enough guarantee. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378771358 From duke at openjdk.org Wed Nov 1 14:05:19 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 1 Nov 2023 14:05:19 GMT Subject: RFR: 8316419: [macos] Setting X/Y makes Stage maximization not work before show [v2] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 21:01:55 GMT, Andy Goryachev wrote: > The test program MaximizedStage JDK-8255835 : very strange - the window appears to be maximized beyond the visible area, the OS tool bar is on top and the dock is visible. It is impossible to minimize or normalize or quit the app via its toolbar. The window is borderless. It's difficult to see what's going on with the original test file so I added a new one to the JBS. MaximizedBorderStage adds a thin red border to the edge of the scene so you can verify that the JavaFX window doesn't go under the toolbar, the top edge of the window is flush with the bottom edge of the toolbar. > SetXYAndMaximize JDK-8316419 works the same with or without the fix, the window appears maximized to fill the visible area (excl. the dock and the tool bar): > The test program StartIconified JDK-8305675 works the same regardless of the fix: the window flashes, then immediately gets minimized. Is this expected? macOS 13.5.2 When I run these two test programs using the current JavaFX master they both fail (the windows don't iconify or maximize) but they work correctly with this fix. This is on my Mac running 13.6 but the OS version shouldn't matter. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1258#issuecomment-1789012239 From kcr at openjdk.org Wed Nov 1 14:13:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 14:13:14 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 31 Oct 2023 21:55:20 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. >> >> **Cause:** >> There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. >> >> **Fix:** >> Included an extra check for the psuedo states to match. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > 8185831: Changes to doc as per review comments The updated docs look good. I also verified that the provided test fails without the fix and passes with the fix. NOTE: There is a Skara bug that causes the state of `/reviewers` command to be ignored. Do not integrate this until there are three (3) approving reviews. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1245#pullrequestreview-1708305784 From angorya at openjdk.org Wed Nov 1 14:52:44 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 14:52:44 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 03:15:16 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review changes Q: should this document https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 be moved to /doc-files/jep for future reference? It looks like it might be useful in the future, and should be made a part of this repo instead of a gist. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1789092984 From jhendrikx at openjdk.org Wed Nov 1 14:57:16 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Nov 2023 14:57:16 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 31 Oct 2023 21:55:20 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. >> >> **Cause:** >> There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. >> >> **Fix:** >> Included an extra check for the psuedo states to match. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > 8185831: Changes to doc as per review comments Looks good, no comments ------------- Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1245#pullrequestreview-1708395985 From angorya at openjdk.org Wed Nov 1 14:59:44 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 14:59:44 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 03:15:16 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review changes modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 122: > 120: > 121: @Override > 122: public Optional getInteger(String key) { Q: is it possible to encounter an unsigned 64 bit value? Should we allow for BigInteger? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378912236 From angorya at openjdk.org Wed Nov 1 14:59:42 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 14:59:42 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 08:24:10 GMT, John Hendrikx wrote: >> This might not be an issue, considering that the Boolean(String) constructor is terminally deprecated anyway. > > It might not be, or it may become a bigger issue than it is now. Why take the risk? The rule in Java is always the same, objects are compared with `equals` unless you specifically need reference equality. > > You don't do this with other primitive wrappers either (because you are probably aware of things like the integer cache, which is just an implementation detail and no guarantee). Same for these booleans, you're relying on implementation details for this to work correctly. I agree with John: `if (Boolean.TRUE.equals(` is much better (maintaintability, correctness) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378908269 From angorya at openjdk.org Wed Nov 1 15:00:17 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 15:00:17 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 31 Oct 2023 21:55:20 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. >> >> **Cause:** >> There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. >> >> **Fix:** >> Included an extra check for the psuedo states to match. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > 8185831: Changes to doc as per review comments ? looks good ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1245#pullrequestreview-1708402492 From jhendrikx at openjdk.org Wed Nov 1 15:20:48 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Nov 2023 15:20:48 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 14:56:23 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> review changes > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 122: > >> 120: >> 121: @Override >> 122: public Optional getInteger(String key) { > > Q: is it possible to encounter an unsigned 64 bit value? > Should we allow for BigInteger? IMHO this can be added when there's a use case. Also, an int can support all values of an unsigned variant, you just need to be careful when interpreting it (ie. do `long unsigned = i & 0xffffffffL` first). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378940028 From kcr at openjdk.org Wed Nov 1 15:24:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 15:24:40 GMT Subject: RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Message-ID: A recent change to Skara in processing of the .jcheck/conf file ([SKARA-2080](https://bugs.openjdk.org/browse/SKARA-2080)) introduced a bug in processing the `[checks "reviewers"]` section that causes the `/reviewers` command to be ignored in some cases. This is tracked by [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The reason we tripped over this bug is that the `.jcheck/conf` file used by jfx (including various update release repos) uses an unrecognized key, "minimum", instead of the expected "reviewers" key to indicate the minimum number of reviewers. We should fix this to be consistent with what Skara expects given the intent of our `[checks "reviewers"]` section. ------------- Commit messages: - 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Changes: https://git.openjdk.org/jfx/pull/1275/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319231 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1275.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1275/head:pull/1275 PR: https://git.openjdk.org/jfx/pull/1275 From kcr at openjdk.org Wed Nov 1 15:24:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 15:24:40 GMT Subject: RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: <3ruIyi3fWNYNYBuVRsIQ1DYJciJ92_6i2CLz04phfs8=.2be7c6cd-40ff-4f9c-af05-3407ad538abd@github.com> On Wed, 1 Nov 2023 15:16:54 GMT, Kevin Rushforth wrote: > A recent change to Skara in processing of the .jcheck/conf file ([SKARA-2080](https://bugs.openjdk.org/browse/SKARA-2080)) introduced a bug in processing the `[checks "reviewers"]` section that causes the `/reviewers` command to be ignored in some cases. This is tracked by [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The reason we tripped over this bug is that the `.jcheck/conf` file used by jfx (including various update release repos) uses an unrecognized key, "minimum", instead of the expected "reviewers" key to indicate the minimum number of reviewers. We should fix this to be consistent with what Skara expects given the intent of our `[checks "reviewers"]` section. @edvbld Can you review this? @andy-goryachev-oracle Can you be the "R"eviewer (once Erik D reviews it)? NOTE: This matches the [equivalent line](https://github.com/openjdk/jdk/blob/master/.jcheck/conf#L25) in the jdk repo's `.jcheck/conf'` file. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1275#issuecomment-1789143456 PR Comment: https://git.openjdk.org/jfx/pull/1275#issuecomment-1789145562 From angorya at openjdk.org Wed Nov 1 15:48:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 15:48:14 GMT Subject: RFR: 8316419: [macos] Setting X/Y makes Stage maximization not work before show [v2] In-Reply-To: References: Message-ID: On Sat, 21 Oct 2023 00:10:50 GMT, Martin Fox wrote: >> When a window is visible the maximized, iconified, and fullscreen properties are two-way streets; changes made in Java are sent on to the platform window and changes in the platform window are sent back into Java. >> >> When a window is hidden these properties (and others, like location and sizing information) are not sent on to the platform window until the window is made visible. In other words, the properties don't reflect the actual state of the window but the intended state after it's shown. >> >> There's a period when the window is transitioning from hidden to shown where the core Stage code is using the stored properties to configure the platform window and the platform window is simultaneously calling back in to update the properties. This was causing the intended state to be wiped out before it could be sent on to the platform window. >> >> The problem is specific to Mac because on that platform any change to the size or location of a window can cause it to enter or leave the maximized (zoomed) state. So just setting the location can cause the maximized flag to be altered. >> >> The proposed solution is to copy the intended state bits to Stage local variables to be used later in the configuration. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Revert core changes. Fix Mac glass code so it reports maximized state correctly. MaximizedStage with a border is much cleaner, works as expected, thank you! StartIconified_8305675 and SetXYAndMaximize_8316419 work the same with our without fix, I just double checked. May be because I am running 13.5.2 on M1 silicon? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1258#issuecomment-1789191049 From kcr at openjdk.org Wed Nov 1 15:51:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 15:51:26 GMT Subject: [jfx-tests] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Message-ID: Fix the `[checks "reviewers"]` section of `.jcheck/conf` to match the mainline jfx repo. See openjdk/jfx#1275 for details. ------------- Commit messages: - 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Changes: https://git.openjdk.org/jfx-tests/pull/14/files Webrev: https://webrevs.openjdk.org/?repo=jfx-tests&pr=14&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319231 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx-tests/pull/14.diff Fetch: git fetch https://git.openjdk.org/jfx-tests.git pull/14/head:pull/14 PR: https://git.openjdk.org/jfx-tests/pull/14 From angorya at openjdk.org Wed Nov 1 15:55:20 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 15:55:20 GMT Subject: RFR: 8316419: [macos] Setting X/Y makes Stage maximization not work before show [v2] In-Reply-To: References: Message-ID: On Sat, 21 Oct 2023 00:10:50 GMT, Martin Fox wrote: >> When a window is visible the maximized, iconified, and fullscreen properties are two-way streets; changes made in Java are sent on to the platform window and changes in the platform window are sent back into Java. >> >> When a window is hidden these properties (and others, like location and sizing information) are not sent on to the platform window until the window is made visible. In other words, the properties don't reflect the actual state of the window but the intended state after it's shown. >> >> There's a period when the window is transitioning from hidden to shown where the core Stage code is using the stored properties to configure the platform window and the platform window is simultaneously calling back in to update the properties. This was causing the intended state to be wiped out before it could be sent on to the platform window. >> >> The problem is specific to Mac because on that platform any change to the size or location of a window can cause it to enter or leave the maximized (zoomed) state. So just setting the location can cause the maximized flag to be altered. >> >> The proposed solution is to copy the intended state bits to Stage local variables to be used later in the configuration. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Revert core changes. Fix Mac glass code so it reports maximized state correctly. Regardless, the code works correctly now, so ? LGTM ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1258#pullrequestreview-1708513917 From ehelin at openjdk.org Wed Nov 1 15:59:10 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 1 Nov 2023 15:59:10 GMT Subject: RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:16:54 GMT, Kevin Rushforth wrote: > A recent change to Skara in processing of the .jcheck/conf file ([SKARA-2080](https://bugs.openjdk.org/browse/SKARA-2080)) introduced a bug in processing the `[checks "reviewers"]` section that causes the `/reviewers` command to be ignored in some cases. This is tracked by [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The reason we tripped over this bug is that the `.jcheck/conf` file used by jfx (including various update release repos) uses an unrecognized key, "minimum", instead of the expected "reviewers" key to indicate the minimum number of reviewers. We should fix this to be consistent with what Skara expects given the intent of our `[checks "reviewers"]` section. Looks good! ------------- Marked as reviewed by ehelin (no project role). PR Review: https://git.openjdk.org/jfx/pull/1275#pullrequestreview-1708522921 From angorya at openjdk.org Wed Nov 1 15:59:10 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 15:59:10 GMT Subject: RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: <_Dqee40yA_YnABeL5_HQyCbMzV7iRtk1DqDBeuFgKN8=.2096ca23-05a5-40e1-9a24-806301d601a6@github.com> On Wed, 1 Nov 2023 15:16:54 GMT, Kevin Rushforth wrote: > A recent change to Skara in processing of the .jcheck/conf file ([SKARA-2080](https://bugs.openjdk.org/browse/SKARA-2080)) introduced a bug in processing the `[checks "reviewers"]` section that causes the `/reviewers` command to be ignored in some cases. This is tracked by [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The reason we tripped over this bug is that the `.jcheck/conf` file used by jfx (including various update release repos) uses an unrecognized key, "minimum", instead of the expected "reviewers" key to indicate the minimum number of reviewers. We should fix this to be consistent with what Skara expects given the intent of our `[checks "reviewers"]` section. matches jdk! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1275#pullrequestreview-1708524743 From angorya at openjdk.org Wed Nov 1 16:06:16 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 16:06:16 GMT Subject: [jfx-tests] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:44:12 GMT, Kevin Rushforth wrote: > Fix the `[checks "reviewers"]` section of `.jcheck/conf` to match the mainline jfx repo. See openjdk/jfx#1275 for details. lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx-tests/pull/14#pullrequestreview-1708537986 From kcr at openjdk.org Wed Nov 1 16:06:16 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 16:06:16 GMT Subject: [jfx-tests] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: <0o4xiaAgSOjn-1NLbxqbteElr2Bd863LfXvdKTiwGQI=.ebce313a-ee31-45c4-8fe9-e14dd7c00516@github.com> On Wed, 1 Nov 2023 15:44:12 GMT, Kevin Rushforth wrote: > Fix the `[checks "reviewers"]` section of `.jcheck/conf` to match the mainline jfx repo. See openjdk/jfx#1275 for details. @andy-goryachev-oracle Can you Review the jcheck fix for this repo, too? The .jcheck/conf file in this repo is identical to the one in the jfx repo (after the identical fix is applied). ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/14#issuecomment-1789221641 PR Comment: https://git.openjdk.org/jfx-tests/pull/14#issuecomment-1789223273 From kcr at openjdk.org Wed Nov 1 16:09:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 16:09:17 GMT Subject: Integrated: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:16:54 GMT, Kevin Rushforth wrote: > A recent change to Skara in processing of the .jcheck/conf file ([SKARA-2080](https://bugs.openjdk.org/browse/SKARA-2080)) introduced a bug in processing the `[checks "reviewers"]` section that causes the `/reviewers` command to be ignored in some cases. This is tracked by [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The reason we tripped over this bug is that the `.jcheck/conf` file used by jfx (including various update release repos) uses an unrecognized key, "minimum", instead of the expected "reviewers" key to indicate the minimum number of reviewers. We should fix this to be consistent with what Skara expects given the intent of our `[checks "reviewers"]` section. This pull request has now been integrated. Changeset: 72c052ee Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/72c052ee2ad7b1f74c3c57078917c719d66a9c10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Reviewed-by: ehelin, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1275 From kcr at openjdk.org Wed Nov 1 16:09:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 16:09:20 GMT Subject: [jfx-tests] Integrated: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: <3pVwz0Gz1Jb0SF4MDLfbKARN7-BXCYz6y33wHDck48k=.ed0be0ad-682c-45a4-ad60-f6ce7ebb3e1b@github.com> On Wed, 1 Nov 2023 15:44:12 GMT, Kevin Rushforth wrote: > Fix the `[checks "reviewers"]` section of `.jcheck/conf` to match the mainline jfx repo. See openjdk/jfx#1275 for details. This pull request has now been integrated. Changeset: 5c61910d Author: Kevin Rushforth URL: https://git.openjdk.org/jfx-tests/commit/5c61910d988a7c535abbc4633fa3cdfb206ac9b4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx-tests/pull/14 From angorya at openjdk.org Wed Nov 1 16:12:21 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 16:12:21 GMT Subject: RFR: 8316518 javafx.print.Paper getWidth / getHeight rounds values, causing errors. [v2] In-Reply-To: References: <1wbl-3ezWxBfauar0VeDmAH_wzpj3Pzb0yhDzRzkLwo=.af43c42d-d581-4556-bf36-e50a4e391980@github.com> Message-ID: On Tue, 31 Oct 2023 11:46:57 GMT, Florian Kirmaier wrote: >> The Method javafx.print.getWidth and getHeight returns a double of points. >> But the values are always rounded to full integers. This causes especially problems, >> with mm based Papers. >> >> I asked in the mailing list, with the conclusion (me and John Hendrix) that is best to just fix this behavior by removing the rounding. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8316518 > small change based on codereview (testing jcheck fix) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1244#issuecomment-1789234370 From kcr at openjdk.org Wed Nov 1 16:13:26 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 16:13:26 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 31 Oct 2023 21:55:20 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. >> >> **Cause:** >> There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. >> >> **Fix:** >> Included an extra check for the psuedo states to match. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > 8185831: Changes to doc as per review comments @SaiPradeepDandem This is now OK to integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1245#issuecomment-1789236157 From kcr at openjdk.org Wed Nov 1 16:35:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 16:35:47 GMT Subject: [jfx21u] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Message-ID: Clean backport to jfx21u. ------------- Commit messages: - Backport 72c052ee2ad7b1f74c3c57078917c719d66a9c10 Changes: https://git.openjdk.org/jfx21u/pull/24/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=24&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319231 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/24.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/24/head:pull/24 PR: https://git.openjdk.org/jfx21u/pull/24 From mstrauss at openjdk.org Wed Nov 1 17:28:42 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 17:28:42 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <5WYT96JJtgNaxudRC2l_EM0Uk0fvb1i7-CIBweYKs0c=.622557fd-c926-4cb2-9d5d-e4d5568393a6@github.com> On Wed, 1 Nov 2023 15:18:01 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 122: >> >>> 120: >>> 121: @Override >>> 122: public Optional getInteger(String key) { >> >> Q: is it possible to encounter an unsigned 64 bit value? >> Should we allow for BigInteger? > > IMHO this can be added when there's a use case. > > Also, an int can support all values of an unsigned variant, you just need to be careful when interpreting it (ie. do `long unsigned = i & 0xffffffffL` first). I also think that that's an addition for another day. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1379098296 From mstrauss at openjdk.org Wed Nov 1 17:28:40 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 17:28:40 GMT Subject: RFR: 8301302: Platform preferences API [v19] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 14:49:57 GMT, Andy Goryachev wrote: > Q: should this document https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548 be moved to /doc-files/jep for future reference? It looks like it might be useful in the future, and should be made a part of this repo instead of a gist. I can do that once the API is finalized and all features are in. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1789355887 From angorya at openjdk.org Wed Nov 1 17:29:14 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 17:29:14 GMT Subject: [jfx21u] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 16:28:50 GMT, Kevin Rushforth wrote: > Clean backport to jfx21u. is the target branch correct? ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/24#issuecomment-1789360507 From mstrauss at openjdk.org Wed Nov 1 17:36:21 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Nov 2023 17:36:21 GMT Subject: RFR: 8301302: Platform preferences API [v20] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changend bool comparison ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/167d4e8b..ad74e397 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From angorya at openjdk.org Wed Nov 1 17:45:19 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 17:45:19 GMT Subject: [jfx21u] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: <_ScudaRFpuj6CnpwcA-dhRnG6x28jfM3XNyikynopZI=.c03aca01-159d-4ca6-b9d8-d657f19839d4@github.com> On Wed, 1 Nov 2023 16:28:50 GMT, Kevin Rushforth wrote: > Clean backport to jfx21u. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/24#pullrequestreview-1708716775 From kcr at openjdk.org Wed Nov 1 17:45:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 17:45:20 GMT Subject: [jfx21u] Integrated: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 16:28:50 GMT, Kevin Rushforth wrote: > Clean backport to jfx21u. This pull request has now been integrated. Changeset: 916df936 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx21u/commit/916df936b78bfee46caa9daaa1c10a04fb46161f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Reviewed-by: angorya Backport-of: 72c052ee2ad7b1f74c3c57078917c719d66a9c10 ------------- PR: https://git.openjdk.org/jfx21u/pull/24 From jvos at openjdk.org Wed Nov 1 19:54:35 2023 From: jvos at openjdk.org (Johan Vos) Date: Wed, 1 Nov 2023 19:54:35 GMT Subject: [jfx17u] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Message-ID: ? command to be ignored Reviewed-by: ehelin, angorya ------------- Commit messages: - 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Changes: https://git.openjdk.org/jfx17u/pull/167/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=167&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319231 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/167.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/167/head:pull/167 PR: https://git.openjdk.org/jfx17u/pull/167 From duke at openjdk.org Wed Nov 1 20:41:13 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 1 Nov 2023 20:41:13 GMT Subject: Integrated: 8316419: [macos] Setting X/Y makes Stage maximization not work before show In-Reply-To: References: Message-ID: <9hEgZyLS8pb8FU3YqZd_35ciOK4igg-ADMgE8z-GkyU=.3dfde797-550f-4f7a-b4ca-e011603368e8@github.com> On Thu, 12 Oct 2023 05:52:04 GMT, Martin Fox wrote: > When a window is visible the maximized, iconified, and fullscreen properties are two-way streets; changes made in Java are sent on to the platform window and changes in the platform window are sent back into Java. > > When a window is hidden these properties (and others, like location and sizing information) are not sent on to the platform window until the window is made visible. In other words, the properties don't reflect the actual state of the window but the intended state after it's shown. > > There's a period when the window is transitioning from hidden to shown where the core Stage code is using the stored properties to configure the platform window and the platform window is simultaneously calling back in to update the properties. This was causing the intended state to be wiped out before it could be sent on to the platform window. > > The problem is specific to Mac because on that platform any change to the size or location of a window can cause it to enter or leave the maximized (zoomed) state. So just setting the location can cause the maximized flag to be altered. > > The proposed solution is to copy the intended state bits to Stage local variables to be used later in the configuration. This pull request has now been integrated. Changeset: f41e3ec0 Author: Martin Fox Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/f41e3ec02bdbdff1417ed20b8e02645348825e4d Stats: 24 lines in 3 files changed: 16 ins; 8 del; 0 mod 8316419: [macos] Setting X/Y makes Stage maximization not work before show 8255835: [macOS] Undecorated stage cannot be maximized 8305675: [macos] Stage set to iconified before being shown is displayed on screen Reviewed-by: lkostyra, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1258 From kcr at openjdk.org Wed Nov 1 21:53:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Nov 2023 21:53:14 GMT Subject: [jfx17u] RFR: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:47:42 GMT, Johan Vos wrote: > ? command to be ignored > > Reviewed-by: ehelin, angorya Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/167#pullrequestreview-1709139006 From duke at openjdk.org Wed Nov 1 22:37:14 2023 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Wed, 1 Nov 2023 22:37:14 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Wed, 1 Nov 2023 16:10:09 GMT, Kevin Rushforth wrote: > @SaiPradeepDandem This is now OK to integrate. @kevinrushforth thanks for confirming. But I am pretty not sure what steps I need to do next. Is it that I need to type a new comment with /integrate ? as mentioned in `To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1245#issuecomment-1789783106 From angorya at openjdk.org Wed Nov 1 22:40:15 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Nov 2023 22:40:15 GMT Subject: RFR: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() [v13] In-Reply-To: References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 31 Oct 2023 21:55:20 GMT, Sai Pradeep Dandem wrote: >> **Issue:** >> Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. >> >> **Cause:** >> There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. >> >> **Fix:** >> Included an extra check for the psuedo states to match. > > Sai Pradeep Dandem has updated the pull request incrementally with one additional commit since the last revision: > > 8185831: Changes to doc as per review comments yes, just type slash-integrate command ------------- PR Comment: https://git.openjdk.org/jfx/pull/1245#issuecomment-1789785224 From duke at openjdk.org Wed Nov 1 22:49:15 2023 From: duke at openjdk.org (Sai Pradeep Dandem) Date: Wed, 1 Nov 2023 22:49:15 GMT Subject: Integrated: 8185831: Pseudo selectors do not appear to work in Node.lookupAll() In-Reply-To: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> References: <0ybBMwZ7W35jsrQjOfigeCjeJVkLXnkEke3gOh6nWws=.3fd4e961-33de-4cb8-946d-b9b8590e8aaa@github.com> Message-ID: On Tue, 19 Sep 2023 12:17:16 GMT, Sai Pradeep Dandem wrote: > **Issue:** > Using pseudo classes in programmatic query using Node.lookupAll() or Node.lookup() gives unexpected results. > > **Cause:** > There is no check for checking the psuedo states matching in the applies() method of SimpleSelector.java. So checking for "applies()" alone is not sufficient in lookup() method. > > **Fix:** > Included an extra check for the psuedo states to match. This pull request has now been integrated. Changeset: bb06b64c Author: Dandem, Sai Pradeep Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/bb06b64c9e1cda9390a84704a75b530c1d1d4577 Stats: 185 lines in 2 files changed: 170 ins; 0 del; 15 mod 8185831: Pseudo selectors do not appear to work in Node.lookupAll() Reviewed-by: kcr, angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1245 From jdv at openjdk.org Thu Nov 2 06:55:29 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 06:55:29 GMT Subject: RFR: 8319079: Missing range checks in decora [v3] In-Reply-To: References: Message-ID: > In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking for range when we read data from the source/destination buffers in native code. > > We need to add appropriate range checks in native JNI code also apart from range checks in Java side to make sure that wherever these JNI methods are used we are not performing out of bounds access. Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: - Update checkRange arguments indentation - Add checkRange function comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1272/files - new: https://git.openjdk.org/jfx/pull/1272/files/5cccac6b..69739db9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1272&range=01-02 Stats: 45 lines in 6 files changed: 5 ins; 20 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/1272.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1272/head:pull/1272 PR: https://git.openjdk.org/jfx/pull/1272 From jdv at openjdk.org Thu Nov 2 06:55:31 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 06:55:31 GMT Subject: RFR: 8319079: Missing range checks in decora [v2] In-Reply-To: References: <75n9uClj6dSU7fekSj-bf6meierM15eek1o11l40rf4=.dcad2b35-63a5-4332-bb29-ca1247a0fe67@github.com> Message-ID: On Tue, 31 Oct 2023 14:54:01 GMT, Kevin Rushforth wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Add common util function > > modules/javafx.graphics/src/main/native-decora/SSEUtils.cc line 187: > >> 185: } >> 186: >> 187: bool checkRange(JNIEnv *env, > > It would be helpful to add a comment indicating that this will return true if the range check fails and false if it is OK. @kevinrushforth thanks for your inputs. I thought for sometime about how to name this function like notInRange() or outOfRange() but since it is checking so many parameters i didn't change function name. I have added comment about what the function is doing as pointed by you. Also @arapte mentioned a small nit offline about how we can keep src/dst arguments on same line instead of dividing them. I have updated that also. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1272#discussion_r1379662928 From arapte at openjdk.org Thu Nov 2 07:14:14 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Nov 2023 07:14:14 GMT Subject: RFR: 8319079: Missing range checks in decora [v3] In-Reply-To: References: Message-ID: <2RibCu14yXm1lWdxRFjBWvXLw7Rr0bp8RUyzeJVI-vI=.5a8f15e4-3f84-4d8e-bc6d-249e6fb42923@github.com> On Thu, 2 Nov 2023 06:55:29 GMT, Jayathirth D V wrote: >> In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking for range when we read data from the source/destination buffers in native code. >> >> We need to add appropriate range checks in native JNI code also apart from range checks in Java side to make sure that wherever these JNI methods are used we are not performing out of bounds access. > > Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: > > - Update checkRange arguments indentation > - Add checkRange function comment Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1272#pullrequestreview-1709579571 From psadhukhan at openjdk.org Thu Nov 2 08:06:23 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 2 Nov 2023 08:06:23 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 Message-ID: A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added ------------- Commit messages: - Test fix - Test fix Changes: https://git.openjdk.org/jfx/pull/1276/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1276&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319147 Stats: 120 lines in 1 file changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1276.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1276/head:pull/1276 PR: https://git.openjdk.org/jfx/pull/1276 From mhanl at openjdk.org Thu Nov 2 08:16:43 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Nov 2023 08:16:43 GMT Subject: RFR: JDK-8187314: All Cells: must show backing data always [v2] In-Reply-To: References: Message-ID: > Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`. > This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise). > We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value. > > Changed and added tests for all 4 cells. Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8187314-cell-backing-data - JDK-8187314: All Cells: must show backing data always ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1197/files - new: https://git.openjdk.org/jfx/pull/1197/files/bcc74881..e36bebc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1197&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1197&range=00-01 Stats: 13370 lines in 329 files changed: 10594 ins; 1569 del; 1207 mod Patch: https://git.openjdk.org/jfx/pull/1197.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1197/head:pull/1197 PR: https://git.openjdk.org/jfx/pull/1197 From mhanl at openjdk.org Thu Nov 2 08:25:20 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Nov 2023 08:25:20 GMT Subject: RFR: JDK-8187314: All Cells: must show backing data always [v2] In-Reply-To: References: Message-ID: <0gcsOclpeOcBqtAVukJwI6RuTLL5dVLrcTzO2fWXZwE=.153de377-a76d-4f40-b184-d01edd61ba21@github.com> On Thu, 2 Nov 2023 08:16:43 GMT, Marius Hanl wrote: >> Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`. >> This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise). >> We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value. >> >> Changed and added tests for all 4 cells. > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8187314-cell-backing-data > - JDK-8187314: All Cells: must show backing data always > TreeTableView with multiple columns works as expected. Thanks for checking. In the meantime I also checked out the tests, and all of them do test one column (`startEdit`, `cancelEdit`, `commitEdit`, `setOnEditCommit`, ....), so I really think we are good here! ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1197#issuecomment-1790268360 From jvos at openjdk.org Thu Nov 2 08:28:14 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 2 Nov 2023 08:28:14 GMT Subject: [jfx17u] Integrated: 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:47:42 GMT, Johan Vos wrote: > ? command to be ignored > > Reviewed-by: ehelin, angorya This pull request has now been integrated. Changeset: 192480a4 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/192480a4e7970904c6b5a729681b1c89f5dc504d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319231: Unrecognized "minimum" key in .jcheck/conf causes /reviewers command to be ignored Reviewed-by: kcr Backport-of: 72c052ee2ad7b1f74c3c57078917c719d66a9c10 ------------- PR: https://git.openjdk.org/jfx17u/pull/167 From mhanl at openjdk.org Thu Nov 2 10:36:15 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Nov 2023 10:36:15 GMT Subject: Integrated: JDK-8187314: All Cells: must show backing data always In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 18:13:34 GMT, Marius Hanl wrote: > Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`. > This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise). > We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value. > > Changed and added tests for all 4 cells. This pull request has now been integrated. Changeset: ead19536 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/ead19536437be1b6e3543a3c9c1e0cf67beb2944 Stats: 108 lines in 8 files changed: 94 ins; 2 del; 12 mod 8187314: All Cells: must show backing data always Reviewed-by: angorya, aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1197 From mhanl at openjdk.org Thu Nov 2 11:03:16 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Nov 2023 11:03:16 GMT Subject: RFR: 8313709: Wrong layout of a FlowPane in a BorderPane in a ScrollPane, if padding is too big [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 23:44:58 GMT, Jose Pereda wrote: >> So far, BorderPane does the calculation for the children min/pref width/height taken into account only the margin applied to them, if any, but not the total padding that could be applied as well to the BorderPane itself. >> >> However, this padding needs to be taken into account as well, and this PR modifies BorderPane to subtract its insets from its size while doing the children min/pref width/height calculations. >> >> A parameterized test has been included. >> >> It is a simplified version of the test case attached to https://bugs.openjdk.org/browse/JDK-8313709, but still shows how without this patch, two of the cases (padding with or without margin) fail, while pass with it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Migrate old tests to JUnit 5 modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java line 413: > 411: @Override protected double computeMinHeight(double width) { > 412: final Insets insets = getInsets(); > 413: if (width != -1) { You could use the constant `Region.USE_COMPUTED_SIZE` here to make the intent here more clear ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1203#discussion_r1379931322 From jvos at openjdk.org Thu Nov 2 11:44:43 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 2 Nov 2023 11:44:43 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used Message-ID: When the Java layer removes a systemmenu, release the native resources related to this systemmenu. This removes the strong JNI Global ref, which prevents its references from being gc'ed. The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. ------------- Commit messages: - When the Java layer removes a systemmenu, release the native resources related to this systemmenu. Changes: https://git.openjdk.org/jfx/pull/1277/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318841 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From arapte at openjdk.org Thu Nov 2 11:46:24 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 2 Nov 2023 11:46:24 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all When a function key is pressed [NSFunctionKeyMask](https://developer.apple.com/documentation/appkit/nsfunctionkeymask) is automatically included by the system. Hence it looks not breaking behavior with this change. As the warning is quite clear it looks logical to not include the modifier. Tested on macOS 12.6.8, warning appears without this change and disappears with this change. Can you please check _KeyCombinationTest.java_ test file and try to add a unit test, at least a mac specific test, which should press a Function key and check that modifiers in the received event contains Function modifier flag. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1790569978 From kcr at openjdk.org Thu Nov 2 11:50:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 11:50:15 GMT Subject: RFR: 8319079: Missing range checks in decora [v3] In-Reply-To: References: Message-ID: <_MZ1ZQa76smKBXuwmtdZ2PBSzcZCulv1yxDlC8spWcI=.df04ebb2-c1a8-489e-9280-e26779a6ee3e@github.com> On Thu, 2 Nov 2023 06:55:29 GMT, Jayathirth D V wrote: >> In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking for range when we read data from the source/destination buffers in native code. >> >> We need to add appropriate range checks in native JNI code also apart from range checks in Java side to make sure that wherever these JNI methods are used we are not performing out of bounds access. > > Jayathirth D V has updated the pull request incrementally with two additional commits since the last revision: > > - Update checkRange arguments indentation > - Add checkRange function comment Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1272#pullrequestreview-1710052045 From kcr at openjdk.org Thu Nov 2 12:20:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 12:20:13 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:39:47 GMT, Johan Vos wrote: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Is it possible to add an automated regression test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1790622466 From jdv at openjdk.org Thu Nov 2 12:52:19 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 12:52:19 GMT Subject: Integrated: 8319079: Missing range checks in decora In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 06:55:11 GMT, Jayathirth D V wrote: > In SW pipeline path of Box/Gaussian Blur/Shadow effects we are not checking for range when we read data from the source/destination buffers in native code. > > We need to add appropriate range checks in native JNI code also apart from range checks in Java side to make sure that wherever these JNI methods are used we are not performing out of bounds access. This pull request has now been integrated. Changeset: 96e5d10a Author: Jayathirth D V Committer: Nir Lisker URL: https://git.openjdk.org/jfx/commit/96e5d10a40dc25b999ff229f1d6601d1058761b2 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod 8319079: Missing range checks in decora Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1272 From nlisker at openjdk.org Thu Nov 2 12:58:25 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 2 Nov 2023 12:58:25 GMT Subject: RFR: 8223298: SVG patterns are drawn wrong [v2] In-Reply-To: References: <5YmcHntf1Eh0B834KOCZKJQPRp54JcokstInXVx-oAM=.17a1eacd-256f-46a0-a70a-e5481458fbb1@github.com> Message-ID: <2XYdmls6e8_qkqFp069NEzX4oq8rkLfagdFnnwSZ3fw=.e6b7d989-04e8-4efa-815d-a95161a81675@github.com> On Wed, 15 Apr 2020 13:35:11 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > As discussed offline, please add a test for this. @kevinrushforth Looks like the `sponsor` tag wasn't removed in this one long ago. ------------- PR Comment: https://git.openjdk.org/jfx/pull/164#issuecomment-1790674620 From thiago.sayao at gmail.com Thu Nov 2 13:21:09 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 2 Nov 2023 10:21:09 -0300 Subject: Making the Stages MODAL by using native modality functionality Message-ID: Hi, On Linux, the current behavior of SetEnabled(true / false) does not work very well. Ideally it should use native MODALITY. On GTK MODAL means APPLICATION_MODAL. MODAL as in JavaFX would be archived by using Window groups: https://docs.gtk.org/gtk3/ctor.WindowGroup.new.html I would make this work, but I am unsure about Windows or MAC capabilities. Would this be possible? One approach is to move Modality to each platform Window implementation and keep the way it is for MAC and Windows and use the platform Thoughts? -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Thu Nov 2 13:41:43 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 2 Nov 2023 13:41:43 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <05Hnd1uKMsYMGQVIEk9TnHg30rMG7RythehtwwsJFfU=.072fee52-33bb-46e4-b2ed-d8f920473907@github.com> On Tue, 31 Oct 2023 17:28:35 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - formatting > - Javadoc change modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1098: > 1096: } else { > 1097: setAccessibilityTheme(null); > 1098: } Can this not be written more simply as String val = Boolean.TRUE.equals(preferences.get("Windows.SPI.HighContrastOn")) && preferences.get("Windows.SPI.HighContrastColorScheme") instanceof String s ? s : null; setAccessibilityTheme(val); ? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 61: > 59: final Map effectivePreferences = new HashMap<>(); > 60: final Map unmodifiableEffectivePreferences = Collections.unmodifiableMap(effectivePreferences); > 61: final PreferenceProperties properties = new PreferenceProperties(this); Why are these not `private`? I don't see them being used outside of this class. Also, if possible, add some documentation on these fields so maintainers can understand better what each is for, modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 67: > 65: > 66: public PlatformPreferences(Map wellKnownKeys) { > 67: this.wellKnownKeys = wellKnownKeys; Is the argument map guaranteed to not change outside of this class, or is there a need for a defensive copy? modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 192: > 190: /** > 191: * Updates this map of preferences with a new set of platform preferences. > 192: * The specified preferences may include all available preferences, or only the changed preferences. I would mention here that removed preferences are specified by being mapped to `null`, but that the resulting preferences (after update) cannot map to `null`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378839517 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1378817922 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380059912 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380097328 From kcr at openjdk.org Thu Nov 2 13:46:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 13:46:19 GMT Subject: RFR: 8223298: SVG patterns are drawn wrong [v3] In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest If I had to guess, there was some sort of bug or race condition in Skara around the time Arun became a committer. Looking at the history, I see that a second `/integrate` command succeeded without needing a sponsor. ------------- PR Comment: https://git.openjdk.org/jfx/pull/164#issuecomment-1790762397 From kcr at openjdk.org Thu Nov 2 13:50:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 13:50:21 GMT Subject: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values [v3] In-Reply-To: References: Message-ID: On Wed, 11 Oct 2023 11:18:17 GMT, Jayathirth D V wrote: >> Two perspective lod tests fail because of minute differences in expected values. >> >> Failing tests: >> test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: >> test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: >> >> Exception: >> test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure >> org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds >> at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) >> at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) >> at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) >> at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at java.base/java.lang.Thread.run(Thread.java:833) >> >> These little difference in values are seen both initial drawing and updates. >> These tests are not run from long time and change in product might change lod values. >> >> With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1). > > Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into lod_tests > - Add lod tolerance > - 8315896: Perspective lod tests fail because of minute difference in values Looks good. Please file a follow-up bug to get the tests running on Windows. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx-tests/pull/6#pullrequestreview-1710342446 From angorya at openjdk.org Thu Nov 2 15:22:12 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Nov 2023 15:22:12 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 06:04:23 GMT, Prasanta Sadhukhan wrote: > A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added looks good, works as expected with the latest master. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1276#pullrequestreview-1710581535 From kcr at openjdk.org Thu Nov 2 15:29:23 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 15:29:23 GMT Subject: RFR: 8223298: SVG patterns are drawn wrong [v3] In-Reply-To: References: Message-ID: On Wed, 15 Apr 2020 15:14:49 GMT, Arun Joseph wrote: >> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the native side which is propagated to the java side as well. But, as transform initialization takes place after scaling, the transform is reset to default value. >> >> Fix: Override scale() method in WCBufferedContext class to call init() before scaling. > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Added SVGTest We will manually remove the label to avoid confusion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/164#issuecomment-1790955401 From angorya at openjdk.org Thu Nov 2 15:31:40 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Nov 2023 15:31:40 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v7] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - Merge remote-tracking branch 'origin/master' into 8299753.resize - undo merge - no new api - Merge remote-tracking branch 'origin/master' into 8299753.resize - cleanup - using snap inner space api - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'ag.8311527.snap.inner' into 8299753.resize - ... and 16 more: https://git.openjdk.org/jfx/compare/04f96b60...5e855022 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1156/files - new: https://git.openjdk.org/jfx/pull/1156/files/abd9af92..5e855022 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=05-06 Stats: 10124 lines in 176 files changed: 8090 ins; 1248 del; 786 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From duke at openjdk.org Thu Nov 2 15:54:19 2023 From: duke at openjdk.org (vlaaad) Date: Thu, 2 Nov 2023 15:54:19 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: <-1eXw5J0wSm0WaJkZjPXjDpnR0TOePok3wAfy-Rv5Sg=.83b6c0f7-4387-406e-9774-4712028c39f6@github.com> On Thu, 2 Nov 2023 11:43:06 GMT, Ambarish Rapte wrote: >> vlaaad has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use NSFunctionKeyMask as modifier at all > > When a function key is pressed [NSFunctionKeyMask](https://developer.apple.com/documentation/appkit/nsfunctionkeymask) is automatically included by the system. > Hence it looks not breaking behavior with this change. > As the warning is quite clear it looks logical to not include the modifier. > Tested on macOS 12.6.8, warning appears without this change and disappears with this change. > > Can you please check _MenuItemTest.java_ test file and try to add a unit test, at least a mac specific test, which should press a Function key and check that modifiers in the received event contains Function modifier flag. @arapte I'm not sure it's possible to detect a single `Fn` key press at all on a Mac. By default, `Fn` press changes the input source, but even if I go to Preferences -> Keyboard and change "Press globe key to" to "Do nothing", pressing `Fn` is still not registered in the JavaFX app. As I understand, it's only used to affect the behavior of other keys so e.g. `Fn F1` can change brightness instead of emitting an `F1` event. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1790999969 From duke at openjdk.org Thu Nov 2 16:03:27 2023 From: duke at openjdk.org (vlaaad) Date: Thu, 2 Nov 2023 16:03:27 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all At least in JavaFX it seems `Fn` modifier is ignored, e.g. pressing `Fn S` reports a key event indistinguishable from `S`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1791017658 From duke at openjdk.org Thu Nov 2 16:03:25 2023 From: duke at openjdk.org (Martin Fox) Date: Thu, 2 Nov 2023 16:03:25 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all The MODIFIER_FUNCTION constant is poorly named and in the wrong place since it has nothing to do with key events. There is no Function modifier in Java. The Mac glass code sets this flag on certain key events but Java just ignores it. The only use for this flag is setting up the system menu bar. We don't have an existing test to verify that the system menu bar processes key events correctly (that would require a Robot and I don't see any Robot tests for this). I will enter a follow-up bug to fix that testing gap. For now I think it's enough that the warning is gone. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1791016957 From jdv at openjdk.org Thu Nov 2 16:32:36 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 16:32:36 GMT Subject: [jfx21u] RFR: 8319079: Missing range checks in decora Message-ID: This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8319079 It adds appropriate range checks in native code for Box/Gaussian Blur/Shadow effects in Software pipeline. ------------- Commit messages: - Backport 96e5d10a40dc25b999ff229f1d6601d1058761b2 Changes: https://git.openjdk.org/jfx21u/pull/25/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=25&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319079 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/25.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/25/head:pull/25 PR: https://git.openjdk.org/jfx21u/pull/25 From jdv at openjdk.org Thu Nov 2 16:41:30 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 16:41:30 GMT Subject: [jfx-tests] RFR: 8315896: Perspective lod tests fail because of minute difference in values [v3] In-Reply-To: References: Message-ID: <03oUYpDQkdIJ337S69vztEmDF978FTg_5GueL4yZqto=.2df39bef-a704-48dc-8a89-817fa50d0a8e@github.com> On Thu, 2 Nov 2023 13:47:26 GMT, Kevin Rushforth wrote: > Looks good. Please file a follow-up bug to get the tests running on Windows. I have created follow-up issue https://bugs.openjdk.org/browse/JDK-8319329 for Windows. ------------- PR Comment: https://git.openjdk.org/jfx-tests/pull/6#issuecomment-1791088077 From thiago.sayao at gmail.com Thu Nov 2 18:18:13 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 2 Nov 2023 15:18:13 -0300 Subject: Making the Stages MODAL by using native modality functionality In-Reply-To: References: Message-ID: Hi, Hold on this question, it might not be necessary. Looking into it. Em qui., 2 de nov. de 2023 ?s 10:21, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > On Linux, the current behavior of SetEnabled(true / false) does not work > very well. > Ideally it should use native MODALITY. > > On GTK MODAL means APPLICATION_MODAL. > > MODAL as in JavaFX would be archived by using Window groups: > https://docs.gtk.org/gtk3/ctor.WindowGroup.new.html > > I would make this work, but I am unsure about Windows or MAC capabilities. > Would this be possible? > > One approach is to move Modality to each platform Window implementation > and keep the way it is for MAC and Windows and use the platform > > Thoughts? > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Thu Nov 2 19:15:04 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Nov 2023 19:15:04 GMT Subject: RFR: 8301302: Platform preferences API [v21] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/ad74e397..38177a8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=19-20 Stats: 22 lines in 1 file changed: 17 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Thu Nov 2 19:15:10 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Nov 2023 19:15:10 GMT Subject: RFR: 8301302: Platform preferences API [v18] In-Reply-To: <05Hnd1uKMsYMGQVIEk9TnHg30rMG7RythehtwwsJFfU=.072fee52-33bb-46e4-b2ed-d8f920473907@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <05Hnd1uKMsYMGQVIEk9TnHg30rMG7RythehtwwsJFfU=.072fee52-33bb-46e4-b2ed-d8f920473907@github.com> Message-ID: On Wed, 1 Nov 2023 13:59:07 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: >> >> - formatting >> - Javadoc change > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java line 1098: > >> 1096: } else { >> 1097: setAccessibilityTheme(null); >> 1098: } > > Can this not be written more simply as > > String val = Boolean.TRUE.equals(preferences.get("Windows.SPI.HighContrastOn")) > && preferences.get("Windows.SPI.HighContrastColorScheme") instanceof String s ? s : null; > setAccessibilityTheme(val); > > ? This doesn't look simpler to me. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 61: > >> 59: final Map effectivePreferences = new HashMap<>(); >> 60: final Map unmodifiableEffectivePreferences = Collections.unmodifiableMap(effectivePreferences); >> 61: final PreferenceProperties properties = new PreferenceProperties(this); > > Why are these not `private`? I don't see them being used outside of this class. > > Also, if possible, add some documentation on these fields so maintainers can understand better what each is for, Done. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 67: > >> 65: >> 66: public PlatformPreferences(Map wellKnownKeys) { >> 67: this.wellKnownKeys = wellKnownKeys; > > Is the argument map guaranteed to not change outside of this class, or is there a need for a defensive copy? It doesn't change in any of the three platform toolkits, but I'm making a defensive copy anyway. > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 192: > >> 190: /** >> 191: * Updates this map of preferences with a new set of platform preferences. >> 192: * The specified preferences may include all available preferences, or only the changed preferences. > > I would mention here that removed preferences are specified by being mapped to `null`, but that the resulting preferences (after update) cannot map to `null`. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380659661 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380661250 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380661904 PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380662009 From nlisker at openjdk.org Thu Nov 2 19:15:12 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 2 Nov 2023 19:15:12 GMT Subject: RFR: 8301302: Platform preferences API [v20] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Wed, 1 Nov 2023 17:36:21 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changend bool comparison modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 198: > 196: * @throws NullPointerException if {@code preferences} is {@code null} > 197: */ > 198: public void update(Map preferences) { I want to make sure I understand the exact details of the update rules. Is this correct? For each key in `preferences`: * if it exists in `effectivePreferences`: * if the values are the same, there is no change (`preferences` contains all mapping and not just the changes) * if the value in `preferences` is `null`, then this is a removal operation (because the value of `effectivePreferences` can't be `null`) * if the value in `preferences` is not `null` and not the same, then this is an update operation * if it doesn't exist in `effectivePreferences`: * if the value in `preferences` is not `null`, then this is an add operation * can the value in `preferences` be `null`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380658831 From mstrauss at openjdk.org Thu Nov 2 19:15:13 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Nov 2023 19:15:13 GMT Subject: RFR: 8301302: Platform preferences API [v20] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Nov 2023 19:05:27 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changend bool comparison > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 198: > >> 196: * @throws NullPointerException if {@code preferences} is {@code null} >> 197: */ >> 198: public void update(Map preferences) { > > I want to make sure I understand the exact details of the update rules. Is this correct? > > For each key in `preferences`: > * if it exists in `effectivePreferences`: > * if the values are the same, there is no change (`preferences` contains all mapping and not just the changes) > * if the value in `preferences` is `null`, then this is a removal operation (because the value of `effectivePreferences` can't be `null`) > * if the value in `preferences` is not `null` and not the same, then this is an update operation > * if it doesn't exist in `effectivePreferences`: > * if the value in `preferences` is not `null`, then this is an add operation > * can the value in `preferences` be `null`? That's correct. > can the value in preferences be `null`? It could be `null` (signalling a removal), but then that's a no-op if the key wasn't present in `effectivePreferences`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380664150 From tsayao at openjdk.org Thu Nov 2 19:20:24 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 2 Nov 2023 19:20:24 GMT Subject: RFR: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) Message-ID: JavaFX on Linux is allowing disabled windows to be minimized. Currently close does nothing as it should, maximize disappears (on MS Windows it's greyed out - it's a platform behavior difference) and minimize is being allowed. Thins PR removes WM functions when window is disabled and restores it back when it's re-enabled. ------------- Commit messages: - 8319340 - [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) Changes: https://git.openjdk.org/jfx/pull/1278/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1278&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319340 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1278.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1278/head:pull/1278 PR: https://git.openjdk.org/jfx/pull/1278 From tsayao at openjdk.org Thu Nov 2 20:05:24 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 2 Nov 2023 20:05:24 GMT Subject: RFR: 8319341: [Linux] Remove operation to show or hide children because it is unnecessary Message-ID: Observed that the window manager takes care of showing and hiding children because we set `gtk_window_set_transient_for`. Works since Ubuntu 16.04. This PR removes the code to show or hide children because it "duplicates" the operation and might lead to unknown bugs. ------------- Commit messages: - Remove show or hide children Changes: https://git.openjdk.org/jfx/pull/1279/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1279&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319341 Stats: 31 lines in 4 files changed: 0 ins; 31 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1279.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1279/head:pull/1279 PR: https://git.openjdk.org/jfx/pull/1279 From jdv at openjdk.org Thu Nov 2 21:31:17 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 2 Nov 2023 21:31:17 GMT Subject: [jfx-tests] Integrated: 8315896: Perspective lod tests fail because of minute difference in values In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 07:07:40 GMT, Jayathirth D V wrote: > Two perspective lod tests fail because of minute differences in expected values. > > Failing tests: > test/scenegraph/fx3d/lod/PerspectiveLodCameraTest.java: > test/scenegraph/fx3d/lod/PerspectiveLodGroupTest.java: > > Exception: > test test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(): failure > org.jemmy.TimeoutExpiredException: State 'Expected 50180.140882730484, but was 50180.137157440186' has not been reached in 1000 milliseconds > at org.jemmy.timing.Waiter.ensureValue(Waiter.java:93) > at test.scenegraph.fx3d.lod.LodTestBase.checkLod(LodTestBase.java:117) > at test.scenegraph.fx3d.lod.LodTests.sphereInitialLightOnTest(LodTests.java:98) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.lang.Thread.run(Thread.java:833) > > These little difference in values are seen both initial drawing and updates. > These tests are not run from long time and change in product might change lod values. > > With updated lod values i have verified that both the tests pass in OpenGL and Metal pipeline with both retina display(scale = 2) and external monitor(scale = 1). This pull request has now been integrated. Changeset: e5f951c7 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx-tests/commit/e5f951c77a315c224710e47cba0ef8084e3a7d8d Stats: 10 lines in 3 files changed: 1 ins; 0 del; 9 mod 8315896: Perspective lod tests fail because of minute difference in values Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx-tests/pull/6 From kcr at openjdk.org Thu Nov 2 22:07:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Nov 2023 22:07:15 GMT Subject: RFR: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 19:13:58 GMT, Thiago Milczarek Sayao wrote: > JavaFX on Linux is allowing disabled windows to be minimized. > > Currently close does nothing as it should, maximize disappears (on MS Windows it's greyed out - it's a platform behavior difference) and minimize is being allowed. > > Thins PR removes WM functions when window is disabled and restores it back when it's re-enabled. We need to verify that there is no possibility of regression. Have you run manual tests including the `HelloModality` and `HelloAlert` test programs in `apps/toys/Hello`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1278#issuecomment-1791603224 From nlisker at openjdk.org Thu Nov 2 22:37:45 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 2 Nov 2023 22:37:45 GMT Subject: RFR: 8301302: Platform preferences API [v20] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Nov 2023 19:11:39 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 198: >> >>> 196: * @throws NullPointerException if {@code preferences} is {@code null} >>> 197: */ >>> 198: public void update(Map preferences) { >> >> I want to make sure I understand the exact details of the update rules. Is this correct? >> >> For each key in `preferences`: >> * if it exists in `effectivePreferences`: >> * if the values are the same, there is no change (`preferences` contains all mapping and not just the changes) >> * if the value in `preferences` is `null`, then this is a removal operation (because the value of `effectivePreferences` can't be `null`) >> * if the value in `preferences` is not `null` and not the same, then this is an update operation >> * if it doesn't exist in `effectivePreferences`: >> * if the value in `preferences` is not `null`, then this is an add operation >> * can the value in `preferences` be `null`? > > That's correct. > >> can the value in preferences be `null`? > > It could be `null` (signalling a removal), but then that's a no-op if the key wasn't present in `effectivePreferences`. So now I'm wondering why the need for the new type `ChangedValue` when you're already accumulating changes with `SimpleChange`. The update method can be something like public void update(Map preferences) { var changes = new ArrayList>(); preferences.forEach((key, newValue) -> { var oldValue = effectivePreferences.get(key); // oldValue can't be null, so no NPE if (Objects.deepEquals(oldValue, newValue)) { return; } var change = new SimpleChange<>(this); if (oldValue != null && newValue == null) { change.setRemoved(key, oldValue); effectivePreferences.remove(key); } else if (oldValue != null && newValue != null) { change.setPut(key, oldValue, newValue); effectivePreferences.put(key, newValue); } else { change.setAdded(key, newValue); effectivePreferences.put(key, newValue); } changes.add(change); }); if (!changes.isEmpty()) { properties.update(changes, platformKeyMappings); fireValueChangedEvent(changes); } } with `fireValueChangedEvent` being private void fireValueChangedEvent(List> changes) { invalidationListeners.forEach(listener -> listener.invalidated(this)); changes.forEach(change -> mapChangeListeners.forEach(listener -> listener.onChanged(change))); } Saves the multiple iterations and the need for a new type. Then `PreferenceProperties::update` can be adjusted: public void update(List> changes, Map platformKeyMappings) { for (SimpleChange change : changes) { ... I didn't test this, it's just an insight. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380852204 From mstrauss at openjdk.org Thu Nov 2 23:01:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Nov 2023 23:01:44 GMT Subject: RFR: 8301302: Platform preferences API [v20] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: On Thu, 2 Nov 2023 22:34:10 GMT, Nir Lisker wrote: >> That's correct. >> >>> can the value in preferences be `null`? >> >> It could be `null` (signalling a removal), but then that's a no-op if the key wasn't present in `effectivePreferences`. > > So now I'm wondering why the need for the new type `ChangedValue` when you're already accumulating changes with `SimpleChange`. > > The update method can be something like > > > public void update(Map preferences) { > var changes = new ArrayList>(); > preferences.forEach((key, newValue) -> { > var oldValue = effectivePreferences.get(key); > // oldValue can't be null, so no NPE > if (Objects.deepEquals(oldValue, newValue)) { > return; > } > > var change = new SimpleChange<>(this); > if (oldValue != null && newValue == null) { > change.setRemoved(key, oldValue); > effectivePreferences.remove(key); > } else if (oldValue != null && newValue != null) { > change.setPut(key, oldValue, newValue); > effectivePreferences.put(key, newValue); > } else { > change.setAdded(key, newValue); > effectivePreferences.put(key, newValue); > } > changes.add(change); > }); > > if (!changes.isEmpty()) { > properties.update(changes, platformKeyMappings); > fireValueChangedEvent(changes); > } > } > > > with `fireValueChangedEvent` being > > private void fireValueChangedEvent(List> changes) { > invalidationListeners.forEach(listener -> listener.invalidated(this)); > changes.forEach(change -> mapChangeListeners.forEach(listener -> listener.onChanged(change))); > } > > Saves the multiple iterations and the need for a new type. > > Then `PreferenceProperties::update` can be adjusted: > > public void update(List> changes, Map platformKeyMappings) { > for (SimpleChange change : changes) { > ... > > > I didn't test this, it's just an insight. The main reason for the new record `ChangedValue` is to modularize the code for easier reuse. At the moment, only `PlatformPreferences` uses it, but a follow-up enhancement will introduce a second class `ApplicationPreferences`, which will also use it to compute the effective changes. At that point, we'd either have to duplicate some code, or factor it out anyway. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1380868731 From thiago.sayao at gmail.com Fri Nov 3 00:12:26 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 2 Nov 2023 21:12:26 -0300 Subject: Wayland In-Reply-To: References: Message-ID: Hi, About Wayland: Porting es2 to use EGL instead of GLX is pretty straightforward, so converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why EGL is needed). The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint directly to the window as es2 do. I've tried to use Gtk4 and composite it with a GL texture - it would work, but does't fit well with es2 as it is designed to swapBuffers. I'm looking for the shortest path to get it working. I'm thinking now to use wayland-client directly for most things, so it will be possible to create the WaylandGL* infrastructure and render directly to a surface. Compositing directly with wayland would be better anyways. Using Gtk (3 or 4) would require rendering somewhere else (other than onscreen wayland surface) and then composite the result with Gtk. So, the conclusion for now is that Gtk won't work with wayland for the use of another toolkit (outside of the gtk rendering scope). wayland-client, here I go. -- Thiago. Em s?b., 21 de out. de 2023 ?s 18:12, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > EGL is the way to go for Linux on Wayland and X11. > > I don't know how to do it yet, but it seems the solution is to use DMABUF > with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not > sure yet). > > Firefox and WebKit GTK uses the same technic. > > Gtk4 does not allow application painting, so direct surface context is not > possible. > > We are using gtk3 and it is still possible, but I want to use GtkHeaderbar > and clean up glass code. Since it means sharing the window/surface with > GTK, direct surface rendering also doesn't work. > > > https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/ > > > https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/ > > https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/ > > It's been nice to learn. > > Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> Hi, >> >> I am investigating about prism on Wayland. >> >> It looks like we could just replace the GLX calls on X11 backend to EGL >> and it will work on both (maybe rename it). >> >> It will need some work to pass the native display around - it assumes X11 >> Display everywhere and it could be a Display or a wl_display. >> >> -- Thiago. >> >> Em dom., 15 de out. de 2023 ?s 16:06, Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> escreveu: >> >>> Hi, >>> >>> Update: It now works on wayland with -Dprism.order=sw >>> >>> >>> >>> Em dom., 15 de out. de 2023 ?s 10:49, Thiago Milczarek Say?o < >>> thiago.sayao at gmail.com> escreveu: >>> >>>> Hi, >>>> >>>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland >>>> >>>> I did some experiments here. So far, so good. >>>> >>>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer >>>> gtk. >>>> 2) Replaced drawing directly in the window and added a GtkDrawingArea >>>> with a GtkHeaderBar which allows control over the whole window >>>> size and allows to get rid of extents* calls - this cleans up a lot. >>>> 3) Unified the WindowContext to clean it up. >>>> >>>> I also integrated the IME replacement proposed here: >>>> https://github.com/openjdk/jfx/pull/1080 >>>> >>>> It almost runs with software rendering on Wayland, but something still >>>> touches X11. >>>> >>>> To finally make it work on Wayland it requires to implement it on prism >>>> es2. I see that there's a EGL part of Monocle. I still don't completely >>>> understand it, but wouldn't it work as a drop-in replacement? >>>> >>>> -- Thiago. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdv at openjdk.org Fri Nov 3 03:50:22 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 3 Nov 2023 03:50:22 GMT Subject: [jfx21u] Integrated: 8319079: Missing range checks in decora In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 16:26:57 GMT, Jayathirth D V wrote: > This is jfx21u backport of https://bugs.openjdk.org/browse/JDK-8319079 > It adds appropriate range checks in native code for Box/Gaussian Blur/Shadow effects in Software pipeline. This pull request has now been integrated. Changeset: 5f21d465 Author: Jayathirth D V Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx21u/commit/5f21d465507ab67eb056f9f34b2cd9523c43bc57 Stats: 85 lines in 6 files changed: 85 ins; 0 del; 0 mod 8319079: Missing range checks in decora Backport-of: 96e5d10a40dc25b999ff229f1d6601d1058761b2 ------------- PR: https://git.openjdk.org/jfx21u/pull/25 From tsayao at openjdk.org Fri Nov 3 10:34:42 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 3 Nov 2023 10:34:42 GMT Subject: RFR: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close) [v2] In-Reply-To: References: Message-ID: > JavaFX on Linux is allowing disabled windows to be minimized. > > Currently close does nothing as it should, maximize disappears (on MS Windows it's greyed out - it's a platform behavior difference) and minimize is being allowed. > > Thins PR removes WM functions when window is disabled and restores it back when it's re-enabled. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Leave the Close button so it does not look too weird. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1278/files - new: https://git.openjdk.org/jfx/pull/1278/files/0d70be5c..1d58a508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1278&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1278&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1278.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1278/head:pull/1278 PR: https://git.openjdk.org/jfx/pull/1278 From angorya at openjdk.org Fri Nov 3 18:44:48 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 3 Nov 2023 18:44:48 GMT Subject: RFR: 8301302: Platform preferences API [v21] In-Reply-To: References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: <-hPx327iTxbQLHVzmwuGAI0LNcexy3tMfYkU3Nk3DSs=.bc3d7dc1-0edd-49ee-998b-60015cd6e763@github.com> On Thu, 2 Nov 2023 19:15:04 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review changes modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 238: > 236: } > 237: } > 238: extra space ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1382100383 From mstrauss at openjdk.org Fri Nov 3 19:42:20 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Nov 2023 19:42:20 GMT Subject: RFR: 8301302: Platform preferences API [v22] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: removed extra newline ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/38177a8d..d012dec9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=21 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=20-21 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From mstrauss at openjdk.org Fri Nov 3 19:42:22 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Nov 2023 19:42:22 GMT Subject: RFR: 8301302: Platform preferences API [v21] In-Reply-To: <-hPx327iTxbQLHVzmwuGAI0LNcexy3tMfYkU3Nk3DSs=.bc3d7dc1-0edd-49ee-998b-60015cd6e763@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <-hPx327iTxbQLHVzmwuGAI0LNcexy3tMfYkU3Nk3DSs=.bc3d7dc1-0edd-49ee-998b-60015cd6e763@github.com> Message-ID: On Fri, 3 Nov 2023 18:38:04 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> review changes > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PreferenceProperties.java line 238: > >> 236: } >> 237: } >> 238: > > extra space Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1014#discussion_r1382131004 From kcr at openjdk.org Sat Nov 4 13:51:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 Nov 2023 13:51:21 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 06:04:23 GMT, Prasanta Sadhukhan wrote: > A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added I verified that this test passes with the fix for JDK-8317836 and fails with that fix locally reverted. The only minor thing I noticed is that the instruction window is obscured by the test window, so you have to move the test window out of the way to see it. Maybe set the X and Y of the instruction window and/or make the test window smaller so they don't overlap? If you would like to fix this, I also left two very minor code format comments that you might consider. I'll approve anyway, and reapprove if you make the changes. tests/manual/swing/JFXPanelOrientationTest.java line 25: > 23: * questions. > 24: */ > 25: import java.awt.BorderLayout; Minor: we prefer a blank line between the copyright block and the package or import statements. tests/manual/swing/JFXPanelOrientationTest.java line 46: > 44: import javafx.scene.layout.VBox; > 45: > 46: Minor: you can remove the extra blank line. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1276#pullrequestreview-1713775541 PR Review Comment: https://git.openjdk.org/jfx/pull/1276#discussion_r1382396717 PR Review Comment: https://git.openjdk.org/jfx/pull/1276#discussion_r1382396762 From kcr at openjdk.org Sat Nov 4 14:32:20 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 Nov 2023 14:32:20 GMT Subject: RFR: 8316423: [linux] Secondary Stage does not respect Scene's dimensions when shown [v8] In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 23:07:04 GMT, Thiago Milczarek Sayao wrote: >> The bug on the title happens because `gtk_widget_realize()` was called on the constructor. It creates the internal underlying window `GdkWindow` and `XWindow` messing the Gtk expected order. It's probably a Mutter change rather than Gtk. But makes sense to not realize it before expected on the gtk/mutter flow. >> >> I moved the code to get the `GdkWindow` to the realize event. >> >> Had to change the background function because it's called before realize. >> >> The initial **Maximized** and **FullScreen** situations are probably a bug on Mutter [filed here](https://gitlab.gnome.org/GNOME/mutter/-/issues/3092). >> >> I could work-around it on this situation, but it would still happen on later focus request. > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Fix unwanted changes > - Fix unwanted changes > - Merge branch 'master' into window_size > - Fix unwanted changes > - Fix background > - Revert "Test" > > This reverts commit ac7b4da75b9690c42aecd484bb3990866a004074. > - Test > - Experiment on not realizing the window > - Experiment on not realizing the window > - Re-enable tests > - ... and 3 more: https://git.openjdk.org/jfx/compare/45ab6aef...315e1b73 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1249#pullrequestreview-1713788992 From kcr at openjdk.org Sat Nov 4 15:50:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 4 Nov 2023 15:50:21 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: Message-ID: <-ikSLLjvPFRNPGNUdneJWLOfO9C2F7vuU_ylcriJkhI=.84886423-1a9e-4cd8-a3f9-04a0800b6a53@github.com> On Thu, 2 Nov 2023 11:39:47 GMT, Johan Vos wrote: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. The fix looks good aside from a missing null check on the Java side. I also left a question as to about two possible other place that might need to zero out a pointer. This will need to be tested in a variety of scenarios, including menus with separators, nested menus, and turning the system menu on and off. What I tested so far looks good. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacMenuDelegate.java line 93: > 91: MacMenuDelegate macMenu = (MacMenuDelegate)item; > 92: _remove(ptr, macMenu == null ? 0L : macMenu.ptr, pos); > 93: macMenu.ptr = 0L; You need to check for `macMenu == null` here (it can be null in the case of a menu separator, which is why the call to `_remove` on the previous line checks for null). Question: Does the zeroing out of the pointer also need to be done in the other `remove` method (the one immediately above this one)? I think that method is for the nested menu case, but I'm not sure. Similarly, do you need to zero out the pointer in the `MacMenuBarDelegate::remove` method (called when a menu is removed from the system menu bar)? ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1713784373 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1382402575 From tsayao at openjdk.org Sat Nov 4 16:36:20 2023 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sat, 4 Nov 2023 16:36:20 GMT Subject: Integrated: 8316423: [linux] Secondary Stage does not respect Scene's dimensions when shown In-Reply-To: References: Message-ID: On Thu, 28 Sep 2023 00:31:59 GMT, Thiago Milczarek Sayao wrote: > The bug on the title happens because `gtk_widget_realize()` was called on the constructor. It creates the internal underlying window `GdkWindow` and `XWindow` messing the Gtk expected order. It's probably a Mutter change rather than Gtk. But makes sense to not realize it before expected on the gtk/mutter flow. > > I moved the code to get the `GdkWindow` to the realize event. > > Had to change the background function because it's called before realize. > > The initial **Maximized** and **FullScreen** situations are probably a bug on Mutter [filed here](https://gitlab.gnome.org/GNOME/mutter/-/issues/3092). > > I could work-around it on this situation, but it would still happen on later focus request. This pull request has now been integrated. Changeset: 21f12c18 Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/21f12c18369358bf2228aa5c8151c550ff082c66 Stats: 67 lines in 3 files changed: 36 ins; 25 del; 6 mod 8316423: [linux] Secondary Stage does not respect Scene's dimensions when shown Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1249 From john.hendrikx at gmail.com Mon Nov 6 02:04:38 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 6 Nov 2023 03:04:38 +0100 Subject: Public Behavior API proposal Message-ID: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> As promised,? a public Behavior API proposal. Summary: Introduce a new|Behavior|interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Mon Nov 6 02:07:32 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 6 Nov 2023 03:07:32 +0100 Subject: Key binding customization proposal Message-ID: This is an extension that builds on top of the Behavior API proposal (see Public Behavior API proposal thread). Summary: Provide an opportunity to customize key bindings during construction time of standard behaviors, without exposing the internal|InputMap|s. The API is constructed in such a way to not block later enhancements to allow|InputMap|s to be shared or made immutable. Goals: * Provide API to customize key bindings provided by default behaviors * Provide a public class|KeyBinding|which is lighter weight, and immutable * Integrate with Behavior proposal * Keep internal details of|InputMap|implementation hidden (it is too complex, and consumes far too much resources) See the full proposal here: https://gist.github.com/hjohn/e432f17452ff13511820487e3602b847 --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Mon Nov 6 06:06:35 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Nov 2023 06:06:35 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: References: Message-ID: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> > A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Formatting - Modify window size ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1276/files - new: https://git.openjdk.org/jfx/pull/1276/files/e2c4dfd7..aa852af2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1276&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1276&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1276.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1276/head:pull/1276 PR: https://git.openjdk.org/jfx/pull/1276 From psadhukhan at openjdk.org Mon Nov 6 06:10:22 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Nov 2023 06:10:22 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: References: Message-ID: On Sat, 4 Nov 2023 13:48:48 GMT, Kevin Rushforth wrote: > make the test window smaller so they don't overlap Done > Maybe set the X and Y of the instruction window Although it is probably not required now, but can you please specify how to do it for my future reference as I dont see Scene accepting x,y params. Is there any in-house or public fx documentation that I can peruse (guess we dont have similar to https://docs.oracle.com/en/java/javase/21/docs/api/index.html) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1794144660 From duke at openjdk.org Mon Nov 6 08:34:27 2023 From: duke at openjdk.org (vlaaad) Date: Mon, 6 Nov 2023 08:34:27 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> On Thu, 2 Nov 2023 11:43:06 GMT, Ambarish Rapte wrote: >> vlaaad has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use NSFunctionKeyMask as modifier at all > > When a function key is pressed [NSFunctionKeyMask](https://developer.apple.com/documentation/appkit/nsfunctionkeymask) is automatically included by the system. > Hence it looks not breaking behavior with this change. > As the warning is quite clear it looks logical to not include the modifier. > Tested on macOS 12.6.8, warning appears without this change and disappears with this change. > > Can you please check _MenuItemTest.java_ test file and try to add a unit test, at least a mac specific test, which should press a Function key and check that modifiers in the received event contains Function modifier flag. @arapte anything else I could do? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1794308065 From jvos at openjdk.org Mon Nov 6 12:37:25 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 12:37:25 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: Message-ID: <13kibGnJHMCOrC3iC_qra9F2PpZkoBRrrpBu9s5e21Y=.63cd395e-401d-45fd-91e2-5b1a3c4d3035@github.com> On Thu, 2 Nov 2023 12:17:57 GMT, Kevin Rushforth wrote: > Is it possible to add an automated regression test? I'm working on that, but it is not trivial as this functionality requires the QuantumToolkit and can not use the StubToolkit which is used in most tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1794722406 From kcr at openjdk.org Mon Nov 6 13:23:25 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Nov 2023 13:23:25 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: <13kibGnJHMCOrC3iC_qra9F2PpZkoBRrrpBu9s5e21Y=.63cd395e-401d-45fd-91e2-5b1a3c4d3035@github.com> References: <13kibGnJHMCOrC3iC_qra9F2PpZkoBRrrpBu9s5e21Y=.63cd395e-401d-45fd-91e2-5b1a3c4d3035@github.com> Message-ID: On Mon, 6 Nov 2023 12:34:41 GMT, Johan Vos wrote: > > Is it possible to add an automated regression test? > > I'm working on that, but it is not trivial as this functionality requires the QuantumToolkit and can not use the StubToolkit which is used in most tests. You could add a headful system test (those all use the QuantumToolkit). You may or may not want it to be a robot-based test, depending on what else you want the test to do (e.g., a robot-based test could click outside the window, which deactivates the window and calls the release methods). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1794812722 From angorya at openjdk.org Mon Nov 6 15:39:27 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Nov 2023 15:39:27 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 06:06:55 GMT, Prasanta Sadhukhan wrote: > can you please specify how to do it for my future reference as I dont see Scene accepting x,y params Use Stage (Window) setX(), setY() before show(). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1795150124 From kcr at openjdk.org Mon Nov 6 16:04:25 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Nov 2023 16:04:25 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 06:06:55 GMT, Prasanta Sadhukhan wrote: > Is there any in-house or public fx documentation that I can peruse (guess we dont have similar to https://docs.oracle.com/en/java/javase/21/docs/api/index.html) Andy already answered your specific question. As for where the docs are, you can find them either by going to [jdk.java.net/javafx21](https://jdk.java.net/javafx21/) and click on the API docs link, which points here: https://download.java.net/java/GA/javafx21.0.1/e5ab43c6aed54893b0840c1f2dcfca4d/docs/api/overview-summary.html Or go to [openjfx.io](https://openjfx.io/) and clicking on the API docs link, which points here: https://openjfx.io/javadoc/21/ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1795215271 From kcr at openjdk.org Mon Nov 6 16:07:28 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Nov 2023 16:07:28 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> References: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> Message-ID: On Mon, 6 Nov 2023 06:06:35 GMT, Prasanta Sadhukhan wrote: >> A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Formatting > - Modify window size Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1276#pullrequestreview-1715588588 From arapte at openjdk.org Mon Nov 6 18:01:49 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 6 Nov 2023 18:01:49 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> References: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> Message-ID: On Mon, 6 Nov 2023 08:31:54 GMT, vlaaad wrote: >> When a function key is pressed [NSFunctionKeyMask](https://developer.apple.com/documentation/appkit/nsfunctionkeymask) is automatically included by the system. >> Hence it looks not breaking behavior with this change. >> As the warning is quite clear it looks logical to not include the modifier. >> Tested on macOS 12.6.8, warning appears without this change and disappears with this change. >> >> Can you please check _MenuItemTest.java_ test file and try to add a unit test, at least a mac specific test, which should press a Function key and check that modifiers in the received event contains Function modifier flag. > > @arapte anything else I could do? @vlaaad Yes please, I think we should have a test along with this fix. A test is missing for this scenario. If a unit test is not feasible, can you please check to add a system test ? ( may be something like setting F1 as accelerator key on a MenuItem results in MenuItem's action getting fired when Function+F1 is pressed ) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1795727652 From jvos at openjdk.org Mon Nov 6 18:08:17 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 18:08:17 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v2] In-Reply-To: <-ikSLLjvPFRNPGNUdneJWLOfO9C2F7vuU_ylcriJkhI=.84886423-1a9e-4cd8-a3f9-04a0800b6a53@github.com> References: <-ikSLLjvPFRNPGNUdneJWLOfO9C2F7vuU_ylcriJkhI=.84886423-1a9e-4cd8-a3f9-04a0800b6a53@github.com> Message-ID: On Sat, 4 Nov 2023 14:11:46 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Check for null in the Java layer and avoid invoking native methods with a zero pointer. >> Zero the relevant pointer in the MenuBarDelegate when a menu is removed. >> - Merge remote-tracking branch 'upstream/master' into 8318841-macmenu >> - When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacMenuDelegate.java line 93: > >> 91: MacMenuDelegate macMenu = (MacMenuDelegate)item; >> 92: _remove(ptr, macMenu == null ? 0L : macMenu.ptr, pos); >> 93: macMenu.ptr = 0L; > > You need to check for `macMenu == null` here (it can be null in the case of a menu separator, which is why the call to `_remove` on the previous line checks for null). > > Question: Does the zeroing out of the pointer also need to be done in the other `remove` method (the one immediately above this one)? I think that method is for the nested menu case, but I'm not sure. Similarly, do you need to zero out the pointer in the `MacMenuBarDelegate::remove` method (called when a menu is removed from the system menu bar)? I added the null check on `macMenu`. I also added the zeroing in the other `remove` method (which indeed is for adding a menu to a menu) and to the `remove` method in `MacMenuBarDelegate`. Apart from that, I noticed that there were a number of possible scenario's where the Delegate objects would still be used. For example, after removing a menuItem from a menu, one could still invoke methods on that menuItem object. The invocations would propagate to the native layer, causing a crash because the pointer to the `GlassMenu` was already zero (and the native GlassMenu instance was released). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1383753209 From jvos at openjdk.org Mon Nov 6 18:08:14 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 18:08:14 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v2] In-Reply-To: References: Message-ID: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Check for null in the Java layer and avoid invoking native methods with a zero pointer. Zero the relevant pointer in the MenuBarDelegate when a menu is removed. - Merge remote-tracking branch 'upstream/master' into 8318841-macmenu - When the Java layer removes a systemmenu, release the native resources related to this systemmenu. This removes the strong JNI Global ref, which prevents its references from being gc'ed. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/f7664b02..5cf8c948 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=00-01 Stats: 651 lines in 32 files changed: 569 ins; 40 del; 42 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From jvos at openjdk.org Mon Nov 6 18:30:15 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 18:30:15 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v3] In-Reply-To: References: Message-ID: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Restore permissions on gradlew ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/5cf8c948..afd48a7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From duke at openjdk.org Mon Nov 6 18:35:09 2023 From: duke at openjdk.org (Martin Fox) Date: Mon, 6 Nov 2023 18:35:09 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> Message-ID: On Mon, 6 Nov 2023 17:53:42 GMT, Ambarish Rapte wrote: >> @arapte anything else I could do? > > @vlaaad > Yes please, I think we should have a test along with this fix. A test is missing for this scenario. > If a unit test is not feasible, can you please check to add a system test ? ( may be something like setting F1 as accelerator key on a MenuItem results in MenuItem's action getting fired when Function+F1 is pressed ) @arapte The best we can do when it comes to the Function keys is a manual test since JavaFX can't manipulate the fn key. I think I have a manual test I can clean up to use here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1795863098 From angorya at openjdk.org Mon Nov 6 18:46:29 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Nov 2023 18:46:29 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> References: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> Message-ID: <09x1xVSQ9XF6bxX-i6ip0GvPA6guyW5--BmOd1PwmKk=.9b6ceeb4-c7f6-4573-b185-f0ffa55e26b0@github.com> On Mon, 6 Nov 2023 06:06:35 GMT, Prasanta Sadhukhan wrote: >> A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Formatting > - Modify window size I was waiting for changes to set the window position, but can re-approve if necessary. A side comment: the arrangement of the test instruction window (as well as the creating the said window) should be a convenience method somewhere in common test units, should it not? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1276#pullrequestreview-1715940121 From jvos at openjdk.org Mon Nov 6 19:22:26 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 19:22:26 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add a system test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/afd48a7e..be847398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=02-03 Stats: 62 lines in 1 file changed: 62 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From jvos at openjdk.org Mon Nov 6 19:23:39 2023 From: jvos at openjdk.org (Johan Vos) Date: Mon, 6 Nov 2023 19:23:39 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: <13kibGnJHMCOrC3iC_qra9F2PpZkoBRrrpBu9s5e21Y=.63cd395e-401d-45fd-91e2-5b1a3c4d3035@github.com> Message-ID: On Mon, 6 Nov 2023 13:20:32 GMT, Kevin Rushforth wrote: > > > Is it possible to add an automated regression test? > > > > > > I'm working on that, but it is not trivial as this functionality requires the QuantumToolkit and can not use the StubToolkit which is used in most tests. > > You could add a headful system test (those all use the QuantumToolkit). You may or may not want it to be a robot-based test, depending on what else you want the test to do (e.g., a robot-based test could click outside the window, which deactivates the window and calls the release methods). I added a test to the existing SystemMenuBarTest in the system tests that fails before and succeeds after the patch. Note that the app needs focus for this test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1796114161 From andy.goryachev at oracle.com Mon Nov 6 19:32:35 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 6 Nov 2023 19:32:35 +0000 Subject: Public Behavior API proposal In-Reply-To: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: Dear John: Thank you for providing these proposals! Do I understand correctly that the idea of translating input events into control-specific events and bubbling them up is now gone? In ?Goals? - * Allow changing the skin of a control without having to recreate behavior As we discussed before, some behaviors cannot be decoupled from the skin. This alone should disqualify the proposal from the start. Perhaps choosing a more complex control rather than a Button for a proof of concept would have been a better starting point? Right now I don?t know what to do - do you want me to repeat the same arguments and explanations? Please advise. Thank you -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, November 5, 2023 at 18:05 To: openjfx-dev at openjdk.org Subject: Public Behavior API proposal As promised, a public Behavior API proposal. Summary: Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Nov 6 19:32:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 6 Nov 2023 19:32:38 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: <09x1xVSQ9XF6bxX-i6ip0GvPA6guyW5--BmOd1PwmKk=.9b6ceeb4-c7f6-4573-b185-f0ffa55e26b0@github.com> References: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> <09x1xVSQ9XF6bxX-i6ip0GvPA6guyW5--BmOd1PwmKk=.9b6ceeb4-c7f6-4573-b185-f0ffa55e26b0@github.com> Message-ID: On Mon, 6 Nov 2023 18:43:48 GMT, Andy Goryachev wrote: > I was waiting for changes to set the window position, but can re-approve if necessary. His earlier comments suggested that he felt it wasn't needed for this PR; with the adjusted window sizes, the windows no longer overlap. > A side comment: the arrangement of the test instruction window (as well as the creating the said window) should be a convenience method somewhere in common test units, should it not? Good idea. Can you file an enhancement to consider this for the next test sprint? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1796154889 From angorya at openjdk.org Mon Nov 6 19:41:40 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 6 Nov 2023 19:41:40 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: References: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> <09x1xVSQ9XF6bxX-i6ip0GvPA6guyW5--BmOd1PwmKk=.9b6ceeb4-c7f6-4573-b185-f0ffa55e26b0@github.com> Message-ID: <_g0JngEvR2z7wO8sAZvB9kSZblQdpW17nz3Qo6pC_Hg=.fc8aecaf-cb19-4e5d-8c13-54cb68bf0566@github.com> On Mon, 6 Nov 2023 19:30:28 GMT, Kevin Rushforth wrote: > Can you file an enhancement to consider this for the next test sprint? Created [JDK-8319555](https://bugs.openjdk.org/browse/JDK-8319555) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1796178835 From andy.goryachev at oracle.com Mon Nov 6 19:54:25 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 6 Nov 2023 19:54:25 +0000 Subject: Key binding customization proposal In-Reply-To: References: Message-ID: Dear John: Thank you again for submitting a separate KeyBinding proposal. Ignoring my objection for its sibling, I just wanted to point to these two items in Goals and Non-Goals: * Keep internal details of InputMap implementation hidden (it is too complex, and consumes far too much resources) I object to this on two fronts: 1. by trying to go around the InputMap, something that many developers find easy to understand, you invented a bunch of weird things like InputContext, Actions (not those Actions that we are used to!), and States. Why? What is the problem? How is what you propose is NOT ?too complex? but an InputMap is? 2. You still need to add a listeners on each control instance, right? But the main objection comes from * Runtime modification of key bindings on a per control basis I believe these two requirements are too valuable. I would object to your proposal because it explicitly provides no support for these two features. There are more objections, but I think these are enough to disqualify this proposal. What do you think? And, more importantly, what do other people - including application developers - think? Thank you -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, November 5, 2023 at 18:07 To: openjfx-dev at openjdk.org Subject: Key binding customization proposal This is an extension that builds on top of the Behavior API proposal (see Public Behavior API proposal thread). Summary: Provide an opportunity to customize key bindings during construction time of standard behaviors, without exposing the internal InputMaps. The API is constructed in such a way to not block later enhancements to allow InputMaps to be shared or made immutable. Goals: * Provide API to customize key bindings provided by default behaviors * Provide a public class KeyBinding which is lighter weight, and immutable * Integrate with Behavior proposal * Keep internal details of InputMap implementation hidden (it is too complex, and consumes far too much resources) See the full proposal here: https://gist.github.com/hjohn/e432f17452ff13511820487e3602b847 --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Nov 6 22:17:17 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 6 Nov 2023 22:17:17 +0000 Subject: Public Behavior API proposal In-Reply-To: References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: To clarify, > some behaviors cannot be decoupled from the skin Imagine a specific skin that has a Node that accepts a user input. A scroll bar, a button, or a region with a some function. Unless this element is proclaimed as must-have for any skin and codified via some new public API (MySkin.getSomeElement()), it is specific to that particular skin and that particular behavior. Another example is when we try to extend a core control by extending its default skin and adding some additional state, linked to, again, a new input element in the new skin. This additional state is unknown to the core behavior, so we can?t simply bolt it on the existing behavior - both skin and the behavior must be extended. The opposite example: when a custom skin *removes* some input element, which might break the existing behavior which relies on the existing of the removed element. Does it make sense? For people listening in: please do not hesitate to offer your opinion on the subject. We are trying to come up with a solution for *you*, so your feedback is extremely important. It might look like John and I are fighting, but we really are trying to find the common ground. Cheers, -andy From: Andy Goryachev Date: Monday, November 6, 2023 at 11:32 To: John Hendrikx , openjfx-dev at openjdk.org Subject: Re: Public Behavior API proposal Dear John: Thank you for providing these proposals! Do I understand correctly that the idea of translating input events into control-specific events and bubbling them up is now gone? In ?Goals? - * Allow changing the skin of a control without having to recreate behavior As we discussed before, some behaviors cannot be decoupled from the skin. This alone should disqualify the proposal from the start. Perhaps choosing a more complex control rather than a Button for a proof of concept would have been a better starting point? Right now I don?t know what to do - do you want me to repeat the same arguments and explanations? Please advise. Thank you -andy From: openjfx-dev on behalf of John Hendrikx Date: Sunday, November 5, 2023 at 18:05 To: openjfx-dev at openjdk.org Subject: Public Behavior API proposal As promised, a public Behavior API proposal. Summary: Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Tue Nov 7 03:34:46 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 7 Nov 2023 03:34:46 GMT Subject: RFR: 8319147: Add regression test for JDK-8317836 [v2] In-Reply-To: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> References: <7aKuKE8oJ9pyixw9yRRm3DsxY95Y3mxY7sEQPkAXV1U=.c185bdd3-07b8-4605-a5d0-dde548f71698@github.com> Message-ID: On Mon, 6 Nov 2023 06:06:35 GMT, Prasanta Sadhukhan wrote: >> A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Formatting > - Modify window size Thank you for the FX API docs link ------------- PR Comment: https://git.openjdk.org/jfx/pull/1276#issuecomment-1797651815 From psadhukhan at openjdk.org Tue Nov 7 03:34:47 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 7 Nov 2023 03:34:47 GMT Subject: Integrated: 8319147: Add regression test for JDK-8317836 In-Reply-To: References: Message-ID: <3xmGU8U1Zp8uWGi7IH0XhbMVwzRd_ERyDK96ET8YW6o=.5bcff8a8-d6ee-4317-9996-4cc5020f92aa@github.com> On Thu, 2 Nov 2023 06:04:23 GMT, Prasanta Sadhukhan wrote: > A manual regression test for JFXPanel orientation fix in [JDK-8317836](https://bugs.openjdk.org/browse/JDK-8317836) is added This pull request has now been integrated. Changeset: 29f9c4d3 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jfx/commit/29f9c4d30c1aca3ef605b56a2445951e9cdbc4a2 Stats: 120 lines in 1 file changed: 120 ins; 0 del; 0 mod 8319147: Add regression test for JDK-8317836 Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1276 From michaelstrau2 at gmail.com Tue Nov 7 07:09:44 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 7 Nov 2023 08:09:44 +0100 Subject: Public Behavior API proposal In-Reply-To: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: Hi John, I like that you clearly define the terms Control, Skin and Behavior, as well as their roles within the control architecture. However, I don't see how your proposal scales to non-trivial controls, and I agree with Andy that the Button example doesn't help (because a Button lacks substructure and provides only a single interaction). I'm missing your previous idea of using the event system for higher-level semantic events, because I think they're required to make this work. Here's how I see these parts working together: 1) A control is an opaque node in the scene graph, which defines the API for a particular interactive element. It also defines the interactions afforded by its implementation. For example, a Spinner will usually consist of a text field and two buttons, but a skin might choose to implement these components differently. The interactions afforded by a control are exposed as semantic events: class SpinnerEvent extends Event { static EventType COMMIT_TEXT; static EventType START_INCREMENT; static EventType STOP_INCREMENT; static EventType START_DECREMENT; static EventType STOP_DECREMENT; } 2) Skins are responsible for generating semantic events, and sending those events to the control. Since we don't need those events to have a tunneling/bubbling behavior, we could have a flag on the event that indicates a "direct event", one that is dispatched directly to its target. 3) Behaviors listen for semantic events on the control, and convert these events into state changes of the control. This part would probably be quite similar to some of the things that have already been proposed. In this way, controls, skins, and behaviors would end up as loosely coupled parts. In particular, I don't see the value in making behaviors public API if they are so tightly coupled to skins that they end up as being basically implementation details. Andy: > Imagine a specific skin that has a Node that accepts a user input. A scroll bar, a button, or a region with a some function. Unless this element is proclaimed as must-have for any skin and codified via some new public API (MySkin.getSomeElement()), it is specific to that particular skin and that particular behavior. I think that's a very important observation. A skin can't just be anything it wants to be, it must be suitable for its control. So we need a place where we define the API and the interactions afforded by that control. In my opinion, this place is the Control. Its functionality is exposed via properties and methods, and its interactions are specified using semantic events. Now skins are free to be implemented in any imaginable way, provided that they interact with the control using semantic events. This gives us very straightforward restrictions: * A skin can never add interactions that the control didn't specify. * If additional interactions are required, the control must be subclassed and the interactions must be specified by the control. Additionally, the behavior must be extended to account for the additional interactions. On Mon, Nov 6, 2023 at 4:50?AM John Hendrikx wrote: > > As promised, a public Behavior API proposal. > > Summary: > > Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. > > See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 > > --John From mstrauss at openjdk.org Tue Nov 7 07:28:44 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Nov 2023 07:28:44 GMT Subject: RFR: 8313648: JavaFX application continues to show a black screen after graphic card driver crash In-Reply-To: References: Message-ID: <8A7kWAZfrojdQfHc56njMCa2odkBi-CEHtJPJ3HTxSs=.e4ec9a74-5748-4b54-aba8-d43a9ae3fc50@github.com> On Sat, 5 Aug 2023 12:28:16 GMT, Thorsten Fischer wrote: > Hi, > > I did open the bug report. Some notes to this PR: > > My colleagues and I are able to reproduce this bug regularly, even though it takes sometimes up to 3 or 4 weeks until the D3DERR_DEVICEHUNG error shows up. We are currently evaluating two versions of fixes, but until now we do not have any results. I will post them as soon as I got them. > > Version 1 (this version): Based on the observation, that the TestCooperativeLevel/CheckDeviceState method returns D3D_OK again after about 20 - 60 seconds, the reinitialize is called after the first time the state is returning D3D_OK. The 'isHung' flag stores the information until then. > > Version 2: calls reinitialize directly after D3DERR_DEVICEHUNG has been returned. Basically > if (hr == D3DERR_DEVICEREMOVED || hr == D3DERR_DEVICEHUNG ) { .. } > > I did not modify the validatePresent method, as for our workaround (see ticket) it was not necessary. At least the native call swapchain->present dows not return that error code (https://learn.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3dswapchain9-present). I did not look decisively into all the native calls behind D3DRTTexture#readPixels. > > As I said I will post the results (prism.verbose output) for the 2 versions later as a base for discussions. Microsoft's [documentation](https://learn.microsoft.com/en-us/windows/win32/direct3d9/dx9lh) states the following for Direct3D 9Ex devices: > Devices are now only lost under two circumstances; when the hardware is reset because it is hanging, and when the device driver is stopped. When hardware hangs, the device can be reset by calling [ResetEx](https://learn.microsoft.com/en-us/windows/desktop/api/d3d9/nf-d3d9-idirect3ddevice9ex-resetex). If hardware hangs, texture memory is lost. The current D3D pipeline doesn't call `ResetEx` when the device hangs, it releases and recreates the device instead. However, I think it is okay to do this. [Here's](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr) what the documentation says about `D3DERR_DEVICEHUNG`: > The device that returned this code caused the hardware adapter to be reset by the OS. Most applications should destroy the device and quit. Applications that must continue should destroy all video memory objects (surfaces, textures, state blocks etc) and call Reset() to put the device in a default state. If the application then continues rendering in the same way, the device will return to this state. On a side note, I think we should remove the non-9Ex code paths from the D3D pipeline. We're not supporting Windows XP, are we? ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1199#pullrequestreview-1716985038 From john.hendrikx at gmail.com Tue Nov 7 11:37:12 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 7 Nov 2023 12:37:12 +0100 Subject: Public Behavior API proposal In-Reply-To: References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: <88bffff4-44c5-7349-c9fd-b26041e1dba8@gmail.com> Hi Michael, Thanks a lot for this early feedback. I think in light of it I will rework the proposal(s) to include semantic events right from the beginning. More inline comments below. --John On 07/11/2023 08:09, Michael Strau? wrote: > Hi John, > > I like that you clearly define the terms Control, Skin and Behavior, > as well as their roles within the control architecture. > > However, I don't see how your proposal scales to non-trivial controls, > and I agree with Andy that the Button example doesn't help (because a > Button lacks substructure and provides only a single interaction). I didn't go into too great detail due to some time constraints, but the API should scale to any kind of control as there is no requirement to make all interactions available immediately, and any interactions you do want to make available that don't bubble up to Control level automatically can be generated by the Skin with non-public events, or by leaving events to bubble up that can be distinguished by a tag on the source; the SpinnerSkin could have ActionEvents bubble up (although it doesn't work that way, and I wouldn't recommend using a public event type for this anyway). > I'm missing your previous idea of using the event system for > higher-level semantic events, because I think they're required to make > this work. Here's how I see these parts working together: I've attempted to keep the proposal small, and I had the impression there was some resistance against the semantic event idea, so I've left that part out for now, although hopefully left enough room to apply it later still. > 1) A control is an opaque node in the scene graph, which defines the > API for a particular interactive element. It also defines the > interactions afforded by its implementation. For example, a Spinner > will usually consist of a text field and two buttons, but a skin might > choose to implement these components differently. The interactions > afforded by a control are exposed as semantic events: > > class SpinnerEvent extends Event { > static EventType COMMIT_TEXT; > static EventType START_INCREMENT; > static EventType STOP_INCREMENT; > static EventType START_DECREMENT; > static EventType STOP_DECREMENT; > } I didn't examine the Spinner before, but I think these would be excellent events for a Spinner control. > 2) Skins are responsible for generating semantic events, and sending > those events to the control. Since we don't need those events to have > a tunneling/bubbling behavior, we could have a flag on the event that > indicates a "direct event", one that is dispatched directly to its > target. Performance tests could show if this is truly needed, many events are fired already to get to this point, and firing another should not be prohibitive. There may also be an option to use a different root instead (instead of Scene as the root, Control is used as root, so dispatching and bubbling is limited to the Control and its substructure; we should consider this carefully to be absolutely sure these events have no value outside the Control and its substructure). > 3) Behaviors listen for semantic events on the control, and convert > these events into state changes of the control. This part would > probably be quite similar to some of the things that have already been > proposed. Yeah, the novelty here is that the Behavior would be also the one responding to the semantic events, and the Behavior would then be calling regular methods directly on the Control again (in my earlier idea, the Behavior also sent out semantic events and the control was the one responding to them). For comparison, my earlier idea had: 1. Controls define semantic events 2. Controls respond to their own semantic events (by calling its own public methods, like `fire` or `increment(int)`) 3. Behaviors take standard events (KeyEvent, MouseEvent) and translates them to semantic events With your adjustment this becomes: 1. Controls define semantic events 2. Behaviors install event handlers on the control They listen for standard events (KeyEvent, MouseEvent) and translate them to semantic events. This indirection can be exposed as a key mapping system, where semantic events are the "Functions". They also listen to semantic events (generated by Skins, or generated by itself) and modify control state accordingly (by calling public methods like `fire` or `increment(int)`). 3. Skins handle the visuals and are allowed to generate semantic events Skins are not allowed to have event handlers at the control level, nor are they allowed to manipulate the control beyond installing listeners.? For Behaviors I'm enforcing such restrictions by using the `BehaviorContext` during installing, but Skins being an older design lack such enforcement for now.? Skins are still alllowed to do anything they want with their nested controls (including manipulating them and installing event handlers). > In this way, controls, skins, and behaviors would end up as loosely > coupled parts. In particular, I don't see the value in making > behaviors public API if they are so tightly coupled to skins that they > end up as being basically implementation details. > > Andy: >> Imagine a specific skin that has a Node that accepts a user input. A scroll bar, a button, or a region with a some function. Unless this element is proclaimed as must-have for any skin and codified via some new public API (MySkin.getSomeElement()), it is specific to that particular skin and that particular behavior. > I think that's a very important observation. A skin can't just be > anything it wants to be, it must be suitable for its control. So we > need a place where we define the API and the interactions afforded by > that control. In my opinion, this place is the Control. Its > functionality is exposed via properties and methods, and its > interactions are specified using semantic events. Yeah, I think we're certainly in agreement here. > Now skins are free to be implemented in any imaginable way, provided > that they interact with the control using semantic events. This gives > us very straightforward restrictions: > * A skin can never add interactions that the control didn't specify. > * If additional interactions are required, the control must be > subclassed and the interactions must be specified by the control. > Additionally, the behavior must be extended to account for the > additional interactions. Something I noticed is that there are Skins that have their own styleable CSS properties (TextInputControlSkin provides for example `-fx-text-fill`, `-fx-prompt-text-fill`, `-fx-display-caret`), but they are presented as properties of TextInputControl (parent class of TextArea and TextField) in the CSS documentation.? The CSS system allows for this, and will find these properties as if the belong to the control.? I have the feeling this shouldn't be done in this manner, especially when they're presented as being part of TextInputControl, when as soon as you reskin it those properties are lost. However, I don't think that's counter to what you said above, but it is a bit surprising. --John > > > > On Mon, Nov 6, 2023 at 4:50?AM John Hendrikx wrote: >> As promised, a public Behavior API proposal. >> >> Summary: >> >> Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. >> >> See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 >> >> --John From jpereda at openjdk.org Tue Nov 7 12:00:57 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 7 Nov 2023 12:00:57 GMT Subject: [jfx21u] RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache Message-ID: Clean backport of 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache Reviewed-by: kcr, angorya, jvos ------------- Commit messages: - 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache Changes: https://git.openjdk.org/jfx21u/pull/26/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=26&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307536 Stats: 20 lines in 1 file changed: 18 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/26.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/26/head:pull/26 PR: https://git.openjdk.org/jfx21u/pull/26 From jpereda at openjdk.org Tue Nov 7 13:07:44 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 7 Nov 2023 13:07:44 GMT Subject: [jfx21u] Integrated: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:55:36 GMT, Jose Pereda wrote: > Clean backport of 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache > > Reviewed-by: kcr, angorya, jvos This pull request has now been integrated. Changeset: ea9f143a Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/ea9f143abfa4e15990f0efccf967609e51f36492 Stats: 20 lines in 1 file changed: 18 ins; 1 del; 1 mod 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache Backport-of: 72f05a79bf66e39848e491320447997e54625617 ------------- PR: https://git.openjdk.org/jfx21u/pull/26 From duke at openjdk.org Tue Nov 7 16:07:46 2023 From: duke at openjdk.org (Martin Fox) Date: Tue, 7 Nov 2023 16:07:46 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> Message-ID: On Mon, 6 Nov 2023 17:53:42 GMT, Ambarish Rapte wrote: >> @arapte anything else I could do? > > @vlaaad > Yes please, I think we should have a test along with this fix. A test is missing for this scenario. > If a unit test is not feasible, can you please check to add a system test ? ( may be something like setting F1 as accelerator key on a MenuItem results in MenuItem's action getting fired when Function+F1 is pressed ) I added a manual test to the original bug report. @arapte I would prefer to approve this PR and submit the manual test under a separate PR since it's by a different author. FWIW it works for me but you may see different results, the function keys are overloaded and the OS or some other app you're running may grab one of these shortcuts. That's why this test avoids Cmd-F5, on Ventura that toggles Voice Over. This variability is the primary reason I don't want to enter an automated Robot test. Perhaps with some experience we can find a subset of the function keys that work reliably for everyone but I don't know what that subset is now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1799036035 From arapte at openjdk.org Wed Nov 8 06:09:13 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 8 Nov 2023 06:09:13 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1252#pullrequestreview-1719434808 From arapte at openjdk.org Wed Nov 8 06:09:14 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 8 Nov 2023 06:09:14 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: <8xD7owdFpBsyAKmHkjKMn8pbbDtPhHnPXgDKj2Sv02A=.98c00773-9869-48c0-ab26-1ceaf9977923@github.com> Message-ID: On Tue, 7 Nov 2023 16:04:56 GMT, Martin Fox wrote: >> @vlaaad >> Yes please, I think we should have a test along with this fix. A test is missing for this scenario. >> If a unit test is not feasible, can you please check to add a system test ? ( may be something like setting F1 as accelerator key on a MenuItem results in MenuItem's action getting fired when Function+F1 is pressed ) > > I added a manual test to the original bug report. @arapte I would prefer to approve this PR and submit the manual test under a separate PR since it's by a different author. FWIW it works for me but you may see different results, the function keys are overloaded and the OS or some other app you're running may grab one of these shortcuts. That's why this test avoids Cmd-F5, on Ventura that toggles Voice Over. > > This variability is the primary reason I don't want to enter an automated Robot test. Perhaps with some experience we can find a subset of the function keys that work reliably for everyone but I don't know what that subset is now. @beldenfox Sounds good, I looked at a the test. The test will need some changes to adapt to other platforms, otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1801149946 From duke at openjdk.org Wed Nov 8 15:22:20 2023 From: duke at openjdk.org (vlaaad) Date: Wed, 8 Nov 2023 15:22:20 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all Yay! Is there any ETA for a new javafx version with this changeset? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802104158 From john.hendrikx at gmail.com Wed Nov 8 15:57:45 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 8 Nov 2023 16:57:45 +0100 Subject: Key binding customization proposal In-Reply-To: References: Message-ID: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> On 06/11/2023 20:54, Andy Goryachev wrote: > > Dear John: > > Thank you again for submitting a separate KeyBinding proposal.? > Ignoring my objection for its sibling, I just wanted to point to these > two items in Goals and Non-Goals: > > * Keep internal details of InputMap?implementation hidden (it is too > complex, and consumes far too much resources) > > I object to this on two fronts: > > 1. by trying to go around the InputMap, something that many developers > find easy to understand, you invented a bunch of weird things like > InputContext, Actions (not those Actions that we are used to!), and > States.? Why? What is the problem?? How is what you propose is NOT > ?too complex? but an InputMap is? > > 2. You still need to add a listeners on each control instance, right? > > But the main objection comes from > > * Runtime modification of key bindings on a per control basis > Before I reply further, where is the use case for this? I don't see it in any of the earlier linked tickets.? All those tickets want Behaviors opened up to ease Skin subclassing, but that's not addressed in any way. https://bugs.openjdk.org/browse/JDK-8092211 https://bugs.openjdk.org/browse/JDK-8091189 https://bugs.openjdk.org/browse/JDK-8186137 Especially runtime modification of default key bindings (ie. ones like Ctrl-A, cut, copy, paste, cursor key based navigation, etc) seems entirely out of scope to be able to modify at runtime as that would be way too confusing for users.? I'd expect these at most to be modified once (immediately after control construction, or simply as part of a Behavior) when preferences change or the application is restarted. Note that I also don't think the key bindings should serve as an alternative mechanism to define keys tied to custom functions (ie, functions not supplied by FX).? That's what KeyEvents are for. The mapping system allows changing of internal key choices, but how these are used exactly (react on pressed or released, on hold duration, etc) is NOT configurable and so should not be seen as an alternative for using KeyEvents. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Nov 8 15:58:19 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 8 Nov 2023 15:58:19 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 15:19:58 GMT, vlaaad wrote: >> vlaaad has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use NSFunctionKeyMask as modifier at all > > Yay! Is there any ETA for a new javafx version with this changeset? @vlaaad The SKARA bot hasn't marked this as ready. I suspect you need to turn on pre-submit tests in your repo. See the Details link next to the line where it says pre-submit tests were skipped. Next version of JavaFX is slated for release in March 2024. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802180127 From kcr at openjdk.org Wed Nov 8 16:02:21 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 16:02:21 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all I should add that, once integrated it will be in the next weekly early access build of JavaFX 22. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802188556 From kcr at openjdk.org Wed Nov 8 16:02:19 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 16:02:19 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: <7s2Wm9GKiFUj6DTMccjAVj69IkMKfNrSfVrCYqvNNes=.068c8aae-243f-4bc9-a6d5-95790203d9e5@github.com> On Wed, 8 Nov 2023 15:19:58 GMT, vlaaad wrote: > Is there any ETA for a new javafx version with this changeset? First you need to integrate the fix so that it will get into the source repo. I see that Skara didn't "count" the review of @beldenfox (he is an Author in the OpenJFX project, although Skara doesn't recognize him as such.). Given this, I'll lower the reviewer criteria for this PR to 1 and attempt to manually add him as a reviewer so that it shows up in the commit metadata. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802186481 From kcr at openjdk.org Wed Nov 8 16:09:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 16:09:13 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: <9GDfkDB_neK_t87KGPmKO-lKsqFljBIkJVrQZ2OMLzI=.d1cc02d0-ba3d-4f42-800b-9cc645d1edd9@github.com> On Wed, 8 Nov 2023 15:19:58 GMT, vlaaad wrote: >> vlaaad has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use NSFunctionKeyMask as modifier at all > > Yay! Is there any ETA for a new javafx version with this changeset? > @vlaaad The SKARA bot hasn't marked this as ready. This is because Skara doesn't know that @beldenfox is the same as OpenJDK user `mfox`. To allow Skara to recognize you, follow the instruction on the Skara Wiki to [associate your GitHub account and OpenJDK username](https://wiki.openjdk.org/display/SKARA#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername). > I suspect you need to turn on pre-submit tests in your repo. See the Details link next to the line where it says pre-submit tests were skipped. This is a good idea in any case. Skara doesn't care, but it is helpful for reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802200446 From andy.goryachev at oracle.com Wed Nov 8 16:23:41 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 8 Nov 2023 16:23:41 +0000 Subject: [External] : Re: Key binding customization proposal In-Reply-To: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> References: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> Message-ID: Dear John: 1. Runtime modification of key bindings on a per control basis Before I reply further, where is the use case for this? A very good question, thank you for asking. You might scroll back to find it answered a couple of times during the discussion, but I think it?s worth exploring it further. There is a number of use cases for runtime modifications: - there might be a requirement to switch between vim/emacs/etc. key mapping - there might be a requirement to customize the mapping per user configuration (see the Eclipse ?Keys? UI that I?ve shown before) - there are many apps (AquaFold Data Studio, for one I remember) which allows for customization of key bindings >From the API perspective, this functionality should be possible. Hope this answers your question. -andy From: John Hendrikx Date: Wednesday, November 8, 2023 at 07:58 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Key binding customization proposal On 06/11/2023 20:54, Andy Goryachev wrote: Dear John: Thank you again for submitting a separate KeyBinding proposal. Ignoring my objection for its sibling, I just wanted to point to these two items in Goals and Non-Goals: 1. Keep internal details of InputMap implementation hidden (it is too complex, and consumes far too much resources) I object to this on two fronts: 1. by trying to go around the InputMap, something that many developers find easy to understand, you invented a bunch of weird things like InputContext, Actions (not those Actions that we are used to!), and States. Why? What is the problem? How is what you propose is NOT ?too complex? but an InputMap is? 2. You still need to add a listeners on each control instance, right? But the main objection comes from 1. Runtime modification of key bindings on a per control basis Before I reply further, where is the use case for this? I don't see it in any of the earlier linked tickets. All those tickets want Behaviors opened up to ease Skin subclassing, but that's not addressed in any way. https://bugs.openjdk.org/browse/JDK-8092211 https://bugs.openjdk.org/browse/JDK-8091189 https://bugs.openjdk.org/browse/JDK-8186137 Especially runtime modification of default key bindings (ie. ones like Ctrl-A, cut, copy, paste, cursor key based navigation, etc) seems entirely out of scope to be able to modify at runtime as that would be way too confusing for users. I'd expect these at most to be modified once (immediately after control construction, or simply as part of a Behavior) when preferences change or the application is restarted. Note that I also don't think the key bindings should serve as an alternative mechanism to define keys tied to custom functions (ie, functions not supplied by FX). That's what KeyEvents are for. The mapping system allows changing of internal key choices, but how these are used exactly (react on pressed or released, on hold duration, etc) is NOT configurable and so should not be seen as an alternative for using KeyEvents. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Nov 8 16:47:16 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 8 Nov 2023 16:47:16 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 08:05:56 GMT, vlaaad wrote: >> This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). >> >> Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! > > vlaaad has updated the pull request incrementally with one additional commit since the last revision: > > Don't use NSFunctionKeyMask as modifier at all I've filed a SKARA issue [SKARA-2100](https://bugs.openjdk.org/browse/SKARA-2100) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802270502 From duke at openjdk.org Wed Nov 8 16:57:09 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 8 Nov 2023 16:57:09 GMT Subject: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically In-Reply-To: <58Z_1DD_g9HgZXiTnb3Wx4eocQJO6j63HC7EJ1Bzzv8=.3fcee3c3-0454-4ee2-94c9-b45c00e55211@github.com> References: <58Z_1DD_g9HgZXiTnb3Wx4eocQJO6j63HC7EJ1Bzzv8=.3fcee3c3-0454-4ee2-94c9-b45c00e55211@github.com> Message-ID: On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox wrote: > A KeyCharacterCombination should match a key if the target character is printed on that key. For example, the user should be able to invoke the `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a key that has '+' printed on it. This should work even if '+' is a shifted symbol but the user doesn't hold down the Shift key. > > The Mac implements KeyCharacterCombinations by monitoring keystrokes to discover the relationship between keys and characters. Currently the system only records the character the user typed and no other characters on the same key. This means a shortcut targeting a shifted character may not work until the user types that character using Shift so the system learns the relationship. > > This PR keeps the same mechanism in place but always records the shifted and unshifted character for each keystroke. > > For the Mac the KeyboardTest app was modified to remove tests for characters accessed using Option. We don't look for these characters because under the hood just about every key has some symbol assigned to the Option modifier that the user probably isn't even aware of. For these character we fall back to the existing logic; once the user types the character it will start working as a shortcut. This is a customer facing issue (see defold/defold#5850). Like most shortcut-related problems there are duplicates in the Defold issue list because KeyCharacterCombinations are malfunctioning in different ways on different platforms and the behavior varies based on the keyboard layout. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1802287346 From duke at openjdk.org Wed Nov 8 17:05:17 2023 From: duke at openjdk.org (Martin Fox) Date: Wed, 8 Nov 2023 17:05:17 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox wrote: > After finding the Window virtual key code for a character getKeyCodeForChar was using a mapping table that only works correctly for U.S. English to retrieve the Java key code. This caused getKeyCodeForChar to encode keys differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles platform key events all agree on how Windows VK codes should map to Java codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). Run the tests by selecting "without keypad combinations" in the second dropdown. This will use a Robot to test KeyCharacterCombinations excluding the numeric keypad (which is a separate issue). Still looking for another reviewer. This was entered due to a bug in a desktop app, see defold/defold#5102 or defold/defold#5589. Both were closed as dupes of other bugs because the app developers had no way of knowing that KeyCharacterCombinations require per-platform fixes in Glass. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1264#issuecomment-1802300519 From kcr at openjdk.org Wed Nov 8 17:45:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 17:45:17 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 16:44:18 GMT, Martin Fox wrote: > I've filed a SKARA issue [SKARA-2100](https://bugs.openjdk.org/browse/SKARA-2100) This has been completed, so Skara will now recognize you. I don't know whether you will need to re-review it, but we'll know shortly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802364164 From kcr at openjdk.org Wed Nov 8 17:50:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 17:50:17 GMT Subject: RFR: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu [v3] In-Reply-To: References: Message-ID: <0NsChLXYvm0LuMS0RzfZ1Oso700cWUx3SJYSOGP58V8=.41f397c4-a11b-4825-a30e-bb928fd033ae@github.com> On Wed, 8 Nov 2023 15:19:58 GMT, vlaaad wrote: >> vlaaad has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't use NSFunctionKeyMask as modifier at all > > Yay! Is there any ETA for a new javafx version with this changeset? @vlaaad This PR is now ready for you to `/integrate` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1252#issuecomment-1802370583 From kcr at openjdk.org Wed Nov 8 18:41:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 18:41:39 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning Message-ID: Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. As noted in the bug report, this PR solves the following problems: * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. ------------- Commit messages: - Revert "Debug logging" - Debug logging - 8319669: [macos14] Running any JavaFX app prints Secure coding warning Changes: https://git.openjdk.org/jfx/pull/1280/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319669 Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1280.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1280/head:pull/1280 PR: https://git.openjdk.org/jfx/pull/1280 From kcr at openjdk.org Wed Nov 8 18:41:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 18:41:39 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 15:04:44 GMT, Kevin Rushforth wrote: > Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: > > 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. > 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. > > As noted in the bug report, this PR solves the following problems: > > * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 > * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) > > * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. > > * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. > > * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. > > This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. I will do some additional testing and then take this PR out of Draft mode, making it "rfr". Reviewers: @prrace @honkar-jdk @azuev-java ------------- PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1802073951 PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1802444216 From kcr at openjdk.org Wed Nov 8 18:45:11 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 18:45:11 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 15:04:44 GMT, Kevin Rushforth wrote: > Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: > > 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. > 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. > > As noted in the bug report, this PR solves the following problems: > > * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 > * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) > > * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. > > * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. > > * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. > > This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. Notes to reviewers: * I pushed a commit with debug logging, and then reverted it. If you want to see the debug logging messages, update to the commit just prior to the HEAD commit. * I recommend to test this on macOS 14 with the latest JDK 22 EA promoted build. Once @honkar-jdk sends the PR for [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854), it would be helpful to test with that as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1802449542 From prr at openjdk.org Wed Nov 8 18:55:13 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 8 Nov 2023 18:55:13 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 15:04:44 GMT, Kevin Rushforth wrote: > Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: > > 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. > 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. > > As noted in the bug report, this PR solves the following problems: > > * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 > * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) > > * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. > > * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. > > * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. > > This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 543: > 541: // Determine if we're running embedded (in AWT, SWT, elsewhere) > 542: NSApplication *app = [NSApplicationFX sharedApplication]; > 543: isEmbedded = isEmbedded = ![app isKindOfClass:[NSApplicationFX class]]; why is there a double assignment here ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1280#discussion_r1387065857 From kcr at openjdk.org Wed Nov 8 19:01:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 19:01:13 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 19:22:26 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add a system test The updated fix looks good. The test passes with the fix and hangs indefinitely without the fix. I left a comment about the fix for the hang and a couple other comments as well. tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 122: > 120: Thread.currentThread().setUncaughtExceptionHandler((t,e) -> { > 121: e.printStackTrace(); > 122: failed.set(true); To avoid the test hanging indefinitely, I recommend adding the following after setting the `failed` flag: memoryLatch.countDown(); tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 145: > 143: stage.show(); > 144: stage.requestFocus(); > 145: Thread t = new Thread(){ Question: Since you do all the work in a `Platform.runLater`, is this thread needed? tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 163: > 161: Platform.runLater( () -> { > 162: System.gc(); > 163: uncollectedMenuItems.removeIf(ref -> ref.get() == null); This assumes that the references will all be collected by a single call to `System.gc` with no delay. While it worked on my system, it might be fragile. Have you considered using JMemoryBuddy? Or if that isn't suitable for some reason, maybe consider looping a few times with a sleep in between each call to gc? tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 165: > 163: uncollectedMenuItems.removeIf(ref -> ref.get() == null); > 164: assertEquals(1, uncollectedMenuItems.size(), "Only the last menuItem should be alive"); > 165: memoryLatch.countDown(); If there is a failure, this statement will be unreached. This is why I recommended also doing a countDown on this latch in the `UncaughtExceptionHandler` ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1721015874 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387038813 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387067229 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387069616 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387070763 From michaelstrau2 at gmail.com Wed Nov 8 19:24:02 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 8 Nov 2023 20:24:02 +0100 Subject: [External] : Re: Key binding customization proposal In-Reply-To: References: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> Message-ID: Hi Andy! > There is a number of use cases for runtime modifications: > > - there might be a requirement to switch between vim/emacs/etc. key mapping > - there might be a requirement to customize the mapping per user configuration (see the Eclipse ?Keys? UI that I?ve shown before) > - there are many apps (AquaFold Data Studio, for one I remember) which allows for customization of key bindings Maybe we should pull on this string a little bit more. It's still not clear to me what the requirements actually are. What is meant by "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific example. 1. The way I understand it, the only thing a public InputMap API would enable developers to do would be to change key mappings of existing control functionality. For example, I could re-map the left arrow to invoke the "moveRight" function, or I could re-map ctrl+A to "copy" text, instead of "select all" text. But why would I want to do that? These are default mappings for a reason. Is there any example in which such a re-mapping would potentially be useful? 2. We seem to be talking about text a lot. Is there any specific example beyond TextInputControl that would benefit from this feature? Maybe this should be an extension for TIC, and not for the control architecture as a whole? 3. I have two examples that are not possible in JavaFX right now (at last not out of the box): - In IntelliJ, there's an option that toggles the way I can scroll through text on a word-by-word basis (look for: "Use CamelHump words"). If toggled, I can ctrl-arrow left or right, and the caret will be placed either at the beginning of the next or previous word boundary, or alternatively at the beginning of the next or previous case change within a word (the "CamelHump"). - Also in IntelliJ, there's an option for "Home moves caret to first non-whitespace character". The alterative is that Home moves the caret to the beginning of the line. The proposed API doesn't enable me to implement those features, does it? This leads me to think that what we really need is a way to customize the "behavior" (whatever this ends up being) of a control more so than its default key mappings. From duke at openjdk.org Wed Nov 8 19:29:15 2023 From: duke at openjdk.org (vlaaad) Date: Wed, 8 Nov 2023 19:29:15 GMT Subject: Integrated: JDK-8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu In-Reply-To: References: Message-ID: On Mon, 2 Oct 2023 12:51:52 GMT, vlaaad wrote: > This PR addresses [JDK-8284445](https://bugs.openjdk.org/browse/JDK-8284445). > > Context: the warning might be more important than it seems. Our JavaFX-based desktop app has [an issue](https://github.com/defold/defold/issues/7845) ? when the user opens 2 instances of the app, one of the instances hangs after a while. While debugging the issue, I found that it's somehow related to the system menu bar ? not refreshing it fixes the issue. Further investigations revealed that the app hangs only if we show menus that use F1-F24 shortcuts. This reminded me of the warnings we get about `NSEventModifierFlagFunction specified to -setKeyEquivalentModifierMask` for such shortcuts. I experimented with removing the modifier for these shortcuts, and it helped with our issue! This pull request has now been integrated. Changeset: c8641e28 Author: Vlad Protsenko Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/c8641e280b41d26a59d20c21813408f6cfe30cbb Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8284445: macOS 12 prints a warning when a function key shortcut is assigned to a menu Reviewed-by: mfox, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1252 From kcr at openjdk.org Wed Nov 8 19:43:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 19:43:24 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning [v2] In-Reply-To: References: Message-ID: > Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: > > 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. > 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. > > As noted in the bug report, this PR solves the following problems: > > * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 > * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) > > * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. > > * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. > > * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. > > This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Fix typo: remove redundant `isEmbedded =` assignement ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1280/files - new: https://git.openjdk.org/jfx/pull/1280/files/ef998928..4a79cb29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1280&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1280&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1280.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1280/head:pull/1280 PR: https://git.openjdk.org/jfx/pull/1280 From kcr at openjdk.org Wed Nov 8 19:49:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 19:49:09 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning [v2] In-Reply-To: References: Message-ID: <1K_5rTUaXAX1IvzYJsBEdPK4NUEXf-7sj_tKqPqXIa0=.640c4eb2-303d-4e52-b478-aa38dff19b0e@github.com> On Wed, 8 Nov 2023 18:52:23 GMT, Phil Race wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo: remove redundant `isEmbedded =` assignement > > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 543: > >> 541: // Determine if we're running embedded (in AWT, SWT, elsewhere) >> 542: NSApplication *app = [NSApplicationFX sharedApplication]; >> 543: isEmbedded = isEmbedded = ![app isKindOfClass:[NSApplicationFX class]]; > > why is there a double assignment here ? That was a typo. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1280#discussion_r1387125250 From andy.goryachev at oracle.com Wed Nov 8 20:18:58 2023 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 8 Nov 2023 20:18:58 +0000 Subject: [External] : Re: Key binding customization proposal In-Reply-To: References: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> Message-ID: Dear Michael: Thank you for specific questions! > "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific example. Vim/emacs might be a bad example, as they use key sequences. Key sequences are not a part of this proposal (but it is possible to implement with the help of the proposed API). One example is a user preference for Go-To-Line function typical in text editors. In jEdit on Mac it?s ?E, while in Eclipse it?s ?G. The user might strongly prefer to have one or the other, so an application requirement might include redefining one or more keys. Since it?s a user preference, it has to be done at runtime. 1. The way I understand it, the only thing a public InputMap API would enable developers to do would be to change key mappings of existing control functionality. For example, I could re-map the left arrow to invoke the "moveRight" function, or I could re-map ctrl+A to "copy" text, instead of "select all" text. But why would I want to do that? These are default mappings for a reason. Is there any example in which such a re-mapping would potentially be useful? The public API should *enable* the possibility, even if the core set of controls do not require it. I It is not the case of whether you want to remap ctrl-A to COPY, but a case when an application developer has a requirement to remap something (command-E to command-G). You even hint at such a requirement when talking about navigating camel case words. 2. We seem to be talking about text a lot. Is there any specific example beyond TextInputControl that would benefit from this feature? Maybe this should be an extension for TIC, and not for the control architecture as a whole? Some controls do not need an input map, some do. Some controls may not benefit from key mapping, but others do. I focused on TIC because that?s the area I am currently focused on, but perhaps Tree/Table view could be another case where custom key mapping might be useful. 3. I have two examples that are not possible in JavaFX right now (at last not out of the box): ... The proposed API doesn't enable me to implement those features, does it? It does, it was specifically designed with these requirements in mind. For example, for Scroll through text on a word-by-word basis (look for: "Use CamelHump words" You?d define a custom function tags for NEXT_CAMEL_HUMP_STOP/PREVIOS_CAMEL_HUMP_STOP and implement the functions (get caret position or selection range from the control, computing the next/previos stop by looking at the text, and setting the caret to the new position), and remapping the RIGHT/LEFT keys to the new function. If everything you need is provided to you by the control?s public API, you don?t even have to touch the default skin or its behavior. Same applies for "Home moves caret to first non-whitespace character". Depending on what you want, the custom function could consult the preference setting, if any, and compute the new caret position entirely from information available via public APIs in the control. A smarter control might even provide these function variants as part of its default behavior, for example MOVE_LINE_START/MOVE_FIRST_NON_WHITESPACE_CHAR or something like that. It?s probably my fault that it is not immediately apparent from the proposal that these use cases are supported by design. Thanks -andy From: openjfx-dev on behalf of Michael Strau? Date: Wednesday, November 8, 2023 at 11:24 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Key binding customization proposal Hi Andy! > There is a number of use cases for runtime modifications: > > - there might be a requirement to switch between vim/emacs/etc. key mapping > - there might be a requirement to customize the mapping per user configuration (see the Eclipse ?Keys? UI that I?ve shown before) > - there are many apps (AquaFold Data Studio, for one I remember) which allows for customization of key bindings Maybe we should pull on this string a little bit more. It's still not clear to me what the requirements actually are. What is meant by "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific example. 1. The way I understand it, the only thing a public InputMap API would enable developers to do would be to change key mappings of existing control functionality. For example, I could re-map the left arrow to invoke the "moveRight" function, or I could re-map ctrl+A to "copy" text, instead of "select all" text. But why would I want to do that? These are default mappings for a reason. Is there any example in which such a re-mapping would potentially be useful? 2. We seem to be talking about text a lot. Is there any specific example beyond TextInputControl that would benefit from this feature? Maybe this should be an extension for TIC, and not for the control architecture as a whole? 3. I have two examples that are not possible in JavaFX right now (at last not out of the box): - In IntelliJ, there's an option that toggles the way I can scroll through text on a word-by-word basis (look for: "Use CamelHump words"). If toggled, I can ctrl-arrow left or right, and the caret will be placed either at the beginning of the next or previous word boundary, or alternatively at the beginning of the next or previous case change within a word (the "CamelHump"). - Also in IntelliJ, there's an option for "Home moves caret to first non-whitespace character". The alterative is that Home moves the caret to the beginning of the line. The proposed API doesn't enable me to implement those features, does it? This leads me to think that what we really need is a way to customize the "behavior" (whatever this ends up being) of a control more so than its default key mappings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Wed Nov 8 23:45:21 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 8 Nov 2023 23:45:21 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture Message-ID: Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. Summary of the changes: * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. ------------- Commit messages: - Removed whitespaces - Remove printing/comments - Java side files update - Add filter type management to native material and meshview Changes: https://git.openjdk.org/jfx/pull/1281/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8092272 Stats: 260 lines in 10 files changed: 200 ins; 21 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1281.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1281/head:pull/1281 PR: https://git.openjdk.org/jfx/pull/1281 From mstrauss at openjdk.org Thu Nov 9 03:33:13 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Nov 2023 03:33:13 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 22:30:34 GMT, Nir Lisker wrote: > Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. > > Summary of the changes: > * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. > * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. > * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. > > The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/TextureData.java line 12: > 10: */ > 11: // Here we can support mipmaps, wrapping modes (which exists internally and can be pulled out), addressing modes etc. > 12: public class TextureData { 1. This type could be a record. 2. There's no actual texture data (i.e. pixels) here, maybe a better name would be `SamplerParameters` or something like that. modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 357: > 355: > 356: enum minmagFilterType { nearest_point, bilinear }; > 357: enum mipmapFilterType { none, nearest, linear }; These two types don't seem to be used anywhere. modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 369: > 367: { > 368: static const D3DTEXTUREFILTERTYPE minMagEnumMap[2] = { D3DTEXF_POINT, D3DTEXF_LINEAR }; > 369: static const D3DTEXTUREFILTERTYPE mipmapEnumMap[3] = { D3DTEXF_NONE, D3DTEXF_POINT, D3DTEXF_LINEAR }; You could use `std::array` as a safer alternative for plain arrays. modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 295: > 293: for (int i = 0; i < map_type::num_map_types; i++) { > 294: map_type type = static_cast(i); > 295: SUCCEEDED(device->SetTexture(type, material->getMap(type))); Wrapping the calls with the `SUCCEEDED` macro doesn't do anything useful. modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.cc line 39: > 37: for (int i = 0; i < map_type::num_map_types; i++) { > 38: map[i] = NULL; > 39: } The size of the array is statically known, you could use `memset(map, 0, sizeof(map))` (or, if you use `std::array`, it's simply `map.fill(NULL)`). However, why is there a destructor at all? It doesn't seem to do anything useful. modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.cc line 70: > 68: > 69: bool D3DPhongMaterial::isBumpMap() { > 70: return map[map_type::bump] ? true : false; Since `map` contains pointers, you might consider `return map[map_type::bump] != NULL`. modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.h line 41: > 39: self_illumination, > 40: num_map_types > 41: }; 1. Types generally seem to use PascalCase in this library, and constants UPPER_CASE or CamelCase. 2. You can use `enum class` to prevent the constants from polluting the global namespace. 3. The underlying type doesn't need to be specified, it's `int` by default. You're casting it to `int` in `D3DMeshView.cc` anyway. modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.h line 57: > 55: bool isSpecularColor(); > 56: bool isSelfIllumMap(); > 57: IDirect3DBaseTexture9 * getMap(map_type type); Space between `*` and `getMap`. modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.h line 67: > 65: float specularColor[4] = {1, 1, 1, 32}; > 66: bool specularColorSet = false; > 67: IDirect3DBaseTexture9 *map[map_type::num_map_types] = {NULL}; You could use `std::array` as a safer alternative for plain arrays. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387437548 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387410882 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387443618 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387437011 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387420999 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387431297 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387419835 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387412857 PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1387429857 From psadhukhan at openjdk.org Thu Nov 9 04:03:30 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 9 Nov 2023 04:03:30 GMT Subject: RFR: 8303826: Add FX test for JDK-8252255 Message-ID: <5bKU4fKgUfZU9OULysZN7KgNiTLrEfrFVtVqcEBcg_c=.3b67e420-6426-4982-bb55-c8c03342aed6@github.com> Manual regression test for 8252255: Blurry rendering of SwingNode with HiDPI scaling in JavaFX is added ------------- Commit messages: - 8303826: Add FX test for JDK-8252255 - 8303826: Add FX test for JDK-8252255 Changes: https://git.openjdk.org/jfx/pull/1282/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303826 Stats: 155 lines in 1 file changed: 155 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1282.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1282/head:pull/1282 PR: https://git.openjdk.org/jfx/pull/1282 From jvos at openjdk.org Thu Nov 9 09:16:10 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 09:16:10 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:26:14 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a system test > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 122: > >> 120: Thread.currentThread().setUncaughtExceptionHandler((t,e) -> { >> 121: e.printStackTrace(); >> 122: failed.set(true); > > To avoid the test hanging indefinitely, I recommend adding the following after setting the `failed` flag: > > > memoryLatch.countDown(); good idea. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387700709 From jvos at openjdk.org Thu Nov 9 09:28:09 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 09:28:09 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:53:42 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a system test > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 145: > >> 143: stage.show(); >> 144: stage.requestFocus(); >> 145: Thread t = new Thread(){ > > Question: Since you do all the work in a `Platform.runLater`, is this thread needed? That's a good question. I do this because we start the test on the FX Thread, but I want to add/remove the menuItems one by one, giving time for a `pulse` in between them. If we do the 50 runs inside a single Runnable, without the possibility for the FX Thread to do other work, the result can be different compared to what we do when doing this in small runnables. But I might be missing something here? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387715251 From kcr at openjdk.org Thu Nov 9 12:39:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 12:39:09 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:25:11 GMT, Johan Vos wrote: >> tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 145: >> >>> 143: stage.show(); >>> 144: stage.requestFocus(); >>> 145: Thread t = new Thread(){ >> >> Question: Since you do all the work in a `Platform.runLater`, is this thread needed? > > That's a good question. I do this because we start the test on the FX Thread, but I want to add/remove the menuItems one by one, giving time for a `pulse` in between them. If we do the 50 runs inside a single Runnable, without the possibility for the FX Thread to do other work, the result can be different compared to what we do when doing this in small runnables. > But I might be missing something here? Oh, I see that now. I had missed that you were calling this method from within a `Util::runAndWait`. Never mind. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387941543 From jvos at openjdk.org Thu Nov 9 12:46:35 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 12:46:35 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v5] In-Reply-To: References: Message-ID: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: countdown in case of a failure as well use jmemorybuddy to detect unreachable weakrefs. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/be847398..1432485f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=03-04 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From jvos at openjdk.org Thu Nov 9 12:52:11 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 12:52:11 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v5] In-Reply-To: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> References: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> Message-ID: On Thu, 9 Nov 2023 12:46:35 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > countdown in case of a failure as well > use jmemorybuddy to detect unreachable weakrefs. Note that I filed another memory issue related to SystemMenu: https://bugs.openjdk.org/browse/JDK-8319779 That one is not related to native mac-specific code, hence I didn't want to combine the solution in this current PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1803769993 From jvos at openjdk.org Thu Nov 9 12:52:15 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 12:52:15 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:56:54 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a system test > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 165: > >> 163: uncollectedMenuItems.removeIf(ref -> ref.get() == null); >> 164: assertEquals(1, uncollectedMenuItems.size(), "Only the last menuItem should be alive"); >> 165: memoryLatch.countDown(); > > If there is a failure, this statement will be unreached. This is why I recommended also doing a countDown on this latch in the `UncaughtExceptionHandler` Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1387953005 From kcr at openjdk.org Thu Nov 9 13:09:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 13:09:14 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v5] In-Reply-To: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> References: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> Message-ID: On Thu, 9 Nov 2023 12:46:35 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > countdown in case of a failure as well > use jmemorybuddy to detect unreachable weakrefs. The test changes look good. One thing I noticed is that it now takes ~ 50 seconds to time out if there is a failure (a call to checkCollectable that returns false takes ~ 1 second, which is needed to ensure that it is a robust check). Maybe cut down the number of menu objects from 50 to, say, 10? I'll approve it as is, since the only way this will ever be a problem is if we reintroduce this bug, and it's still under 1 minute so OK. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1722491475 From kcr at openjdk.org Thu Nov 9 13:12:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 13:12:13 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning In-Reply-To: References: Message-ID: <8qRixw-axthY6c8UPJ0d03lC23HRafjY5ISSc1uyEwc=.bb685616-cdbd-44ae-8acb-8a46c6dc520b@github.com> On Wed, 8 Nov 2023 18:42:32 GMT, Kevin Rushforth wrote: > I recommend to test this on macOS 14 with the latest JDK 22 EA promoted build. Once @honkar-jdk sends the PR for [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854), it would be helpful to test with that as well. PR openjdk/jdk#16569 has been created. It's still in Draft, but should be "rfr" soon. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1803801340 From jvos at openjdk.org Thu Nov 9 15:17:25 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 15:17:25 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/1432485f..cbe5ea46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From kcr at openjdk.org Thu Nov 9 15:17:25 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 15:17:25 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 15:14:58 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1722787546 From kcr at openjdk.org Thu Nov 9 15:29:10 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 15:29:10 GMT Subject: RFR: 8303826: Add FX test for JDK-8252255 In-Reply-To: <5bKU4fKgUfZU9OULysZN7KgNiTLrEfrFVtVqcEBcg_c=.3b67e420-6426-4982-bb55-c8c03342aed6@github.com> References: <5bKU4fKgUfZU9OULysZN7KgNiTLrEfrFVtVqcEBcg_c=.3b67e420-6426-4982-bb55-c8c03342aed6@github.com> Message-ID: On Thu, 9 Nov 2023 03:43:48 GMT, Prasanta Sadhukhan wrote: > Manual regression test for 8252255: Blurry rendering of SwingNode with HiDPI scaling in JavaFX is added Looks good. I confirm that if I run the test using JDK 19 it fails (Swing content is blurry) and using JDK 21 it passes. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1282#pullrequestreview-1722813715 From jvos at openjdk.org Thu Nov 9 15:38:20 2023 From: jvos at openjdk.org (Johan Vos) Date: Thu, 9 Nov 2023 15:38:20 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v5] In-Reply-To: References: <_pkDmn-glaHx1oWgJ1vBZyToXRgNAFSlu6jo6fpC_fo=.a06e61a9-7fa5-47fb-b1cc-9803811c9e78@github.com> Message-ID: On Thu, 9 Nov 2023 13:06:50 GMT, Kevin Rushforth wrote: > The test changes look good. One thing I noticed is that it now takes ~ 50 seconds to time out if there is a failure (a call to checkCollectable that returns false takes ~ 1 second, which is needed to ensure that it is a robust check). > > Maybe cut down the number of menu objects from 50 to, say, 10? I'll approve it as is, since the only way this will ever be a problem is if we reintroduce this bug, and it's still under 1 minute so OK. makes sense, done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1804061283 From duke at openjdk.org Thu Nov 9 17:52:31 2023 From: duke at openjdk.org (brunesto) Date: Thu, 9 Nov 2023 17:52:31 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text Message-ID: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> The fix prevents the DatePicker from losing focus if the date is not parsable. ------------- Commit messages: - DatePicker restores the previous value when focus is lost and the date is not parseable - method visibility - whitespaces - 8303478: DatePicker throws uncatchable exception on tab out from garbled text Changes: https://git.openjdk.org/jfx/pull/1274/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303478 Stats: 228 lines in 2 files changed: 227 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1274.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1274/head:pull/1274 PR: https://git.openjdk.org/jfx/pull/1274 From angorya at openjdk.org Thu Nov 9 17:52:33 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 9 Nov 2023 17:52:33 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Tue, 31 Oct 2023 19:20:48 GMT, brunesto wrote: > The fix prevents the DatePicker from losing focus if the date is not parsable. Just preliminary comments, will do a full review once OCA process is completed. tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. it's a brand new file, I wonder if it should have 2023 only tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 36: > 34: import org.junit.Before; > 35: import org.junit.BeforeClass; > 36: import org.junit.Test; could we switch to junit5 please? tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 98: > 96: // 3. Click on button to grab the focus and hence attempt to datePicker.commitValue() > 97: // 4. Verify that in case of typo, the value was reverted, as well as the editor's text > 98: public void testDatePickerCommit(boolean typo) throws Exception { thank you for explaining what the test cases attempt to do! tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 141: > 139: // 6 check if onChangeListener was called (already working as expected before the patch) > 140: if (typo) > 141: Assert.assertEquals(onChangeListenerCalled, 0); please always use { } in `if` statements tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 185: > 183: button = new Button("..."); > 184: root.getChildren().add(button); > 185: extra newline (here and elsewhere) ------------- PR Review: https://git.openjdk.org/jfx/pull/1274#pullrequestreview-1708442005 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378943077 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378939425 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378940060 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378938085 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378938680 From kcr at openjdk.org Thu Nov 9 17:52:33 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 17:52:33 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Tue, 31 Oct 2023 19:20:48 GMT, brunesto wrote: > The fix prevents the DatePicker from losing focus if the date is not parsable. I left a few inline comments. I'll leave it to others to formally review it. I should add that we won't formally review the fix until the OCA status is recorded (which Andy mentioned above). modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 159: > 157: * This is to address https://bugs.openjdk.org/browse/JDK-8303478 > 158: */ > 159: private void commitValueOnFocusLost(){ Minor: add a space before the `{` ------------- PR Review: https://git.openjdk.org/jfx/pull/1274#pullrequestreview-1710061973 PR Comment: https://git.openjdk.org/jfx/pull/1274#issuecomment-1790619083 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379990815 From duke at openjdk.org Thu Nov 9 17:52:33 2023 From: duke at openjdk.org (brunesto) Date: Thu, 9 Nov 2023 17:52:33 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Tue, 31 Oct 2023 19:20:48 GMT, brunesto wrote: > The fix prevents the DatePicker from losing focus if the date is not parsable. FYI a company Agreement was sent for the OCA, it is under review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1274#issuecomment-1790662061 From mhanl at openjdk.org Thu Nov 9 17:52:33 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 9 Nov 2023 17:52:33 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Tue, 31 Oct 2023 19:20:48 GMT, brunesto wrote: > The fix prevents the DatePicker from losing focus if the date is not parsable. modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 157: > 155: > 156: /** > 157: * This is to address https://bugs.openjdk.org/browse/JDK-8303478 I don't think this javadoc is needed, since it just links the issue one can also lookup when checking the git history tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 98: > 96: // 3. Click on button to grab the focus and hence attempt to datePicker.commitValue() > 97: // 4. Verify that in case of typo, the value was reverted, as well as the editor's text > 98: public void testDatePickerCommit(boolean typo) throws Exception { you actually can also write a normal JUnit test as far as I get this. Then there is no need for `Util.runAndWait`, `sleep` and so on. See: `test.javafx.scene.control.DatePickerTest` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379717425 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379714171 From kcr at openjdk.org Thu Nov 9 17:52:33 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 17:52:33 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Thu, 2 Nov 2023 08:01:01 GMT, Marius Hanl wrote: >> The fix prevents the DatePicker from losing focus if the date is not parsable. > > modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 157: > >> 155: >> 156: /** >> 157: * This is to address https://bugs.openjdk.org/browse/JDK-8303478 > > I don't think this javadoc is needed, since it just links the issue one can also lookup when checking the git history Exactly. Remove this line and either add a comment describing what the method does, or since the name is self-explanatory, remove the comment block entirely. > tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 98: > >> 96: // 3. Click on button to grab the focus and hence attempt to datePicker.commitValue() >> 97: // 4. Verify that in case of typo, the value was reverted, as well as the editor's text >> 98: public void testDatePickerCommit(boolean typo) throws Exception { > > you actually can also write a normal JUnit test as far as I get this. Then there is no need for `Util.runAndWait`, `sleep` and so on. > > See: `test.javafx.scene.control.DatePickerTest` A headless test is the preferred way to do it, if feasible. If it is, move the test to the `javafx.controls` module. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379989660 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379993571 From kcr at openjdk.org Thu Nov 9 17:52:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 17:52:34 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Wed, 1 Nov 2023 15:20:29 GMT, Andy Goryachev wrote: >> The fix prevents the DatePicker from losing focus if the date is not parsable. > > tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. > > it's a brand new file, I wonder if it should have 2023 only Unless this file was substantially copied from another test, it should be 2023 only. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1379991426 From mstrauss at openjdk.org Thu Nov 9 17:52:34 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Nov 2023 17:52:34 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: On Tue, 31 Oct 2023 19:20:48 GMT, brunesto wrote: > The fix prevents the DatePicker from losing focus if the date is not parsable. modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 159: > 157: * This is to address https://bugs.openjdk.org/browse/JDK-8303478 > 158: */ > 159: protected void commitValueOnFocusLost(){ The `protected` modifier makes this method public API, which would most likely require a CSR to be approved. Since there doesn't seem to be a reason why this method should be public, I suggest making it private instead. modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 163: > 161: commitValue(); > 162: } catch (DateTimeParseException dtpe) { > 163: this.requestFocus(); I'm not sure whether moving focus to the control is a good idea, because this effectively captures focus and forces me to enter a valid date before I can do anything else. Why not just restore the previous value instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378108562 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378110040 From duke at openjdk.org Thu Nov 9 17:52:34 2023 From: duke at openjdk.org (brunesto) Date: Thu, 9 Nov 2023 17:52:34 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text In-Reply-To: References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: <81HlyGpmentHlLtRx7fFIy0ZKlw2bLzEu64S7M19G5Q=.b1dfc6eb-e72f-411d-bf58-ce4ca6fce288@github.com> On Tue, 31 Oct 2023 20:01:39 GMT, Michael Strau? wrote: >> The fix prevents the DatePicker from losing focus if the date is not parsable. > > modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 159: > >> 157: * This is to address https://bugs.openjdk.org/browse/JDK-8303478 >> 158: */ >> 159: protected void commitValueOnFocusLost(){ > > The `protected` modifier makes this method public API, which would most likely require a CSR to be approved. Since there doesn't seem to be a reason why this method should be public, I suggest making it private instead. ok, I have changed it to private > modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 163: > >> 161: commitValue(); >> 162: } catch (DateTimeParseException dtpe) { >> 163: this.requestFocus(); > > I'm not sure whether moving focus to the control is a good idea, because this effectively captures focus and forces me to enter a valid date before I can do anything else. Why not just restore the previous value instead? I have changed the behavior as you suggested. The downside is that user might not notice that his/her changes were replaced, but it is anyway consistent to what happens when typing ENTER. Robot test is updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378511728 PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1378691165 From kcr at openjdk.org Thu Nov 9 19:31:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 19:31:13 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 15:17:25 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). @jperedadnr do you want to be the second reviewer on this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1804486167 From jpereda at openjdk.org Thu Nov 9 19:37:09 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 9 Nov 2023 19:37:09 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 15:17:25 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). Yes, I'll review it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1277#issuecomment-1804502745 From kcr at openjdk.org Thu Nov 9 20:23:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 9 Nov 2023 20:23:09 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:43:24 GMT, Kevin Rushforth wrote: >> Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: >> >> 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. >> 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. >> >> As noted in the bug report, this PR solves the following problems: >> >> * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 >> * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) >> >> * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. >> >> * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. >> >> * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. >> >> This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: remove redundant `isEmbedded =` assignement I completed my testing of this patch in combination with the patch from PR [jdk#16569](https://github.com/openjdk/jdk/pull/16569). I tested all four cases: (patched / unpatched JDK) X (patched / unpatched FX) See [this PR comment](https://github.com/openjdk/jdk/pull/16569#pullrequestreview-1723423580) for details. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1804615330 From jpereda at openjdk.org Thu Nov 9 23:25:13 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 9 Nov 2023 23:25:13 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 15:17:25 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). Looks good, tested successfully before (fails) and after (passes). I've left some comments, mostly minor remarks. tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 34: > 32: import java.lang.ref.WeakReference; > 33: import java.util.ArrayList; > 34: minor, move `test.util.memory.JMemoryBuddy` here, and remove empty line: import test.util.Util; + import test.util.memory.JMemoryBuddy; + import java.lang.ref.WeakReference; + import java.util.ArrayList; import java.util.concurrent.CountDownLatch; tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 50: > 48: import static org.junit.jupiter.api.Assertions.assertEquals; > 49: > 50: import test.util.memory.JMemoryBuddy; remove tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 133: > 131: } > 132: > 133: public void createMenuBarWithItemsStage() { change to `private` tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 148: > 146: stage.show(); > 147: stage.requestFocus(); > 148: Thread t = new Thread(){ minor, use `new Thread(() -> {...});`(or else add a whitespace before the curly brace: `new Thread() {`) tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 159: > 157: menu.getItems().clear(); > 158: MenuItem menuItem = new MenuItem("MyItem"); > 159: WeakReference wr = new WeakReference<>(menuItem); Use type parameter `WeakReference wr` tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 164: > 162: }); > 163: } > 164: Platform.runLater( () -> { Why is `Platform.runLater` needed here? To wait until the last `Platform.runLater` in the for loop ends? Is it guaranteed that it will be called only after the previous one ends? Minor: remove unneeded white space: `Platform.runLater(() -> {` tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 166: > 164: Platform.runLater( () -> { > 165: int strongCount = 0; > 166: for (WeakReference wr: uncollectedMenuItems) { Use type parameter `WeakReference wr` tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 175: > 173: }; > 174: t.start(); > 175: minor: remove empty line ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1723576135 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388631396 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388631765 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388645794 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388635094 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388642837 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388636531 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388647360 PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1388639830 From john.hendrikx at gmail.com Fri Nov 10 00:18:32 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 10 Nov 2023 01:18:32 +0100 Subject: [External] : Re: Key binding customization proposal In-Reply-To: References: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> Message-ID: On 08/11/2023 21:18, Andy Goryachev wrote: > > Dear Michael: > > Thank you for specific questions! > > > "switch between vim/emacs/etc. key mappings"? Maybe you can give a specific example. > > Vim/emacs might be a bad example, as they use key sequences.? Key > sequences are not a part of this proposal (but it is possible to > implement with the help of the proposed API). > > One example is a user preference for Go-To-Line function typical in > text editors.? In jEdit on Mac it?s ?E, while in Eclipse it?s ?G.? The > user might strongly prefer to have one or the other, so an application > requirement might include redefining one or more keys.? Since it?s a > user preference, it has to be done at runtime. > That's not a function offered by text controls at all.? That's a short cut for a menu function that will pop-up a dialog asking for a line number (Ctrl + L in Eclipse). Standard behavior is everything that's standard about a control's behavior that people come to expect when using their platform of choice.? Any text field will offer defaults like: left: move cursor one character to the left control+left: move cursor one word to the left home: move cursor to start of line ctrl+home: move cursor to start of text ctrl+x/c/v: cut/copy/paste etcetera. What you are proposing here is about providing high level short-cuts which IMHO is squarely in the domain of the application developer, or some 3rd party.? FX should only care about offering ways to change the implicit standard key bindings that you use without even thinking about. Basically, if it isn't a function offered directly by the control, and handled directly by the control, then it's the application that should be handling it.? And they can handle this already by assigning such a short cut to a menu, or by installing global/local event handlers. What they CAN'T do right now is: - Disabling one of those implicit key bindings because you want to use it for something else (ie, application managed) - Remapping an implicit key binding to a different key Both of these are a rare occurence, as this would immediately cause usability issue as you'd be deviating from standard control behavior, but it may perhaps be useful in some very rare cases. This is why I think it's fine to have to do a bit more work to achieve this (ie. subclass a Behavior). > 1. The way I understand it, the only thing a public InputMap API would > enable developers to do would be to change key mappings of existing > control functionality. For example, I could re-map the left arrow to > invoke the "moveRight" function, or I could re-map ctrl+A to "copy" > text, instead of "select all" text. But why would I want to do that? > These are default mappings for a reason. Is there any example in which > such a re-mapping would potentially be useful? > > The public API should **enable** the possibility, even if the core set > of controls do not require it.? I It is not the case of whether you > want to remap ctrl-A to COPY, but a case when an application developer > has a requirement to remap something (command-E to command-G). You > even hint at such a requirement when talking about navigating camel > case words. > How are you going to configure all the intricacies here?? When should a key trigger, on PRESSED, RELEASED, on both?? What about when I hold it down for more than 0.7 seconds?? That's not something I made up, but in use in actual code: ????? long heldTime = System.currentTimeMillis() - keyPressedStartTime; ????? if (keyPressedCode == event.getCode() && heldTime >= 700) { ??????? handleLongPressKeyEvent(event); ????? } ...there are so many cases, and there is no way this can all be captured with a simple "A to B" input map. It also still ignores the fact that some of these standard keys react differently already.? Take SPACE for Button for example; it doesn't fire on PRESSED, it fires on RELEASED.? If I want it to fire immediately (so I can do key repeat on Buttons, for some game or something), I already need to write a custom function, but without the benefit of being able to access ButtonBehavior's internal state, like the "keydown" flag (which to be clear is not the same as Control.isArmed()). > 2. We seem to be talking about text a lot. Is there any specific > example beyond TextInputControl that would benefit from this feature? > Maybe this should be an extension for TIC, and not for the control > architecture as a whole? > > Some controls do not need an input map, some do.? Some controls may > not benefit from key mapping, but others do.? I focused on TIC because > that?s the area I am currently focused on, but perhaps Tree/Table view > could be another case where custom key mapping might be useful. > > 3. I have two examples that are not possible in JavaFX right now (at > last not out of the box): > ... > The proposed API doesn't enable me to implement those features, does > it? > > It does, it was specifically designed with these requirements in mind. > > For example, for > > Scroll through text on a word-by-word basis (look for: "Use CamelHump > words" > > You?d define a custom function tags for > NEXT_CAMEL_HUMP_STOP/PREVIOS_CAMEL_HUMP_STOP and implement the > functions (get caret position or selection range from the control, > computing the next/previos stop by looking at the text, and setting > the caret to the new position), and remapping the RIGHT/LEFT keys to > the new function.? If everything you need is provided to you by the > control?s public API, you don?t even have to touch the default skin or > its behavior. > I'm wondering if you tried doing this already: modify a Skin (directly in FX repository), removing one of its more complicated bindings, and reimplement it. I suspect that there is quite some internal state that is unavailable on Control that you'd need to know in order to make it feel again like it is part of the control (why else are Behaviors stateful) and so it works exactly the same as it did before. I suspect that without access to all the internals, such a custom function will feel like a hotkey, that disregards anything else that's going on in the control, and just does its thing whether that's a good idea right now or not; it won't feel as an integrated part of the control. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Fri Nov 10 00:23:02 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 10 Nov 2023 01:23:02 +0100 Subject: [External] : Re: Key binding customization proposal In-Reply-To: References: <803e97ed-7a67-939d-1d3f-f567c8fd0ba3@gmail.com> Message-ID: <00dbbc5a-2ea3-d8b8-c1e7-a3077fe76463@gmail.com> On 08/11/2023 17:23, Andy Goryachev wrote: > > Dear John: > > 1.Runtime modification of key bindings on a per control basis > > Before I reply further, where is the use case for this? > > A very good question, thank you for asking.? You might scroll back to > find it answered a couple of times during the discussion, but I think > it?s worth exploring it further. > Thanks, unfortunately I wasn't asking for potential ideas and use cases raised here -- I'm curious about the actual tickets created by FX users asking for these functionalities.? I'd like to read about them myself to see if what they're asking is not an XY problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From honkar at openjdk.org Fri Nov 10 00:39:09 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Nov 2023 00:39:09 GMT Subject: RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:43:24 GMT, Kevin Rushforth wrote: >> Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows: >> >> 1. Override the `NSApplicationDelegate` method `applicationSupportsSecureRestorableState` in `GlassApplication` and return `YES`. This silences the warning that FX applications now get on macOS 14. >> 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` with no additional functionality. This stops AWT from overwriting the NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit initialization in the case where the AWT toolkit is used from a JavaFX Application (e.g., when using SwingNode or other Swing functionality), and is necessary in order to safely do the above. It also fixes other problems that can result from the delegate being overwritten. >> >> As noted in the bug report, this PR solves the following problems: >> >> * Eliminates the "Secure coding is not enabled for restorable state" warning on macOS 14 >> * The assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) >> >> * The FX application stops getting messages when the application is hidden, deactivated, reactivated, etc. We currently don't do anything with these messages once the application is running, but we might do so in the future. >> >> * Probably related to the above, we sometimes get an odd behavior when trying to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit has been initialized. Instead of hiding the window, it pops up a finder window with a folder icon and a label that shows the version of Java. >> >> * If AWT and FX return a different answer from their delegate's `applicationSupportsSecureRestorableState` method, it will crash on macOS 13.x. >> >> This is the FX equivalent of [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo: remove redundant `isEmbedded =` assignement Fix looks good and works well with the corresponding JDK patch Tested by applying JavaFX changes + corresponding JDK patch. Testing looks good on older macOS version and macOS 14.1 GA. All combinations of patched/unpatched JDK and patched/unpatched FX along with different combinations of env vars was tested. ------------- Marked as reviewed by honkar (no project role). PR Review: https://git.openjdk.org/jfx/pull/1280#pullrequestreview-1723740084 PR Comment: https://git.openjdk.org/jfx/pull/1280#issuecomment-1804892483 From johan.vos at gluonhq.com Fri Nov 10 09:39:27 2023 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 10 Nov 2023 10:39:27 +0100 Subject: Wayland In-Reply-To: References: Message-ID: Hi Thiago, Thanks for the work on Wayland. I spent some time on it in the past as well, and I'll hope to find some time to look at your work soon. The main worry I had in the past was how to deal with the robot, where we need to get pixels from the screen -- did you tackle that? - Johan On Fri, Nov 3, 2023 at 1:14?AM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi, > > About Wayland: > > Porting es2 to use EGL instead of GLX is pretty straightforward, so > converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why > EGL is needed). > The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint > directly to the window as es2 do. > I've tried to use Gtk4 and composite it with a GL texture - it would work, > but does't fit well with es2 as it is designed to swapBuffers. > > I'm looking for the shortest path to get it working. > > I'm thinking now to use wayland-client directly for most things, so it > will be possible to create the WaylandGL* infrastructure and render > directly to a surface. > Compositing directly with wayland would be better anyways. Using Gtk (3 or > 4) would require rendering somewhere else (other than onscreen wayland > surface) and then composite the result with Gtk. > > So, the conclusion for now is that Gtk won't work with wayland for the use > of another toolkit (outside of the gtk rendering scope). > > wayland-client, here I go. > > -- Thiago. > > > > > > > > > > Em s?b., 21 de out. de 2023 ?s 18:12, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> EGL is the way to go for Linux on Wayland and X11. >> >> I don't know how to do it yet, but it seems the solution is to use DMABUF >> with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not >> sure yet). >> >> Firefox and WebKit GTK uses the same technic. >> >> Gtk4 does not allow application painting, so direct surface context is >> not possible. >> >> We are using gtk3 and it is still possible, but I want to use >> GtkHeaderbar and clean up glass code. Since it means sharing the >> window/surface with GTK, direct surface rendering also doesn't work. >> >> >> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/ >> >> >> https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/ >> >> https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/ >> >> It's been nice to learn. >> >> Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> escreveu: >> >>> Hi, >>> >>> I am investigating about prism on Wayland. >>> >>> It looks like we could just replace the GLX calls on X11 backend to EGL >>> and it will work on both (maybe rename it). >>> >>> It will need some work to pass the native display around - it assumes >>> X11 Display everywhere and it could be a Display or a wl_display. >>> >>> -- Thiago. >>> >>> Em dom., 15 de out. de 2023 ?s 16:06, Thiago Milczarek Say?o < >>> thiago.sayao at gmail.com> escreveu: >>> >>>> Hi, >>>> >>>> Update: It now works on wayland with -Dprism.order=sw >>>> >>>> >>>> >>>> Em dom., 15 de out. de 2023 ?s 10:49, Thiago Milczarek Say?o < >>>> thiago.sayao at gmail.com> escreveu: >>>> >>>>> Hi, >>>>> >>>>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland >>>>> >>>>> I did some experiments here. So far, so good. >>>>> >>>>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer >>>>> gtk. >>>>> 2) Replaced drawing directly in the window and added a GtkDrawingArea >>>>> with a GtkHeaderBar which allows control over the whole window >>>>> size and allows to get rid of extents* calls - this cleans up a lot. >>>>> 3) Unified the WindowContext to clean it up. >>>>> >>>>> I also integrated the IME replacement proposed here: >>>>> https://github.com/openjdk/jfx/pull/1080 >>>>> >>>>> It almost runs with software rendering on Wayland, but something still >>>>> touches X11. >>>>> >>>>> To finally make it work on Wayland it requires to implement it on >>>>> prism es2. I see that there's a EGL part of Monocle. I still don't >>>>> completely understand it, but wouldn't it work as a drop-in replacement? >>>>> >>>>> -- Thiago. >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Fri Nov 10 10:01:14 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 10 Nov 2023 10:01:14 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 22:09:30 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 164: > >> 162: }); >> 163: } >> 164: Platform.runLater( () -> { > > Why is `Platform.runLater` needed here? To wait until the last `Platform.runLater` in the for loop ends? Is it guaranteed that it will be called only after the previous one ends? > > Minor: remove unneeded white space: `Platform.runLater(() -> {` No, it is needed because we want to give the JavaFX platform the opportunity to do "whatever is needed" after the last runLater() is done. Hence, we put what we want to do on the Runnable queue of the FX thread, so that we don't depend on internals. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1389184538 From jvos at openjdk.org Fri Nov 10 10:09:15 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 10 Nov 2023 10:09:15 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 22:07:34 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Use only 10 cycles instead of 50 (preventing this test to take 50 seconds in case it fails). > > tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 148: > >> 146: stage.show(); >> 147: stage.requestFocus(); >> 148: Thread t = new Thread(){ > > minor, use `new Thread(() -> {...});`(or else add a whitespace before the curly brace: `new Thread() {`) I'll go with the whitespace then, as I find it much more clear to explicitly construct, assign, and start a thread. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1389194261 From jpereda at openjdk.org Fri Nov 10 10:20:23 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 10 Nov 2023 10:20:23 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v7] In-Reply-To: <6ox9sEJ0nRCNO3jxe4S0s09kXbFq1Y8EL01e1JcVENE=.fe3c0b7e-e4a3-493a-bb61-a172c4699a54@github.com> References: <6ox9sEJ0nRCNO3jxe4S0s09kXbFq1Y8EL01e1JcVENE=.fe3c0b7e-e4a3-493a-bb61-a172c4699a54@github.com> Message-ID: On Fri, 10 Nov 2023 10:17:18 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > formatting Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1724472898 From jvos at openjdk.org Fri Nov 10 10:20:23 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 10 Nov 2023 10:20:23 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v7] In-Reply-To: References: Message-ID: <6ox9sEJ0nRCNO3jxe4S0s09kXbFq1Y8EL01e1JcVENE=.fe3c0b7e-e4a3-493a-bb61-a172c4699a54@github.com> > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1277/files - new: https://git.openjdk.org/jfx/pull/1277/files/cbe5ea46..2d4ac874 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1277&range=05-06 Stats: 9 lines in 1 file changed: 1 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1277.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1277/head:pull/1277 PR: https://git.openjdk.org/jfx/pull/1277 From jvos at openjdk.org Fri Nov 10 10:38:18 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 10 Nov 2023 10:38:18 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed Message-ID: A listener was added but never removed. This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 ------------- Commit messages: - A listener was added but never removed. Changes: https://git.openjdk.org/jfx/pull/1283/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319779 Stats: 61 lines in 1 file changed: 40 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jhendrikx at openjdk.org Fri Nov 10 12:42:11 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 10 Nov 2023 12:42:11 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 10:34:08 GMT, Johan Vos wrote: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Should there be an updated test for this? I see a lot of raw type use (`ListChangeListener`, `ObservableList`), any chance those can be avoided? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 63: > 61: private MenuBar glassSystemMenuBar = null; > 62: private final Map menuListeners = new HashMap<>(); > 63: private final Map listenerItems = new HashMap<>(); minor: Suggestion: private final Map menuListeners = new HashMap<>(); private final Map listenerItems = new HashMap<>(); modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 171: > 169: if (item instanceof MenuBase) { > 170: // submenu > 171: addMenu(glassMenu, (MenuBase)item); Suggestion: if (item instanceof MenuBase baseItem) { // submenu addMenu(glassMenu, baseItem); modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java line 189: > 187: > 188: private ListChangeListener createListener(final Menu glassMenu) { > 189: ListChangeListener answer = ((ListChangeListener.Change change) -> { minor: I see extra parenthesis around the whole, and I think you can just `return` this immediately (no need for `answer` local) ------------- PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-1724683737 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1389343964 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1389338458 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1389340165 From thiago.sayao at gmail.com Fri Nov 10 12:43:53 2023 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 10 Nov 2023 09:43:53 -0300 Subject: Wayland In-Reply-To: References: Message-ID: Hi Johan, Robot will be a challenge. For mouse and keyboard simulation this could work: https://www.kernel.org/doc/html/v4.12/input/uinput.html of maybe: https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.RemoteDesktop For screenshot: https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Screenshot Haven't tested anything yet. I did some experiments on the jfx-sandbox (it displays the window on wayland with software rendering), but the conclusion so far is that it's better to ditch gtk and use wayland-client directly, except for system dialogs such as file open. -- Thiago. Em sex., 10 de nov. de 2023 ?s 06:39, Johan Vos escreveu: > Hi Thiago, > > Thanks for the work on Wayland. I spent some time on it in the past as > well, and I'll hope to find some time to look at your work soon. > > The main worry I had in the past was how to deal with the robot, where we > need to get pixels from the screen -- did you tackle that? > > - Johan > > On Fri, Nov 3, 2023 at 1:14?AM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > >> Hi, >> >> About Wayland: >> >> Porting es2 to use EGL instead of GLX is pretty straightforward, so >> converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why >> EGL is needed). >> The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint >> directly to the window as es2 do. >> I've tried to use Gtk4 and composite it with a GL texture - it would >> work, but does't fit well with es2 as it is designed to swapBuffers. >> >> I'm looking for the shortest path to get it working. >> >> I'm thinking now to use wayland-client directly for most things, so it >> will be possible to create the WaylandGL* infrastructure and render >> directly to a surface. >> Compositing directly with wayland would be better anyways. Using Gtk (3 >> or 4) would require rendering somewhere else (other than onscreen wayland >> surface) and then composite the result with Gtk. >> >> So, the conclusion for now is that Gtk won't work with wayland for the >> use of another toolkit (outside of the gtk rendering scope). >> >> wayland-client, here I go. >> >> -- Thiago. >> >> >> >> >> >> >> >> >> >> Em s?b., 21 de out. de 2023 ?s 18:12, Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> escreveu: >> >>> EGL is the way to go for Linux on Wayland and X11. >>> >>> I don't know how to do it yet, but it seems the solution is to use >>> DMABUF with EGL and share it with GTK (I suspect on a GtkGLArea widget, but >>> not sure yet). >>> >>> Firefox and WebKit GTK uses the same technic. >>> >>> Gtk4 does not allow application painting, so direct surface context is >>> not possible. >>> >>> We are using gtk3 and it is still possible, but I want to use >>> GtkHeaderbar and clean up glass code. Since it means sharing the >>> window/surface with GTK, direct surface rendering also doesn't work. >>> >>> >>> https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/ >>> >>> >>> https://blogs.igalia.com/carlosgc/2023/04/03/webkitgtk-accelerated-compositing-rendering/ >>> >>> https://blog.gtk.org/2021/05/10/adventures-in-graphics-apis/ >>> >>> It's been nice to learn. >>> >>> Em seg., 16 de out. de 2023 20:51, Thiago Milczarek Say?o < >>> thiago.sayao at gmail.com> escreveu: >>> >>>> Hi, >>>> >>>> I am investigating about prism on Wayland. >>>> >>>> It looks like we could just replace the GLX calls on X11 backend to EGL >>>> and it will work on both (maybe rename it). >>>> >>>> It will need some work to pass the native display around - it assumes >>>> X11 Display everywhere and it could be a Display or a wl_display. >>>> >>>> -- Thiago. >>>> >>>> Em dom., 15 de out. de 2023 ?s 16:06, Thiago Milczarek Say?o < >>>> thiago.sayao at gmail.com> escreveu: >>>> >>>>> Hi, >>>>> >>>>> Update: It now works on wayland with -Dprism.order=sw >>>>> >>>>> >>>>> >>>>> Em dom., 15 de out. de 2023 ?s 10:49, Thiago Milczarek Say?o < >>>>> thiago.sayao at gmail.com> escreveu: >>>>> >>>>>> Hi, >>>>>> >>>>>> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland >>>>>> >>>>>> I did some experiments here. So far, so good. >>>>>> >>>>>> 1) Replaced GDK events for Gtk Signals - It's the way to go for newer >>>>>> gtk. >>>>>> 2) Replaced drawing directly in the window and added a GtkDrawingArea >>>>>> with a GtkHeaderBar which allows control over the whole window >>>>>> size and allows to get rid of extents* calls - this cleans up a lot. >>>>>> 3) Unified the WindowContext to clean it up. >>>>>> >>>>>> I also integrated the IME replacement proposed here: >>>>>> https://github.com/openjdk/jfx/pull/1080 >>>>>> >>>>>> It almost runs with software rendering on Wayland, but something >>>>>> still touches X11. >>>>>> >>>>>> To finally make it work on Wayland it requires to implement it on >>>>>> prism es2. I see that there's a EGL part of Monocle. I still don't >>>>>> completely understand it, but wouldn't it work as a drop-in replacement? >>>>>> >>>>>> -- Thiago. >>>>>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Nov 10 13:59:13 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Nov 2023 13:59:13 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v7] In-Reply-To: <6ox9sEJ0nRCNO3jxe4S0s09kXbFq1Y8EL01e1JcVENE=.fe3c0b7e-e4a3-493a-bb61-a172c4699a54@github.com> References: <6ox9sEJ0nRCNO3jxe4S0s09kXbFq1Y8EL01e1JcVENE=.fe3c0b7e-e4a3-493a-bb61-a172c4699a54@github.com> Message-ID: <3CKnqs_8e_S6yT7utAa7wey9Y6KX43WQNIkn-gGvMW0=.c6755c30-2375-4d25-b6a1-38b9b97b1233@github.com> On Fri, 10 Nov 2023 10:20:23 GMT, Johan Vos wrote: >> When the Java layer removes a systemmenu, release the native resources related to this systemmenu. >> This removes the strong JNI Global ref, which prevents its references from being gc'ed. >> >> The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. >> With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). >> The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > formatting Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1277#pullrequestreview-1724829012 From kcr at openjdk.org Fri Nov 10 13:59:14 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Nov 2023 13:59:14 GMT Subject: RFR: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used [v6] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:58:21 GMT, Johan Vos wrote: >> tests/system/src/test/java/test/javafx/stage/SystemMenuBarTest.java line 164: >> >>> 162: }); >>> 163: } >>> 164: Platform.runLater( () -> { >> >> Why is `Platform.runLater` needed here? To wait until the last `Platform.runLater` in the for loop ends? Is it guaranteed that it will be called only after the previous one ends? >> >> Minor: remove unneeded white space: `Platform.runLater(() -> {` > > No, it is needed because we want to give the JavaFX platform the opportunity to do "whatever is needed" after the last runLater() is done. Hence, we put what we want to do on the Runnable queue of the FX thread, so that we don't depend on internals. This makes sense. To answer one of Jose's questions: > Is it guaranteed that it will be called only after the previous one ends? Yes, this is specified behavior of `Platform::runLater`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1277#discussion_r1389427353 From kcr at openjdk.org Fri Nov 10 14:02:12 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 10 Nov 2023 14:02:12 GMT Subject: RFR: 8303826: Add FX test for JDK-8252255 In-Reply-To: <5bKU4fKgUfZU9OULysZN7KgNiTLrEfrFVtVqcEBcg_c=.3b67e420-6426-4982-bb55-c8c03342aed6@github.com> References: <5bKU4fKgUfZU9OULysZN7KgNiTLrEfrFVtVqcEBcg_c=.3b67e420-6426-4982-bb55-c8c03342aed6@github.com> Message-ID: On Thu, 9 Nov 2023 03:43:48 GMT, Prasanta Sadhukhan wrote: > Manual regression test for 8252255: Blurry rendering of SwingNode with HiDPI scaling in JavaFX is added I think this test only needs a single reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1282#issuecomment-1805779453 From jvos at openjdk.org Fri Nov 10 14:24:12 2023 From: jvos at openjdk.org (Johan Vos) Date: Fri, 10 Nov 2023 14:24:12 GMT Subject: Integrated: 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:39:47 GMT, Johan Vos wrote: > When the Java layer removes a systemmenu, release the native resources related to this systemmenu. > This removes the strong JNI Global ref, which prevents its references from being gc'ed. > > The current implementation for the mac-specific system menu creates a menu, but never releases its resources. In the `dealloc` of this menu, the strong jni refs are deleted. > With this PR, we now release the native resources associated with a menuItem when that one is removed from a menu. A consequence is that this menuItem should never be used after being removed from its current menu (e.g. it should not be re-added, or its text/shortcut should not be altered). > The current implementation will create a new MacMenuDelegate every time a menuItem is inserted into a menu, so there should be no references to the native resources lingering. This pull request has now been integrated. Changeset: 8dd3c37c Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/8dd3c37cae3dd52dc3a258033d0e8f168ceaf307 Stats: 80 lines in 4 files changed: 80 ins; 0 del; 0 mod 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used Reviewed-by: kcr, jpereda ------------- PR: https://git.openjdk.org/jfx/pull/1277 From nlisker at openjdk.org Fri Nov 10 15:27:12 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 10 Nov 2023 15:27:12 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture In-Reply-To: References: Message-ID: <6xKLzZARce0g3rRgAeOD-4IqxTsFi0CRl5zRqGjbyeA=.e3cfc498-8cd8-4aee-9301-a3238e5867f7@github.com> On Thu, 9 Nov 2023 03:16:51 GMT, Michael Strau? wrote: >> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. >> >> Summary of the changes: >> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. >> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. >> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. >> >> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/TextureData.java line 12: > >> 10: */ >> 11: // Here we can support mipmaps, wrapping modes (which exists internally and can be pulled out), addressing modes etc. >> 12: public class TextureData { > > 1. This type could be a record. > 2. There's no actual texture data (i.e. pixels) here, maybe a better name would be `SamplerParameters` or something like that. 1. Not when it will be promoted to public API. Adding record components breaks backwards compatibility, so making this a record will not allow adding more configuration later on. What might be possible is making it an interface and using a record as an implementation. 2. I think that this class can go beyond sampler configurations. For example, wrapping is a render state, not a sampler state. Maybe something more general like "TextureParameters" can work. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1389539073 From nlisker at openjdk.org Fri Nov 10 15:52:16 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 10 Nov 2023 15:52:16 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture In-Reply-To: References: Message-ID: <8VAeWvY-jJXBshXuVyldP8zWhTB7fsZlcuY6y9EIkVk=.a842f065-bbeb-4053-b25f-8859c4ca0636@github.com> On Thu, 9 Nov 2023 03:15:27 GMT, Michael Strau? wrote: >> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. >> >> Summary of the changes: >> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. >> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. >> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. >> >> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. > > modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 295: > >> 293: for (int i = 0; i < map_type::num_map_types; i++) { >> 294: map_type type = static_cast(i); >> 295: SUCCEEDED(device->SetTexture(type, material->getMap(type))); > > Wrapping the calls with the `SUCCEEDED` macro doesn't do anything useful. Yes, but it's done everywhere else in the class, and was done for these calls before I changed this code. Maybe a better error handling design is needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1389570725 From duke at openjdk.org Fri Nov 10 16:43:23 2023 From: duke at openjdk.org (brunesto) Date: Fri, 10 Nov 2023 16:43:23 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v2] In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: > The fix prevents the DatePicker from losing focus if the date is not parsable. brunesto has updated the pull request incrementally with one additional commit since the last revision: replaced robot test by plain junit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1274/files - new: https://git.openjdk.org/jfx/pull/1274/files/43c0f940..7e2361a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=00-01 Stats: 244 lines in 2 files changed: 30 ins; 214 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1274.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1274/head:pull/1274 PR: https://git.openjdk.org/jfx/pull/1274 From duke at openjdk.org Fri Nov 10 16:46:10 2023 From: duke at openjdk.org (brunesto) Date: Fri, 10 Nov 2023 16:46:10 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v2] In-Reply-To: References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: <67ThwFItSMYOcCNmz8i3IGgbAiBoyB5QeaaoFbANysY=.bf72d3d5-e9fc-46c4-8400-ff03d2f30371@github.com> On Thu, 2 Nov 2023 11:55:46 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/DatePickerOnFocusLostTest.java line 98: >> >>> 96: // 3. Click on button to grab the focus and hence attempt to datePicker.commitValue() >>> 97: // 4. Verify that in case of typo, the value was reverted, as well as the editor's text >>> 98: public void testDatePickerCommit(boolean typo) throws Exception { >> >> you actually can also write a normal JUnit test as far as I get this. Then there is no need for `Util.runAndWait`, `sleep` and so on. >> >> See: `test.javafx.scene.control.DatePickerTest` > > A headless test is the preferred way to do it, if feasible. If it is, move the test to the `javafx.controls` module. I have removed the robot test, and replaced it by a simple test case in the existing class `DatePickerTest` in `javafx.controls` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1389638701 From duke at openjdk.org Fri Nov 10 16:51:22 2023 From: duke at openjdk.org (brunesto) Date: Fri, 10 Nov 2023 16:51:22 GMT Subject: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v3] In-Reply-To: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> References: <-xFvaNo-U1WITTQzW-qwWa5Oj80rNpF6ZtZ6ISAOD2c=.527bd7fd-56a0-4150-8d09-a07f406c39af@github.com> Message-ID: > The fix prevents the DatePicker from losing focus if the date is not parsable. brunesto has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1274/files - new: https://git.openjdk.org/jfx/pull/1274/files/7e2361a5..decc7226 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1274.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1274/head:pull/1274 PR: https://git.openjdk.org/jfx/pull/1274 From mstrauss at openjdk.org Fri Nov 10 21:23:54 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 10 Nov 2023 21:23:54 GMT Subject: RFR: 8301302: Platform preferences API [v23] In-Reply-To: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> Message-ID: > Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Rename Appearance to ColorScheme ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1014/files - new: https://git.openjdk.org/jfx/pull/1014/files/d012dec9..9b607c6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=22 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1014&range=21-22 Stats: 121 lines in 6 files changed: 45 ins; 44 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1014.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/jfx/pull/1014 From nlisker at openjdk.org Fri Nov 10 23:36:06 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 10 Nov 2023 23:36:06 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 02:44:44 GMT, Michael Strau? wrote: >> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. >> >> Summary of the changes: >> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. >> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. >> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. >> >> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. > > modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.h line 41: > >> 39: self_illumination, >> 40: num_map_types >> 41: }; > > 1. Types generally seem to use PascalCase in this library, and constants UPPER_CASE or CamelCase. > 2. You can use `enum class` to prevent the constants from polluting the global namespace. > 3. The underlying type doesn't need to be specified, it's `int` by default. You're casting it to `int` in `D3DMeshView.cc` anyway. About 2, I tried that initially and got into problems iterating over the enum in `D3DMeshView.cc` line 293. How would you perform the iteration? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1390020946 From nlisker at openjdk.org Fri Nov 10 23:39:21 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 10 Nov 2023 23:39:21 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: Message-ID: > Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API. > > Summary of the changes: > * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later. > * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty` properties. > * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily. > > The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1281/files - new: https://git.openjdk.org/jfx/pull/1281/files/34e1d1ab..bd3c9204 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1281&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1281&range=00-01 Stats: 37 lines in 4 files changed: 3 ins; 5 del; 29 mod Patch: https://git.openjdk.org/jfx/pull/1281.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1281/head:pull/1281 PR: https://git.openjdk.org/jfx/pull/1281 From duke at openjdk.org Sat Nov 11 08:39:13 2023 From: duke at openjdk.org (leewyatt) Date: Sat, 11 Nov 2023 08:39:13 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v10] In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 10:46:43 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Make it a default method for compatibility > > Should I wait for feedback if it's working properly before doing the CSR? > > I think it would be better to first stabilize it and see what need changes. Hi @tsayao , I have been closely following the development of this PR, which addresses the crucial JDK-8305418 issue for non-English input methods in JavaFX on Linux systems. The significance of this work for the global JavaFX user community cannot be overstated. I would like to extend my sincere thanks to not only you, @tsayao , for your outstanding work but also to the Reviewers who are contributing their valuable time and expertise to refine and perfect this PR. Your collective efforts are greatly appreciated, and I eagerly await the completion and integration of this PR. It's initiatives like these that truly enhance the functionality and inclusivity of open-source projects. Best regards, Lee Wyatt ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1806751133 From john.hendrikx at gmail.com Mon Nov 13 00:12:46 2023 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 13 Nov 2023 01:12:46 +0100 Subject: Public Behavior API proposal In-Reply-To: References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: Hi everyone, and specifically Andy and Michael, I'm working on updating the Behavior API proposal, and I've been thinking about the semantic events a lot.? I would really like to hear what you think, and how it matches with your ideas. Quick recap, Semantic Events are high level events (like the ActionEvent from Button) that can be triggered by a combination of low level events. They represent an action to be achieved, but are not tied to any specific means of triggering it.? For example, the ActionEvent can be triggered with the mouse, or with the keyboard; it is irrelevant which one it was.? Semantic events can be generated by Skins (as a result of interactions with the Skin's managed children), by Controls (see below) and users directly. You can compare these with Andy's FunctionTags or Actions from various systems. Let me describe exactly each part's role as I see it currently: # Controls Controls define semantic events, provides infrastructure for handling events that is separated from internal needs (user comes first). User installed event handlers always have priority to make the user feel in control. The Control also provides for another new infrastructure, the managing of key mappings.? The mapping system can respond directly to Key events (after the user had their chance) to generate a semantic event.? This means that both Control and Skin are allowed to generate semantic events, although for Control this is strictly limited to the mapping system.? The key mappings are only overrideable, and their base configuration is provided by whatever Behavior is installed.? Exchanging the Behavior does not undo user key mapping overrides, but instead provides a new base line upon which the overrides are applied.? So if a Behavior provides a mapping for SPACE, and the user removed it, installing a different behavior that also provides a mapping for SPACE will still see that mapping as removed.? If a behavior doesn't define SPACE, and the user removed it, then nothing special happens (but it is remembered). - Controls refer to a Skin and Behavior - Controls define semantic events - Controls can generate semantic events (via mappings) - Controls never modify their own (user writable) state on their own accord (the user is in full control) - Controls provide an override based key mapping system # Skins Skins provide the visuals, and although they get a Control reference, they are restricted to only adding property listeners (not event handlers) and modifying the children list (which is read only for users as Control extends from Region).? This keeps the user fully in control when it comes to any writable properties and events on Control.? Most Skins already do this as I think it was an unwritten rule from the beginning.? Skins then install event handlers on their children (but never the top level Control) where translation takes place to semantic events.? Skins have no reference to the Behavior to ensure that all communication has to go through (interceptable) semantic events.? Not all events a Skin receives must be translated; if some events only result in the Skin's internal state changing, and does not need to be reflected in the Control's state then Skins can handle these directly without going through a Behavior.? Examples might be the position of the caret, or the exact scroll location of a View, if such things aren't part of the Control state. - Skins refer to a Control (legacy inheritance) but are limited in their allowed interactions (unwritten rule since the beginning) ? - Better would be to provide skins with only a Context object that only allows installing of listeners to ensure they can't do nasty things (and to track all changes a Skin did for when it is replaced, similar idea to BehaviorContext) - Skins interprete normal events of their CHILDREN only (after the user did not consume them), and either: ?? - Translates them to semantic events (targetted at the top level Control) ?? - Acts upon them directly if only Skin internal state is involved - Skins never act upon semantic events # Behaviors Behaviors provide a standard set of key mappings, and provide standard ways of dealing with semantic events.? Installing a new Behavior on a control can make it "feel" completely different, from how it reacts to keys, and which keys, how it deals with the high level semantic events, as well as how it handles mouse interactions.? Behaviors can act upon both normal and semantic events, but don't generate any events themselves.? Again, they only act upon events after the user had a chance to act upon them first. A behavior is free to act upon Key events directly (for things too complicated for a simple key mapping), but it would be better to indirect them as much as possible via a semantic event that is triggered by a key mapping in the Control.? Mouse events are more complicated and don't need to be indirected to be handled (not 100% sure here yet).?? When receiving a semantic event that the user didn't care about, the Behavior consumes it and does its thing by calling methods on the Control and modifying control state. - Behaviors refer to nothing ?? - Control reference is received via event handler and listeners only - Behaviors define base key mappings ?? - Controls refer to these, after first checking for any user overrides ?? - Base key mappings can be global and immutable, user overrides (maintained in Control) are mutable - Behaviors never generate events - Behaviors can act upon events of any type (if unconsumed by the user) that are targetted at the control (enforced as that's the only place they can install handlers) - Behaviors are allowed to modify control state and their own state # Interaction with Andy's proposal I think the above works pretty nicely together with Andy's proposal.? By moving the responsibility managing the key mappings to Control, but leaving the responsibility of defining the mappings with Behaviors, I see a nice path forward to opening up a key mapping system for simple overrides, as well as having a public Behavior API for more advanced behaviorial modifications. Notice that I didn't provide for a FunctionTag remapping system; as these would be semantic events in this proposal, they can be filtered/handled before the Behavior gets them.? So to change a function, just consume it and fire a different one.? To completely block it, just consume it.? To replace a single function with two functions, consume it and fire two new ones, etc.? So to globally swap the increment/decrement functions of all Spinners, at the Scene level you could have a handler do this. To also answer Andy's 10 questions: Q1. Changing an existing key binding from one key combination to another. -> Control provides a small API to override base mappings (remap) Q2. Remapping an existing key binding to a different function. -> Control provides a small API to override base mappings, including to which semantic event they translate Q3. Unmapping an existing key binding. -> Control provides a small API to override base mappings (disable) Q4. Adding a new key binding mapped to a new function. -> Still debatable if this should be provided, but I don't see much blockers for this; someone will have to interpret the new function though; this could be a user event handler that knows the event (which can be a custom one) or a customized Behavior. Q5. (Q1...Q4) scenarios, at run time. -> All possible at runtime.? With a "-fx-behavior" CSS feature, this could also be provided via CSS selectors, allowing far reaching changes without having to modify each control individually. Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added. -> Behaviors act only upon events targetted at the Control. Skins that don't provide some events means they will just not be picked up by Behaviors.? Skins that provide unknown semantic events require a corresponding Behavior upgrade.? Skins actions that don't require Control state changes (only Skin state changes) can ignore this system altogether. Q7. Once the key binding has been modified, is it possible to invoke the default functionality? -> Yes, just fire the appropriate semantic event at the Control Q8. How are the platform-specific key bindings created? -> Debatable if this is needed, but probably something similar to your proposal will be possible; Platforms don't change at runtime, so why they are even added as bindings (instead of just skip adding them if not on the right platform) is a mystery to me.? A simple tool (perhaps on the Platform class) to check the platform should be sufficient; no need to interweave this with key mappings themselves. Q9. How are the skin-specific (see Q6) handlers removed when changing the skins? -> Skins clean up after themselves, and they're not allowed to install handlers on the control (only on their children) Q10. When a key press happens, does it cause a linear search through listeners or just a map lookup? -> No, Controls have freedom to optimize how they do this; Behaviors provide base mappings in some kind of Map form, or have an API to quickly look up a base mapping (probably the latter to encapsulate it better). Thanks for reading, --John On 07/11/2023 08:09, Michael Strau? wrote: > Hi John, > > I like that you clearly define the terms Control, Skin and Behavior, > as well as their roles within the control architecture. > > However, I don't see how your proposal scales to non-trivial controls, > and I agree with Andy that the Button example doesn't help (because a > Button lacks substructure and provides only a single interaction). > > I'm missing your previous idea of using the event system for > higher-level semantic events, because I think they're required to make > this work. Here's how I see these parts working together: > > 1) A control is an opaque node in the scene graph, which defines the > API for a particular interactive element. It also defines the > interactions afforded by its implementation. For example, a Spinner > will usually consist of a text field and two buttons, but a skin might > choose to implement these components differently. The interactions > afforded by a control are exposed as semantic events: > > class SpinnerEvent extends Event { > static EventType COMMIT_TEXT; > static EventType START_INCREMENT; > static EventType STOP_INCREMENT; > static EventType START_DECREMENT; > static EventType STOP_DECREMENT; > } > > 2) Skins are responsible for generating semantic events, and sending > those events to the control. Since we don't need those events to have > a tunneling/bubbling behavior, we could have a flag on the event that > indicates a "direct event", one that is dispatched directly to its > target. > > 3) Behaviors listen for semantic events on the control, and convert > these events into state changes of the control. This part would > probably be quite similar to some of the things that have already been > proposed. > > In this way, controls, skins, and behaviors would end up as loosely > coupled parts. In particular, I don't see the value in making > behaviors public API if they are so tightly coupled to skins that they > end up as being basically implementation details. > > Andy: >> Imagine a specific skin that has a Node that accepts a user input. A scroll bar, a button, or a region with a some function. Unless this element is proclaimed as must-have for any skin and codified via some new public API (MySkin.getSomeElement()), it is specific to that particular skin and that particular behavior. > I think that's a very important observation. A skin can't just be > anything it wants to be, it must be suitable for its control. So we > need a place where we define the API and the interactions afforded by > that control. In my opinion, this place is the Control. Its > functionality is exposed via properties and methods, and its > interactions are specified using semantic events. > > Now skins are free to be implemented in any imaginable way, provided > that they interact with the control using semantic events. This gives > us very straightforward restrictions: > * A skin can never add interactions that the control didn't specify. > * If additional interactions are required, the control must be > subclassed and the interactions must be specified by the control. > Additionally, the behavior must be extended to account for the > additional interactions. > > > > > On Mon, Nov 6, 2023 at 4:50?AM John Hendrikx wrote: >> As promised, a public Behavior API proposal. >> >> Summary: >> >> Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. >> >> See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 >> >> --John From mstrauss at openjdk.org Mon Nov 13 01:26:07 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 13 Nov 2023 01:26:07 GMT Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 23:33:12 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.h line 41: >> >>> 39: self_illumination, >>> 40: num_map_types >>> 41: }; >> >> 1. Types generally seem to use PascalCase in this library, and constants UPPER_CASE or CamelCase. >> 2. You can use `enum class` to prevent the constants from polluting the global namespace. >> 3. The underlying type doesn't need to be specified, it's `int` by default. You're casting it to `int` in `D3DMeshView.cc` anyway. > > About 2, I tried that initially and got into problems iterating over the enum in `D3DMeshView.cc` line 293. How would you perform the iteration? You're right, there's no implicit conversion from scoped enums to integers. While one could get very creative with C++, maybe just using an unscoped enum is easier. You might want to prefix the constants with `MT_` or something like that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1390543995 From michaelstrau2 at gmail.com Mon Nov 13 06:14:07 2023 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 13 Nov 2023 07:14:07 +0100 Subject: Public Behavior API proposal In-Reply-To: References: <0b5a8446-5d43-d364-1edb-f6b7affc2d2d@gmail.com> Message-ID: Hi John, I think this is an excellent summary of all the discussions so far, and the best proposal I've seen for a comprehensive control architecture capable of addressing many shortcomings of the existing controls. Here are some thoughts: 1. Semantic events == Interaction API Previously, skins were a black box with close to no extensibility. Re-implementing skins is often a no-starter because you'll instantly lose all of the intricate behaviors that are invisibly built into the skins. Semantic events are a game changer, as they clearly define the API of a skin, i.e. the kind of interactions that a well-behaved skin will support. A custom skin doesn't need to recreate the entirety of its control behavior from scratch, it should be enough to implement the interaction API defined by its control's semantic events. If you consider ActionEvent (which *is* a semantic event), it seems obvious to me that more semantic events are a natural evolution of JavaFX. 2. Clear separation of concerns All parts in the control architecture now have a clearly defined purpose. Some of the restrictions that come with each of the parts could be enforced by API, others might need to be explained in documentation. The roles and responsibilities of each part of the control architecture are easy to understand with a small set of rules (what's allowed and what's not allowed). 3. Behaviors I'm not sold on the Behavior design as proposed in the GitHub document, specifically the idea of BehaviorContext and using composition to extend existing behaviors. The API feels rather clunky, and maybe unnecessary. Perhaps mirroring the Skin design (i.e. an interface that gets a Control reference) can narrow down the API surface. Note that, like with skins, this doesn't mean that a behavior should do things it isn't supposed to be doing. It should be easy to override aspects of behavior (as you put it, the "illusion" that user code is the only code), and it is not entirely clear if this requires an enhancement of the JavaFX event system. 4. InputMap proposal All things considered, I don't think that the current InputMap proposal carries its weight in terms of complexity and API surface. Doing InputMap first and in its current state might foreclose on our ability to revamp the control architecture to be more flexible and extensible. I do think that InputMap would benefit from having a new control architecture in place, and being more tailored towards controls that really need it (as discussed before, not all controls will benefit from InputMap). 5. Migration compatibility In order to have any chance of gaining traction, we need a story how this proposal can support gradual migration without breaking compatibility with existing controls. On Mon, Nov 13, 2023 at 1:12?AM John Hendrikx wrote: > > Hi everyone, and specifically Andy and Michael, > > I'm working on updating the Behavior API proposal, and I've been > thinking about the semantic events a lot. I would really like to hear > what you think, and how it matches with your ideas. > > Quick recap, Semantic Events are high level events (like the ActionEvent > from Button) that can be triggered by a combination of low level events. > They represent an action to be achieved, but are not tied to any > specific means of triggering it. For example, the ActionEvent can be > triggered with the mouse, or with the keyboard; it is irrelevant which > one it was. Semantic events can be generated by Skins (as a result of > interactions with the Skin's managed children), by Controls (see below) > and users directly. You can compare these with Andy's FunctionTags or > Actions from various systems. > > Let me describe exactly each part's role as I see it currently: > > # Controls > > Controls define semantic events, provides infrastructure for handling > events that is separated from internal needs (user comes first). User > installed event handlers always have priority to make the user feel in > control. The Control also provides for another new infrastructure, the > managing of key mappings. The mapping system can respond directly to > Key events (after the user had their chance) to generate a semantic > event. This means that both Control and Skin are allowed to generate > semantic events, although for Control this is strictly limited to the > mapping system. The key mappings are only overrideable, and their base > configuration is provided by whatever Behavior is installed. Exchanging > the Behavior does not undo user key mapping overrides, but instead > provides a new base line upon which the overrides are applied. So if a > Behavior provides a mapping for SPACE, and the user removed it, > installing a different behavior that also provides a mapping for SPACE > will still see that mapping as removed. If a behavior doesn't define > SPACE, and the user removed it, then nothing special happens (but it is > remembered). > > - Controls refer to a Skin and Behavior > - Controls define semantic events > - Controls can generate semantic events (via mappings) > - Controls never modify their own (user writable) state on their own > accord (the user is in full control) > - Controls provide an override based key mapping system > > # Skins > > Skins provide the visuals, and although they get a Control reference, > they are restricted to only adding property listeners (not event > handlers) and modifying the children list (which is read only for users > as Control extends from Region). This keeps the user fully in control > when it comes to any writable properties and events on Control. Most > Skins already do this as I think it was an unwritten rule from the > beginning. Skins then install event handlers on their children (but > never the top level Control) where translation takes place to semantic > events. Skins have no reference to the Behavior to ensure that all > communication has to go through (interceptable) semantic events. Not > all events a Skin receives must be translated; if some events only > result in the Skin's internal state changing, and does not need to be > reflected in the Control's state then Skins can handle these directly > without going through a Behavior. Examples might be the position of the > caret, or the exact scroll location of a View, if such things aren't > part of the Control state. > > - Skins refer to a Control (legacy inheritance) but are limited in their > allowed interactions (unwritten rule since the beginning) > - Better would be to provide skins with only a Context object that > only allows installing of listeners to ensure they can't do nasty things > (and to track all changes a Skin did for when it is replaced, similar > idea to BehaviorContext) > - Skins interprete normal events of their CHILDREN only (after the user > did not consume them), and either: > - Translates them to semantic events (targetted at the top level > Control) > - Acts upon them directly if only Skin internal state is involved > - Skins never act upon semantic events > > # Behaviors > > Behaviors provide a standard set of key mappings, and provide standard > ways of dealing with semantic events. Installing a new Behavior on a > control can make it "feel" completely different, from how it reacts to > keys, and which keys, how it deals with the high level semantic events, > as well as how it handles mouse interactions. Behaviors can act upon > both normal and semantic events, but don't generate any events > themselves. Again, they only act upon events after the user had a > chance to act upon them first. A behavior is free to act upon Key events > directly (for things too complicated for a simple key mapping), but it > would be better to indirect them as much as possible via a semantic > event that is triggered by a key mapping in the Control. Mouse events > are more complicated and don't need to be indirected to be handled (not > 100% sure here yet). When receiving a semantic event that the user > didn't care about, the Behavior consumes it and does its thing by > calling methods on the Control and modifying control state. > > - Behaviors refer to nothing > - Control reference is received via event handler and listeners only > - Behaviors define base key mappings > - Controls refer to these, after first checking for any user overrides > - Base key mappings can be global and immutable, user overrides > (maintained in Control) are mutable > - Behaviors never generate events > - Behaviors can act upon events of any type (if unconsumed by the user) > that are targetted at the control (enforced as that's the only place > they can install handlers) > - Behaviors are allowed to modify control state and their own state > > # Interaction with Andy's proposal > > I think the above works pretty nicely together with Andy's proposal. By > moving the responsibility managing the key mappings to Control, but > leaving the responsibility of defining the mappings with Behaviors, I > see a nice path forward to opening up a key mapping system for simple > overrides, as well as having a public Behavior API for more advanced > behaviorial modifications. > > Notice that I didn't provide for a FunctionTag remapping system; as > these would be semantic events in this proposal, they can be > filtered/handled before the Behavior gets them. So to change a > function, just consume it and fire a different one. To completely block > it, just consume it. To replace a single function with two functions, > consume it and fire two new ones, etc. So to globally swap the > increment/decrement functions of all Spinners, at the Scene level you > could have a handler do this. > > To also answer Andy's 10 questions: > > Q1. Changing an existing key binding from one key combination to another. > > -> Control provides a small API to override base mappings (remap) > > Q2. Remapping an existing key binding to a different function. > > -> Control provides a small API to override base mappings, including to > which semantic event they translate > > Q3. Unmapping an existing key binding. > > -> Control provides a small API to override base mappings (disable) > > Q4. Adding a new key binding mapped to a new function. > > -> Still debatable if this should be provided, but I don't see much > blockers for this; someone will have to interpret the new function > though; this could be a user event handler that knows the event (which > can be a custom one) or a customized Behavior. > > Q5. (Q1...Q4) scenarios, at run time. > > -> All possible at runtime. With a "-fx-behavior" CSS feature, this > could also be provided via CSS selectors, allowing far reaching changes > without having to modify each control individually. > > Q6. How the set behavior handles a change from the default skin to a > custom skin with some visual elements that expects input removed, and > some added. > > -> Behaviors act only upon events targetted at the Control. Skins that > don't provide some events means they will just not be picked up by > Behaviors. Skins that provide unknown semantic events require a > corresponding Behavior upgrade. Skins actions that don't require > Control state changes (only Skin state changes) can ignore this system > altogether. > > Q7. Once the key binding has been modified, is it possible to invoke the > default functionality? > > -> Yes, just fire the appropriate semantic event at the Control > > Q8. How are the platform-specific key bindings created? > > -> Debatable if this is needed, but probably something similar to your > proposal will be possible; Platforms don't change at runtime, so why > they are even added as bindings (instead of just skip adding them if not > on the right platform) is a mystery to me. A simple tool (perhaps on > the Platform class) to check the platform should be sufficient; no need > to interweave this with key mappings themselves. > > Q9. How are the skin-specific (see Q6) handlers removed when changing > the skins? > > -> Skins clean up after themselves, and they're not allowed to install > handlers on the control (only on their children) > > Q10. When a key press happens, does it cause a linear search through > listeners or just a map lookup? > > -> No, Controls have freedom to optimize how they do this; Behaviors > provide base mappings in some kind of Map form, or have an API to > quickly look up a base mapping (probably the latter to encapsulate it > better). > > Thanks for reading, > > --John > From rsheperd at sig-gis.com Mon Nov 13 17:27:01 2023 From: rsheperd at sig-gis.com (RJ Sheperd) Date: Mon, 13 Nov 2023 09:27:01 -0800 Subject: WebAssembly Support in JavaFX WebKit Message-ID: First, big thanks to the folks who have maintained this project. I recently opened a "Feature Request" ticket for "WebAssembly Support in JavaFX WebKit", and stated that I would be happy to help get this support enabled. WebAssembly has been enabled in WebKit since 2017: https://webkit.org/blog/7691/webassembly/ The basic gist is: when I run load the following HTML, I get "undefined" rather than "object": <-- index.html --> Hello from Webkit!