Menu

[GroovinChip]

[kiesman99]

However, clicking near the edge of the flutter window will place the context menu to the inner side of the ContextMenuArea.

As I've said I can see positive and negative points in both approaches and thus it would be totally fine if we decide against my implementation. Maybe I will publish a small package to pub.dev so that anyone can use my implementation to create flutter context menus.

Edit: wrong screenshot

[GroovinChip]

That's a really interesting drawback. @lesnitsky do you think custom items like those tags @kiesman99 showed is possible to achieve with a native implementation?

[bdlukaa]

I don't like the idea of a native implementation. It's not how Flutter works. If you want native, use react native or something like that.

[GroovinChip]

@lesnitsky does your native approach overflow over the edge of a Flutter window?

[kiesman99]

I've worked a bit on the proportions of the context-menu, the brightness adaptability and the blur of the context menu in dark mode.

Darkmode version:

Context Menu	Without

Here you can see a light blue shape underneath the context menu, which is the blur effect you can see in native context menus:

Context Menu	Without

Lightmode version:

Context Menu	Without

Context Menu	Without

( I am not sure if there is a very subtle blur in the light mode version or if I am just imagining it 😅)

I think we can mimic the macOS native context menus quite good, even if there is some more fine-tuning to be done.

However while implementing these things I've noticed it will be very handy to have a ContextMenuTheme class from which every custom tile can gather the default values. This is not yet implemented.

[GroovinChip]

Looking good @kiesman99! I appreciate your hard work despite the prospect of moving to native!

[kiesman99]

Thanks @GroovinChip :)

[lesnitsky]

If a user wants to have such a custom item he would need to implement it in swift right

I don't see any problems with providing a way to build custom items in dart and forwarding those to native (lesnitsky/native_context_menu#3)

---

@lesnitsky does your native approach overflow over the edge of a Flutter window?

It does Personally, I'm ok with this behavior (works same way in most, if not all, apps). Positioning could be tuned (lesnitsky/native_context_menu#4)

---

I don't like the idea of a native implementation. It's not how Flutter works. If you want native, use react native or something like that.

That's a matter of opinion. Native views and ability to communicate with native is in flutter for a good reason and noone on flutter team will ever tell you "go build with RN if you want native look and feel" 😉. If native works better and implementation is more straightforward I see no problem going with native in flutter world

---

I know flutter team works on context menu widget and they implemented it w/o any interactions w/ native. My motivation for building a native plugin for it, is my personal preference, and it easily could be very unpopular in general. As a macOS user I'm just very used to the look and feel of the native context menu and building exactly the same seems impossible to me (I may be wrong)

And just to give another round of respect – what are you doing here looks very cool, amazing work @kiesman99!

[GroovinChip]

@lesnitsky I'm glad to hear that the native approach overflows the window, that was one of my concerns about the non-native approach. I'm also glad to hear that you don't see any problem with doing custom menu options.

I think I personally would say that the native approach is the desired one. Here's what I think we should do: @lesnitsky and @kiesman99 should work on porting over the native approach in a new branch, and then we can compare each version and see which approach is more appropriate - we don't lose anything either way, because I will keep @kiesman99's PR open.

What do you all think?

[kiesman99]

Hey @lesliearkorful thank you very much!

I don't see any problems with providing a way to build custom items in dart and forwarding those to native (lesnitsky/native_context_menu#3)

I think it could be very interesting to build such a bridge to create custom native menus in MacOS/Windows/Linux, however i have no idea how to implement such a feature. Just to please my interest in this topic, do you have some references in which someone does something similar like this?

I think your implementation is very cool, and I am looking forward to seeing this fully implemented 😊.

As a macOS user I'm just very used to the look and feel of the native context menu and building exactly the same seems impossible to me (I may be wrong)

Personally, I think it would be possible to rebuild the context menus. The one and only thing that is currently not possible is making the context menu overflow. I don't know if this will be possible in the future when multiple flutter window instances are possible that are communicating with each other.

Correct me if I am wrong @GroovinChip but the risk of this flutter macos port is that we don't replicate the UI 100%. Sure, it's best if we are able to do so, but every component is build trying to be the exact same. The main benefit will be that people can build macos applications that look almost like real macos applications, without knowing how to code native applications.

I totally see that the slightest offset of UI components can destroy the image, but that's the risk by trying to rebuild the macos components in flutter.

I think I personally would say that the native approach is the desired one. Here's what I think we should do: @lesnitsky and @kiesman99 should work on porting over the native approach in a new branch, and then we can compare each version and see which approach is more appropriate - we don't lose anything either way, because I will keep @kiesman99's PR open.

Nonetheless, it's totally fine for me to choose the native approach, work it out and see if it suits better. I am not very familiar with native macos/windows/linux development but if I can help in any way @lesliearkorful feel free to hit me up!

