Auto DJ: (Re-)enable search in the Auto DJ view by cr7pt0gr4ph7 · Pull Request #13337 · mixxxdj/mixxx

cr7pt0gr4ph7 · 2024-06-06T19:17:42Z

The search feature for the Auto DJ view was originally disabled by 54f71ea over 12 years ago.

We now have some new tools available, which means we can implement a workaround instead of disabling search altogether. Searching within normal playlists is already possible and works correctly, and the Auto DJ queue is basically just another playlist, so being able to search there matches user expectations.

The implementation here reuses the ProxyTrackModel code already used by the file browser view for the actual filtering behavior (4970e30). Most of the changes here are for making BaseSqlTableModel play nicely with ProxyTrackModel (75ce4d0), for making cut, copy & paste work (62c3a0f) and behave correctly w.r.t. keyboard focus (35569a4).

This enables correct filtering of proxy models that wrap an instance of BaseSqlTableModel (or a subclass).

The search feature for the Auto DJ view was originally disabled by 54f71ea over 12 years ago. We now have some new tools available, which means we can implement a workaround instead of disabling search altogether. Searching within normal playlists is already possible and works correctly, and the Auto DJ queue is basically just another playlist, so being able to search there matches user expectations. We reuse the ProxyTrackModel code already used by the file browser view, so this shouldn't cause any additional problems.

This is to allow these actions to work as expected in the Auto DJ view. Whether these actions are allowed or not should be determined by the underlying TrackModel, and not by the ProxyTrackModel.

This fixes the focus behavior of copy/cut/paste in the Auto DJ view.

cr7pt0gr4ph7 · 2024-06-06T20:02:12Z

Huh, seems like I found a slight bug with the code formatting rules when confronted with changes in files that contain old, wrongly indented code. Fixing the indent of the old code makes the issues with the new code disappear... so that's what I will be doing. Don't know enough about clang-format to know if there's a config option that would fix this.

…d issues with clang-format This prevents clang-format from inferring the wrong indent sizes for other parts of the file.

ronso0 · 2024-06-06T22:14:36Z

Just a hint: IIRC from a related discussion, one of the reasons to keep the search disabled in Auto DJ was that it is not obvious that the view is filtered. A possible solution, also relevant here IMHO, would be inserting narrow, empty dummy lines where the invisible tracks would be. Not sure how that could work though.

cr7pt0gr4ph7 · 2024-06-07T09:23:09Z

Just a hint: IIRC from a related discussion, one of the reasons to keep the search disabled in Auto DJ was that it is not obvious that the view is filtered. A possible solution, also relevant here IMHO, would be inserting narrow, empty dummy lines where the invisible tracks would be. Not sure how that could work though.

Okay, I understand the concerns. I tried to look up the discussion you where mentioning, but couldn't find it. After thinking a bit about it, let me explain my reasoning why I think this is should not be a problem in practice.

cr7pt0gr4ph7 · 2024-06-07T09:23:26Z

Update / TLDR: See my comment below for an overview, and then possibly come back for the detailed reasoning here.

As I see it, there are three problems to be avoided here:

How do we avoid users from being confused by not being able to see all tracks in the Auto DJ playlist?
- Consistency: I'd argue that because the same can be said about filtering the main library, playlists and crates, users should learn about this behavior pretty quickly simply by us being consistent throughout the application. If we worry about that, we should worry about the other places in the application, too.
- Teachability: As soon as a user starts to type in the search field, they see the immediate effect of the list being filtered. If they reverse their recent action (entering the text/one more character), the original list is being shown again. I'd argue that this is a pretty effective way of teaching user's how filtering works. And if you never use the search field, you are never confronted by this anyway.
- Visual Indicators: The entered search is stored separately per library view. There is the chance of forgetting that you entered a search term in this view before, but I'd argue that by combining the visual indicator of the search field's text changing with the fact that this can happen everywhere else, too, users will quickly (and also have to) learn to check the search field in those cases anyway.
How do we avoid users from being surprised that a track they couldn't currently see was picked as the next track by the Auto DJ?
- This one's a bit trickier, but I think it again boils down to:
  - Teachability: How do we teach users that currently-invisible tracks are still present in the (Auto DJ, but also other) playlists?
    - In the out-of-the-box default configuration, the Auto DJ view has a "#" column visible, which shows the index of the track (in the unfiltered playlist) even when the playlist is filtered.
  - Visual Indicators: How do we indicate that the playlist is currently being filtered?
    - The same way as in all other library views: By there being text in the search field (and maybe an additional visual indicator, see below).
