Menu about macos_ui HOT 75 CLOSED

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.

from macos_ui.

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 :)

from macos_ui.

@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

from macos_ui.

Hey there :)

Quick update! Unfortunately I couldn't do much, but there is still some progress.

I've implemented a rudimentary showContextMenu which can be used to initiate a context menu. This function however is not used to show the submenus. Instead, there is a ContextMenuNotifier which deals with the logic internally an.
Here a quick sample:

I am not quite satisfied with the current API which has to be used to create the context menu. But as I said this is a rudimentary approach as I am still researching on how others are implementing context menus.

Things I want to approach as next steps:

• Make use of the showMenu function and mimic its way of introducing popup menus
• Provide some wrapper classes to implement custom tiles
• Actually return something on clicking on a tile (will be implemented while mimicing showMenu)
• Place the context menu according to leftover place
• remove overlay by clicking anywhere and not just in ContextMenuArea

from macos_ui.

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!

from macos_ui.

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 😄

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

@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).

from macos_ui.

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

from macos_ui.

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

I vote for the show method

from macos_ui.

@GroovinChip That's awesome!
Unfortunately I think requiring NativeShell for Macos would be cumbersome for many people and hinder them using this awesome library.

As more and more big companies (canonical for example) are adopting flutter I could imagine this kind of feature could be implemented by them native into flutter.

As cool as this embedder extension is I think we should keep the current native flutter solution and adopt a new official approach once it's available.

from macos_ui.

What would stop you from using the show method from implementing such a Toolbar?

Nothing, but there should be a widget that abstracts and implements that.

A more specific element such as Toolbars or these ActionButtons should abstract the usage of showContextMenu and we can do that.

A general "I want to right click something and get a context menu" would be easier using a show method. Further abstraction is still possible for specific use cases. The question here is "which elements should get abstracted" IMO.

Also in this PR I'd solely focus on the right click menu but I'll keep in mind that we may want to use the implementation in different spots.

It's kinda funny that I started with the mindset A widget would be better but this discussion is shifting me to the show-method approach 😅

from macos_ui.

Hey @GroovinChip I think you can start to review #125.

In the next days I am going to implement adapting the system design, which is the last missing part.

This version does not include submenus, because I've done a whole re-write of my first implementation, taking some inspiration on the PopupMenuButton from flutter.

Submenus will be included in a separate PR after these "simple" context menus are reviewed and merged (if that's okay to you)

from macos_ui.

Thanks @GroovinChip :)

from macos_ui.

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

from macos_ui.

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

from macos_ui.

Absolutely, please go for it!

from macos_ui.

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!

from macos_ui.

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

from macos_ui.

@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 :)

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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!

from macos_ui.

I tweeted this issue out here

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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)

from macos_ui.

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!

from macos_ui.

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

from macos_ui.

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

from macos_ui.

because all flutter material overlays use this approach.

Tooltip doesn't.

The thing is that implementing the following would be harder with the show method:

from macos_ui.

This may be of some interest: https://matejknopp.com/post/introducing-nativeshell/?s=09

from macos_ui.

@bdlukaa you're right. Tooltip abstracts the usage of Overlay.
Isn't this a special case as tooltips can be applied to a multitude of widgets, thus having this kind of overlay as an attribute is very convenient.

As for the gif you showed:
What would stop you from using the show method from implementing such a Toolbar (the toolbar here is different from the one discussed before)?
You'd have to pass the position which you'll get on hovering over the menus and then the submenu will get rendered on this position.

Could you elaborate?

from macos_ui.

What would stop you from using the show method from implementing such a Toolbar?

Nothing, but there should be a widget that abstracts and implements that.

from macos_ui.

Also in this PR I'd solely focus on the right click menu but I'll keep in mind that we may want to use the implementation in different spots.

I think this is a good idea @kiesman99

from macos_ui.

Excellent! And how does the menu behave when opened near a window boundary?

from macos_ui.

I believe the position of the context menu should be altered when opening near the window boundaries.
e.g opening a context menu on the rightmost bottom should be moved left (with a minimum width offset of context Menu) and up with (a minimum height offset of context Menu). Similarly considering this in all 4 directions. I believe this will solve for not having to deal with multiple window support, As this is not yet supported in flutter.

from macos_ui.

@kiesman99 Do you have any further updates to share?

from macos_ui.

Hey @GroovinChip, I am very sorry for not responding.

Unfortunately, a few of my exams were brought forward. Therefore, I have shifted the focus a little.

I have made a few minor changes and would start there again when the exams are over.
If you prefer, I can also do a first working version, which I'll tweak a bit afterwards.

from macos_ui.

Hey @GroovinChip, I am very sorry for not responding.

Unfortunately, a few of my exams were brought forward. Therefore, I have shifted the focus a little.

I have made a few minor changes and would start there again when the exams are over.
If you prefer, I can also do a first working version, which I'll tweak a bit afterwards.

No worries @kiesman99 thanks for the update. We can wait till your exams are over.

from macos_ui.

@kiesman99 any news on this? Are your exams over?

from macos_ui.

@kiesman99 any movement on this?

from macos_ui.

Hey @GroovinChip, I am very sorry for not responding for a while. Duo to private matter and the exams I hadn't had the time for social media. This semester was way more stressful than the other ones and I underestimated it.
Now my exams are done and I will focus again on the menu implementation.

from macos_ui.

Excellent, I'm glad to hear it!

from macos_ui.

CC @lesnitsky

from macos_ui.

Sure, that's fine. Thanks for your hard work! I will review in the near future, likely either tomorrow or next week.

Edit: cc @lesnitsky

from macos_ui.

hey all
awesome work here!
I've published native_context_menu recently

I was looking into context menu implementations in flutter repo and chose a native approach for a couple of reasons, the main was native styling. As good as flutter is in rendering part it's still hard to make things look exactly like native. Imo context menu is one of the most used native controls, so users are very used to how it looks and behaves. custom implementations are always kind-of confusing. + macos has some nice ux touches (e.g. submenu waits a bit before hiding when cursor exits the parent menu item, so diagonal gesture has less invalid resulting items selected)

we can collaborate to integrate native_context_menu "natively" to macos_ui, lmk wdyt

from macos_ui.

@kiesman99 what do you think about collaborating with @lesnitsky about folding his native implementation into macos_ui? I think it could be a good approach. I know you've worked super hard on this, and I don't want your work to go to waste, so I think a collaboration between the two of you is a good middle ground. We'd get native behavior and you'd still get to work on this issue.

from macos_ui.

@GroovinChip, @lesnitsky I see the benefits of using a native approach and it would be totally fine, if we'd decide to take @lesnitsky's implementation.

I like that the native approach feels on spot, because it is native and we are able to have a context menu that has an offset to the actual flutter window. One drawback that I can see however is custom items.

For example in the finder app we can choose coloured tags:

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

from macos_ui.

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:

from macos_ui.

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

from macos_ui.

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?

from macos_ui.

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.

from macos_ui.

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

from macos_ui.

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.

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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!

from macos_ui.

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.

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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

from macos_ui.

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';

from macos_ui.

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.

from macos_ui.

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

from macos_ui.

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.

from macos_ui.

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.

from macos_ui.

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

from macos_ui.

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

from macos_ui.