Menu #89

GroovinChip · 2021-05-14T01:34:37Z

GroovinChip · 2021-05-26T15:17:35Z

See https://gitlab.com/TheOneWithTheBraid/contextmenu/-/tree/main/lib/src for how to make this. Demo here https://theonewiththebraid.gitlab.io/contextmenu/#/

kiesman99 · 2021-05-31T21:53:11Z

Hey I'd like to try to implement this feature if help is still needed :)

However, duo to university stuff I can not promise keeping a deadline 😄

GroovinChip · 2021-05-31T22:36:01Z

Absolutely, please go for it!

kiesman99 · 2021-06-01T07:00:40Z

Is there a good exemplary application from which I should copy the macos design and feel?

I am kinda new to macos thus I don't really know where to find certain elements :)

Thank you!

lesliearkorful · 2021-06-01T11:42:07Z

@kiesman99 https://www.figma.com/file/M6K5L3GK0WJh6pnsASyVeE/macOS-Big-Sur-UI-Kit?node-id=26%3A5

GroovinChip · 2021-06-01T16:14:25Z

@kiesman99 I know its difficult for you to get a sense of your timeline because of school, but do you think you have a rough idea of when you think you can deliver this? Just so we know when to look out for it?

kiesman99 · 2021-06-01T19:46:13Z

@GroovinChip I'm playing a little with the api today to get a feel for it. I will respond after I've checked it out :)

GroovinChip · 2021-06-01T19:46:59Z

@GroovinChip I'm playing a little with the api today to get a feel for it. I will respond after I've checked it out :)

Sounds great, thank you!

kiesman99 · 2021-06-01T20:21:20Z

Hey @GroovinChip quick question:

The snippet you provided uses showModal which is a function coming from the animations package.

Is it okay to depend on this library or should I try to implement this feature using OverlayEntry or Remi Rousselet's flutter_portal (currently unmaintained)?

GroovinChip · 2021-06-01T20:22:11Z

I'd say let's try our own implementation, the less we depend on outside libraries the better.

GroovinChip · 2021-06-01T20:38:36Z

Looks like this is actually a duplicate of #53 but I'll keep this open since more movement is happening here

kiesman99 · 2021-06-01T22:27:27Z

Hey I've wanted to give a quick summary on what I've done today.

I've played around with the OverlayEntry and accomplished a rather basic Version of the contextmenu as you can see here:

Currently, I get an exception if remove the Overlay on exiting the region this has to be investigated.

Also, I don't know if we should proceed or wait with this issue as the context menu cannot be drawn outside of the flutter application with this approach.

Whereas in Macos the context menu should display above the flutter application:

I'd imagine such an implementation would require looking into the Flutter Macos Embedder. Doing a (very) quick research i could not find a method to implement this behavior, but as canonical is choosing flutter as the main framework to write desktop applications maybe they'll implement such a feature in the future.

kiesman99 · 2021-06-01T22:29:07Z

Regarding the 'deadline': I will try to implement this feature in the upcoming two weeks I think.

GroovinChip · 2021-06-01T22:29:54Z

Wow @kiesman99 this is amazing work, thank you! Maybe we can ask around the Flutter community for some ideas. I'd say you should keep going, this is really great!

GroovinChip · 2021-06-01T22:37:30Z

I tweeted this issue out here

kiesman99 · 2021-06-01T22:47:16Z

Thanks @GroovinChip!

I've created a WIP PR #125.

I am very excited if we could accomplish to place the context menu outside the flutter application. I'll keep an eye on that tweet :)

bdlukaa · 2021-06-01T23:06:17Z

I am very excited if we could accomplish to place the context menu outside the flutter application.

See flutter/flutter#30701 for more info on this

bdlukaa · 2021-06-01T23:19:50Z

@kiesman99 While you can't render anything outside of the window (for security reasons), you can add something like a "padding" to make it fit the window.

When implementing tooltip, I found a method on the framework that does exactly that. It tries to position the child on the required offset, but if not possible, it handles that for you.

https://github.com/GroovinChip/macos_ui/blob/dev/lib/src/labels/tooltip.dart#L578

positionDependentBox can be found on flutter/rendering

kiesman99 · 2021-06-01T23:25:13Z

@bdlukaa i will look into this :)

My plan is to move the context menu to the left side if the user clicks somewhere near the right border but that wouldn't solve the issue of too small windows.

I think this is especially crucial, because context menus are limited in height and therefore in the number of elements. Also this is a red light to distinguish a flutter Mac_OS app from a native MacOS application.

bdlukaa · 2021-06-01T23:39:15Z