[kiesman99]

I know flutter team works on context menu widget and they implemented it w/o any interactions w/ native.

@lesliearkorful are there some links you could share on this topic? Would be very nice to follow the flutter team and what they are doing 😄

---

@GroovinChip, @lesliearkorful, @bdlukaa Do you guys think people outside this project would benefit from a more abstract version of my implementation? I could extract everything, build a package and publish it on pub.dev.

[bdlukaa]

are there some links you could share on this topic?

You can see this on the PopupMenuButton. There is one for iOS as well, but I don't remember the name.

Do you guys think people outside this project would benefit from a more abstract version of my implementation?

It's all up to you. I personally don't think it's necessary

[lesnitsky]

@kiesman99 I believe you tagged @lesliearkorful by mistake, sorry @lesliearkorful if that was spammy, but feel free to jump in 😄

I think it could be very interesting to build such a bridge to create custom native menus in MacOS/Windows/Linux, however i have no idea how to implement such a feature. Just to please my interest in this topic, do you have some references in which someone does something similar like this?

No references really, I haven't done any research yet, I'm judging by what I see in desktop apps. If finder could add those menu items with tags – it's doable. Maybe some menu items will be platform specific, not sure. Just to clarify – I didn't mean you could render the whole widget tree as a menu item, but rather that current API where you only able to render text could be extended to support e.g. leading items, hotkeys indicators etc.

are there some links you could share on this topic?

https://github.com/flutter/flutter/issues/31955#issuecomment-764001802 https://github.com/flutter/flutter/pull/73882 (I can see a clear difference between native and flutter impl, that's why I built a plugin which calls native)

btw 👆 @GroovinChip have you seen this? I'm guessing this will be available in Q4 stable release

note: screenshots in #73882 don't look too

The main benefit will be that people can build macos applications that look almost like real macos applications, without knowing how to code native applications.

You write dart code either way, platform plugins are there exactly to abstract the platform specifics and allow users to deal with dart code only

Do you guys think people outside this project would benefit from a more abstract version of my implementation? I could extract everything, build a package and publish it on pub.dev.

Do it 🚀 I'm pretty sure some users will find your implementation more feature-rich (e.g. if they want to go fully custom with their menu items)

[GroovinChip]

• @lesnitsky I have not seen those PR's, very interesting
• @kiesman99 I'm not worried about replicating the UI, with the platform channel approach we will be able to do so and the user will not be writing any native code, only Flutter code

[GroovinChip]

@lesnitsky and @kiesman99 have you guys been working on this?

[lesnitsky]

it's not really clear what kind of effort is required from me. something specific to be done?

[GroovinChip]

I thought you guys would coordinate the effort together. At this point I'd say just go ahead and start porting, if you want.

[kiesman99]

@lesnitsky Can I support you designing your approach or do you think it would be better if you just implement it by yourself and afterwards we compare both implementations?

BTW Sorry @lesliearkorful for tagging you 😅 and thanks @lesnitsky for correcting me!

[lesnitsky]

I'm not sure what's my role here :) If you could describe what are the goals and why this 👇 is not enough – that'd be helpful.

pubspec.yaml

dependencies:
  native_context_menu:

macos_ui.dart

export 'package:native_context_menu/native_context_menu.dart';

[GroovinChip]

I'm not sure what's my role here :) If you could describe what are the goals and why this 👇 is not enough – that'd be helpful.

pubspec.yaml

dependencies:
  native_context_menu:

macos_ui.dart

export 'package:native_context_menu/native_context_menu.dart';

The reason I don't want to do this is because then I am relying on an external dependency. I would rather have your code directly integrated into macos_ui.

[lesnitsky]

then feel free to copy native code over to your repo. no free bug-fixes and features though 😉

[GroovinChip]

I think what I will do is import it as a dependency play around with it that way, while also forking the package so I can manually integrate it if the need arises.

[GroovinChip]

I'm not sure what's my role here :) If you could describe what are the goals and why this 👇 is not enough – that'd be helpful. pubspec.yaml

dependencies:
  native_context_menu:

macos_ui.dart

export 'package:native_context_menu/native_context_menu.dart';

The reason I don't want to do this is because then I am relying on an external dependency. I would rather have your code directly integrated into macos_ui.

Okay so I've set it up like this and it works really well! I think I'm going to keep this, @kiesman99, but thank you SO MUCH for your hard work! I really do appreciate it even though I didn't pick it in the end. If you'd like, I can add you as a contributor to the repo and you can pick something else to work on? Maybe something related to date/time pickers, or dropdowns? I can also add you to the contributor Slack if you drop me your email address.

[GroovinChip]

Ah crap. Doing it this way would lower my pub score!

[GroovinChip]

@kiesman99 don't forget to send me your email address so I can add you to the contributor Slack!