Fixes #1512, don't save edits with no clips

[JamesUoM]

Before allowing the edits to be saved/processed, check that there isn't a single segment that deletes the whole video. Otherwise Opencast will create a SMIL file with not clips and the editor WOH will fail.

[github-actions]

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1517/2024-12-11_11-36-08/ .
It might take a few minutes for it to become available.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1517/2024-12-11_11-41-22/ .
It might take a few minutes for it to become available.

[Arnei]

I've found some things that I believe should be addressed before merging.

I'm not happy with how we present the user with the problem. Simply replacing the usual save text with a warning is not obvious at first glance and does not really make clear that it is supposed to be warning. Maybe keeping the usual text and instead adding a warning box would be better? (Could use the error boxes from appkit for that hint hint #1392). I would also prefer to keep rendering the save button, but disable it.

[JamesUoM]

Maybe keeping the usual text and instead adding a warning box would be better? (Could use the error boxes from appkit for that hint hint #1392). I would also prefer to keep rendering the save button, but disable it.

Agree with using the error boxes. But disabling buttons is not meant to be good accessible UX design - also I did try but as they are not form elements, disabling doesn't work. The aria-disabled will tell screen readers that it's disabled but doesn't stop it functioning.

[github-actions]

This pull request is deployed at test.editor.opencast.org/1517/2024-12-18_14-09-53/ .
It might take a few minutes for it to become available.

[Arnei]

My concerns have been addressed, thanks!

But disabling buttons is not meant to be good accessible UX design

I disagree with this as a general statement. While disabling a button alone is indeed not good UX, I do believe it can be valuable if there are additional measures taken that make it clear to the user why it is disabled. It then helps making clear that there indeed would be a button here that they could click, instead of having the button suddenly appear.

But apparently whether disabling buttons is a good or bad thing is a whole big discussion that I do not find worth getting into since the PR looks fine to me.

also I did try but as they are not form elements, disabling doesn't work. The aria-disabled will tell screen readers that it's disabled but doesn't stop it functioning.

Oh good to know. That's an issue with ProtoButton from appkit, right? I'll open an issue over there.

[github-actions]

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

[gregorydlogan]

If/when you fix this @JamesUoM, remember to change the branch target to r/17.x if you want this in a 17.x release!

Nevermind, turns out I can fix that myself.

[gregorydlogan]

@JamesUoM this, IMO, should still be fixed. But maybe in 18/19 since we probably don't want to change this in legacy at this point.