I think this is especially crucial, because context menus are limited in height and therefore in the number of elements.

We can do a few things to solve this:

Set a min size to the window (bitsdojo_window)
If the menu is too small for its content, a ScrollView (SingleChildScrollView or ListView) can be added to the menu (with(out) a scrollbar)

kiesman99 · 2021-06-03T10:53:10Z

I think for now I'll go with the ScrollView or similar to solve the shrink issue.

Yesterday I've implemented a basic version of a ChangeNotifier that should keep track of all open ContextMenus.

How do we want to design the api? Do you want to provide a Widget in which the ContextMenu can be invoked

build(context) {
  return ContextMenuArea(
    menu: ContextMenu(
      children: [
        ContextMenuTile(),
        ContextMenuTile(),
        ContextMenuDivider(),
        ContextMenuTile(
          subMenu: ContextMenu(
            children: [
              // some more items for the submenu
            ]
          )
        )
      ]
    )
    child: Child() // inside of this child the user is able to invoke the context menu
  );
}

The ContextMenuArea handles the right clicks on the Child().

Or do we want to provide an imperative approach similar to showDialog?

void _contextMenu(TapDownDetails details) {
  // actual call to open context menu
  showContextMenu(
    position: details.globalPosition,
    builder: (context) {
      // build context menu in build function
      return ContextMenu(
        children: [
          ContextMenuTile(),
          ContextMenuTile(),
          ContextMenuDivider(),
          ContextMenuTile(
            subMenu: ContextMenu(
              children: [
                // some more items for the submenu
              ]
            )
          )
        ]
      );
    }
  );
}

build(context) {
  return GestureDetector(
    onSecondaryTapDown: (details) => _contextMenu(details)
    child: Child()
  );
}

Here is an issue from Remi in which he discusses the imperative approach of Overlay. This might help to form an opinion on this topic.

Thanks for your help!

GroovinChip · 2021-06-03T12:50:12Z

I personally am in favor of the second approach, the show function.

bdlukaa · 2021-06-03T12:51:22Z

Or do we want to provide an imperative approach similar to showDialog?

I don't think the showDialog approach will work with this. The current design seems good for me

kiesman99 · 2021-06-03T12:57:50Z

@bdlukaa I am not certain, because I could not yet test this approach, but I think it would work as Overlay is already imperative (see) and the Overlay is provided in the Navigator. Thus i can use the Overlay provided by the Navigator to inject context menus.

But I think this is a design decision. I think solving this with Widgets is a bit nicer, because its simpler to use for the end user of the library, but providing the show method gives the user more control.

However, if the show function can be implemented I could just provide a ContextMenuArea which abstracts the usage of the show method. This however could be confusing, because there is no "right" way of providing a ContextMenu (The user could be confused which approach he/she should use).

kiesman99 · 2021-06-03T13:03:05Z

The show method could be a bit more intuitive, because all flutter material overlays use this approach.

kiesman99 · 2021-09-25T20:37:32Z

With a flutter non-native implementation the context menu will always be bound by the flutter window size, but it's possible to implement custom items.

There is the ContextMenuEntry<T> class which can be used to implement custom tiles with custom behaviour:

class CustomContextMenuItem<T> extends ContextMenuEntry<T> {
  const CustomContextMenuItem({Key? key}) : super(key: key);

  @override
  _CustomContextMenuItemState<T> createState() => _CustomContextMenuItemState<T>();
}

/// [ContextMenuEntry.handleTap] is not used in this state, because we want to have 3 buttons which
/// each should return a seperate value
class _CustomContextMenuItemState<T> extends ContextMenuEntryState<CustomContextMenuItem, T> {
  @override
  Widget build(BuildContext context) {
    return Container(
      child: Row(
        children: [
          TextButton(onPressed: () {
            Navigator.pop<int>(context, 3);
          }, child: Text('3')),
          TextButton(onPressed: () {
            Navigator.pop<int>(context, 4);
          }, child: Text('4')),
          TextButton(onPressed: () {
            Navigator.pop<int>(context, 5);
          }, child: Text('5'))
        ],
      )
    );
  }
}

which will result in:

kiesman99 · 2021-09-25T20:41:09Z

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 · 2021-09-25T20:55:53Z

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 · 2021-09-25T21:23:43Z

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 · 2021-09-25T21:28:23Z

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

kiesman99 · 2021-09-25T22:43:07Z

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 · 2021-09-25T22:46:01Z

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

kiesman99 · 2021-09-25T22:51:44Z

Thanks @GroovinChip :)

lesnitsky · 2021-09-27T09:52:55Z

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 · 2021-09-27T13:34:50Z

