Skip to content

Conversation

terrakok
Copy link
Member

Support text context menus in web targets
image
image

Fixes https://youtrack.jetbrains.com/issue/CMP-113

Testing

This should be tested by QA

Release Notes

Highlights - Web

  • Text context menu is supported on web platforms for both modes: mobile and desktop

@terrakok terrakok requested review from MatkovIvan and eymar June 30, 2025 13:53
@MatkovIvan MatkovIvan requested a review from m-sasha June 30, 2025 14:13
@m-sasha
Copy link
Member

m-sasha commented Jun 30, 2025

I see lots of

//TODO: remove this file
// when this will be in JB fork
// https://android.googlesource.com/platform/frameworks/support/+/d8bc9d81dffa35162626e45ee68d4a7e271c6ada

Why not cherry-pick instead?

@MatkovIvan
Copy link
Member

@m-sasha it was my request to avoid merge conflicts - it's not a part of 1.9 in AOSP. Having such commonMain refactor is not what should be done via cherry-picks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if we should be using Google's UI code.
I already added our version to skikoMain in my PR, which looks better on the desktop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably worth adjusting such things in commonMain now...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How? Google wants material-like looks there. We don't.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And again it's not compilation target dependent. And we DO want to use AOSP version as a source of truth.

Using material-like styles in foundation is against Google's architectural layers design principles. If it's really the case - it needs to be fixed in AOSP

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is for web targets. I guess it is better to follow the common style (material) until we support something else

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then why did you ask me to put the corresponding desktop code into skikoMain?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And again it's not compilation target dependent. And we DO want to use AOSP version as a source of truth.

If I understand correctly, it wasn't in common until we asked to put it there. Maybe we should not have asked for this.

@m-sasha
Copy link
Member

m-sasha commented Jun 30, 2025

Sorry, I don't understand what was done here.

I thought this was commonizing and upstreaming the (old) API we had for the desktop.
But it looks like it's commonizing (and copy pasting to skikoMain) the merge between some kind of Android context menu API (but AFAIK Android did not have such an API until now; where did it come from?) and the new context menu API.

And we'll need to merge it with our adaptations of the new context menu API, e.g. my PR. My head is exploding.

@terrakok
Copy link
Member Author

No.

  1. The PR has copy-pasted android implementation of the "desktop"-mode android context menu for the "desktop"-mode web targets.
  2. Implements TextToolbarMenu for "mobile"-mode web targets.

@m-sasha
Copy link
Member

m-sasha commented Jun 30, 2025

android implementation of the "desktop"-mode android context menu

What is that?

@terrakok
Copy link
Member Author

It is the menu you can see when you connect a mouse to the android device

@terrakok
Copy link
Member Author

at the end I use the "android"-mouse

acm.mp4

@m-sasha
Copy link
Member

m-sasha commented Jun 30, 2025

It is the menu you can see when you connect a mouse to the android device

I don't think this existed before 1.9, but maybe I'm wrong.

Why did we chose to commonize that instead of our own desktop stuff?
Now we'll have 3 context menu implementations: jb-desktop, commonized-aosp-desktop and new.

And they're not entirely separate - some classes are shared. I'm really having trouble wrapping my head around it.

@terrakok terrakok force-pushed the k.tskh/web-ctx-menu branch from fe9b628 to 958dab7 Compare July 2, 2025 08:22
@terrakok terrakok force-pushed the k.tskh/web-ctx-menu branch from 958dab7 to 264c651 Compare July 2, 2025 08:26
@terrakok terrakok requested review from MatkovIvan and eymar July 2, 2025 08:28
@terrakok
Copy link
Member Author

terrakok commented Jul 2, 2025

At the moment, the PR introduces the same text context menus as in Android. That was an initial idea. In the future it is possible to reuse your new Desktop API for the menus, but not in the current task.

The aim is to run existed code in the web.

@m-sasha m-sasha self-requested a review July 3, 2025 13:00
@terrakok terrakok merged commit 9fd5d09 into jb-main Jul 3, 2025
10 checks passed
@terrakok terrakok deleted the k.tskh/web-ctx-menu branch July 3, 2025 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants