Add grid placement tool

[OliBomby]

Part of #26303
closes #30118

Requires

• Add ability to change position, spacing, and rotation of the positional snap grid in the editor #26309
• Add hexgrid and circular grid to the osu editor #26310
• Make editor flip, rotate, and scale tools revolve around the grid center #26311
• Refactor placement blueprints to not be limited to hit objects #29986

Adds the 'Change grid' placement tool to the left tool box.

Mappers might want to align their grid with some hit objects they have already placed, so I also added a 'Grid from points' feature which allows the mapper to select two points on the playfield and then the grid aligns itself with those points. The origin is centered on the first point and then the spacing and rotation is determined by the difference between the two points. The two points will be on two neighbouring grid lines in the resulting grid.
This point selection has snapping to nearby objects so its easy to align it exactly with hit objects.
Also clicking with right click will end the point selection immediately so you can select just one point allowing you to change just the grid origin.

I repurposed the initial PR #26303 to add the remaining keybinds for cycling grid type.

osu._k6UmTIJN2n.mp4

[bdach]

Feature seems useful but as usual I have UX concerns.

2024-09-20.10-29-06.mp4

There is no guidance on how to use this feature. There is a button with no tooltip. You click on it and nothing visually happens. You click on it five times and maybe move it over the playfield and notice the grid starts moving. Only at that point you can probably figure out that you need to click the playfield twice to have it work. I'd still say both points should be visually indicated somehow rather than just relying on the grid but maybe that's optional.

The main problem is no indication on what you're supposed to do with the feature at all.

Also there is no way to cancel a grid change if you decide you don't want to change the grid anymore. Esc doesn't work.

Also I don't get what the criteria for the grid spacing subdividing is. It appears that it will decrease when the cursor moved too much between clicks 1 & 2, but I have no idea why it's doing what it's doing in particular.

There's also whatever this is:

2024-09-20.10-34-27.mp4

You can be in the "change grid" mode and still have things like object placement appear to work but they actually will not work and instead the grid change thing will take priority. At that point I'd start thinking if this shouldn't be a tool in the toolbox on the left.

[OliBomby]

I changed the 'grid from points' button into a placement tool like @bdach suggested. I think the UX is really nice now.

The diffstat became pretty big but most of it is from 1a81e12 which is mostly just refactoring name change. It should be pretty easy to review as that commit should not change any behaviours.

I'll need an icon for the new placement tool so that's still TODO

[OliBomby]

I added a tooltip so it tells you what to do while you are hovering the button wondering what to do. From then on it should be pretty obvious how it works.

[bdach]

I guess UX wise I'd be fine with this in its current state, but I'd want @peppy's reading of it too to proceed with merging this in.

[bdach]

This entire change with making TooltipText virtual is quite dodgy because some derived classes override the getter but leave the setter intact. Previously the intent was that the tooltip in those classes was derived from internal data and as such is immutable outside the class. But now with this you can freely overwrite the TooltipText of a ReadyButton or FavouriteButton or whatever else which is improper design.

The easiest way out of this would probably be to drop the virtual, and update the places that override the getter so that instead of it they use the setter (which will require a few bindable subscriptions or something to provide the same effect).

[OliBomby]

This might be a good place to use the new keyword. By declaring a public new LocalisableString TooltipText in ReadyButton and FavouriteButton we can remove the setter entirely which seems more appropriate for these classes which want to manage their tooltip text internally.

[bdach]

Eh. I don't like shadowing because it makes things tricky anyway. Simple non-virtual non-shadowed public get; set; is best.

[OliBomby]

I would agree with you that shadowing makes things tricky in most cases, but in this case using shadowing seems like the simplest solution. If we just considered ReadyButton and FavouriteButton it would be quite a simple change because they use only bindables for their tooltip. However we have to consider the tooltip of ReadyButton actually gets overriden by PlaylistsReadyButton and MultiplayerReadyButton which each use several non-bindable variables in determining their tooltip text.
I'd have to add new bindables in several classes and it would become a quite complicated chain of bindable updates.

That or make a new subclass of RoundedButton with tooltip text setter. That seems like the correct OOP approach.