@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 · 2021-09-28T06:31:44Z

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 · 2021-09-28T06:36:12Z

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 · 2021-09-28T08:51:16Z

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 · 2021-09-28T09:21:02Z

@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?

flutter/flutter#31955 (comment)
flutter/flutter#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 · 2021-09-28T13:44:02Z

@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 · 2021-10-03T16:40:38Z

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

lesnitsky · 2021-10-03T17:00:18Z

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

GroovinChip · 2021-10-03T17:06:40Z

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 · 2021-10-11T21:26:59Z

@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 · 2021-10-12T08:18:24Z

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 · 2021-10-12T19:59:47Z

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 · 2021-10-12T20:21:04Z

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

GroovinChip · 2021-10-13T01:31:00Z

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 · 2021-10-13T01:55:56Z

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 · 2021-10-13T02:18:28Z

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

GroovinChip · 2021-10-13T14:47:30Z

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

GroovinChip added good first issue Good for newcomers new widget Requests for new widgets help wanted Extra attention is needed and removed good first issue Good for newcomers labels May 14, 2021

GroovinChip mentioned this issue Jun 1, 2021

Contextual menu #53

Closed

This was referenced Sep 27, 2021

Custom menu items lesnitsky/native_context_menu#3

Open

Allow to configure context menu positioning (stay inside the window/overflow it) lesnitsky/native_context_menu#4

Open

GroovinChip mentioned this issue Oct 13, 2021

feat(package): 0.9.0 - native context menus! #162

Merged

5 tasks

GroovinChip closed this as completed in #162 Oct 13, 2021

Menu #89

Menu #89

Comments

GroovinChip commented May 14, 2021

GroovinChip commented May 26, 2021 • edited Loading

kiesman99 commented May 31, 2021

GroovinChip commented May 31, 2021

kiesman99 commented Jun 1, 2021

lesliearkorful commented Jun 1, 2021

GroovinChip commented Jun 1, 2021 • edited Loading

kiesman99 commented Jun 1, 2021

GroovinChip commented Jun 1, 2021

kiesman99 commented Jun 1, 2021

GroovinChip commented Jun 1, 2021

GroovinChip commented Jun 1, 2021

kiesman99 commented Jun 1, 2021

kiesman99 commented Jun 1, 2021

GroovinChip commented Jun 1, 2021

GroovinChip commented Jun 1, 2021

kiesman99 commented Jun 1, 2021

bdlukaa commented Jun 1, 2021

bdlukaa commented Jun 1, 2021

kiesman99 commented Jun 1, 2021

bdlukaa commented Jun 1, 2021

kiesman99 commented Jun 3, 2021 • edited Loading

GroovinChip commented Jun 3, 2021

bdlukaa commented Jun 3, 2021

kiesman99 commented Jun 3, 2021

kiesman99 commented Jun 3, 2021

kiesman99 commented Sep 25, 2021

kiesman99 commented Sep 25, 2021 • edited Loading

GroovinChip commented Sep 25, 2021

bdlukaa commented Sep 25, 2021

GroovinChip commented Sep 25, 2021

kiesman99 commented Sep 25, 2021 • edited Loading

Darkmode version:

Lightmode version:

GroovinChip commented Sep 25, 2021

kiesman99 commented Sep 25, 2021

lesnitsky commented Sep 27, 2021

GroovinChip commented Sep 27, 2021

kiesman99 commented Sep 28, 2021

kiesman99 commented Sep 28, 2021

bdlukaa commented Sep 28, 2021

lesnitsky commented Sep 28, 2021

GroovinChip commented Sep 28, 2021

GroovinChip commented Oct 3, 2021

lesnitsky commented Oct 3, 2021

GroovinChip commented Oct 3, 2021

kiesman99 commented Oct 11, 2021 • edited Loading

lesnitsky commented Oct 12, 2021

GroovinChip commented Oct 12, 2021

lesnitsky commented Oct 12, 2021

GroovinChip commented Oct 13, 2021

GroovinChip commented Oct 13, 2021 • edited Loading

GroovinChip commented Oct 13, 2021

GroovinChip commented Oct 13, 2021

GroovinChip commented May 26, 2021 •

edited

Loading

GroovinChip commented Jun 1, 2021 •

edited

Loading

kiesman99 commented Jun 3, 2021 •

edited

Loading

kiesman99 commented Sep 25, 2021 •

edited

Loading

kiesman99 commented Sep 25, 2021 •

edited

Loading

kiesman99 commented Oct 11, 2021 •

edited

Loading

GroovinChip commented Oct 13, 2021 •

edited

Loading