macosui / macos_window_utils.dart Goto Github PK

When downgraded, the window styles works normally.

Screenshot:

Add methods for the miniaturize, deminiaturize, performMiniaturize, and isMiniaturized methods of the NSWindow.

None of those methods require any arguments (except for a sender, which may be nil), and are therefore very straightforward to implement, which is why I have marked this issue as a “good first issue”.

If this is your first time contributing to a macOS plugin, feel free to use the CONTRIBUTING.md file as guidance.

Running the example in this repo renders an empty window on macOS 12.7.1 and 10.15.7 (both running on Intel) but works as expected on an Apple Silicon machine with macOS 14.2.1:

I first tested older Flutter versions and then older versions of this repo. Using git bisect I was able to track it down to this one commit: 9f09f88

So I am guessing the changes in 24fe66e somehow only work for newer macOS versions? @Adrian-Samoticha do you have any ideas why this might be the case and how to fix it?

Allow the window's level property to be changed.

When setting the window size, background, etc, upon launch, there's a visual glitch because the window begins with the standard Flutter configuration and then switches to the desired configuration when the Dart application starts running.

This glitch can be avoided by coding the application delegate to set all of these properties on launch, but writing Swift in the XCode project largely eliminates the value of this package from a window configuration standpoint.

Is there anything that can be done about this initial glitch? Is there a way to avoid showing any window until the Dart app starts up, and therefore the Dart code can set the configuration before any window is visible?

macos_window_utils/MainFlutterWindowManipulator.swift:370: Fatal error: Unexpectedly found nil while unwrapping an Optional value

Got this when running old code.

Here is the setup in main.swift:

import Cocoa
import FlutterMacOS

class MainFlutterWindow: NSWindow {
  override func awakeFromNib() {
    let flutterViewController = FlutterViewController.init()
    let windowFrame = self.frame
    self.contentViewController = flutterViewController
    self.setFrame(windowFrame, display: true)

    RegisterGeneratedPlugins(registry: flutterViewController)

    super.awakeFromNib()
  }
}

This library has TitlebarSafeArea, which pushes content down below the title bar.

I'm displaying tabs in the title bar area and I need the tabs to avoid the traffic lights, but not by pushing the content down. Instead, I need to push the content to the right of the traffic lights, but remain at the top of the screen.

Consider offering a TrafficLightsSafeArea for this purpose. Or, consider adding a property to TitlebarSafeArea that toggles between pushing content down, vs pushing content away from the traffic lights within the title bar.

I filed an equivalent issue in macos_ui before seeing that this package already has a TitlebarSafeArea: macosui/macos_ui#437

I'll let the maintainers hash out where that belongs.

Every Mac desktop window has three little window control buttons, often called "traffic lights".

These buttons have a default appearance, but their location can be changed by the developer.

The traffic lights create at least a couple of issues for UI developers.

First, content needs to avoid the traffic lights. If I'm building a custom app bar, or allowing my content to flow to the top of the window, how do I know where those traffic lights are? This requires an ability to query the current size and location of the traffic lights, from the platform.

Second, if I'm building a custom app bar, it's conventional that the traffic light buttons should appear vertically centered in that app bar. Therefore, I'd like to be able to tell the platform where to put the traffic lights.

I recommend approaching this problem as pass-through control of the platform. I don't recommend trying to hide information, or simplify behavior. The platform has an API for these details - making that API available through this package via Dart is the most versatile option available. Simplified behaviors and widgets can be added on top in macos_ui.

Environment

CPU M1 Pro
macOs 14.3
Flutter 3.19.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision abb292a07e (7 days ago) • 2024-02-20 14:35:05 -0800
Engine • revision 04817c99c9
Tools • Dart 3.3.0 • DevTools 2.31.1

Issue

As described in getting start section, I changed the minimum deployment target to 11.0. But Is still got "increase your application's deployment target to at least 10.14.6" error. By the way, I can find "MACOSX_DEPLOYMENT_TARGET = 11.0;" in project/macos/Runner.xcodeproj/project.pbxproj file, which means I successfully changed the deployment target.

Change this line:

An abstract NSWindowDelegate class that can be used detect NSWindow events, such as window resizing, moving, exposing, and minimizing.

to

“An abstract NSWindowDelegate class that can be used to detect NSWindow events, such as window resizing, moving, exposing, and minimizing.”

When exiting the app, the following error occurs