[bdach]

Needs xmldoc

[peppy]

No idea about the tooltip changes I just wangs some shit to make it compile so I could comment on the UX.

• I don't think the right-click method needs to exist. You can just left-click twice to get the same behaviour right?
• I preferred this being on the left, as it clears the user's selection and behaves like a modal operation but now has no indication that it will do that. Can we move it back?
• It seems to maintain a spacing under 64 while the limit is 128, is there a reason for that?

[peppy]

Updated UX feedback.

[OliBomby]

• I don't think the right-click method needs to exist. You can just left-click twice to get the same behaviour right?

Yes left-click twice has the same behaviour, but I prefer to use a single right-click instead. It doesn't hurt to have a little redundancy to make it a bit easier to use right?

• I preferred this being on the left, as it clears the user's selection and behaves like a modal operation but now has no indication that it will do that. Can we move it back?

It already clears the user's selection, but if you prefer it being on the left I'll move it there.

• It seems to maintain a spacing under 64 while the limit is 128, is there a reason for that?

There's a good reason for that. I made the spacing match the range of the grid spacing cycle hotkey which is [4,64), so you can always cycle the spacing value back to the original value you got from the grid placement tool. I think these are all reasonable spacing values, beyond that there are so few snappable points on the screen that it is barely of any utility. The limit on the spacing slider is intentionally bigger for the off-chance you want to use a big spacing, so you can set that manually.

The grid placement tool and the spacing cycling hotkey are tools that set the spacing automatically so I think it makes sense to restrict them to a range of more reasonable values.

I hope to get this in the next release, so I'll be available to reply to any feedback ASAP

[peppy]

It already clears the user's selection, but if you prefer it being on the left I'll move it there.

Let me rephrase: because it clears the selection, I think it should be on the left. Users are understanding that their selection will be lost when changing tools here. A button on the right randomly nuking a selection is unexpected.

[OliBomby]

Let me rephrase: because it clears the selection, I think it should be on the left. Users are understanding that their selection will be lost when changing tools here. A button on the right randomly nuking a selection is unexpected.

That makes sense. I've moved it back to the left toolbox.

[peppy]

I'd either call the toolbox item "Grid" or "Place grid". The first may fit better with the other tools? @bdach thoughts?

Also I think the FA icon looks nicer:

diff --git a/osu.Game.Rulesets.Osu/Edit/GridFromPointsTool.cs b/osu.Game.Rulesets.Osu/Edit/GridFromPointsTool.cs
index bc143886ce..11c97d78d9 100644
--- a/osu.Game.Rulesets.Osu/Edit/GridFromPointsTool.cs
+++ b/osu.Game.Rulesets.Osu/Edit/GridFromPointsTool.cs
@@ -3,7 +3,6 @@
 
 using osu.Framework.Graphics;
 using osu.Framework.Graphics.Sprites;
-using osu.Game.Graphics;
 using osu.Game.Rulesets.Edit;
 using osu.Game.Rulesets.Edit.Tools;
 using osu.Game.Rulesets.Osu.Edit.Blueprints;
@@ -13,7 +12,7 @@ namespace osu.Game.Rulesets.Osu.Edit
     public partial class GridFromPointsTool : CompositionTool
     {
         public GridFromPointsTool()
-            : base("Change grid")
+            : base("Place grid")
         {
             TooltipText = """
                           Left click to set the origin.
@@ -23,7 +22,7 @@ Right click to only set the origin.
                           """;
         }
 
-        public override Drawable CreateIcon() => new SpriteIcon { Icon = OsuIcon.EditorPlaceGrid };
+        public override Drawable CreateIcon() => new SpriteIcon { Icon = FontAwesome.Solid.DraftingCompass };
 
         public override PlacementBlueprint CreatePlacementBlueprint() => new GridPlacementBlueprint();
     }

[peppy]

As above

[OliBomby]

I'd either call the toolbox item "Grid" or "Place grid". The first may fit better with the other tools? @bdach thoughts?

Also I think the FA icon looks nicer:

I agree. "Grid" fits better in the theme of the other placement tools.