- If we look to e.g. Spotify, they have a similar feature for filtering playlists, with the same behavior as implemented here (filtering hides tracks temporarily but still plays them). I'd guess they've done a lot of usability testing and A/B testing,
How do we avoid users from being confused because they can't see any tracks (due to their search terms filtering out all available tracks)?
- This may be an actual problem in practice (at least when going from my own, personal experience/confusion), but isn't limited to the Auto DJ view. The confusion mainly stems from the fact that my perception that I have successfully switched to a different library view is based on the list of tracks in the track table changing.
- My suggestion would be to insert a visual indicator when some (or all) tracks have been filtered out due to the current search and/or when the current playlist/crate/view didn't contain any tracks whatsoever even before filtering. There are two alternatives I can think of (centered text in the background, or an unselectable "phantom row" at the end of the tables), I'll try to craft a proof-of-concept pull request.

cr7pt0gr4ph7 · 2024-06-07T09:37:34Z

These are just my two cents, though. I appreciate feedback whether I missed something!

As an aside, here are possibly related issues from the past that I could find:

Search
Sorting (only tangentially related w.r.t. the implementation in this PR, but related to the user's mental model of filtering and sorting playlists)
- Sort by column in Auto DJ #11107
- No Sorting in AutoDJ List after update to 1.10 #6335

If if I infer everything correctly, the limitations for searching & sorting the Auto DJ queue were primarily motivated by technical restrictions, and not by user expectations. As explained by @daschuer in this comment on #6335, most users probably expect the Auto DJ queue to behave like a playlist.

cr7pt0gr4ph7 · 2024-06-07T10:09:50Z

My personal, real-world use case that motivated this PR is this:

I have prepared a 3 hour/100 track playlist in the Auto DJ queue for a dance party, and want to remove a specific track from the queue because I have added another copy of it near the top of the queue during the course of the party.

Without neither search nor sorting, this is an arduous task - that's why we have search. Inserting narrow placeholder rows or greying out filtered out tracks instead of fully hiding them would be slightly better, but would still force me to scroll through a large list of tracks.

It seems to me that there are three camps of users:

Those that want to interact with the Auto DJ just like with a playlist, including sorting & filtering, and whose mental model is that Mixxx will play the underlying playlist, and not their filtered view of it. (This is the solution proposed here, and the one employed by other music players like Spotify)
Those that expect the visible list in the Auto DJ view to be what will be played, including sorting (and probably filtering, for the sake of consistency). There are some consistency problems with implementing this IMO, but it would be possible. (This is the solution proposed in No Sorting in AutoDJ List after update to 1.10 #6335 AFAIU)
Those that fall in the middle of not particularly needing to filter a large Auto DJ queue, and either do not expect the filters/sorting to affect the play order, or do not care because they don't use (or know about) it anyway. The main concern is to prevent those users from accidentally shooting themselves in the foot through unintended filtering. (This correlates with the compromise of greying out tracks instead of hiding them, as proposed before).
And the fourth solution: Disabling search to postpone a decision on the behavior.

I think that the second solution conflicts with how playlists (that is, the specific objects called "playlists" in the UI, not the general concept which also includes in the Auto DJ queue) behave currently in Mixxx, and thus is undesirable in my opinion, but could be solved using a config option or separate feature. The third and fourth solutions are compromises that give noone what they want, except for the people that do not need or use the feature anyway.

ronso0 · 2024-06-07T10:25:21Z

Thanks for elaborating!

Visual Indicators: How do we indicate that the playlist is currently being filtered?

The same way as in all other library views: By there being text in the search field (and maybe an additional visual indicator, see below).

tracked by #7922

ronso0 · 2024-06-07T10:46:32Z

How do we avoid users from being confused because they can't see any tracks (due to their search terms filtering out all available tracks)?

I think a status bar / info bar could also solve this. (stale PR #3406).

an unselectable "phantom row" at the end of the tables

That wouldn't help much IMO. If the filtered tracks fill the view such a bottom row wouldn't be visible.

daschuer

I can confirm your use case.

However, I am strictly against filtering and sorting in the Auto-DJ playlist. The reliable view what will happen next is, IMHO much more important than any desire for sorting and filtering.

I often search for a successor and forget to go to the Track view first. If that happens with Auto DJ late at night, even a warning bar would be not enough, considering other visual clutter we have already.

I like however @ronso0 idea to highlight and probably select and auto scroll to the filter matches. That is IMHO quiicker as a normal filtering for your tracks.
You just need to press del and the tracks are gone.
What do you think?

cr7pt0gr4ph7 · 2024-06-08T19:23:33Z

I can confirm your use case.

However, I am strictly against filtering and sorting in the Auto-DJ playlist. The reliable view what will happen next is, IMHO much more important than any desire for sorting and filtering.

After giving it some more thought, I can't really come up with a valid use case for sorting an already running Auto DJ playlist, either, so we can restrict the discussion to filtering only, and see whether we can find a good solution for that.

I often search for a successor and forget to go to the Track view first. If that happens with Auto DJ late at night, even a warning bar would be not enough, considering other visual clutter we have already.

Yeah, I'd be kind of opposed to a warning bar / status bar at the bottom of the screen, too, due to its distraction potential. The search bar is basically the main entry point for starting to interact with tracks/playlists (see #13200), so any visual indicators or such, if any, should be in close visual proximity to it or the track list, because that are the places users will look at.

I think that your use case is very valid. Just to understand correctly, what are your main concerns/issues you want to avoid?

Accidentally modifying the Auto DJ playlist
Taking too long to realize that you're in the Auto DJ view, and won't find the tracks you are looking for there
Taking a glance at the Auto DJ playlist to see what will be played next, and not noticing that there is a filter active

Also, for clarification, are you using an external DJ controller or a Mixxx-only setup? (For context, I'm running Mixxx on a laptop and do not have any experience whatsoever with external controllers).

I like however @ronso0 idea to highlight and probably select and auto scroll to the filter matches. That is IMHO quiicker as a normal filtering for your tracks. You just need to press del and the tracks are gone. What do you think?

I don't know about introducing a whole different behavior of the search control just for one library view, though. That has a great potential for confusion, and feels a bit like overkill. I like the idea of scrolling, but that only works well for a single selected track. As soon as multiple tracks are selected, you have to find a way for the user to see that there are offscreen track which are selected, and for the user to cycle through those tracks, ... it removes one potential issue but creates others.

cr7pt0gr4ph7 · 2024-06-08T19:36:24Z

The best solutions I think of so far (based on the suggestions here and elsewhere) are:

Providing a config option to enable/disable searching the Auto DJ view (but that feels like cheap pseudo-solution because it's not really discoverable for new users)
Visually indicating that there are rows which have been filtered out in the Auto DJ track list itself:

#	Title	Artist	Album
1	... Filtered out ...
2	Some track	A	B
3	Some other track	A	B
4 - 8	... Filtered out ...
9	Another track	C	D
10 - 50	... Filtered out ...

ronso0 · 2024-06-08T21:58:30Z

I like however @ronso0 idea to highlight and probably select and auto scroll to the filter matches. That is IMHO quiicker as a normal filtering for your tracks.

For the record, I didn't propose that (here ; ) Maybe in some ancient combo. I agree it's bad UX)

Let's take a step back and ignore the imlipcit constraints we set when thinking of the AutoDJ as a regular (playlist) view, e.g. when sorting all rows are sorted, when filtering the filter is strict, no exceptions.

There are basically two situations where filtering and/or sorting can be applied, AutoDJ ON or OFF, but IMO there are different constraints / requirements / expectations:

AutoDJ on:
- I agree the next 1, 2, 3 queued tracks should always be visible
- sorting like in other views can be very confusing, especially in the heat of the night
AutoDJ off:
- no restrictions required, it's just a playlist

In both situations filtering / sorting may be desired, mostly like in playlists:

clean up the view, remove duplicates
find a good next track (BPM, key, genre, artist ...) and pull that to the top (drag or with Alt keys, Alt+Home/PageUp)
- here we have to views: sorted/filtered with a selection and unfiltered, sorted by #
- it is absolutely necessary that the selection from the filtered/sorted view is maintained when switching back to the # view in order to move it to the desired position

So if we now have a somewhat independent table model (at least we can tweak the filtered view to our liking) could it be possible to present the filtered view differently?

Like I mentioned above: when filtering, indicate that tracks (spans) are hidden by replacing the hidden tracks with some sort of placeholder? an empty row that is only half the height of a normal row, perhaps with filled with a gradient or other type of infill that distinguishes it from a regular track row?
edit oh, I overlooked @cr7pt0gr4ph7's proposal above. Showing the hidden # range would be great (though we'll debate the "... Filtered out ..." placeholder 😆 )
enforce the # column, always left most column, paint it in a special way if the queue is not sorted by Rename colours? #12719
Maybe turn it into a vertical header so it's always visible?

What do you think?

daschuer · 2024-06-09T00:10:19Z

I agree the next 1, 2, 3 queued tracks should always be visible

I can confirm. They can be grayed out or such. That's still ok for me.

For the rest, the view proposed in #13337 (comment)
works for me. However I would prefer to see all of them grayed out. This should be more easy to implement.
From there we can than interate after some brief testing.

cr7pt0gr4ph7 · 2024-06-10T09:37:15Z

Let's take a step back and ignore the imlipcit constraints we set when thinking of the AutoDJ as a regular (playlist) view, e.g. when sorting all rows are sorted, when filtering the filter is strict, no exceptions. [...]

I agree with your analysis.

I agree the next 1, 2, 3 queued tracks should always be visible

Yeah, that would work for me, too. We could maybe implement these "next tracks" kind of like pinned table rows that are always visible. That would also make the (probably pretty common) use case of dragging something from later in the queue to e.g. the third place pretty easy.

Update: Maybe like this? (Not implemented yet, just a quick mockup using GIMP)

Enforce the # column, always left most column, paint it in a special way if the queue is not sorted by #. Maybe turn it into a vertical header so it's always visible?

Pinning the '#' column so it is always visible (even when scrolling to the right) sounds good. That would also reinforce its special meaning.

If we decide to allow sorting, highlighting the '#' sounds like an idea we can try, although I'm a bit cautious to not add too much visual noise. But if we decide to do that, we could combine it with a tooltip when hovering over the highlighted '#' column that explains "Sorting only affects the visual display. Play order is indicated by the numbers in the '#' column.".

As an additional idea, we could also put an orange border around the Auto DJ view to indicate active filtering/sorting.

However I would prefer to see all of them grayed out. This should be more easy to implement.
From there we can than interate after some brief testing.

I need the filter to reduce the number of visible tracks, so that all (or most) tracks found by the filter are visible on the same screen, so hiding/collapsing at least some of the tracks would be required for me. I'll have a look at implementing a proof-of-concept.

When filtering, indicate that tracks (spans) are hidden by replacing the hidden tracks with some sort of placeholder? an empty row that is only half the height of a normal row, perhaps with filled with a gradient or other type of infill that distinguishes it from a regular track row?

Yeah, some visual indicator would be good. Just graying out tracks conflicts with the "already played" indication of tracks, so we have to be at least somewhat different to that. Although maybe a different, darker grey is enough.
I'm not a huge fan of half-height rows because they disrupt the vertical visual rhythmn, but maybe I'm just prejudiced.

daschuer · 2024-06-10T11:50:11Z

Let's not allow sorting.

What is the reason you need to see all filter matches on a single page?

If we pin the first four, and than replace the hidden rows with a single line as you demonstrate above that could work. Maybe with a + icon to uncollapse these rows and remove the filter.

github-actions · 2024-09-10T00:09:03Z

This PR is marked as stale because it has been open 90 days with no activity.

cr7pt0gr4ph7 · 2024-09-11T08:45:08Z

Sorry, this PR is still active, just didn't find time to work on it. I'll try to implement the requested features some time in the next months.

github-actions · 2025-01-23T00:09:20Z

This PR is marked as stale because it has been open 90 days with no activity.

ronso0 · 2025-11-11T00:54:32Z

Coming back to this after I read https://mixxx.discourse.group/t/search-function-for-auto-dj/32934

Recently I noticed that Betterbird (a ThunderBird fork) changes the background of the email list when a Quick Filter is active. It's pattern of diagonal lines, clearly distinguishing the regular, full view from the filtered one.
I think it's dark grey lines for 'filtered' and drak red lines for 'filtered, no matches'.

So, while I like some of the ideas we discussed here (especially keeping next 1-3 tracks visible), I'd prefer to implement this kind of "filtered" indicator and only keep tracks 1,2,3.

I'll publish a quick POC when it's ready.

daschuer · 2025-11-11T07:53:49Z

Nice, here is a screenshot for reference.
https://share.google/ZisdK9DNbGhHFDgL0

cr7pt0gr4ph7 · 2025-11-11T09:59:27Z

Sorry, I haven't been active for the last months due to other things requiring my time.

Just for reference, I've been running this patch¹ in production for 1,5 years now (including at dance parties and weddings) and can offer my experience so far:

Filtering the Auto DJ view is really useful for changing play order on the fly based on the mood, especially when you (1) have prepared a large playlist, (2) use the shuffle feature, or (3) want to see whether you already have tracks of this specific artist in your setlist.

What I'm mostly missing is just a context menu entry for Move to Top/Bottom (Auto DJ Queue), which would nicely mirror the Add to Auto DJ Queue (top/bottom/replace) entries². My current workaround is using Ctrl+X -> Ctrl+V.
Also a Play Next (Auto DJ) / Load as Next (Auto DJ) / Move to Top (Next Track) entry would be nice if I want to replace an already loaded next track. My current workaround is "Disable Auto DJ (Shift+F12)" -> "Add to Top" -> "Enable Auto DJ (Shift+F12)", but that's annoying if time is of the essence.

Thinking about it, it could also make the most sense if we have the following set of context entries: Move to Top (Play Next), Move to Top+1, Move to Top+2, Move to Top+3, Move to Bottom, as that allows for the common use case of planning out the next few tracks.

The issue of "Why the f* don't I see this track..?!?... ooooh, I have a filter active" isn't exclusive to the Auto DJ view, but applies to all views equally.

I've learned to subconciously check whether the search field has content, but a visual indication (like a small orange border around the search field or the table, or a colored background for the search field, or a striped background like Betterbird) would be nice³.

Based on my experience, I don't feel like we need to insert placeholder rows, for the following reasons:
1. The index column already tells the same information.
2. The immediately next track is always visible in the deck.
3. Users are most likely to learn quickly if we offer a single, uniform visual indication for filtering that's consistent across all other views as well.
4. Vertical screen space is limited, especially when using 4 decks on a laptop.
The much bigger Auto DJ-related footgun is that "Move to Auto DJ Queue (replace)" doesn't ask for confirmation before accidentally clearing out your 3 hour playlist (though that may have been fixed in newer versions, as I'm currently running an older version due to my extensive patches), and there's no "Undo" function.
Also, a placeholder (or different visual indication) when your search filters out all tracks would be useful. Betterbird uses a red striped background instead of gray striped background, but I would tend to propose just a line of text Your current search "<search text>" filters out all tracks (Click here to clear filter) (or No tracks found... (click here to clear filter)) in italics.

The placeholder should be selectable, so that a pressable navigation knob on a DJ controller can be easily used to clear the filter.

Which enables filtering but still disallows sorting. ↩
And should probably be mapped to the same keyboard shortcuts. ↩
Sidenote 2: We should probably delegate the decision of the specific visuals to the skin, that is: (1) Whether to highlight the search field, the tracks table, or both, and/or display an icon somewhere (2) Which highlighting color to use (3) Whether to use a solid or dashed border, a solid background, a striped background... ↩

cr7pt0gr4ph7 · 2025-11-11T10:07:13Z

I'm also a user of Betterbird, so I can say that:

The striped background when searching is a bit jarring at first ("You type something, and suddenly a lot of red appears on the screen" makes you jump a bit and makes you intuitively think that an error has happened), so a slightly more subtle visual indication would be better for the purpose of not scaring users.
But it works well for the purpose of preventing you from accidentally having a search active when you didn't intend to.

ronso0 · 2025-11-11T12:00:01Z

@cr7pt0gr4ph7 Thanks for your feedback!

What I'm mostly missing is just a context menu entry for Move to Top/Bottom (Auto DJ Queue)

Since we introduced the Alt move keys we have Alt+Homefor this purpose (or Pos1 or whatever it is called on var. keyboards).
I'm hesitant to add more actions to the context menu, after all we also support Drag'n'drop in playlist (which admittedly may not be practical when you have to move a track from the bottom up to the top, and also there seems to be Qt regression with very slow DnD auto-scrolling

Thinking about it, it could also make the most sense if we have the following set of context entries: Move to Top (Play Next), Move to Top+1, Move to Top+2, Move to Top+3, Move to Bottom

So "move to top+2" would be Alt+Home and Alt+Down

ronso0 · 2025-11-11T12:08:21Z

The much bigger Auto DJ-related footgun is that "Move to Auto DJ Queue (replace)" doesn't ask for confirmation before accidentally clearing out your 3 hour playlist

Indeed, that would be consistent with the existing warning for manual track removal in playlists and crates.
I thought we have some protection against that 🤔 but we don't..

edit
Ah we have the popup for the sidebar action "Clear AutoDJ queue"

ronso0 · 2025-11-11T12:48:20Z

I managed to get the background warning, but it's not polished, yet. The alternate-background-color interferes with the background-image and it looks a bit odd.
And yes, this needs to be styled on skin level. In qss we can style it for all WTrackTableViews or individually for all that are in some feature Dlg.. (AutoDJ, Hidden, Missing, Analyze, Recording).

I'll open a PR for testing, then we can decide whether we want this everywhere (in every library view) or only in Auto DJ.

cr7pt0gr4ph7 added 4 commits June 6, 2024 21:13

BaseSqlTableModel: Expose the search columns via searchColumns()

75ce4d0

This enables correct filtering of proxy models that wrap an instance of BaseSqlTableModel (or a subclass).

ProxyTrackModel: Forward Cut and Paste to underlying TrackModel

62c3a0f

This is to allow these actions to work as expected in the Auto DJ view. Whether these actions are allowed or not should be determined by the underlying TrackModel, and not by the ProxyTrackModel.

WTrackTableView: Use calculateCutIndex instead of restoreCurrentIndex

35569a4

This fixes the focus behavior of copy/cut/paste in the Auto DJ view.

github-actions Bot added library ui autodj labels Jun 6, 2024

cr7pt0gr4ph7 changed the title ~~AutoDJ:~~ Auto DJ: (Re-)enable search in the Auto DJ view Jun 6, 2024

cr7pt0gr4ph7 added 2 commits June 6, 2024 22:03

AutoDJFeature: Fix indentation of findOrCrateAutoDjPlaylistId to avoi…

fc078b5

…d issues with clang-format This prevents clang-format from inferring the wrong indent sizes for other parts of the file.

Fix: Remove leftover debugging output

007184f

daschuer requested changes Jun 8, 2024

View reviewed changes

ronso0 mentioned this pull request Jun 20, 2024

Avoid playing multiple versions of the same song #13391

Open

github-actions Bot added the stale Stale issues that haven't been updated for a long time. label Sep 10, 2024

github-actions Bot removed the stale Stale issues that haven't been updated for a long time. label Sep 12, 2024

github-actions Bot added the stale Stale issues that haven't been updated for a long time. label Jan 23, 2025

github-actions Bot removed the stale Stale issues that haven't been updated for a long time. label Feb 24, 2025

Uh oh!

Conversation

cr7pt0gr4ph7 commented Jun 6, 2024

Uh oh!

cr7pt0gr4ph7 commented Jun 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Jun 6, 2024

Uh oh!

cr7pt0gr4ph7 commented Jun 7, 2024

Uh oh!

cr7pt0gr4ph7 commented Jun 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cr7pt0gr4ph7 commented Jun 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cr7pt0gr4ph7 commented Jun 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Jun 7, 2024

Uh oh!

ronso0 commented Jun 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daschuer left a comment

Choose a reason for hiding this comment

Uh oh!

cr7pt0gr4ph7 commented Jun 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cr7pt0gr4ph7 commented Jun 8, 2024

Uh oh!

ronso0 commented Jun 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daschuer commented Jun 9, 2024

Uh oh!

cr7pt0gr4ph7 commented Jun 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daschuer commented Jun 10, 2024

Uh oh!

github-actions Bot commented Sep 10, 2024

Uh oh!

cr7pt0gr4ph7 commented Sep 11, 2024

Uh oh!

github-actions Bot commented Jan 23, 2025

Uh oh!

ronso0 commented Nov 11, 2025

Uh oh!

daschuer commented Nov 11, 2025

Uh oh!

cr7pt0gr4ph7 commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

cr7pt0gr4ph7 commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Nov 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cr7pt0gr4ph7 commented Jun 6, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Jun 7, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Jun 7, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Jun 7, 2024 •

edited

Loading

ronso0 commented Jun 7, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Jun 8, 2024 •

edited

Loading

ronso0 commented Jun 8, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Jun 10, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Nov 11, 2025 •

edited

Loading

cr7pt0gr4ph7 commented Nov 11, 2025 •

edited

Loading

ronso0 commented Nov 11, 2025 •

edited

Loading

ronso0 commented Nov 11, 2025 •

edited

Loading