embedder.cc (2425): 'FlutterPlatformMessageCreateResponseHandle' returned 'kInvalidArguments'. Engine handle was invalid

Using MacOS M1

WindowManipulator is completely based on static methods. This seems to create at least three limitations:

Developers can't use Dart's built-in builder syntax:

WindowManipulator
  ..makeTitlebarTransparent()
  ..enableFullSizeContentView()
  ..etc

It seems unlikely that this API will work in a world with multiple windows.

The implementation can't be replaced with a fake version for tests.

All of these issues could be alleviated by using a typical singleton implementation: WindowManipulator.instance or WindowManipulator.primary, etc.

Is there currently a set of APIs that makes it possible to set the size of the window and place it at the center of the screen?

If not, it would be great to have those APIs. I'm trying to control the initial launch of the app to center a window of a particular window size.

Original issue: alexmercerind/flutter_acrylic#75

NSWindowDelegate offers a number of window-related events, such as window resizing, moving, exposing, and minimizing. This issue proposes a method to listen for those events from the Dart side.

By default, a window is resizable. I'd like to display a window at a set width, that the user isn't allowed to change. I'd like the height to respect a minimum and maximum height if the user tries to resize the window.

Please consider adding an API to specify imposed window constraints that prevent the user from making a window thinner/wider/taller/shorter than desired.

On a related note, I found that the only control I have over window sizing is to set the global rect, which requires knowledge of screen space. I'd prefer to just set the window size, and retain the existing location.

Similarly, the window delegate notifies us when the window will resize to a given Size, but if we want to then further resize the window, based on that new Size, we're forced to create a Rect in global screen space, so that we can use the Rect-based sizing method.

Please consider creating a symmetric API in which we can read and write sizes with Size, and we can read and write global positions with Rect. As of right now, we read Sizes and we write Rects, which is asymmetric.

Lastly, on a further related note, you might consider providing a method to change only the windows offset, without exposing the full Rect. Perhaps I want to move the (x,y) offset of the window, but I don't know the size, and I don't care about the size.

I've longed for an easy way to easily capture global keyboard hotkeys for apps like screen capture (think ShareX) etc... looking to start a bounty for this (not sure how, but definitely need this lol)

https://developer.apple.com/documentation/appkit/nswindow/1419130-ismainwindow

Hello, I saw that it is possible to make sub window transparent like so: macosui/macos_ui#322 (reply in thread)

How did you manage to make it work?
I want to implement it in a fork of this since it would be unreasonable to introduce breaking changes.
It could be helpful for others too, as I honestly don't see official multi-window implementation happening this year.

As of now, calling WindowManipulator.makeWindowFullyTransparent() on sub windows really doesn't do anything as far as I notice.

Expose all colors listed in UI Element Colors.

This could be especially useful for colors whose value depends on the user's system preferences, such as controlAccentColor or selectedTextBackgroundColor.

According to the README.md file, the macOS Deployment Target needs to be set to 10.13 or above:

Now press ⇧ + ⌘ + O once more and search for Runner.xcodeproj. Go to info > Deployment Target and set the macOS Deployment Target to 10.13 or above.

However, in the Podfile, of the example project, the first line reads as follows:

platform :osx, '10.14.6' # IMPORTANT: Make sure this is set to 10.14.6 or above!

There is no mention of this in the README.md file. This could cause confusion for users trying to implement this plugin into their projects.

Add methods to modify and retrieve the minSize and maxSize properties of the NSWindow.

If this is your first time contributing to a macOS plugin, feel free to use the CONTRIBUTING.md file as guidance.

As far as I can tell, based on the README documentation, all window configurations go through imperative static methods.

Consider offering a widget for most/all of these configurations. You don't need to remove the imperative configurations, but it might be a lot more natural for Flutter developers to consume these options as a widget.

Widget build(BuildContext context) {
  return MacWindow(
    initialSize: const Size(1000, 650),
    titlebarStyle: const MacWindowTitleBarStyle(
      transparent: true,
      hideTitle: true,
    ),
    fullSizeContentView: true,
    child: MaterialApp(
      home: MyHomePage(),
    ),
  );
}

By offering these capabilities as a widget, you don't need for developers to explicitly initialize the Flutter binding. You don't need developers to create a place for asynchronous execution. You don't need developers to leave the widget tree.

Allow the window's styleMask property to be modified.