How to handle Space vs Enter for buttons

From https://github.com/phetsims/scenery/issues/934, in the browser they are different, @pixelzoom and @zepumph discussed at one point whether or not that adds value to phetsims, it would be good to discuss that further, and then implement from there. This also may relate to how we are handling sun buttons, and that should be looked at in this issue to.
Related potentially to https://github.com/phetsims/sun/issues/424, there is likely little use for the default behavior of Enter to be fire multiple events.
Even though it is browser default, we know we want to support users at PhET that are younger, and may not have as much keyboard experience, it could easily be overwhelming to have a button fire many times without a good, pedagogical reason to. Expanding on that, then why would we make that the default behavior for Enter?
I think from discussing with @pixelzoom that we are mostly in agreement (correct me if I'm wrong) that the default behavior for both should (a) be the same, and (b) be a single click for buttons. See https://github.com/phetsims/scenery/issues/931 for adding support for options that would deal with "fire on hold" features.

@zepumph, @pixelzoom, @jessegreenberg, currently from phettest and using Safari on Mac OS (with or without a screen reader on), the button that pops up the the list of options is not operable with the Enter key, only the Space key.
It's a button, so it needs to be operable via the Enter key.
Perhaps this article by Paul J. Adam from Deque on building accessible buttons will help us gain some understanding. It is important to note, however, that our implementation is a pop-up button. I don't think we are using aria-expanded, but rather, aria-haspopup="listbox".
Note, we are using a real button, more specifically, a real pop-up button so our job should be a lot easier.
From article:

When a JavaScript onclick event is attached to a native  or  the keyboard accessibility for both Enter and Spacebar keys is included for free and you don’t need a role attribute.

Further down in the article, for native button's:

To make a button keyboard operable all you need is the onclick event and it works with Enter and Spacebar keys!

The pattern that we adapted for the PhET Combobox if I am remembering correctly from the example of a Collapsible Drop Down List. Of course, we pop up rather than down.
The short of it is that we need the Enter key to work on the button that pops up the list.
Enter key should pop up the list and the list should stay visible with focus shown on the selected solute until Space, Enter or Esc are pressed. Arrow keys are used to move focus within the list of options.

I think we can close this issue if we agree that we should be supporting both Space and Enter keys on buttons.

Please re-assign to me as needed.

Adding links to previous research in other issues
https://github.com/phetsims/a11y-research/issues/64 and https://github.com/phetsims/sun/issues/314
I appreciate all the effort going into the PhET Combobox!

@terracoda reported:

... currently from phettest and using Safari on Mac OS (with or without a screen reader on), the button that pops up the the list of options is not operable with the Enter key, only the Space key.

Thanks @terracoda.  This specific issue with ComboBox is being tracked in https://github.com/phetsims/sun/issues/447.   A general solution is preferrable, and workaround in ComboBox is a last resort, and we've been deferring that issue until this more general issue is addressed.

Over in https://github.com/phetsims/sun/issues/447#issuecomment-460010180 (the problem specific to ComboBox), I said:

... I added logging of a11y keyboard events. Run Molarity with ?a11y&log and you'll see these events logged to the browser console. This demonstrates the problem that is specific to ComboBox, as well as the more general issues with Enter and Space keys.

It would be great if everyone played around with this before our Wednesday 2/6 conference call, so that we're all up to speed on what the current behavior is.

Notes from discussion today:

CM: PhET, at the beginning of HTML5 work, decided not to mimic HTML buttons in phet sims.
TS: if PDOM buttons act differently then HTML buttons, then it is potentially important to convey that to the user (with custom interaction instead of using native HTML buttons in the PDOM)
CM: what are people "relying on" in terms of difference between ui of enter and space? Because it will be easier to inline them in the long run
	TS and JG: don't think that many basic users (not super users) that understand the nuance of difference between the two.

What do we want:

We want space and enter to both be a way of firing a button.
Currently space fires on up, enter fires on down, and will continue to fire.

one thought:
have enter and space bar both run on keyup.

behavior for fire on hold:

for buttons, here are the way that events work

no screen reader
	space
	keydown
	keydown
	keyup
	click

	enter
	keydown
	click
	keydown
	click
	keyup

yes screen reader:
	space
	click

	enter
	click
	click

TS, perhaps using enter is "built in fire on hold"
CM: that doesn't give us a way to specify parameters, like we do in PushButtonModel

Seems like a priority to investigate turning off fireOnHold for enter key

CM: maybe we should make our own thing instead of trying to work with HTML buttons in the PDOM.

JG: does changing to "
"  solve all our problems. Perhaps screen readers
TS: as a reference: https://www.deque.com/blog/accessible-aria-buttons/
MK: but does it change use for screen readers.
	For example can you use 'b' to navigate through div role buttons?
		TS: yes hopefully the role will handle that for you.
JG: we tried div with button role before but decided, after testing, that things weren't great (past issue reference to come)
TS and many: We really hope that a div with button role gives us all events, but we may find that screen readers suppress keydown/up.
CM JG: hopefully we don't need click

Ideal behavior for buttons:
(perhaps we can do this with div role button)

In a mixin like `AccessibleButton.js`
space and enter: act the same (ideally) as PushButtonModel

// default to fire on keyup
fireOnDown: false, // true: fire on pointer down; false: fire on pointer up if pointer is over button
fireOnHold: false, // is the fire-on-hold feature enabled?
fireOnHoldDelay: 400, // start to fire continuously after pressing for this long (milliseconds)
fireOnHoldInterval: 100,
a11yFireOnHold: `default to fireOnHold but overridable just for a11y` same with other values.

Reflection from today's meeting:

seems there was consensus that we want enter and space to ultimately have the same behavior for buttons in PhET sims.
currently in-progress work in scenery will (or potentially will?) streamline how input is handled by scenery, leaving to sim developers only implementation decisions regarding behavior attributes (fire on hold, etc.) and display-related stuff.
(my thought) One idea is to plan for a time this year to have developer (and team-wide, as needed) collaborative work to assess the current range of available buttons and to organize, design, and create the central button behavior and necessary parameters to meet the current and foreseeable button needs. I'm thinking this might be something like investigating the various button models in use, and any one-off tweaks of these for special cases, and creating the simplest structure to meet the range of needs we find holistically (from a11y and other perspectives).

Thoughts?

@emily-phet asked:

... Thoughts?

@jbphet was the primary architect of sun buttons, so it might be good to get him involved.
@jonathanolson is the primary architect of scenery, so he's in a good position to help with how input is handled by scenery.

I agree with @emily-phet that it would be great to have some collaborative time

to assess the current range of available buttons and to organize, design, and create the central button behavior and necessary parameters to meet the current and foreseeable button needs.

Currently, the names for buttons describe a mixture of different button attributes some related to the how the button functions and some related to how the button looks.
We have already had many long discussion about whether some buttons should be represented in the PDOM as an HTML checkbox.
To complicate things further, some PhET buttons look like buttons but in terms of HTML they would not have a button role. For example, the PhET radio buttons would likely be represented as actual HTML radiobuttons in the PDOM, even though they can visually look like a group of labelled square buttons in a simulation.
Many of the visual qualities of PhET buttons are designed to scaffold students in a particular way.
I'd like a collaborative re-categorization to focus around scaffolding across multiple modalities for diverse users.

Also, before any changes are made we will want to carefully test that ` works well on the AT we want to support.
This could also have implications for supporting switch like devices in the future, since those have no keyboard. Depending on how they interact with buttons we may still need to observe click.

@jessegreenberg, I said this in our meeting, but I will repeat it here as we experiment with
. Aria roles give us only "semantics". The Accessibility Tree will tell the AT that this thing is a button. We will have to provide all the functionality to make it accessible.
Since the Accessibility Tree will say it is a button, that should give us some hope that the AT will recognize it as a button and do its proper thing from the the AT's perspective - i.e. work with screen reader commands.

I totally agree @terracoda, that is true. I made this JSFiddle to test:
https://jsfiddle.net/7g6pxq9t/1/
Ill give it a try with NVDA and paste results in this comment.

So after testing with NVDA, I am seeing that none of the elements in https://jsfiddle.net/cepk8m69/1/ receive keyup and keydown events, they only receive click events. Furthermore, *without NVDA, neither of the non-native buttons receive click events! This surprises me. The only way for us to receive keyup and keydown events is if the screen reader is in "forms mode", which it only is for certain ARIA roles.

@jessegreenberg thanks for investigating.

So even if div role="button worked well everywhere, it would not solve this issue.

Bummer :(

With this "button", we get keyup and keydown events as we would hope. But it is a monster, and I have only tested on NVDA.

Button Application

role="application" to receive keyup and keydown events.
aria-roledescription so the AT describes the role of the elements as "button" instead of "application".
aria-label so that the accessible name is read read (from https://github.com/phetsims/a11y-research/issues/116).
But it can't be found by normal screen reader strategies. And it forces "forms" mode so the user can't continue reading with virtual cursor. I don't think we should do this for all buttons yet.

I'm going to unassign myself from this issue, but will remain subscribed so that I can follow progress. Mention me if you need any input.

@jessegreenberg, thanks for making a test so quickly. I'm not sure the test code has everything that is needed.
I am reading through Paul J. Adam's article on accessible buttons. Could you verify that all the pieces mentioned in the article are included in your test code. The author notes that you need the following to make a
 accessible:
Code pieces:

tabindex=0, role=button, onkeydown, .keyCode == 13, .keyCode == 32, event.preventDefault()

Why pieces are needed*

tabindex="0" to make the div focusable which you already have,
onkeydown event as tabindex="0" only makes the div focusable, not operable
.keyCode == 13, .keyCode == 32 to check if the Enter or Space keys are pressed
.preventDefault() to prevent Space key's default behaviour of scrolling

Then in addition, we have to manage focus once the button is activated, but I don't think that is needed for your example.
@jessegreenberg, apologies if the mentioned pieces are all in place. I have trouble fully understanding the javascript in the js fiddle example.
As an aside, unrelated to this issue
I just want to note that aria-roledescription is no use to us in this case; it is not an ARIA role. It is just a way to rename an element, so a screen reader hears the custom name rather than the HTML name for the element. The element in question would still need a valid role. In my opinion, the aria-roledescription attribute could be very useful to us to provide specific names for sim objects, but at the moment it is not well supported (only supported in VoiceOver). Thus far, we have only tried used aria-roledescription for custom interactions with role="application", like the Yellow balloon in BASE and the Chemistry book in Friction. We haven't explored the benefit of using aria-roledescription on an native HTML elements, or custom elements with native roles.

@terracoda and I met to discuss the examples. We tried something more like the example from https://www.deque.com/blog/accessible-aria-buttons/, where the listeners were added as inline attributes. Here is the link to the JSFiddle:
https://jsfiddle.net/07gs8cfe/1/
The HTML that we tried:

Inline Button

We tested with NVDA/Firefox and results matched the behavior in https://github.com/phetsims/scenery/issues/939#issuecomment-461524582. When NVDA is off we only get keydown/keyup events. When NVDA is on, we only get click events.
In the example from deque, keyup and keydown are added for non-AT use and click is added just for screen readers. For sims to behave the same with and without screen readers, we would need to support only receiving click events anyway. So I don't see benefit in PhET doing this since it creates two separate implementations for buttons.

@jessegreenberg, I tried the js fiddle example with VoiceOver.
For the inline div role button, the dialogs popped up, and no events were logged.
For the others, the events were logged and there were no click events.
Events were even logged even when I tabbed to the buttons. Not sure if that was supposed to happen.

@jessegreenberg  regarding https://github.com/phetsims/scenery/issues/939#issuecomment-461824374

But it can't be found by normal screen reader strategies. And it forces "forms" mode so the user can't continue reading with virtual cursor. I don't think we should do this for all buttons yet.

I agree, your "monster" is a bit wild to consider.
In interviews, thus far, screen reader users (adult screen reader users) have always been a bit confused about the behaviour of objects with role application.
@jessegreenberg, question: is aria-roledescription now recognized by NVDA?

OK, thanks for testing @terracoda, that is good to know. And yes aria-roledescription is now working with NVDA! 🎉
@zepumph and I also reviewed the list of roles in https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques, but didn't see any others that would be appropriate to use or fix this problem.
So based on the above comments, we are back to the fact that elements with "role=button" will not receive keydown and keyup events with screen readers. Our two options are

Continue with click events for most PhET buttons. For things like RoundMomentaryButton where we must have keyup/keydown to get the button to work correctly, we use something different so we get these events, possibly https://github.com/phetsims/scenery/issues/939#issuecomment-461634445 (with role="application" aria-roledescription="button").
Use https://github.com/phetsims/scenery/issues/939#issuecomment-461634445 (with role="application aria-roledescription=button) everywhere so all PhET buttons are the same, and we get the ability to use keydown and keyup on all buttons.

If we do this for buttons, would we want to do this for checkboxes, links, and every other kind of native input element too?  If we go down that road, all of our input elements become non-standard for a11y, and likely confusing for a screen reader user. We lose two of the greatest benefits of the PDOM, native interaction with assistive devices and ability to find UI elements with common screen reader navigation strategies.
So I think we should go with option 1. But there are drawbacks to each, so it would be good to discuss with the team again.

@terracoda @emily-phet @zepumph @pixelzoom can you please review https://github.com/phetsims/scenery/issues/939#issuecomment-462521440? If everyone is on board with option 1, I think we can close this issue and continue with the specific issues that have come out of this one. If not, I think we should have another brief discussion.

... If everyone is on board with option 1, ...

Does option 1 support our requirements?  I was under the impression that relying solely on click events made it difficult (impossible?) to implement the button options that we agreed were essential in https://github.com/phetsims/scenery/issues/939#issuecomment-461103903, that is:
fireOnDown: false, // true: fire on pointer down; false: fire on pointer up if pointer is over button
fireOnHold: false, // is the fire-on-hold feature enabled?
fireOnHoldDelay: 400, // start to fire continuously after pressing for this long (milliseconds)
fireOnHoldInterval: 100,
a11yFireOnHold: ... // default to fireOnHold but overridable just for a11y` same with other values.

Option 1 will support those options but only where we need them. The HTML in those cases will not use role="button" so that we get the keydown and keyup events we need. But the rest of PhET buttons will continue to use role="button" and listen for click events so they support all of the standard accessibility features.
The down side is that not all buttons will listen to the same DOM events, but it supports all of our requirements.

All PhET buttons currently have the options that we identified.  So what buttons are you planning to use role="button" for?    For example, would you use it for ResetAllButton, which is currently (and undesirably) firing repeatedly with the Enter key?

I would use role="buton" for ResetAllButton. We can address that issue generally by limiting the frequency of calling listeners in response to click events. Maybe that will use options a11yFireInterval or just fireOnHoldInterval. But I don't believe buttons like ResetAllButton need any of the other options, keyboard/alternative input.

@jessegreenberg said:

.... But I don't believe buttons like ResetAllButton need any of the other options for keyboard/alternative input.

Then you'll need to prevent those options from being changed and passed to the superclass.  Because RoundPushButton (and the other sun button base classes) are general and do need to handle those options.

Re https://github.com/phetsims/scenery/issues/939#issuecomment-462521440 I do not believe option 2 is at all advisable. The use of role="application has not yet been understandable by users in interviews (i.e. BASE, Faraday's Law, Friction), mind you these were all drag and drop type interactions.
The buttons that we have implemented thus far have been intuitively accessible to participants in interviews. These buttons include:

generic buttons - BASE's Grab buttons and Remove Wall button, and the Reset All button
toggle buttons - the Mute Sound button is read out as a toggle button
pop-up buttons - the PhET Menu button is read out as a pop-up button

We have not yet worked on a sim with a "fire-on-hold" button. We do not know what keyboard users or screen reader users will do when they come across a fire-on-hold button like the eye dropper button. They might know exactly what the differences are between Enter and Space key or they might try both and realize that one adds drops while the other keeps the eye dropper squeezed and adds  a stream.
@jessegreenberg, I am really uncomfortable with the idea of re-coding the Reset All button.  It works well for users as it is. I don't think users will hold down the button to hear multiple alerts. Are the multiple firings a performance issue?

@jessegreenberg, I am really uncomfortable with the idea of re-coding the Reset All button. It works well for users as it is. I don't think users will hold down the button to hear multiple alerts. Are the multiple firings a performance issue?

ResetAllButton is a RoundPushButton with a specific look.   There will certainly be a11y specific features required for buttons like Reset All button. But those features should be related to is specialization as a Reset All button, not things that are general to RoundPushButton . As much of the a11y functionality as possible should be in base classes (like RoundPushButton), not in subclasses (like ResetAllButton).   And RestAllButton should most definitely not be deciding whether it fires multiple times, that should be handled consistently for all buttons in a base class.  This is a problem that needs to be solve generally.  And once it's solved generally, ResetAllButton will inherit that solution.
Re multiple firings... They are in general undesirable. They can result in performance issues, and they will result in multiple messages in the PhET-iO data stream.   And for a button like ResetAllButton that is used in all sims, we cannot predict it will cause a performance issue.  I can tell you that in Equality Explorer, there were performance issues with a single reset call.

@terracoda said:

.... This has lead to a plethora of buttons with very nuanced meaning and very nuanced inheritance patterns based on visuals and based on mouse/touch interactions. ...

It is not the case that we have a plethora of buttons. PhET's buttons are modeled on a standard button taxonomy, and most of the functionality is in a few base classes. You said that things like whether a button is round or rectangular have no relevance to a11y, and that is indeed the case regardless of a11y.  In the implementation of PhET buttons there is a clear separation between how a button looks and how it processes raw events (whether it fires on up or down, whether it fires on hold, etc.).   How a button processes events is handled by a base class (e.g. PushButtonModel, ButtonModel).  Details about how a button looks are added by subclasses (e.g. RoundPushButton, RectangularPushButton).  What a button specifically does when it has been told to "fire" is handled in more still more specialized classes (e.g. ResetAllButton).   How a button decides when to fire is independent of how a button looks (e.g. round or rectangular, icon, etc.), and independent of what the button does when it fires (e.g. "reset the sim"). This type of separation and subclasses is typical of most UI toolkits -- Java Swing, X/Motif, Qt, ...
So when you said in https://github.com/phetsims/scenery/issues/939#issuecomment-464512679 that you are "uncomfortable with the idea of re-coding the Reset All button"...  Processing of the raw Enter and Space events is not (and should not) be coded in ResetAllButton, it is the responsibility of a base class. ResetAllButton is told by the base class to "fire", and then does what is specific to "reset all".   So resolving the issue of how Enter/Space events are converted to "fire" is not a matter of changing the implementation of the Reset All button.

To me, the Reset All button is a simple button. Upon activation:

it fires once to reset the sim
it triggers a single aria-live alert that the sim has been reset
there is no label change that often indicates a toggled state
there is no meaningful continued pressed state, requiring multiple firings
there is no change in context, so focus remains on the button

This is a good summary.  Everything here is specific to the "reset all" function of the button.  And how it "fires once" is the responsibility of the more general base class.  So I think we're on the same page.

From an accessibility perspective we want buttons:

to have a bright bold visible focus style that respects the bounds of the button's visual presentation (round,square, or whatever)
to have very visible styles to communicate critical state information (e.g. pressed, grabbed, etc)
to be operable via the keyboard using Space key and Enter key

In addition, focus has to be managed carefully when a button is activated clearly communicating whether or not there is a change in context (i.e. focus is sent to another element). ...

The first 2 bullets are related to how the button is presented, that seems to be working well, and it is being handled in the base classes.  Focus also seems to be working well. The 3rd bullet (handling of raw events) is where we're having problems.  We don't have a solution that works in the base classes, and we cannot afford to have specific buttons (or worse, client code that uses those button), work around things like multiple firings, etc.

Do these types cover it? ...

Sort of, but this doesn't quite match the PhET button taxonomy.  PhET buttons live in  https://github.com/phetsims/sun/tree/master/js/buttons, and I would encourage anyone who is interested to poke around there.  It's a combination of base classes and some very specific subclasses (ArrowButton, CarouselButton).

@pixelzoom thank you for the detailed explanations.
How do I identify the base button classes?
There are 36 buttons in https://github.com/phetsims/sun/tree/master/js/buttons including radiobuttons that actually do not have the button role when coded in HTML.

Thanks for the careful review and comments everyone. I thought of a different solution to this that we should explore that may allow us to keep using standard HTML/roles for a11y while also supporting all the options in https://github.com/phetsims/scenery/issues/939#issuecomment-463718627. I started https://github.com/phetsims/scenery/issues/945 to play with the idea. Please see that issue for more details if interested, and will report back here when we know more.

Back to this question that @terracoda asked in https://github.com/phetsims/scenery/issues/939#issuecomment-464512679:

@jessegreenberg, I am really uncomfortable with the idea of re-coding the Reset All button. It works well for users as it is. I don't think users will hold down the button to hear multiple alerts. Are the multiple firings a performance issue?

The reason that ResetAllButton works well for users is due to this workaround:
// a11y - when reset all button is fired, disable alerts so that there isn't an excessive stream of alerts
    // while many Properties are reset. When callbacks are ended for reset all, enable alerts again and announce an
    // alert that everything was reset.
    this.isFiringProperty.lazyLink( function( isFiring ) {
      utteranceQueue.enabled = !isFiring;

      if ( isFiring ) {
        utteranceQueue.clear();
      }
      else {
        utteranceQueue.addToBack( new Utterance( {
          alert: resetAllAlertString,

          // only one "Reset" alert should be in the queue at a time so the user doesn't get spammed with alerts
          // relating to Reset if the button is pressed rapidly
          uniqueGroupId: 'resetAllButtonAlert',

          // Wait this long in ms before announcing the alert so that old utterances with the same uniqueGroupId
          // are removed before they can be anounced. This way only a single utterance for Reset is
          // announced even if "enter" is held down to click the button every few milliseconds.
          // TODO: This is a general problem that will come up for many buttons, see
          // https://github.com/phetsims/sun/issues/424 - when that issue is resolved this line can potentially
          // be removed
          delayTime: 500
        } ) );
      }
    } );

This is a work around prevents multiple announcement that could occur with the Enter.   This workaround is almost 25% of the code in ResetAllButton, and it's complicated.   The same workaround will be needed by other buttons - the expand/collapse button on AccordionBox comes to mind.  We can't be duplicating something like this.

Maybe @jessegreenberg's idea will produce a quiet button.

https://github.com/phetsims/scenery/issues/945 is working well enough that I think it is a viable option. I am going to request that we discuss in greater detail, but here is a summary prior to meeting.
Proposed change works by catching the single click when it isn't accompanied by keydown and keyup events. In this case, we dispatch a fake keydown event then a fake keyup event to the target of the click event. In all other cases, we just handle the usual keydown and keyup events as they reach the browser.
This way all buttons can respond to keyup and keydown events. PressListener will be changed to respond to keydown and keyup rather than click, and since button models use PressListener, options of PushButtonModel will work without any additional effort. And enter and spacebar will behave the same way (unless we don't want that, but the point is we have control now).
This doesn't change the fact that the behavior will still be different when a screen reader is enabled. While pressing and holding enter, we will catch lots of click events and dispatch many keydown keyup events to the target, so the button gets pressed many times. We can do something to prevent buttons from being fired too rapidly in this case. But the API for listening to alternative input is the same for all buttons and is more similar to pointer events.
In special cases (like usages of MomentaryButtonModel exemplified in EyeDropperNode of ph-scale), the only change will be to use something other than role="button" so that we get accurate keydown and keyup events when a screen reader is in use. No other changes related to input handling would be necessary.

This approach sounds promising, thanks for all the work investigating!

This doesn't change the fact that the behavior will still be different when a screen reader is enabled.

That's unfortunate, because it's going to increase implementation and testing cost. If  buttons fire only once without a screen reader, but fire more than once with a screen reader, then both behaviors need to be accounted for and tested.   It's not clear how we'll account for multiple firings, but we shouldn't just let it happen and keep our fingers crossed.  We need to ensure that the sim doesn't have performance problems or (worse) crash.
I really think that the entire dev team should be brought up to speed on this issue, so that we all know what the limitations are, and what we potentially will have to address when using PhET buttons.

Participants of this issue set up a time to discuss https://github.com/phetsims/scenery/issues/939#issuecomment-466537529 in more detail on March 4.
Also adding dev meeting label to review with the dev team. The challenge that we are facing is that screen readers change which events are sent to the browser. Please see this comment: https://github.com/phetsims/scenery/issues/939#issuecomment-458636828
Some screen readers only sends a single click event for buttons without keydown and keyup events. Responding to single click events alone doesn't let us implement the options of PushButtonModel (fireOnDown, fireOnHold, fireOnHoldDelay, fireOnHoldInterval) for alternative input. Our recommended solution with pros and cons is listed in https://github.com/phetsims/scenery/issues/939#issuecomment-466537529.
For dev meeting we are hoping to review that proposal and how it affects use of PhET buttons in sims.

Mapping click to down/up sounds reasonable to me.  It seems we have the problem of repeat clicks whether or not we map click to down/up.

This doesn't change the fact that the behavior will still be different when a screen reader is enabled. While pressing and holding enter, we will catch lots of click events and dispatch many keydown keyup events to the target, so the button gets pressed many times

Can you please provide steps to reproduce this behavior?  Can it be demonstrated with VoiceOver?

W3C describes support for Enter and Space in buttons, see https://www.w3.org/WAI/GL/wiki/Making_actions_keyboard_accessible_by_using_keyboard_event_handlers_with_WAI-ARIA_controls#Example_1:_Using_Space_to_activate_a_button:

Adding the ARIA role "button" makes it clear that this is a button control and not a link. Because we are using an anchor element, the control is focusable and the browser will automatically call the onclick handler for the Enter keystroke. Since users expect to be able to activate buttons with either Enter or Space, a keyboard handler provides the support for activating the button via the Space character.
Note that supporting SPACE in addition to ENTER is not required by WCAG 2.0; this control would still be keyboard accessible without the key event handler for SPACE. However, supporting platform keyboard conventions for controls is strongly encouraged.

This supports PhET's decision to handle both Space and Enter, and is a more "official" reference than the Stackoverflow thread referenced in https://github.com/phetsims/scenery/issues/939#issuecomment-458652876.

We will talk about this more on Monday. I thought it was still worth having a "pre-discussion" to explain the lower level details of the issue. The dev team briefly discussed this (only 15 minutes).
Most of the discussion was explaining the how the events work for space/enter and toggling while AT is on/off. We also explained @jessegreenberg's work on the click event "catching" branch.
AP: in addition to the click catching, perhaps some buttons could have a timing like "you can't fire this faster than x." "Remove Wall" button and "Reset All" button could be potential options.
CM: maybe we can do more natively, have we tried type="submit"?
JB: seems like there is significant value in keeping a button role right?
MK: yes, but it seems like there will be places, like momentary buttons, where we will most likely not be able to support role button.

In comment https://github.com/phetsims/scenery/issues/939#issuecomment-463725218 @pixelzoom said:

All PhET buttons currently have the options that we identified. So my feeling is that all PhET buttons need those options.

I think this is where we are having trouble communicating. My feeling is that not all PhET buttons need all the options.
From an accessibility point of view the Reset All button and the fire-on-hold button (e.g., the eye-dropper button) are different types of buttons. It would seem logical to me that they would not share the same base class. The fire-on-hold interaction is not a native button interaction. It is actually a custom interaction, one we have not yet tackled for accessibility.
Our best guidance is in ARIA authoring practices.
https://www.w3.org/TR/wai-aria-practices-1.1/
Buttons are described here:
https://www.w3.org/TR/wai-aria-practices-1.1/#button
Native button functionality we already use in sims:

a simple button - a button that does something: e.g., Reset All button
a Grab button - I think this is also a simple button, but it launches something more complex, a drag interaction. E.g., Grab Yellow balloon button
buttons that show and hide content
buttons that toggle things on and off - Mute Sound button
buttons that pop things up - PhET Menu pop-up button, Drink Mix Solute pop-up button

It would great in our meeting on Monday if we can get some clarity not only for a solution that works for now, but a possible ideal solution.

@terracoda said:

In comment #939 (comment) @pixelzoom said:
All PhET buttons currently have the options that we identified. So my feeling is that all PhET buttons need those options.
I think this is where we are having trouble communicating. My feeling is that not all PhET buttons need all the options.

Agreed and agreed.
I should have said "All PhET button base classes currently support the features needed by PhET buttons.  Base classes contain code that is needed to support all buttons.  Individual button types use those features as needed.  Examples: Most buttons use the default of fireOnDown: false, but momentary buttons use fireOnDown: true.  Most buttons use the default of fireOnHold: false, but ArrowButton uses fireOnHold: true.   Implementing these features individually for button subclasses would result in lots of code duplication, maintenance issues, and (possibility) idiosyncratic differences across features that should have identical behavior.  For the same reasons, ideally most of the a11y instrument would be (and currently is) in base classes, with subclasses override the default a11y where necessary.
Is that clearer?

Our communication might be improved if I provide some background on how (and why) PhET buttons are implemented.  I'll use ResetAllButton as an example, since we're all familiar with it.  I'll start with the most general classes, and work my way "up" to ResetAllButton. There are 7 classes described, and I'll provide links to all of the files mentioned.
The most general classes live in the sun and scenery repositories. Classes in these repositories are intended to be usable by 3rd parties (outside of PhET).
As with most things in PhET, buttons use the MVC (Model View Controller) design pattern to separate model and view parts of the implementation. The model determines behavior and the view determines "look". (We can safely skip the Controller for the purposes of this discussion.)  The inheritance relationships are:
model: PushButtonModel extends ButtonModel
ButtonModel - describes the most basic behavior of buttons when users interact with them
PushButtonModel - specializes ButtonModel to handle behavior that is specific to push buttons
view: RoundButtonView extends Node
Node - base class for anything that is rendered
RoundButtonView - visual representation of any button that is round
RoundPushButton puts the model and view together, using composition for the model and inheritance for the view.  RoundPushButton has an instance of PushButtonModel (composition) and RoundPushButton extends RoundButtonView (inheritance). So to summarize:
RoundPushButton - creates a functional push button by combining the appropriate model (PushButtonModel) and view (RoundButtonView)
So all of the above gives something that we can use in any situation where we need a "round push button".  It provides the general look of a round push button, and the general behavior for responding to user interaction.  It doesn't determine specifically what happens when the user interacts; that's up to clients and subclasses to specify.
Now let's look at the button classes that are specific to PhET. They live in the scenery-phet repository, which is where all PhET-specific UI components live.
The buttons here are specialized via inheritance.  ResetButton extends  RoundPushButton, and its sole responsibility is to add the icon that appears on a general "reset" button.  RestAllButton extends ResetButton, and its responsibility is to add modify the look (make the button orange) and perform tasks that are specific to "reset all".   It does not know anything about fireOnDown, fireOnHold, the button's shape (round), or any of the other general features -- that is all handled in base classes, and ResetAllButton would only be concerned with a based class feature if it needed to override default behavior.  The client who creates a ResetAllButton is responsible for specifying what specifically happens when the button is pressed.  To summarize:
RestButton - a round push button with "reset" icon
ResetAllButton - a rest button with standard color for "reset all"
The above undoubtedly seems complicated.  And it is very different than buttons in web-based toolkits.  Back when PhET started HTML5 development, we evaluated web-based UI toolkits, and determined that they were insufficient to meet the requirements of PhET sims.   PhET sims require UI components that are more sophisticated.  So PhET invested in writing its own button library (sun/buttons/), which is closer in style and implementation to an application toolkit (vs a web toolkit).
ARIA is a W3C (web) standard that's targeted at typical web applications. PhET sims run in a web browser, but are not typically web applications.   So I think that's why we're having difficulty applying ARIA practices to PhET buttons, communicating about this issue, etc.
Hope that helps some.

Thanks @pixelzoom. Glad we agree that accessibility needs to be built into the base classes.
Looking forward to Monday's discussion.

In preparation of Monday's conference call, I did a deeper dive into the ARIA references that @terracoda provide in https://github.com/phetsims/scenery/issues/939#issuecomment-468624994.  I was looking for info relevant to this issue, especially ways that we might customize the ARIA button role to better align with PhET button behavior.   Here are some chunks of information and questions that I thought might be relevant. (Apologies to readers who already know this, or have already investigated these questions.)

So that's we're all on board with terminology... In the ARIA specification, “button activation” is what PhET has referred to as “button firing”.  When a button is activated (fired), the action(s) associated with the button should be performed.

Regard UX, we haven't been able to answer these questions:" "Why does activation of Enter vs Space behave so differently?", "What activation behavior (if any) do users expect?"  Unfortunately when Enter and Space are mentioned for ARIA roles, the specification is vague and doesn't describe default behavior. For example, from the description of button role at https://www.w3.org/TR/wai-aria-practices-1.1/#button:

When the button has focus:

Space: Activates the button.
Enter: Activates the button.

While I could find no specification the activation behavior for Enter and Space keys, I did find a section that defines Activation in general, see https://www.w3.org/TR/html5/editing.html#activation. Activation appears to be highly customizable. Can we customize button activation behavior to meet our requirements?

HTML buttons have an optional type attribute, see
https://www.w3.org/TR/html5/sec-forms.html#the-button-element.  The type attribute “controls the behavior of the button when it is activated.”  Have we investigated how button activation changes depending on the value of the type attribute?

ARIA buttons have an optional aria-pressed attribute, used to determine whether a button is pressed.  See https://www.w3.org/TR/wai-aria-1.1/#button. This attribute is typically used only for toggle buttons, but perhaps we could leverage it for other buttons.  Could we use the aria-pressed attribute to provide more context for interpreting click events?

More about the click event that has been mentioned extensively in this issue.
The click event is a synthetic (DOM) event, specified in https://www.w3.org/TR/uievents/#click.  It is synthesized in response to other events (e.g. keydown, keyup).
https://www.w3.org/TR/html5/webappapis.html#fire-a-click-event defines what a click event is:

Firing a click event means firing a synthetic mouse event named click, which bubbles and is cancelable.

https://www.w3.org/TR/html5/webappapis.html#firing-a-synthetic-mouse-event-named-e
defines what “firing a synthetic mouse event” means.
https://www.w3.org/TR/html5/editing.html#dom-htmlelement-click describes what happens when a click event is synthesized:

The click() method must run the following steps:
1	If the element is a form control that is disabled, abort these steps.
2	Run synthetic click activation steps on the element.

The steps involved in “run synthetic click activation steps” are defined in the Activate section of the spec, mentioned above and at https://www.w3.org/TR/html5/editing.html#activation.  These steps appear to be customizable.
Questions:
Do any of the click event fields provide us with useful information?
Is synthesizing of the click event customizable?

ARIA examples for role=button are at https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/examples/button/button.html#.   The behavior of the "Mute" button here is interesting.  If you tab to the Mute button, then press and hold the Space key, there is a brief delay, then the button activates (fires) repeatedly.  This does not match the behavior that we've seen for the Space key - we've seen activation on keydown, with seemingly no way to accomplish fireOnHold.
Question: Why is the behavior different in this example? Is there something we can apply?

Here's a bug report related to the difference between Enter and Space, and it indicates that the button example in https://github.com/phetsims/scenery/issues/939#issuecomment-469057113 is buggy.
The bug report is https://github.com/w3c/aria-practices/issues/610:

The synthetic click event that happens on native  elements occurs on keydown for Enter and keyup for Space, but the button pattern doesn't describe this behavior and the example does not exhibit it.

I found this bug report by clicking the "Related Issues" link for the ARAI role=button examples at https://www.w3.org/TR/wai-aria-practices/examples/button/button.html. Note that this issues is in repository w3c/aria-practices (ARIA Practices).  It was verified to be a bug, it was fixed, and the issue was closed on 10/12/2018.

Great investigation and questions @pixelzoom. And glad you found the latest version of the button examples. The first link was to a "WD" or "working draft".  In the latest version, on the Mute toggle button, the Space key fires/is activated on release and the Enter key fires/activates repeatedly which seems more typical, though still unexplained by the standards documentation.
@jessegreenberg and I investigated many types of button in our early investigations for BASE's custom "drag & gab" interaction, but for other reasons. We know a lot more now - both about users and about the HTML and ARIA specifications.
Exploring how activation can be customized, understanding the fullest potential of the click event, and exploring further possibilities available through the aria-pressed attribute are all very worthy discussion topics.
Looking forward to our discussion.

@jessegreenberg or @zepumph can you please summarize the discussion from Monday, and point out the next steps for this issue?  Does it still need to be discussed at dev meeting?

During discussion on 3/4/19 we reviewed why we are encountering this issue and potential solutions. We discussed how scenery/simulations would behave if we proceed with changes described in https://github.com/phetsims/scenery/issues/945. No major concerns with this came up during the meeting.
An alternative proposed during the meeting was to ignore "press and hold" and "fire on down" type buttons for alternative input and just fire buttons on click events as they hit the browser natively (which is what we are doing now). @jessegreenberg thinks it is still worth exploring https://github.com/phetsims/scenery/issues/945 since this will provide us with "press and hold" and "fire on down" buttons for alternative input, while still responding to single click events when they are received from an assistive device. During the meeting it was mentioned that the downside of this is that behavior will change when an AT is in use and therefore increase the cost of development and testing.
Here are the next steps:
After the meeting @zepumph mentioned that he encountered different results than I had reported in https://github.com/phetsims/scenery/issues/939#issuecomment-458585395, we should understand why that is the case.
@pixelzoom identified a number of resources and questions in https://github.com/phetsims/scenery/issues/939#issuecomment-469051241 https://github.com/phetsims/scenery/issues/939#issuecomment-469053432 and https://github.com/phetsims/scenery/issues/939#issuecomment-469058519, those should be reviewed before more work is done.
After doing those things we can decide whether or not to proceed with #945.

@jessegreenberg, I also shared with you, @pixelzoom and @zepumph comments from the WAI ARIA interest group which included a mark-up idea that we have not yet explored, nesting a button element within a parent element with role=application.

  <button>Squeeze Eye-dropper</button>

This mark-up could potentially be useful for the "press and hold" and "fire on down" buttons once we get them for alternative input.
Just adding it, since it is related to the issue.

Thanks for collecting resources and questions @pixelzoom. Some of this we have already considered but all
of it is worth looking into.
I am reviewing the questions and links listed in https://github.com/phetsims/scenery/issues/939#issuecomment-469051241, https://github.com/phetsims/scenery/issues/939#issuecomment-469053432, https://github.com/phetsims/scenery/issues/939#issuecomment-469057113 and https://github.com/phetsims/scenery/issues/939#issuecomment-469058519

Question: Can we customize button activation behavior?

Not to my knowledge. https://www.w3.org/TR/html5/editing.html#activation spec is for the user agent (browser), I don't see anything there usable by web developers.

Question: Have we investigated how button activation changes depending on the value of the type attribute?

The type attribute controls the behavior of the button with respect to a containing <form> element. It doesn't have an impact on the DOM events. I created https://jsfiddle.net/ne2xrhyp/1/ to verify, this example has submit, reset, and button buttons. Event behavior is the same for all.

Question: Can we use the aria-pressed attribute to provide more context for interpreting click events? (EDIT: After further reading, using aria-pressed for non-toggle buttons doesn't sound like a good idea.)

+1 to the edit. But I also verified that aria-pressed has no impact on events when an AT is in use.

The steps involved in “run synthetic click activation steps” are defined in the Activation section of the spec, mentioned above and at https://www.w3.org/TR/html5/editing.html#activation. These steps appear to be customizable.
Question: Do any of the click event fields provide us with useful information?
Question: Can synthesis of the click event be customized?

These are steps for the user agent. The fields available for web developers are listed in MouseEvent(because click uses the MouseEvent interface even though it is commonly triggered with keyboards and assistive tech).

ARIA examples for role=button are at...
In button.js, they add event listeners for click and keydown to each button. Why?
Question: Why is the activation behavior different in this example? Is there something we can apply?

It is mentioned in https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/examples/button/button.html# that keydown is added to handle keyboard support and click is added to handle mouse clicks and screen readers. @terracoda and I tried something similar in https://github.com/phetsims/scenery/issues/939#issuecomment-461824374. It could be a way to get enter and spacebar to behave the same, but it has the same problem with AT in that it won't support the options of PushButtonModel.

Question: Should we contact someone from W3C ARIA to find out why Enter and Space are different, if it's a standard that shouldn't be changed, etc.?

Yes, we could do that. We happen to know the author of that issue who is a member of the ARIA WG. Differences between enter and spacebar go beyond buttons and the web. For instance, checkboxes only activate with spacebar, they don't respond to enter. I just verified that was true in a native Windows app.

Actually, I had forgotten that @terracoda already reached out to the ARIA group about this. https://lists.w3.org/Archives/Public/w3c-wai-ig/2019JanMar/0086.html

No matter whata we do, somewhere in button code we will need to change the markup for the button so that it looks like

  <button>BUTTON</button>

If we don't go with #945, somewhere in button code we will also have to opt out of click listeners. We could have an option in PressListener like activateWithKeyboardEvent that disables the click listeners and uses  keyup and keydown listeners instead.
If we do this, it will make button code a little more complicated, keyboard use without a screen reader will generally not support PushButtonModel options. But we avoid doing something tricky and PhET specific for a11y in scenery. And we avoid adding differences in sim behavior when a screen reader is enabled vs disabled.
I think we should just do that. This will also set us up for switching to #945 strategy if we need to later, but avoids trickiness for now.
@zepumph can we talk at tomorrows dev meeting to finalize?

Notes from 4/8/19 discussion:
During discussion on 4/8/19, @samreid suggested that rather than having some of our buttons use use unique markup and input handling that we modify the user interface (both visual and PDOM) to support different modes of interaction. For instance, for the StepButton we could also have a "slow motion" button that changes the behavior of step to work better with single click activations. However, it is unclear how this would work  because the step button will still  respond to click events at the interval that the assistive device sends events to the browser. And modifying the UI will be more time intensive.
By keeping our current system, we get the semantic button interaction that has been tested with users and we know works well. We don't have to change our input system for a11y or doing anything that is PhET specific. For specific buttons, we can support PushButtonModel options doing the following:

Some buttons will have different markup that looks like

    <button>BUTTON</button>

And PressListener will be modified to optionally support keydown and keyup events rather than click events.

If in user interviews we determine that this is too confusing for users, we will be in an OK position to
change approaches again at that point.
@zepumph recommended that these decisions should be documented in style guide document files (like PushButton.md) for review from relevant people in the future.

@samreid also provided these notes from discussion:
We additionally discussed these examples:

Changing the pDOM elements for MomentaryPushButtonModel buttons to toggle buttons, so on the first click, the button is pressed and on the second click, the button is released.
Breaking out the “Step” button with 2 mode of interaction (press once to step once vs press and hold to go in slow motion), to two buttons each with one mode of interaction (one button that steps once when pressed once and another button or radio button for slow motion).

We concluded that
 can be used to get things working “out of the box” but that should be “opt in” and for components that use that strategy, we should consider other alternate patterns during the a11y design process, because “press and hold” is (a) not necessarily something all users can do and (b) an unconventional accessibility pattern compared to standard html components.

We concluded that  can be used to get things working “out of the box” but that should be “opt in” and for components that use that strategy, we should consider other alternate patterns during the a11y design process, because “press and hold” is (a) not necessarily something all users can do and (b) an unconventional accessibility pattern compared to standard html components.

I agree that
 should be an opt-in option.
 is meant for custom interactions. In interviews thus far (BASE, Friction, Faraday's Law) this role has not yet been understandable or easily operable by users.  Explicit guiding instructions are always needed and these instructions vary by platform (e.g., keyboard, touch).
I also agree with (a) and (b) in the above comment.
We need to tread very carefully with
.

Some buttons will have different markup that uses role="application"
And PressListener will be modified to optionally support keydown and keyup events rather than click events.

This means that we are proceeding with our current input system for catching click events and we will add support for keydown keyup in PressListener when we require them. This issue no longer needs to block publication.

The work described in https://github.com/phetsims/scenery/issues/939#issuecomment-483781361 has been moved to #1117. Closing this issue.

Reopening based on the TODO in the code:
   * TODO: This may change after https://github.com/phetsims/scenery/issues/939 is done, at which point
   * `click` should likely be replaced by `keydown` and `keyup` listeners.

Thanks, I updated the link to point to the new issue referenced in https://github.com/phetsims/scenery/issues/939#issuecomment-729207681


[SYSTEMML-1325] Bugfix for GPU memory manager clear temporary memory

In GPUMemoryManager.clearTemporaryMemory() we deallocate pointers but do not set the corresponding Pointer slots to null in the associated GPUObject instances. This can lead to attempted double-freeing of Pointers which results in an exception. This PR fixes this issue by creating a list of GPU objects associated with Pointers that have been freed as part of clearTemporaryMemory() and setting the corresponding pointer slots to null. This PR also addresses a minor issue with cleanup in JMLC which was causing Pointers for pinned data to be improperly cleared. Note this PR will reduce performance of GPUMemoryManager.clearTemporaryMemory() because it is now necessary to search through the list of managed GPUObjects to find the ones corresponding to pointers being freed. However, this method is only called once at the end of script invocation and so the performance cost will be small.
@niketanpansare can you please take a look and let me know what you think?

Looks good to me. Thanks @thomas9t 👍

@niketanpansare - anything else we need to do here?


fix: support Encoding class for xml write_to

What problem is this PR intended to solve?
Fixes #2774

Have you included adequate test coverage?
The PR adds two tests that cover both setting encoding with a string and the Encoding class.

Question
I discovered that the html5 node write_to (lib/nokogiri/html5/node.rb) also doesn't support the Encoding class, is this something you'd like me to add as well? Where would be a good place to test this? I couldn't find any encoding tests for this class.

@ellaklara Thank you for contributing this! I've kicked off CI. I think we should support this in the HTML5  version as well. If there aren't tests we should definitely add that coverage. I'll take a deeper look in the next day or so.

OK, bug report filed at https://github.com/sparklemotion/nokogiri/issues/2801

@ellaklara OK! I've added a commit on this PR (before yours) that introduces a new file, test/test_serialization_encoding.rb that has some coverage for encoded output for XML, HTML4, and HTML5 serialization methods.
Again, only if you're up for it, it would be great to add Encoding tests there, and make sure they work for all those classes and methods. Let me know either way! :heart:

I'm working on the failing JRuby tests, so don't worry about those!

@ellaklara It's been about a week, so I'm going to go ahead and finish the work you so awesomely started! Will be sure to credit you in the CHANGELOG!


Better organization of sound effects

📝 Description
Fix the mess of gun sound effects by arranging them into groups as follows:

general sound effects
Draw sound effects
Gunshot sound effects
Shotgun slide sound effect
bolt action sound effect
Bullet impact sound effect on game blocks
grenades sound effect
Car sound effect
turret sound effects and accessory activation
Sound effects of the hostile mobs of the mod

🎯 Goals
Better organization and to facilitate the work of sound effects in the future
🚦 Testing
Only a sound effect that does not exist and is not used was removed.
🖼 Screenshots/Recordings
NOP :V
📖 Added to documentation?

[ ] 📜 README.md
[ ] 📑 Documentation
[ ] 📓 Javadoc
[ ] 🍕 Comments
[X] 🙅 No documentation needed

Since it is just a file, it is easy to move it to another branch


Minor ux improvements

I'm happy to split this up into multiple PRs if you'd prefer.
I added two commits with things I forgot to include in the PR. I wasn't sure how you felt about rebasing open PRs. Those commits should probably be combined with the commits they fix at some point, I'm happy to do it whenever.

I like this at a first glance. It is after 10pm here now, so I will look again in my morning and probably merge. Thanks!


Bedrock Text + Paperweight clean setup

Hello, this pull request fixes the paperweight issue of setting up the versions in multiple modules. instead setup the version once with apply false. Updated paper weight to 1.7.1
Bedrock text, server owners now may specify bedrock_text in holograms.yml, and if a player is a geyser user. it'll show this text. Please note I haven't created any command implementations, and adding, removing and inserting is still changing the base text. Maybe something like this should make it implemented to make it more completed.

I would like to see this merged, it would be a very nice feature to have.

Unfortunately yeah some servers have floodgate installed on velocity, and then using geyser standalone so then the server would not even know if the player is a bedrock player. I don't know much about geyser so please suggest a better idea for this kinda setup

Unfortunately yeah some servers have floodgate installed on velocity, and then using geyser standalone so then the server would not even know if the player is a bedrock player. I don't know much about geyser so please suggest a better idea for this kinda setup

The only solution I can think of for this PR is to use floodgate. Floodgate can (and should) be put on all backend servers, the majority of plugins that offer bedrock support will do this through floodgate, if a server owner doesn't want floodgate on their backend servers that is on them and will cause them to lose features in a handful of bedrock compatible plugins.

Unfortunately yeah some servers have floodgate installed on velocity, and then using geyser standalone so then the server would not even know if the player is a bedrock player. I don't know much about geyser so please suggest a better idea for this kinda setup

The only solution I can think of for this PR is to use floodgate. Floodgate can (and should) be put on all backend servers, the majority of plugins that offer bedrock support will do this through floodgate, if a server owner doesn't want floodgate on their backend servers that is on them and will cause them to lose features in a handful of bedrock compatible plugins.

I completely agree, the way of checking of the players name is not nice whatsoever. I'll make sure to revert back to floodgate and make sure that people use floodgate if they want this implementation

I'll have another look at this in the morning :)

This pr got me inspired to work on my placeholder plugin, it's just a basic PlaceholderAPI add-on that adds a config file for defining text that bedrock players and java players will see.
I was wondering if this would be more suitable for you guys?

This pr got me inspired to work on my placeholder plugin, it's just a basic PlaceholderAPI add-on that adds a config file for defining text that bedrock players and java players will see.
I was wondering if this would be more suitable for you guys?

i don't know why i didn't think of this from the start, in fact i think a lot of servers would benefit from this as its not just limited to the fancy holograms plugin.

This pr got me inspired to work on my placeholder plugin, it's just a basic PlaceholderAPI add-on that adds a config file for defining text that bedrock players and java players will see.
I was wondering if this would be more suitable for you guys?

i don't know why i didn't think of this from the start, in fact i think a lot of servers would benefit from this as its not just limited to the fancy holograms plugin.

I did mention this to someone before the pr was made but I guess it didn't make it to you. Nonetheless I do believe that people would still appreciate and use this PR.

I'm going to close up this PR due to it being inactive for a couple months


docs: separate tooling.md and translation.md

Solves: #12414
Changes made:

Placed the content related to tooling in a separate tooling.md file from translation.md file in docs/translating

Testing Plan:
GIFs or Screenshots:

@rossoskull thanks for working on this!  I ended up rewriting the changes as 3225fd39a5138bc219824b43624cfd818630b637 and merging that, because I realized a lot of what I wanted added as part of this migration was a basic explanation of i18n for folks who aren't familiar with it yet.
Thanks for your work on this!


Update Netty Version

Purpose
Part of https://github.com/ballerina-platform/ballerina-standard-library/issues/4908
Examples
Checklist

[ ] Linked to an issue
[ ] Updated the specification
[ ] Updated the changelog
[ ] Added tests
[ ] Checked native-image compatibility

We need to remove the http timestamp version before release.


Clean-up npm scripts (and make them work on Windows)

I'm on Windows, and when working with #29, had to fix the npm scripts in order to get my changes tested. Here are the changes in case you'd like to pull these in.
Note: please test the commands in your (non-Windows) OS to double-check they still work as expected.
Some references about the fixes:

https://github.com/npm/npm/issues/4040#issuecomment-27159695 (about not having /.bin/ dir in the scripts)
https://github.com/npm/npm/issues/2800#issuecomment-15379469 (about how to set env vars for test env in cross-platform way)

@besarthoxhaj do you have time to check this out...?

Thanks @harriha sorry for the delay.


_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+1 :green_heart:
mvninstall
4m  0s
master passed

+1 :green_heart:
compile
0m 50s
master passed

+1 :green_heart:
checkstyle
0m 26s
master passed

+1 :green_heart:
spotbugs
0m 47s
master passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 36s
the patch passed

+1 :green_heart:
compile
0m 47s
the patch passed

+1 :green_heart:
javac
0m 47s
the patch passed

-0 :warning:
checkstyle
0m 23s
hbase-common: The patch generated 2 new + 4 unchanged - 0 fixed = 6 total (was 4)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
18m 11s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
0m 54s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 14s
The patch does not generate ASF License warnings.

38m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3408/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3408

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux ad1252c85398 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 9f4177f7b4

Default Java
AdoptOpenJDK-1.8.0_282-b08

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3408/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-common.txt

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3408/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Thanks a lot for the review, @wchevreuil  @virajjasani  and @tomscut . I'll merge it.


Add support for scoped dependencies

This is a fix to allow scoped packages to be included as dependencies in a zero project. A scoped package name will always start with an @ and must include a /, so we can be reasonably be sure that if it starts with @ we should not split it.

This fixes https://github.com/remoteinterview/zero/issues/10

This looks great! I wonder if it's a valid import if I try to import a file inside a scoped package like:
 import file from @babel/core/somefile

Good point. I took another stab at it, and implemented a regex that should do what we want.
@babel/core/somefile => @babel/core
@babel/core/somefile/someotherfile => @babel/core
bootstrap/dist/css/bootstrap.min.css => bootstrap
babel => babel

Awesome! I am releasing an npm patch in a moment. Thanks!


implement vector_euclidean_to_spherical

Closes: https://github.com/pygfx/pylinalg/issues/14
This PR implements euclidean -> spherical space transformation. It also adds a pb test; however, this will have to wait until https://github.com/pygfx/pylinalg/pull/35 is merged, because then we can add a round-trip test to ensure that the conversion does what we think it does.

@Korijn General question: Is there anything preventing us from using squash-merges instead of normal merges? I always find that squash-merging leads to a much cleaner git history.


[10.x] Dispatch model pruning started and ended events

When the model pruning command has completed I want to run some additional SQL, such as ANALYZE TABLE, on the affected models' tables. The existing events the command dispatches aren't sufficient to do this because they fire per chunk of records deleted. This PR adds starting and ending events, similar to the migrate command, which include an array of the model classes that were pruned.

Renamed - also don't think they should run on pretend tbh.


[Bug]: Error.cause still not being logged

🔎 Search Terms
error, cause
The problem
Error.cause is still not logged even after https://github.com/winstonjs/winston/pull/2447.

What version of Winston presents the issue?
v3.17.0
What version of Node are you using?
v20.18.1
If this worked in a previous version of Winston, which was it?
No response
Minimum Working Example
const winston = require('winston');
const { format, transports } = winston;

const log = winston.createLogger({
  format: format.combine(format.errors({ cause: true }), format.json()),
  transports: [new transports.Console()],
});

log.error(new Error("I'm an error", { cause: new Error('with a cause') }));

Additional information
No response

https://github.com/winstonjs/winston/pull/2467

Why do we have winston/logger.js#L63 and winston/logger.js#L271-L273, if when I run iRoachie's 'Minimum Working Example' above, it tooks me to logform/errors.js#L15? How can I exercise winston/logger.js#L63 and winston/logger.js#L271-L273?


Compute uptime reports

The requirements doc defines uptime as the time when the system is available for computation - it is not "up" if users are locked out for system management reasons.  I don't know how to make that distinction yet, but as an approximation we can define uptime as the time when the system is running sonar data collection.  Sonalyze needs to have an uptime command that prints an uptime report based on the sonar data.  The output should probably be compact, something like
system-name system-came-up-timestamp system-went-down-timestamp

where the last record (if sorted by system-came-up-timestamp) will have a sentinel value for system-went-down-timestamp.
This being sonalyze, the data would be subject to the usual filtering and would have the usual formatting options (text, csv, json).
The requirements currently ask only for historical uptime, which means that the uptime report may be up to an hour old - computed and uploaded at the same time as the load report.
The way we compute uptime is probably by looking at the log, and if there's a gap that is more than the monitoring window then we can assume the system is down.  This means some assumptions about the monitoring window must be passed to sonalyze, most likely.
There's at least one unknown here, which is the precise behavior of Sonar when nvidia-smi times out (which happens often enough to be annoying, see https://github.com/NordicHPC/sonar/issues/92).  We need to make sure a report is still produced in this case.
(I think that if the requirements evolve to want up-to-date status we should implement that some other way than via Sonar.)
Implementation work

[x] #124
[x] https://github.com/NordicHPC/sonar/issues/107
[x] Implement the uptime verb - design report formats and write code
[x] Implement scripts to generate uptime reports and upload them

Blockers (must land first):

[x] #124
[ ] https://github.com/NordicHPC/sonar/issues/107

OK, that method to compute uptime doesn't actually work 100%, because Sonar will write no records if there is no activity on the system; there will be gaps in the timeline when the system is idle.
We'll want to either update how sonar ps works so that it always writes at least one record, or we'll want to add an option to force it to do so.  Then we can choose whether to always write a synthetic record (probably with a special command name "sonar_is_up" and pid=job=0) or to write that only when there is nothing else to write.
(The alternative is to not use sonar for this.  But I think sonar is a good fit and I'll explore that further.)

(Development on branch larstha-implement-uptime in this repo)

For the dashboard code, the most useful report format will be:

only "down" records
json
all hosts together in a single file with the usual -minutely, -daily, -weekly, -monthly suffixes

Live data:
$ sonalyze uptime --data-path ~/sonar/data -f2w --fmt=all --host=ml1 --only-down --interval=4
device  host            state  start             end
host    ml1.hpc.uio.no  down   2023-09-29 12:15  2023-09-29 12:42
host    ml1.hpc.uio.no  down   2023-09-29 12:50  2023-09-29 13:05
host    ml1.hpc.uio.no  down   2023-09-29 13:10  2023-09-29 13:20
gpu     ml1.hpc.uio.no  down   2023-10-04 06:35  2023-10-06 10:05
host    ml1.hpc.uio.no  down   2023-10-06 10:05  2023-10-06 10:30

and (inserted line breaks)
$ sonalyze uptime --data-path ~/sonar/data -f2w --fmt=json,device,host,start,end --host=ml1 --only-down --interval=4
[{"device":"host","host":"ml1.hpc.uio.no","start":"2023-09-29 12:15","end":"2023-09-29 12:42"},
 {"device":"host","host":"ml1.hpc.uio.no","start":"2023-09-29 12:50","end":"2023-09-29 13:05"},
 {"device":"host","host":"ml1.hpc.uio.no","start":"2023-09-29 13:10","end":"2023-09-29 13:20"},
 {"device":"gpu","host":"ml1.hpc.uio.no","start":"2023-10-04 06:35","end":"2023-10-06 10:05"},
 {"device":"host","host":"ml1.hpc.uio.no","start":"2023-10-06 10:05","end":"2023-10-06 10:30"}]

The use of interval=4 is an artifact of #136.

The uptime data (really, downtime data) should probably be folded into the load report on the report generation side, doing it in the client is more hassle than necessary.  naicreport can generate all the data and can perform the merging in a sensible way.  Downtime data can be added as data arrays parallel to the existing data.  (Data volume is becoming an issue but should be addressed separately.)

Folding it into naicreport worked very well, but the resulting plot makes my eyes bleed.  So probably fix #165 along with this one (or add a hack that is sensible and similar in spirit), and then consider upgrading the plotting strategy somehow.


feat(svelte): prefer proxy to allow live updates

Fixes #207

still doesn't seem to work with Vite plugin.


why you have kept, NOSCAN=1?

curl -sSL https://download.sourceclear.com/ci.sh | CACHE_DIR=/tmp NOSCAN=1 bash
by default value of NOSCAN=0, why you have kept it 1

We do that in the Dockerfile just for the side effect of installing the agent. It only runs later, when a container is created.

Closing because not a bug or an issue.


Logging should only be triggered when Secureli Scan is run from a pre-commit hook not from running via the scan command directly in the CLI

On Init and secrets are discovered in the repo should we log those secrets? Yes those should be logged and sent to the observability backend.

Need to refine this more with Caleb to get more information on the expected behavior.

when logging is enabled, scan action shouldn't send logs to observability API (can print locally) when called by CLI. Should only send logs during pre-commit scan action, not manual CLI call of that action.

This appears to be the existing functionality. Not sure when it was implemented, it very well may not have been the case when this ticket was submitted. But the current functionality is that publishing is set to never by default. You need to include --publish-results=always in order to publish results.
The pre-commit hook does have that parameter/value, and so results will always be published when secureli is run via the hook.

Moving to done, as this issue was resolved at some point in the past.


Use ID from request URI instead of this from request body

Summary
Currently, most of the PUT endpoints require for user to put resource ID both in URI and request body. The first one is hovewer ignored in most cases. Let's change that behaviour.
Details
Application should use only ID from URI - the request one should be ignored.
It it possible that modification of some of the common REST classes will do the trick.
Acceptance criteria

[ ] PUT endpoint uses only the ID from the URI
[ ] Update Swagger documentation (i.e. PUT from /users/ endpoint)

Additional context
N/A

Completed in two pull requests: #132 and #133


LiteXLTeam.LiteXL version 2.1.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.1 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

I'll fix as many of these as possible right now, but lite-xl 2.1 hasn't been launched in the main repo yet, and considering the following point in the docs:

Only one pull request per package version is allowed.

I think I should wait until jgmdev's PR is accepted for getting the winget package out. (for this, I have communicated with the core team, and they have recommended me to wait for the release to be out)
Should I close this PR? or will it be set to a draft PR until version 2.1 of lite-xl is officially released?

I'll fix as many of these as possible right now, but lite-xl 2.1 hasn't been launched in the main repo yet, and considering the following point in the docs:

Only one pull request per package version is allowed.

I think I should wait until jgmdev's PR is accepted for getting the winget package out. (for this, I have communicated with the core team, and they have recommended me to wait for the release to be out)
Should I close this PR? or will it be set to a draft PR until version 2.1 of lite-xl is officially released?

I would change the package identifier here to jgmdev.LiteXL and then when the official package is released I would put it under the package identifier LiteXL.LiteXL


US 06.02.01

As a user, I want to be able to edit my profile.
Requirements/Prerequisites:

The username should still be unique.
The user should be able to edit or update their name.
The user should be able to edit or update their bio.

The username should still be unique. ✅
The user should be able to edit or update their name.  ❌
The user should be able to edit or update their bio.  ❌

The username should still be unique.✅
The user should be able to edit or update their name.✅
The user should be able to edit or update their bio.✅
Input validation (character limit) should be done for all the text fields.✅

Only tests left.

Tests all done! ✅


Add English/Chinese Version

Please.

I have English language support. However, in some places I forgot to translate.....

Chinese I'm unlikely to support because I'm not a native speaker of the language, nor do I have native speaker acquaintances, nor do I have the money for a professional translator.

我可以试试
I want to do.
but I'm pupil.(12 year's old, CHN)

When I release the next version, I will write to you


Feature/dnssec updates

I've merged the deploy into this branch. When you think it's ready, we can merge into staging @mdtanrikulu


collections.OrderedDict in test_mio.py

in test_mio.py, the try/except is unnecessary, as the code is only tested on Python 2.7. The chunk is 6 years old, which probably explains the fallback.
try:
        from collections import OrderedDict
    except ImportError:
        pass
    else:
dict_types += ((OrderedDict, True),)

Indeed it looks like a historical relic, do you have time to make a quick PR to simplify this?


New tool: git-safe-dependencies

A new tool to help people get their git dependencies safely.
It's all an elaborate linter.
A prompt review would mean I can release it as alpha and recommend to people online who are already concerned with my findings that this is addressing ;)

@naugtur Well, it's definitely missing a TS config 🤣


better handling of mal-formed sequence input

putting non-fasta data in the form (or uploading via file) causes:
Disconnected from the server.
Reload

should instead say something incredibly helpful and informative!

Fixed in commit 48aa457.


[BUG] - cardano_node_metrics_txsProcessedNum_int stays always at zero - 1.24.1

External
Summary
The prometheus/metrics output of .cardano_node_metrics_txsProcessedNum_int stays always at zero in 1.24.1 (master), it worked in 1.24.0. But 1.24.1 introduced a lot of metrics-name-changes, so there must be a mismatch somewhere.

Hmm, now it worked with an additional test. I will keep an eye on that, maybe false alarm.

So, this happens because https://github.com/input-output-hk/cardano-node/blob/master/cardano-node/src/Cardano/Tracing/Metrics.hs#L143-L145 underreports the metric, by reporting its old state.

Thank you @gitmachtl!

Fixed in https://github.com/input-output-hk/cardano-node/pull/2192


Initialize TCP write and error closures only once.

We are initializing the closures in the hot path on every event.

thanks


Full screen support.

Hi, Is there any chance you could guys add the form factor to gen_main.min.js and gen_index.min.js as full screen and direct it to some config file with max resolution and some keymap to exit app  ? This would be very handy feature.

How do you load an app full screen? The instructions are not clear on that page.
"Tweak Apps
Add "resize": "scale" to "arc_metadata" in manifest.json."
I open manifest.json with a text editor. But I do not see the line "arc_metadata". Is this something I have to add myself? Or do I just add "resize": "scale" somewhere in one of the lines? Or does it look like this?
"arc_metadata": "resize": "scale"
or this
"resize": "scale"
And exactly where in the manifest.json file do you add this line?
The instructions are not clear on how to do this.


Dark Theme Toggler

It'll be nice to let people have options for theme style and let them decide.

Resolved in https://github.com/sinix-dev/sinix/pull/61

Resolved in https://github.com/sinix-dev/sinix/pull/61


Views hash syntax

Retriggered specs since this failed https://github.com/sudara/alonetone/issues/187

Retriggering due to https://github.com/sudara/alonetone/issues/187 https://travis-ci.org/sudara/alonetone/builds/418514549


Compilation failed: linking globals named when integrate sentry multiplatform

Hi. I'm trying to integrate sentry multi platform for my project.

After integration, I get an error when building for ios

How can I solve this problem?
Thank you in advance

@TheMrDOC111 do any of your modules or dependencies already have Sentry in it?
Also check https://docs.sentry.io/platforms/kotlin-multiplatform/#install
Your cocoapods block is slightly different than ours, not sure if that's the case.

@marandaneto, Hi
No, this is the only place where I integrate sentry
Here is the full connection code:
plugins {
  alias(libs.plugins.multiplatform)
  alias(libs.plugins.compose)
  alias(libs.plugins.cocoapods)
  alias(libs.plugins.android.application)
  alias(libs.plugins.libres)
  alias(libs.plugins.buildConfig)
  alias(libs.plugins.kotlinx.serialization)
  alias(libs.plugins.sqlDelight)
  alias(libs.plugins.apollo)
}

kotlin {
  android {
    compilations.all {
      kotlinOptions {
        jvmTarget = "1.8"
      }
    }
  }

  iosX64()
  iosArm64()
  iosSimulatorArm64()

  cocoapods {
    version = "1.0.0"
    summary = "Compose application framework"
    homepage = "empty"
    ios.deploymentTarget = "11.0"
    podfile = project.file("../iosApp/Podfile")
    pod("Sentry", "~> 8.7.2")
    framework {
      baseName = "ComposeApp"
      export("io.sentry:sentry-kotlin-multiplatform:0.1.1")
    }
  }

  sourceSets {
    val commonMain by getting {
      dependencies {
        api("io.sentry:sentry-kotlin-multiplatform:0.1.1")
        implementation(compose.runtime)
        implementation(compose.foundation)
        implementation(compose.material)
        implementation(libs.libres)
        implementation(libs.voyager.navigator)
        implementation(libs.composeImageLoader)
        implementation(libs.napier)
        implementation(libs.kotlinx.coroutines.core)
        implementation(libs.ktor.core)
        implementation(libs.composeIcons.featherIcons)
        implementation(libs.kotlinx.serialization.json)
        implementation(libs.kotlinx.datetime)
        implementation(libs.multiplatformSettings)
        implementation(libs.multiplatformSettings.serialization)
        implementation(libs.multiplatformSettings.noArg)
        implementation(libs.koin.core)
        implementation(libs.koin.core)
        implementation(libs.kstore)
        implementation(libs.apollo.runtime)

        implementation("io.ktor:ktor-client-content-negotiation:2.2.4")
        implementation("io.ktor:ktor-serialization-kotlinx-json:2.2.4")
        implementation("io.ktor:ktor-client-logging:2.2.4")
      }
    }

    val commonTest by getting {
      dependencies {
        implementation(kotlin("test"))
      }
    }

    val androidMain by getting {
      dependencies {
        implementation(libs.androidx.appcompat)
        implementation(libs.androidx.activityCompose)
        implementation(libs.compose.uitooling)
        implementation(libs.kotlinx.coroutines.android)
        implementation(libs.ktor.client.okhttp)
        implementation(libs.sqlDelight.driver.android)
        implementation("io.insert-koin:koin-android:3.3.2")
      }
    }

    val iosX64Main by getting
    val iosArm64Main by getting
    val iosSimulatorArm64Main by getting
    val iosMain by creating {
      dependsOn(commonMain)
      iosX64Main.dependsOn(this)
      iosArm64Main.dependsOn(this)
      iosSimulatorArm64Main.dependsOn(this)
      dependencies {
        implementation(libs.ktor.client.darwin)
        implementation(libs.sqlDelight.driver.native)
      }
    }

    val iosX64Test by getting
    val iosArm64Test by getting
    val iosSimulatorArm64Test by getting
    val iosTest by creating {
      dependsOn(commonTest)
      iosX64Test.dependsOn(this)
      iosArm64Test.dependsOn(this)
      iosSimulatorArm64Test.dependsOn(this)
    }
  }
}

[versions]

kotlin = "1.8.20"
agp = "7.4.2"
compose = "1.4.0"
androidx-appcompat = "1.6.1"
androidx-activityCompose = "1.7.0"
compose-uitooling = "1.4.1"
libres = "1.1.8"
voyager = "1.0.0-rc05"
composeImageLoader = "1.4.0"
napier = "2.6.1"
buildConfig = "3.1.0"
kotlinx-coroutines = "1.6.4"
ktor = "2.2.4"
composeIcons = "1.1.0"
kotlinx-serialization = "1.5.0"
kotlinx-datetime = "0.4.0"
multiplatformSettings = "1.0.0"
koin = "3.4.0"
kstore = "0.5.0"
sqlDelight = "2.0.0-alpha05"
apollo = "3.8.0"

Hi, could you try using the pod version 8.4.0 of Sentry?

@buenaflor the docs state 8.7.2, but we use 8.4.0 https://github.com/getsentry/sentry-kotlin-multiplatform/blob/332164a58e37aba8fca0c17b94efcee3d83a9adc/buildSrc/src/main/java/Config.kt#L37
Should we fix the docs right away? what was the reason for having the newest version?

@marandaneto I have a PR ready in the sentry docs fixing a couple issues including setting the Cocoa version.
But I'm not sure if this fixes the error, I tested it out and couldn't reproduce the error with 8.7.2. I haven't seen that error yet in general myself

@buenaflor,
When I changed the version to 8.4.0, it fixed the previous error, but another one appeared
/Users/adtarassov/AndroidStudioProjects/Entity/iosApp/iosApp/iosApp.swift:26:8: error: type 'ComposeView' does not conform to protocol 'UIViewControllerRepresentable'
struct ComposeView: UIViewControllerRepresentable {
       ^
/Users/adtarassov/AndroidStudioProjects/Entity/iosApp/iosApp/iosApp.swift:26:8: note: do you want to add protocol stubs?
struct ComposeView: UIViewControllerRepresentable {

But I didn't change anything in this file, most likely the problem is in the generated links

@TheMrDOC111 that does not seem related to Sentry though.

@marandaneto, maybe. But this error appears only when I connect Sentry 8.4.0. If I don't integrate Sentry, ios project builds fine

@TheMrDOC111 If you could provide a minimal reproducible sample it would be greatly helpful, this might be an edge case since we don't have explicit support for iOS compose yet

@TheMrDOC111 If you could provide a minimal reproducible project sample it would be greatly helpful, this might be an edge case since we don't have explicit support for iOS compose yet and since it's compose ios still alpha it's hard to tell what's wrong from code snippets.
Other than that I'd suggest for you to remove export("io.sentry:sentry-kotlin-multiplatform:0.1.1") from your framework configuration in build.gradle.kts and see what happens.
I suspect the issue is that io.sentry.kotlin.multiplatform.Context clashes with the Context from Compose that's why it might not be able to conform to the UIViewControllerRepresentable protocol when exporting it as a framework.
We are currently working on improving the docs as exporting the framework is not necessary to install the SDK but rather optional.

Oh my God.
I deleted export("io.sentry:sentry-kotlin-multiplatform:0.2.0") and now everything is working. Thank you very much!


One resource added under the Container section in  README.md

A Docker tutorial was added in the Container section.

Fixes Issue

Changes proposed
Complete Docker Course - From BEGINNER to PRO! tutorial added in the container section.
Screenshots

Note to reviewers

This tutorial was also applauded by Saiyam Pathak in socials. Link

Is my fresh commit visible?
I have sorted the requested changes.

Happy to Contribute 🙃.


Delete prometheus-dcos dockerfile

Motivation
Clean up our docker directory in the pulsar project.
We have unmaintained files for a custom prometheus docker image that adds a small prometheus.yaml file to the prometheus docker image. The prometheus version in the dockerfile is v1.8.2. The latest version is v2.32.0. We haven't modified this section of the code for 3 years since its initial commit in PR #1127. Since this is unmaintained, I'd like to propose removing it from our repo.
Note, we were not building or publishing the docker image created by this dockerfile.
Modifications

Delete the docker/prometheus-dcos directory.

Verifying this change
We don't currently build/publish this docker image. It is possible that some users are interested in the prometheus.yaml file. I will send a note to the mailing list to discuss this feature's removal to make sure it is not being used.
Does this pull request potentially affect one of the following parts:
This is a deprecation of a feature that likely hasn't been used very much.
Documentation

[x] no-need-doc

As far as I can tell, there are no docs related to this feature.

Note that we technically reference this docker image here: https://github.com/apache/pulsar/blob/c5d7a84c8e5c27e48022df8c7082496840cd3be9/deployment/dcos/PulsarGroups.json#L250-L254.
However, that is a reference to a private docker repo, and not the apachepulsar docker repo. I just ran docker pull zhaijia/prometheus and it returned an image that is between 3 and 4 years old.
It's possible we should remove the deployment/dcos directory. It was last updated in May 2018.