frontend: Add vertical snap positions for activities

[kahirokunn]

Summary

This PR adds vertical snap positions for activities (e.g. Edit dialogs) so they can be docked to the top or bottom of the main area in addition to left/right/full/window.

Related Issue

N/A

Changes

• Added split-top / split-bottom locations to the activity layout system.

Steps to Test

1. Open any resource details page and click Edit to open the editor activity.
2. Use the new Snap Top / Snap Bottom buttons in the activity header and confirm the activity docks to the top/bottom half of the main area.

Screenshots

Notes for the Reviewer

[joaquimrocha]

At this point I think we should have a drop down (on hover) for all those positions instead of just laying them horizontally. WDYT?

[kahirokunn]

@joaquimrocha
I've implemented a dropdown on mouseover. What do you think? It feels really easy to use when trying it out.

[joaquimrocha]

I had imagined using the icons instead of the full text for the drop down but I think it also works. @sniok , WDYT?

[kahirokunn]

I realized after you mentioned it, but with text, icons might be better for multi-language support. I've switched to the icon version. Which one do you prefer?

[joaquimrocha]

I think the icons + the text as tooltips works fine. Thanks for the changes.

[joaquimrocha]

Also, try to anchor the popover at the center horizontally, so it opens like:

 [O] | A | | B | 

instead of (currently):

[O] | A | | B | 

[kahirokunn]

How does this look?

[skoeva]

neat idea, LGTM

[kahirokunn]

Thank you 🙌

[joaquimrocha]

How does this look?

I was proposing only the icons. I think if you have the text you don't need the icons there, but it does look good.

I can go with this solution.

[kahirokunn]

I misunderstood "icons + text as tooltips" to mean using both icons and text together. Sorry about that!

[joaquimrocha]

@kahirokunn , I think I found a side effect of your PR at the task overview (click the lower right icon at the task bar when you have a task snapped to the bottom):

I mean, it's maybe a quirky feature that it's shown at the bottom, but I think we should have them all at the same height. Also because if you have more windows snapped to the bottom in the overview than your screen holds horizontally, then it will not show beyond that first line of windows. See the 4 tasks opened but only 3 windows showing in the overview below:

Another problem: The popover for selecting the snap modes should go away if we do not hover it or the trigger button, because right now, if you try to hit the minimize button, you almost always hover the snap button and then the popover stays on, requiring an extra click to hide it before we can hit the minimize button.

There are a couple of issues that I have highlighted in my comments.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kahirokunn
Once this PR has been reviewed and has the lgtm label, please assign illume for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kahirokunn]

Thanks for the review 🙏
I’ve addressed the issues you highlighted in this update. The snap menu now opens after a 350ms hover to avoid accidental popovers, and I also added click-to-open for better support on touch-based devices. Also, even if the dropdown opens, it won’t block clicks (e.g. you can still click Minimize in one click). I also fixed the layout problems that came up as a side effect. When you have a moment, could you please try it again and let me know if it looks good?

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[sniok]

I think it's a good idea to allow for more position for activities. I'm not sure about this iteration though. I think left/right/fullscreen are the most common options and with these changes it makes it harder to use them since they're now hidden under a menu.
I'm not sure what would be a perfect solution here but I don't think this should go into 0.39 yet.

[kahirokunn]

Thank you for your thoughtful feedback! I really appreciate you taking the time to consider the UX implications.

I'd like to share some context about why I believe this change is important. I've noticed that when activities are snapped left or right, they inevitably block UI elements of the currently opened page in Headlamp, and there's no way to avoid this overlap.

Imagine this scenario: you're writing source code in VS Code, and Chrome always overlays on top of VS Code's interface. That's essentially what happens with the current left/right snap positions in Headlamp.

If this were a split-screen approach where the screen area is shared (like traditional window tiling), I probably wouldn't have created this PR. However, since Headlamp uses an overlay design, I believe we need more positioning options beyond just left/right/top/bottom. Specifically, I think corner positions (top-left, top-right, bottom-left, bottom-right) would be valuable additions to give users more flexibility in avoiding overlapping critical UI elements.

Regarding your concern about frequently-used positions being harder to access: I completely understand this is a valid UX concern. I'm open to exploring alternative UI approaches that keep the most common positions (left/right/fullscreen) easily accessible while accommodating additional positioning options.

Would you be open to discussing potential UI solutions that could address both needs? I'm happy to iterate on the design to find the right balance.

What do you think?