-
Notifications
You must be signed in to change notification settings - Fork 40
Improve Windows Support #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Implemented getPlatform method in the flow interface to retrieve the current device platform. * Added custom CSS variants for platform-specific styling in index.css. * Updated BrowserSidebar and main component to apply platform-specific classes for better UI adaptation. * Wrapped BrowserApp in PlatformProvider for platform context management.
WalkthroughThis pull request refactors and extends the application’s codebase across both Electron and Vite. In the Electron layer, it adjusts the visual appearance of the window title bar via native theme detection and modularizes the application’s initialization logic. A new module for managing user profiles has been added. Additionally, platform-detection logic is introduced through added methods in preload and flow modules, and a new PlatformProvider component is implemented to wrap the UI with platform-specific classes. Lastly, styling has been updated with custom CSS variants and package versions have been incremented. Changes
Sequence Diagram(s)sequenceDiagram
participant App as Application
participant Main as initializeApp
participant Auto as setupAutoUpdate
participant Tasks as setupWindowsUserTasks
participant Dock as setupMacOSDock
participant IPC as setupIPCHandlers
participant Browser as Browser Instance
App->>Main: Start app
Main->>Auto: setupAutoUpdate()
Main->>Tasks: setupWindowsUserTasks()
Main->>Dock: setupMacOSDock()
Main->>IPC: setupIPCHandlers()
Main->>Browser: Initialize Browser
Browser-->>Main: Browser created
Main->>App: App initialized
sequenceDiagram
participant Provider as PlatformProvider
participant Flow as getPlatform
participant UI as Child Components
Provider->>Flow: getPlatform()
Flow-->>Provider: Return platform value
Provider->>UI: Render children with platform class
Possibly related PRs
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (2)
electron/preload.ts (1)
43-46: Good addition of platform detection capability.The
getPlatformmethod provides essential platform information to the renderer process, which is crucial for applying platform-specific UI adjustments. This is a fundamental addition for improving Windows support, as it allows the UI to adapt based on the detected platform.Consider returning a more structured object with additional platform information that might be useful for UI adaptations:
- getPlatform: () => { - if (!canUseInterfaceAPI) return; - return process.platform; + getPlatform: () => { + if (!canUseInterfaceAPI) return; + return { + platform: process.platform, + isWindows: process.platform === 'win32', + isMacOS: process.platform === 'darwin', + isLinux: process.platform === 'linux' + }; }electron/modules/profiles.ts (1)
1-4: Consider adding profile validation and additional profile operationsThe module provides basic profile management, but consider adding:
- Profile name validation to prevent filesystem issues
- Functions for renaming and deleting profiles
- Verification that directories in the profiles folder are actually valid profiles
This would make the profiles module more robust and complete.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
electron/browser/main.ts(2 hunks)electron/index.ts(2 hunks)electron/modules/profiles.ts(1 hunks)electron/package.json(1 hunks)electron/preload.ts(1 hunks)package.json(1 hunks)vite/src/components/browser-ui/browser-sidebar.tsx(1 hunks)vite/src/components/browser-ui/main.tsx(1 hunks)vite/src/components/main/platform.tsx(1 hunks)vite/src/index.css(1 hunks)vite/src/lib/flow.ts(2 hunks)vite/src/routes/main/page.tsx(1 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
vite/src/components/main/platform.tsx (1)
vite/src/lib/flow.ts (1)
getPlatform(126-128)
🔇 Additional comments (18)
electron/package.json (1)
4-4: Version bump looks good.The version has been incremented from 0.2.1 to 0.2.2, which aligns with the Windows support improvements made in this PR.
package.json (1)
3-3: Version bump matches electron package.json.The version increment is consistent with the changes in electron/package.json, maintaining alignment between the workspace packages.
electron/browser/main.ts (2)
1-10: Correctly imported nativeTheme for dynamic theme detection.The addition of
nativeThemeto the imports is necessary for the dynamic theme detection that's implemented later in the file.
456-458: Good implementation of dynamic window title bar appearance.The changes improve Windows support by:
- Using
nativeTheme.shouldUseDarkColorsto dynamically set the symbol color based on system theme- Setting a transparent background color for the title bar overlay
This creates a more native-looking experience on Windows while maintaining compatibility with other platforms.
vite/src/components/browser-ui/browser-sidebar.tsx (1)
48-48: Good platform-specific styling implementationThe change adds a platform-specific prefix
platform-darwin:to the height calculation, ensuring this styling only applies on macOS systems. This aligns well with the PR objective of improving Windows support by making styles conditional based on the operating system.vite/src/lib/flow.ts (2)
71-75: Well-documented platform detection APIThe addition of the
getPlatformmethod to the interface is well-documented and provides essential functionality for platform-specific features.
126-128: Clean implementation of the platform detection functionThe
getPlatformfunction correctly wraps the interface method and follows the same pattern as other exported functions in this file.vite/src/routes/main/page.tsx (1)
3-3: Good component hierarchy for platform detectionThe
PlatformProvideris correctly integrated at the root level of the application, which allows platform-specific behaviors to be available throughout the component tree.Also applies to: 11-15
vite/src/components/browser-ui/main.tsx (1)
36-41: Great addition of Windows platform support!The platform-specific styling for Windows (using the
platform-win32prefix) correctly adjusts the padding to account for the title bar height. This is an essential improvement for Windows users that ensures proper content positioning.vite/src/components/main/platform.tsx (1)
1-24: Well-structured platform detection implementationThis platform provider component is well-designed and follows React best practices. It properly detects the operating system platform and wraps the application with the appropriate CSS class. This is a clean approach to enable platform-specific styling throughout the application.
vite/src/index.css (1)
6-9: Good addition of platform-specific CSS variantsThe addition of platform-specific custom variants follows the existing pattern used for dark mode and provides a consistent way to apply platform-specific styles. This approach makes the CSS more maintainable by keeping platform adaptations declarative.
electron/index.ts (7)
10-18: Clean encapsulation of auto-update functionalityThis function properly encapsulates the auto-update configuration, making the code more modular and easier to maintain.
20-31: Good implementation of Windows-specific user tasksThis function nicely modularizes the Windows-specific user tasks setup, which is key for improving Windows support. The implementation allows users to create new windows from the taskbar.
33-55: Well-structured macOS dock menu setupThe dock menu implementation is properly encapsulated, with clear item definitions. This makes the platform-specific behavior more maintainable.
57-98: Good organization of IPC handlersMoving the IPC handlers into a dedicated function improves code organization and readability without changing the functionality.
100-114: Clear header printing functionThis extraction of header printing logic into its own function is a good refactoring that improves code organization.
116-159: Excellent application initialization refactoringThe
initializeAppfunction provides a clear entry point with well-organized initialization steps. It handles startup conditions, single instance checks, and properly delegates to the platform-specific setup functions. This refactoring significantly improves code maintainability.
161-162: Clean application startThe application start is now a simple call to the initialization function, which makes the main flow much clearer.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (3)
electron/modules/profiles.ts (3)
7-9: Consider adding profile ID validation.The function works well, but Windows has stricter filename restrictions than other operating systems. Consider validating
profileIdto reject characters invalid in Windows paths (like< > : " / \ | ? *).export function getProfilePath(profileId: string): string { + // Windows has restrictions on characters in file paths + const invalidChars = /[<>:"\/\\|?*]/; + if (invalidChars.test(profileId)) { + throw new Error(`Invalid profile ID. Contains characters not allowed in file paths: ${profileId}`); + } return path.join(PROFILES_DIR, profileId); }
22-38: Consider filtering out system files in the profiles listing.Windows often creates system files like "desktop.ini" or "thumbs.db" in directories. These should be filtered out when listing profiles to avoid confusion.
export function getProfiles() { try { // Check if directory exists first if (!fs.existsSync(PROFILES_DIR)) { fs.mkdirSync(PROFILES_DIR, { recursive: true }); return []; } - return fs.readdirSync(PROFILES_DIR).map((profile) => ({ - id: profile, - name: profile - })); + // Filter out hidden and system files common on Windows + return fs.readdirSync(PROFILES_DIR) + .filter(profile => { + // Skip hidden files and common Windows system files + return !profile.startsWith('.') && + !['desktop.ini', 'thumbs.db', 'Thumbs.db'].includes(profile); + }) + .map((profile) => ({ + id: profile, + name: profile + })); } catch (error) { console.error("Error reading profiles directory:", error); return []; } }
22-38: Consider adding profile existence check in createProfile.To improve Windows support, add a check to prevent profile overwriting, as this can cause unexpected behavior or errors on Windows when files in the directory are in use.
export function createProfile(profileName: string) { try { const profilePath = getProfilePath(profileName); + // Check if profile already exists to avoid overwriting + if (fs.existsSync(profilePath)) { + console.warn(`Profile ${profileName} already exists.`); + return false; + } fs.mkdirSync(profilePath, { recursive: true }); return true; } catch (error) { console.error(`Error creating profile ${profileName}:`, error); return false; } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
assets/screenshots/beta-3.pngis excluded by!**/*.pngassets/screenshots/beta-4.pngis excluded by!**/*.png
📒 Files selected for processing (3)
README.md(1 hunks)electron/browser/main.ts(3 hunks)electron/modules/profiles.ts(1 hunks)
🔇 Additional comments (6)
README.md (1)
18-21: Enhance Screenshot Labeling for Platform ClarityThe updated screenshot labels now clearly differentiate between macOS and Windows environments, directly supporting the PR objective to improve Windows support. This change enhances documentation clarity and sets the expectation for platform-specific visuals. Please verify that the referenced image files (beta-1.png, beta-2.png, beta-3.png, beta-4.png) exist and are correctly stored in the
./assets/screenshots/directory.electron/modules/profiles.ts (2)
1-5: LGTM: Good approach for cross-platform imports and path handling.The imports and path setup use platform-agnostic methods, which is essential for Windows compatibility. Using
path.join()ensures proper path separators across different operating systems.
11-20: Good implementation with error handling.The implementation properly handles errors during profile creation and returns a meaningful result. This is already following the best practices suggested in the previous review.
electron/browser/main.ts (3)
8-9: Good addition of nativeTheme import.The import of
nativeThemefrom Electron is appropriate for implementing dynamic theme detection, which will improve the application's appearance on Windows systems by properly adapting window control buttons to the user's system theme.
456-457: Well-implemented theme-aware title bar overlay.The changes to the titleBarOverlay configuration enhance cross-platform compatibility:
- Setting
symbolColordynamically based onnativeTheme.shouldUseDarkColorsensures window controls are always visible in both light and dark themes.- Using transparent background color (
rgba(0,0,0,0)) instead of a fixed color improves visual integration with the application's UI.This is a robust approach to handle theme differences across platforms.
471-471:Details
❓ Verification inconclusive
Appropriate compromise for Windows UI.
The comment clearly explains why the Windows-specific
backgroundMaterialproperty is disabled, preventing potential conflicts with rounded corners. This demonstrates careful consideration of the tradeoffs between different visual effects on Windows.Consider exploring alternative approaches if both rounded corners and acrylic effects are desired in future updates.
🏁 Script executed:
#!/bin/bash # Check if there are any open issues related to Windows UI elements like rounded corners and acrylic effect gh issue list --search "rounded corners acrylic windows" --limit 5Length of output: 68
Windows UI compromise in
electron/browser/main.ts(line 471) looks acceptable—with a caveat.
- The disabled Windows-specific
backgroundMaterial: "acrylic"(commented out) is clearly explained as being necessary to avoid conflicts with rounded corners. This trade-off is reasonable given the visual constraints.- The suggestion to explore alternative approaches for achieving both acrylic effects and rounded corners in future revisions is prudent.
- However, the automated check for related issues (using
gh issue list --search "rounded corners acrylic windows") did not return any results. Please perform manual verification to ensure there are indeed no open concerns or emerging issues that might impact Windows UI behavior.
Summary by CodeRabbit
New Features
PlatformProvidercomponent added for improved context management.Refactor
Chores