docs(v3): update API references to new Manager API pattern #4863
Conversation
Update documentation to reflect the Manager API refactoring from alpha.10: Window API: - app.NewWebviewWindow() -> app.Window.New() - app.NewWebviewWindowWithOptions() -> app.Window.NewWithOptions() - app.CurrentWindow() -> app.Window.Current() - app.GetAllWindows() -> app.Window.GetAll() - app.WindowByName() -> app.Window.GetByName() Event API: - app.EmitEvent() -> app.Event.Emit() - app.OnEvent() -> app.Event.On() - app.OnApplicationEvent() -> app.Event.OnApplicationEvent() Dialog API: - app.OpenFileDialog() -> app.Dialog.OpenFile() - app.SaveFileDialog() -> app.Dialog.SaveFile() - app.InfoDialog() -> app.Dialog.Info() - app.ErrorDialog() -> app.Dialog.Error() - app.WarningDialog() -> app.Dialog.Warning() - app.QuestionDialog() -> app.Dialog.Question() Other APIs: - app.NewSystemTray() -> app.SystemTray.New() - app.SetApplicationMenu() -> app.Menu.Set() - app.GetPrimaryScreen() -> app.Screen.GetPrimary() - app.GetAllScreens() -> app.Screen.GetAll() - app.ClipboardGetText() -> app.Clipboard.Text() - app.ClipboardSetText() -> app.Clipboard.SetText() - app.BrowserOpenURL() -> app.Browser.OpenURL() Fixes outdated code examples across 31 documentation files.
|
Caution Review failedThe pull request is closed. WalkthroughDocumentation examples updated to reflect API reorganization: application-level helpers moved into manager namespaces (e.g., Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/src/content/docs/reference/menu.mdx (1)
384-384: Update example code to use new ContextMenu API.The example code still uses the old API
app.RegisterContextMenu("editor", contextMenu), but the reference documentation at line 360-365 correctly shows the new API should beapp.ContextMenu.Add("editor", contextMenu).♻️ Suggested fix for consistency
Line 384:
-app.RegisterContextMenu("editor", contextMenu) +app.ContextMenu.Add("editor", contextMenu)Line 409:
-app.RegisterContextMenu("editor", contextMenu) +app.ContextMenu.Add("editor", contextMenu)Also applies to: 409-409
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (31)
docs/src/content/docs/concepts/architecture.mdxdocs/src/content/docs/concepts/bridge.mdxdocs/src/content/docs/concepts/build-system.mdxdocs/src/content/docs/contributing/runtime-internals.mdxdocs/src/content/docs/faq.mdxdocs/src/content/docs/features/bindings/best-practices.mdxdocs/src/content/docs/features/bindings/methods.mdxdocs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/features/clipboard/basics.mdxdocs/src/content/docs/features/dialogs/custom.mdxdocs/src/content/docs/features/drag-and-drop/files.mdxdocs/src/content/docs/features/events/system.mdxdocs/src/content/docs/features/menus/application.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/menus/systray.mdxdocs/src/content/docs/features/screens/info.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/features/windows/multiple.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/guides/distribution/custom-protocols.mdxdocs/src/content/docs/guides/performance.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/migration/v2-to-v3.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/reference/events.mdxdocs/src/content/docs/reference/menu.mdxdocs/src/content/docs/reference/overview.mdxdocs/src/content/docs/reference/window.mdx
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
Learnt from: popaprozac
Repo: wailsapp/wails PR: 4839
File: docs/src/content/docs/reference/window.mdx:616-620
Timestamp: 2025-12-29T08:02:15.134Z
Learning: In Wails v3, the correct API for creating windows is `app.Window.New()` and `app.Window.NewWithOptions(...)`, not `app.NewWebviewWindow()` or `app.NewWebviewWindowWithOptions(...)`. The Application struct exposes a Window field of type *WindowManager that provides these methods.
📚 Learning: 2025-12-29T08:02:06.122Z
Learnt from: popaprozac
Repo: wailsapp/wails PR: 4839
File: docs/src/content/docs/reference/window.mdx:616-620
Timestamp: 2025-12-29T08:02:06.122Z
Learning: In Wails v3, document window creation using app.Window.New() and app.Window.NewWithOptions(...). Do not show or reference app.NewWebviewWindow() or app.NewWebviewWindowWithOptions(...). The Application struct exposes a Window field of type *WindowManager that provides these methods. When updating docs, replace examples accordingly and mention that WindowManager methods create and configure new windows.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/overview.mdxdocs/src/content/docs/concepts/build-system.mdxdocs/src/content/docs/guides/performance.mdxdocs/src/content/docs/reference/window.mdxdocs/src/content/docs/concepts/architecture.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/migration/v2-to-v3.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/contributing/runtime-internals.mdxdocs/src/content/docs/features/bindings/best-practices.mdxdocs/src/content/docs/faq.mdxdocs/src/content/docs/features/events/system.mdxdocs/src/content/docs/guides/distribution/custom-protocols.mdxdocs/src/content/docs/concepts/bridge.mdxdocs/src/content/docs/features/drag-and-drop/files.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/reference/events.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/features/menus/application.mdxdocs/src/content/docs/reference/menu.mdxdocs/src/content/docs/features/dialogs/custom.mdxdocs/src/content/docs/features/menus/systray.mdxdocs/src/content/docs/features/clipboard/basics.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/screens/info.mdxdocs/src/content/docs/features/bindings/methods.mdxdocs/src/content/docs/features/windows/multiple.mdx
📚 Learning: 2024-09-20T23:34:29.841Z
Learnt from: nixpare
Repo: wailsapp/wails PR: 3763
File: v3/examples/keybindings/main.go:16-17
Timestamp: 2024-09-20T23:34:29.841Z
Learning: In the codebase, `application.Options.KeyBindings` uses the `application.Window` type, whereas `application.WebviewWindowOptions.KeyBindings` uses `*application.WebviewWindow`. This is intentional and acceptable.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/overview.mdxdocs/src/content/docs/concepts/build-system.mdxdocs/src/content/docs/reference/window.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/migration/v2-to-v3.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/contributing/runtime-internals.mdxdocs/src/content/docs/faq.mdxdocs/src/content/docs/features/events/system.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/reference/events.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/features/menus/application.mdxdocs/src/content/docs/features/dialogs/custom.mdxdocs/src/content/docs/features/menus/systray.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/screens/info.mdxdocs/src/content/docs/features/bindings/methods.mdxdocs/src/content/docs/features/windows/multiple.mdx
📚 Learning: 2025-08-08T09:13:16.916Z
Learnt from: APshenkin
Repo: wailsapp/wails PR: 4480
File: v2/internal/frontend/desktop/darwin/message.h:17-19
Timestamp: 2025-08-08T09:13:16.916Z
Learning: In Wails v2 bindings origin verification, processBindingMessage intentionally has different signatures across platforms: Darwin includes an isMainFrame bool (WKWebKit provides it), Linux uses two params (message, source) as WebKitGTK doesn’t expose main-frame info there, and Windows handles origin checks in Go via WebView2 sender/args without a C bridge. This divergence is acceptable/expected per maintainer (APshenkin).
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/features/screens/info.mdx
📚 Learning: 2025-10-17T23:16:11.570Z
Learnt from: Sammy-T
Repo: wailsapp/wails PR: 4570
File: v2/internal/frontend/desktop/linux/window_webkit6.go:97-108
Timestamp: 2025-10-17T23:16:11.570Z
Learning: For webkit_6/GTK4 builds in v2/internal/frontend/desktop/linux/window_webkit6.go, GTK widget creation should not be wrapped in invokeOnMainThread. The activation mechanism (activateWg + onActivate export) already handles thread safety, and additional wrapping would cause issues.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/overview.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/contributing/runtime-internals.mdxdocs/src/content/docs/faq.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/features/dialogs/custom.mdxdocs/src/content/docs/features/windows/basics.mdx
📚 Learning: 2024-10-08T22:11:37.054Z
Learnt from: nixpare
Repo: wailsapp/wails PR: 3763
File: v3/pkg/application/application_options.go:93-93
Timestamp: 2024-10-08T22:11:37.054Z
Learning: The `KeyBindings` property of `application.Option` uses the `application.Window` type, while `application.WebviewWindowOptions` still accepts `*application.WebviewWindow`, and this is intentional.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/window.mdxdocs/src/content/docs/migration/v2-to-v3.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/features/dialogs/custom.mdxdocs/src/content/docs/features/menus/systray.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/screens/info.mdxdocs/src/content/docs/features/windows/multiple.mdx
📚 Learning: 2025-12-13T19:52:13.812Z
Learnt from: leaanthony
Repo: wailsapp/wails PR: 4783
File: v3/pkg/events/events.go:72-100
Timestamp: 2025-12-13T19:52:13.812Z
Learning: In Wails v3, the linux:WindowLoadChanged event was intentionally removed as a breaking change and replaced with four granular WebKit2 load events: linux:WindowLoadStarted, linux:WindowLoadRedirected, linux:WindowLoadCommitted, and linux:WindowLoadFinished. Users should migrate to linux:WindowLoadFinished for detecting when the WebView has finished loading.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/window.mdxdocs/src/content/docs/features/windows/events.mdxdocs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/features/menus/context.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/guides/distribution/custom-protocols.mdxdocs/src/content/docs/guides/raw-messages.mdxdocs/src/content/docs/features/menus/application.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/screens/info.mdxdocs/src/content/docs/features/bindings/methods.mdx
📚 Learning: 2024-09-30T06:13:46.595Z
Learnt from: leaanthony
Repo: wailsapp/wails PR: 3763
File: v3/examples/window/main.go:472-475
Timestamp: 2024-09-30T06:13:46.595Z
Learning: In `v3/examples/window/main.go`, `time.Sleep` is used within a goroutine and does not block the UI thread.
Applied to files:
docs/src/content/docs/features/bindings/models.mdxdocs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/reference/overview.mdxdocs/src/content/docs/concepts/build-system.mdxdocs/src/content/docs/reference/window.mdxdocs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/migration/v2-to-v3.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/contributing/runtime-internals.mdxdocs/src/content/docs/faq.mdxdocs/src/content/docs/reference/application.mdxdocs/src/content/docs/features/windows/basics.mdxdocs/src/content/docs/features/bindings/methods.mdx
📚 Learning: 2024-09-21T13:34:24.145Z
Learnt from: nixpare
Repo: wailsapp/wails PR: 3763
File: v3/pkg/application/webview_window_bindings_darwin.h:0-0
Timestamp: 2024-09-21T13:34:24.145Z
Learning: In this codebase, typedefs for window references (like replacing `void *` with `WindowRef`) are not preferred; using `void *` is acceptable.
Applied to files:
docs/src/content/docs/features/windows/options.mdxdocs/src/content/docs/features/windows/frameless.mdxdocs/src/content/docs/features/screens/info.mdx
📚 Learning: 2025-03-24T20:22:56.233Z
Learnt from: popaprozac
Repo: wailsapp/wails PR: 4098
File: v3/pkg/services/notifications/notifications.go:46-55
Timestamp: 2025-03-24T20:22:56.233Z
Learning: In the notifications package, initialization of the `Service` struct is handled through platform-specific `New()` functions in each implementation file (darwin, windows, linux) rather than a generic constructor in the main package file. Each platform implementation follows a singleton pattern using `notificationServiceOnce.Do()` and creates a global `NotificationService` variable that's accessed through a thread-safe `getNotificationService()` function.
Applied to files:
docs/src/content/docs/features/bindings/services.mdxdocs/src/content/docs/features/events/system.mdxdocs/src/content/docs/reference/events.mdx
📚 Learning: 2025-04-18T05:57:34.711Z
Learnt from: leaanthony
Repo: wailsapp/wails PR: 4128
File: v3/examples/gin-service/services/gin_service.go:67-85
Timestamp: 2025-04-18T05:57:34.711Z
Learning: In Wails services (like GinService), initializing the app field in ServiceStartup rather than in the constructor is an acceptable pattern, as ServiceStartup is guaranteed to be called before any HTTP requests are handled.
Applied to files:
docs/src/content/docs/features/events/system.mdxdocs/src/content/docs/reference/events.mdx
📚 Learning: 2025-03-24T20:22:56.233Z
Learnt from: popaprozac
Repo: wailsapp/wails PR: 4098
File: v3/pkg/services/notifications/notifications.go:46-55
Timestamp: 2025-03-24T20:22:56.233Z
Learning: In the notifications package, initialization of the `Service` struct is handled through platform-specific `New()` functions in each implementation file (darwin, windows, linux) rather than a generic constructor in the main package file.
Applied to files:
docs/src/content/docs/features/events/system.mdxdocs/src/content/docs/reference/events.mdx
📚 Learning: 2025-01-24T22:41:18.566Z
Learnt from: leaanthony
Repo: wailsapp/wails PR: 4031
File: v3/pkg/application/menu.go:199-202
Timestamp: 2025-01-24T22:41:18.566Z
Learning: In the Wails menu system (v3/pkg/application/menu.go), shared state between menus is intentionally designed and desirable. Methods like `Append()` and `Prepend()` should maintain shared references to menu items rather than creating deep copies.
Applied to files:
docs/src/content/docs/reference/menu.mdx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: Run Go Tests v3 (macos-latest, 1.24)
- GitHub Check: Run Go Tests v3 (ubuntu-latest, 1.24)
- GitHub Check: Run Go Tests v3 (windows-latest, 1.24)
- GitHub Check: semgrep/ci
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Analyze (go)
- GitHub Check: Analyze (go)
- GitHub Check: Cloudflare Pages
🔇 Additional comments (42)
docs/src/content/docs/features/bindings/models.mdx (1)
631-631: LGTM! Correct usage of the new Window Manager API.The update to
app.Window.New()correctly reflects the new Manager API pattern for window creation in Wails v3 alpha.10.Based on learnings, this is the correct API for creating windows in v3.
docs/src/content/docs/features/bindings/services.mdx (3)
441-441: LGTM! Correct API update for event emission.The change from
EmitEvent()toEvent.Emit()correctly reflects the new Manager API pattern for event operations.
488-488: LGTM! Consistent API update for event emission.The change correctly updates the event emission to use the new
Event.Emit()pattern, consistent with the Manager API refactoring.
783-783: LGTM! Correct API update for window creation.The change from
NewWebviewWindow()toWindow.New()correctly reflects the new Manager API pattern for window operations. This aligns with the established pattern documented in the learnings.docs/src/content/docs/concepts/architecture.mdx (1)
267-267: LGTM! Correct API update for event emission.The change from
app.EmitEvent()toapp.Event.Emit()correctly reflects the Manager API pattern introduced in alpha.10. The event name and payload remain unchanged, ensuring semantic equivalence.docs/src/content/docs/features/bindings/best-practices.mdx (1)
277-277: LGTM! Event emission correctly updated.The update from
s.app.EmitEvent()tos.app.Event.Emit()is correct and aligns with the new Manager API pattern. The progress payload structure remains intact.docs/src/content/docs/features/menus/context.mdx (1)
485-485: LGTM! Window creation API correctly updated.The change from
app.NewWebviewWindow()toapp.Window.New()correctly reflects the Window manager API. This aligns with the documented pattern where the Application struct exposes a Window field of type *WindowManager.Based on learnings, this is the correct v3 API for window creation.
docs/src/content/docs/contributing/runtime-internals.mdx (1)
42-42: LGTM! Internal documentation correctly updated.The comment accurately reflects that
app.Window.New()delegates to the platform-specific constructors ininternal/runtime/webview_window_*.go. This keeps the internal architecture documentation consistent with the new API surface.docs/src/content/docs/concepts/bridge.mdx (1)
541-541: LGTM! Event emission correctly updated in streaming example.The change from
app.EmitEvent()toapp.Event.Emit()properly demonstrates the Manager API pattern for streaming data via events. The example remains a valid best practice for handling large data transfers.docs/src/content/docs/features/clipboard/basics.mdx (1)
67-67: LGTM! API references correctly updated to new Manager pattern.The dialog and event API calls have been properly updated to use the new namespaced manager pattern (
app.Dialog.Info(),app.Dialog.Error(),app.Event.Emit()), which aligns with the Manager API refactoring introduced in alpha.10. Based on learnings, this is the correct API pattern for Wails v3.Also applies to: 72-72, 299-299
docs/src/content/docs/faq.mdx (1)
126-127: LGTM! FAQ examples correctly updated to new Manager API.All API references have been properly updated to reflect the new manager pattern:
app.Window.New()for window creationapp.SystemTray.New()for system trayapp.Dialog.OpenFile()for file dialogsapp.Event.Emit()for eventsThese changes correctly document the v3 API pattern as confirmed by the retrieved learnings.
Also applies to: 135-135, 145-145, 197-197, 207-207
docs/src/content/docs/features/dialogs/custom.mdx (2)
17-17: LGTM! Custom dialog window creation correctly updated.All custom dialog examples now properly use
app.Window.NewWithOptions(application.WebviewWindowOptions{...})instead of the old flat API. This correctly demonstrates the Window manager pattern for creating dialog windows in v3. Based on learnings, this is the correct approach for window creation.Also applies to: 51-51, 82-82, 122-122, 159-159, 218-218, 269-269, 339-339, 424-424, 473-473
175-175: LGTM! Event handlers correctly updated to Event manager.Event registration calls have been properly migrated to
app.Event.On(), which is the correct v3 pattern for listening to custom events in dialog examples.Also applies to: 180-180, 237-237, 245-245
docs/src/content/docs/features/events/system.mdx (2)
19-19: LGTM! Event system API comprehensively updated to new Manager pattern.All event-related API calls throughout this documentation have been correctly updated:
app.Event.Emit()for emitting eventsapp.Event.On()for listening to custom eventsapp.Event.OnApplicationEvent()for system eventsThe examples now accurately demonstrate the v3 Event manager API across all use cases including pub/sub patterns, request/response, broadcasting, and event aggregation.
Also applies to: 45-47, 65-65, 72-72, 98-98, 105-121, 148-148, 157-157, 167-169, 207-207, 211-211, 218-218, 222-222, 234-234, 239-239, 248-248, 253-253, 262-262, 267-267, 350-350, 356-356, 361-361, 366-366, 379-379, 386-386, 401-401, 425-425, 449-449, 463-463, 465-465, 469-469, 483-483, 488-488
480-480: LGTM! Window creation correctly uses Window manager.The window creation example properly uses
app.Window.New(), which is the correct v3 API as confirmed by the retrieved learnings.docs/src/content/docs/guides/performance.mdx (1)
119-119: LGTM! Event emission in async operations correctly updated.The event emission calls in the goroutine example have been properly updated to use
s.app.Event.Emit(), correctly demonstrating the v3 Event manager API for notifying about background task completion and errors.Also applies to: 122-122
docs/src/content/docs/reference/overview.mdx (1)
40-40: LGTM! API reference correctly updated.The error handling example now correctly demonstrates the new
app.Window.New()API, consistent with the Manager pattern refactoring.docs/src/content/docs/features/windows/options.mdx (1)
89-895: LGTM! Window creation examples correctly updated throughout.All window creation calls have been consistently updated to use the new Manager API:
app.Window.NewWithOptions(...)for windows with configurationapp.Window.New()for simple creationThe changes correctly preserve all options and demonstrate the new pattern across diverse examples (hidden windows, file drop, content protection, complete production setup).
docs/src/content/docs/features/drag-and-drop/files.mdx (1)
118-118: LGTM! Event emission correctly updated.The event emission call now uses
app.Event.Emit(...), correctly following the new Manager API pattern while preserving the event name and payload structure.docs/src/content/docs/features/screens/info.mdx (1)
269-349: LGTM! Screen-related window creation examples updated correctly.Both the multi-monitor window creation (
CreateWindowOnScreen) and DPI-aware window sizing (createDPIAwareWindow) examples now correctly useapp.Window.NewWithOptions(...), demonstrating the new Manager API in screen information contexts.docs/src/content/docs/concepts/build-system.mdx (1)
328-328: LGTM! Build system example correctly updated.The asset embedding example correctly uses
app.Window.New()for window creation, consistent with the new Manager API pattern. Documentation has been fully migrated to the new API.docs/src/content/docs/guides/raw-messages.mdx (3)
50-53: LGTM! Correctly updated to Window manager API.The migration from
app.NewWebviewWindowWithOptions()toapp.Window.NewWithOptions()correctly reflects the new Manager API pattern introduced in alpha.10.Based on learnings, this is the correct v3 API for window creation.
294-299: LGTM! Window creation API correctly updated.Consistent use of the new
app.Window.NewWithOptions()pattern in the complete example.
385-385: LGTM! Event API correctly updated.The migration from
app.EmitEvent()toapp.Event.Emit()correctly reflects the new Event manager pattern.docs/src/content/docs/features/windows/frameless.mdx (1)
17-22: LGTM! Comprehensive and consistent API migration.All window creation examples throughout this frameless windows documentation have been correctly updated to use
app.Window.NewWithOptions(). The migration is consistent across:
- Quick Start example
- Basic frameless windows
- Transparent background examples
- Platform-specific sections (Windows, macOS, Linux)
- Common patterns (splash screens, rounded windows, overlays)
- Complete production example
Also applies to: 55-59, 76-79, 339-344, 374-380, 409-411, 503-510, 533-536, 563-567, 605-625
docs/src/content/docs/features/bindings/methods.mdx (2)
464-464: LGTM! Event emission correctly updated.The progress event example correctly uses
app.Event.Emit()to demonstrate the streaming pattern with the new Event manager API.
533-533: LGTM! Simple window creation correctly updated.The Todo example correctly uses
app.Window.New()for straightforward window creation without custom options.docs/src/content/docs/reference/window.mdx (5)
33-35: LGTM! Window creation examples correctly updated.Both reference examples correctly demonstrate
app.Window.New()for basic window creation in the Show() and Centre() method documentation.Also applies to: 205-207
444-453: LGTM! Dialog API correctly updated.The window close confirmation example correctly uses
app.Dialog.Question()with the new Dialog manager API pattern. The chained method calls (SetTitle, SetMessage, SetButtons, Show) remain correct.
460-475: LGTM! Dialog usage consistent.The save-before-closing example correctly uses
app.Dialog.Question()consistent with the new Dialog manager API.
623-631: LGTM! Window creation with options correctly updated.The complete example correctly demonstrates
app.Window.NewWithOptions()with comprehensive window configuration, serving as a good reference for the new API pattern.
641-650: LGTM! Dialog API correctly applied.The complete example's close confirmation correctly uses
app.Dialog.Question(), consistent with the Dialog manager API migration throughout this file.docs/src/content/docs/features/menus/application.mdx (1)
63-63: LGTM! Window creation correctly updated in menu examples.Both the Quick Start and Complete Example sections correctly use
app.Window.New()for basic window creation, appropriately focusing on menu setup while demonstrating the new Window manager API.Also applies to: 490-490
docs/src/content/docs/features/menus/systray.mdx (1)
41-41: LGTM! API migration is accurate.All system tray and window creation calls have been correctly updated to use the new Manager API pattern (
app.SystemTray.New(),app.Window.New(),app.Window.NewWithOptions()). The changes are consistent throughout the document.Based on learnings, this aligns with the correct Wails v3 API where window creation uses
app.Window.New()and related methods.Also applies to: 56-56, 71-71, 98-98, 165-165, 184-184, 201-201, 448-448, 456-456
docs/src/content/docs/reference/menu.mdx (1)
319-324: LGTM! Reference documentation updated correctly.The API reference sections have been properly updated to reflect the Manager pattern:
app.Menu.Set()for application menusapp.ContextMenu.Add()for context menu registrationapp.SystemTray.New()for system tray creation- Window creation using
app.Window.New()All function signatures and usage examples in the updated sections are accurate.
Based on learnings, these API paths align with the correct Wails v3 Manager API structure.
Also applies to: 350-350, 360-365, 415-420, 425-425, 575-575, 577-577, 589-589, 670-670
docs/src/content/docs/features/windows/events.mdx (1)
77-77: LGTM! Event and Window API migrations are correct.All window creation and event handling calls have been properly updated:
- Window creation:
app.Window.New()andapp.Window.NewWithOptions()- Event emission:
app.Event.Emit()- Event listening:
app.Event.On()The changes maintain consistency with the Manager API pattern across all examples.
Also applies to: 167-167, 440-440, 569-569, 573-573, 592-592, 659-659
docs/src/content/docs/guides/distribution/custom-protocols.mdx (1)
45-45: LGTM! Protocol handler API migration is accurate.The custom protocol documentation has been correctly updated:
- Event registration:
app.Event.On(application.Events.ApplicationOpenedWithURL, ...)- Window creation:
app.Window.NewWithOptions(...)The migration maintains the protocol handling functionality while using the new Manager API pattern.
Also applies to: 65-65, 365-365, 373-373
docs/src/content/docs/reference/application.mdx (1)
83-94: LGTM! Application API reference comprehensively updated.The core Application API reference has been thoroughly updated to document the Manager pattern:
Window Manager:
app.Window.New()- Create windowsapp.Window.NewWithOptions()- Create windows with optionsapp.Window.GetByName()- Retrieve windows by nameapp.Window.GetAll()- Get all windowsEvent Manager:
app.Event.Emit()- Emit custom eventsapp.Event.On()- Listen for custom eventsapp.Event.OnApplicationEvent()- Handle application lifecycle eventsAll function signatures, parameters, and usage examples are accurate and consistent with the new API structure.
Based on learnings, this correctly documents the Window and Event manager APIs introduced in Wails v3.
Also applies to: 98-115, 117-132, 134-149, 171-171, 210-226, 228-244, 246-262, 418-426
docs/src/content/docs/features/windows/basics.mdx (1)
27-27: LGTM! Consistent API pattern updates.All window creation, retrieval, and event API references have been correctly updated to the new Manager pattern. The documentation clearly demonstrates:
app.Window.New()andapp.Window.NewWithOptions()for window creationapp.Window.Current()andapp.Window.GetAll()for window retrievalapp.Event.Emit()andapp.Event.On()for event handlingThe examples are consistent and align with the alpha.10 API refactoring.
Based on learnings, these changes correctly reflect the Wails v3 API where the Application struct exposes a Window field of type *WindowManager.
Also applies to: 50-50, 64-64, 104-104, 262-262, 273-273, 326-326, 334-334, 352-357, 370-370, 416-416, 445-445, 470-470, 496-496
docs/src/content/docs/migration/v2-to-v3.mdx (1)
52-52: LGTM! Migration guide accurately reflects API reorganization.The migration guide correctly documents all key API surface changes:
- Window management moved to
app.Window.*namespace- Event handling moved to
app.Event.*namespace- Dialog methods moved to
app.Dialog.*namespace- SystemTray creation moved to
app.SystemTray.*namespaceAll v3 examples consistently use the new Manager pattern, and the "Why this is better" explanations provide helpful context for migrating developers.
Also applies to: 140-140, 145-145, 206-211, 239-243, 342-342, 419-422, 513-513, 552-552, 605-606, 619-619
docs/src/content/docs/reference/events.mdx (1)
27-33: LGTM! Comprehensive event API documentation update.The Events API reference is thoroughly and consistently updated:
- All method signatures correctly show
em *EventManageras the receiver- Section headers and examples use
app.Event.Emit(),app.Event.On(), andapp.Event.OnApplicationEvent()- The complete example (lines 484-566) demonstrates proper integration with other updated APIs
- Cross-references to Window and Dialog APIs are also correctly updated
The documentation clearly reflects the Event namespace reorganization in the Manager API pattern.
Also applies to: 54-60, 190-196, 206-218, 271-320, 352-394, 438-456, 501-530, 539-565, 676-683, 723-723, 752-780
docs/src/content/docs/features/windows/multiple.mdx (1)
35-43: LGTM! Multi-window patterns correctly updated.All multi-window documentation has been thoroughly updated to use the Manager API pattern:
- Window creation consistently uses
app.Window.New()andapp.Window.NewWithOptions()- Window enumeration and retrieval use
app.Window.GetAll()andapp.Window.Current()- Inter-window communication uses
app.Event.Emit()andapp.Event.On()- All patterns (singleton, document windows, tool palettes, modal dialogs, inspector/preview, window pools, workspace management) demonstrate correct API usage
- The complete production example (lines 633-784) serves as an excellent reference implementation
The documentation is internally consistent with no mixing of old and new API styles.
Also applies to: 74-74, 95-95, 135-141, 173-173, 207-207, 248-248, 278-278, 297-297, 335-335, 360-360, 385-385, 466-466, 533-533, 601-601, 670-714
Deploying wails with
|
| Latest commit: |
32ecec1
|
| Status: | ⚡️ Build in progress... |
|
|
Summary
Updates documentation to reflect the Manager API refactoring introduced in alpha.10.
The docs contained many references to the old flat API pattern (e.g.,
app.NewWebviewWindow(),app.EmitEvent()) which was replaced with the organized manager pattern (e.g.,app.Window.New(),app.Event.Emit()).Changes
Window API
app.NewWebviewWindow()→app.Window.New()app.NewWebviewWindowWithOptions()→app.Window.NewWithOptions()app.CurrentWindow()→app.Window.Current()app.GetAllWindows()→app.Window.GetAll()app.WindowByName()→app.Window.GetByName()Event API
app.EmitEvent()→app.Event.Emit()app.OnEvent()→app.Event.On()app.OnApplicationEvent()→app.Event.OnApplicationEvent()Dialog API
app.OpenFileDialog()→app.Dialog.OpenFile()app.SaveFileDialog()→app.Dialog.SaveFile()app.InfoDialog()→app.Dialog.Info()app.ErrorDialog()→app.Dialog.Error()app.WarningDialog()→app.Dialog.Warning()app.QuestionDialog()→app.Dialog.Question()Other APIs
app.NewSystemTray()→app.SystemTray.New()app.SetApplicationMenu()→app.Menu.Set()app.GetPrimaryScreen()→app.Screen.GetPrimary()app.GetAllScreens()→app.Screen.GetAll()app.ClipboardGetText()→app.Clipboard.Text()app.ClipboardSetText()→app.Clipboard.SetText()app.BrowserOpenURL()→app.Browser.OpenURL()Files Changed
31 documentation files across:
Notes
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.