Merging Upstream

.cursor/rules/cursor-rules-location.mdc

@@ -0,0 +1,80 @@
+---
+description: Rules for placing and organizing Cursor rule files in the repository.
+globs: 
+alwaysApply: false
+---
+---
+description: Cursor Rules Location
+globs: *.mdc
+---
+# Cursor Rules Location
+
+Rules for placing and organizing Cursor rule files in the repository.
+
+<rule>
+name: cursor_rules_location
+description: Standards for placing Cursor rule files in the correct directory
+filters:
+  # Match any .mdc files
+  - type: file_extension
+    pattern: "\\.mdc$"
+  # Match files that look like Cursor rules
+  - type: content
+    pattern: "(?s)<rule>.*?</rule>"
+  # Match file creation events
+  - type: event
+    pattern: "file_create"
+
+actions:
+  - type: reject
+    conditions:
+      - pattern: "^(?!\\.\\/\\.cursor\\/rules\\/.*\\.mdc$)"
+        message: "Cursor rule files (.mdc) must be placed in the .cursor/rules directory"
+
+  - type: suggest
+    message: |
+      When creating Cursor rules:
+
+      1. Always place rule files in PROJECT_ROOT/.cursor/rules/:
+         ```
+         .cursor/rules/
+         ├── your-rule-name.mdc
+         ├── another-rule.mdc
+         └── ...
+         ```
+
+      2. Follow the naming convention:
+         - Use kebab-case for filenames
+         - Always use .mdc extension
+         - Make names descriptive of the rule's purpose
+
+      3. Directory structure:
+         ```
+         PROJECT_ROOT/
+         ├── .cursor/
+         │   └── rules/
+         │       ├── your-rule-name.mdc
+         │       └── ...
+         └── ...
+         ```
+
+      4. Never place rule files:
+         - In the project root
+         - In subdirectories outside .cursor/rules
+         - In any other location
+
+examples:
+  - input: |
+      # Bad: Rule file in wrong location
+      rules/my-rule.mdc
+      my-rule.mdc
+      .rules/my-rule.mdc
+
+      # Good: Rule file in correct location
+      .cursor/rules/my-rule.mdc
+    output: "Correctly placed Cursor rule file"
+
+metadata:
+  priority: high
+  version: 1.0
+</rule>

.cursor/rules/git-conventional-commits.mdc

@@ -0,0 +1,84 @@
+---
+description: Rule for automatically committing changes made by CursorAI using conventional commits format.
+globs: 
+alwaysApply: false
+---
+# Git Conventional Commits
+
+Rule for automatically committing changes made by CursorAI using conventional commits format.
+
+<rule>
+name: conventional_commits
+description: Automatically commit changes made by CursorAI using conventional commits format
+filters:
+  - type: event
+    pattern: "build_success"
+  - type: file_change
+    pattern: "*"
+
+actions:
+  - type: execute
+    command: |
+      # Extract the change type and scope from the changes
+      CHANGE_TYPE=""
+      case "$CHANGE_DESCRIPTION" in
+        *"add"*|*"create"*|*"implement"*) CHANGE_TYPE="feat";;
+        *"fix"*|*"correct"*|*"resolve"*) CHANGE_TYPE="fix";;
+        *"refactor"*|*"restructure"*) CHANGE_TYPE="refactor";;
+        *"test"*) CHANGE_TYPE="test";;
+        *"doc"*|*"comment"*) CHANGE_TYPE="docs";;
+        *"style"*|*"format"*) CHANGE_TYPE="style";;
+        *"perf"*|*"optimize"*) CHANGE_TYPE="perf";;
+        *) CHANGE_TYPE="chore";;
+      esac
+
+      # Extract scope from file path
+      SCOPE=$(dirname "$FILE" | tr '/' '-')
+
+      # Commit the changes
+      git add "$FILE"
+      git commit -m "$CHANGE_TYPE($SCOPE): $CHANGE_DESCRIPTION"
+
+  - type: suggest
+    message: |
+      Changes should be committed using conventional commits format:
+
+      Format: <type>(<scope>): <description>
+
+      Types:
+      - feat: A new feature
+      - fix: A bug fix
+      - docs: Documentation only changes
+      - style: Changes that do not affect the meaning of the code
+      - refactor: A code change that neither fixes a bug nor adds a feature
+      - perf: A code change that improves performance
+      - test: Adding missing tests or correcting existing tests
+      - chore: Changes to the build process or auxiliary tools
+
+      The scope should be derived from the file path or affected component.
+      The description should be clear and concise, written in imperative mood.
+
+examples:
+  - input: |
+      # After adding a new feature to track user activities
+      CHANGE_DESCRIPTION="add automatic idle detection feature"
+      FILE="electron/src/background/watchStates/idleService.ts"
+    output: "feat(electron-src-background): add automatic idle detection feature"
+
+  - input: |
+      # After fixing a bug in the timeline component
+      CHANGE_DESCRIPTION="fix incorrect time calculation in timeline"
+      FILE="client/src/components/Timeline/TimelineItem.tsx"
+    output: "fix(client-src-components): fix incorrect time calculation in timeline"
+
+  - input: |
+      # After improving database performance
+      CHANGE_DESCRIPTION="optimize track item queries for better performance"
+      FILE="electron/src/drizzle/trackItem.ts"
+    output: "perf(electron-src-drizzle): optimize track item queries for better performance"
+
+
+metadata:
+  priority: high
+  version: 1.0
+</rule>

.cursorrules

@@ -0,0 +1,192 @@
+# Tockler - Electron/React Time Tracking Application
+
+Tockler is an automatic time-tracking desktop application built with Electron, React, TypeScript, and Chakra UI.
+
+## Project Organization
+
+This project follows a clear separation of concerns:
+
+- **electron/** directory contains all Electron main process code:
+  - System-level operations 
+  - Background activity tracking
+  - Database operations with better-sqlite3
+  - IPC handlers
+  - Application lifecycle management
+  - Tray functionality
+
+- **client/** directory contains all React renderer code:
+  - React UI components
+  - State management with easy-peasy
+  - Chakra UI styling
+  - Data visualization components
+  - View controllers
+  - User interactions
+
+## Knowledge Model
+
+Tockler is a free application that automatically tracks computer usage and working time, providing insights into application usage, window titles, computer states, and visualizations.
+
+## System Design
+
+### Architecture
+- **Main**: The application follows the Electron architecture with a main process and renderer process.
+- **Main Process**: The main process (in electron/ directory) handles system-level operations, background tracking, and database operations.
+- **Renderer Process**: The renderer process (in client/ directory) handles the React UI and user interactions.
+
+### Data Flow
+User activities are tracked by the main process (electron/), stored in a SQLite database using better-sqlite3, and displayed through React components in the renderer process (client/).
+
+### Database Schema
+The application uses better-sqlite3 with Drizzle ORM for data persistence, with database operations handled in the electron/ directory.
+
+## Common Patterns
+
+### State Management
+Use easy-peasy for global state management in the client/ directory.
+
+### API Calls
+Use IPC for communication between main (electron/) and renderer (client/) processes.
+
+### Error Handling
+Use try/catch blocks with proper error logging via electron-log.
+
+### Logging
+Use electron-log for consistent logging across the application.
+
+## Best Practices
+
+### General
+- Follow the Single Responsibility Principle
+- Use TypeScript interfaces/types for all data structures
+- Prefer functional programming patterns where applicable
+- Use proper error handling and logging
+- Document complex functions and components
+
+### Electron (electron/ directory)
+- Use IPC for main/renderer communication
+- Minimize direct access to Node.js APIs from renderer
+- Handle app lifecycle events properly
+- Use proper window management techniques
+- Implement proper auto-updates using electron-updater
+
+### React (client/ directory)
+- Use functional components with hooks
+- Avoid prop drilling by using context or state management
+- Memoize expensive calculations and component renders
+- Split components into smaller, reusable pieces
+- Use Chakra UI components consistently
+
+### Styling (client/ directory)
+- Use Chakra UI theming system
+- Support both light and dark themes
+- Maintain consistent spacing and sizing
+
+## Warnings
+- Avoid synchronous IPC calls as they can block the UI
+- Be careful with memory usage when tracking activities continuously
+- Remember to handle permissions properly for system access features
+- Consider performance implications when working with large datasets
+
+## TypeScript Guidelines
+
+### Rules
+- Use strict type checking
+- Define interfaces for all data structures
+- Use TypeScript's utility types when appropriate
+- Use union types for state management
+- Properly type async functions and their return values
+
+### Naming Conventions
+- **Interfaces**: IPascalCase (e.g., ITrackItem)
+- **Types**: TPascalCase (e.g., TTimelineState)
+- **Components**: PascalCase (e.g., TimelineChart)
+- **Functions**: camelCase (e.g., trackActiveWindow)
+- **Constants**: UPPER_SNAKE_CASE (e.g., DEFAULT_SETTINGS)
+
+### Import Organization
+1. React imports first
+2. Third-party library imports
+3. Local component imports
+4. Type/interface imports
+5. Style/asset imports
+
+## Technology Guidelines
+
+### Electron (electron/ directory)
+
+#### Best Practices
+- Use contextBridge for secure preload scripts
+- Implement proper window management
+- Handle app lifecycle events properly
+- Use proper IPC patterns for main/renderer communication
+- Implement auto-updates correctly
+
+#### Common Patterns
+- **IPC**: Use ipcMain and ipcRenderer for communication
+- **Window Management**: Properly handle window states (minimize, maximize, close)
+- **Tray Integration**: Use menubar for tray window implementation
+- **Auto Launch**: Implement auto-launch on system startup feature
+- **System Access**: Use proper APIs for accessing system information
+
+### React (client/ directory)
+
+#### Best Practices
+- Use functional components with hooks
+- Implement proper state management with easy-peasy
+- Use React Router for navigation
+- Properly handle form state and validation
+- Implement proper error boundaries
+
+#### Component Structure
+- Organize components by feature, with shared components in a common directory
+- Use compound components when appropriate
+- Use Chakra UI for consistent styling
+
+### Chakra UI (client/ directory)
+
+#### Best Practices
+- Use the theme provider for consistent styling
+- Leverage Chakra's built-in responsive design utilities
+- Use Chakra's color mode for light/dark theme support
+- Use Chakra's layout components for consistent spacing
+
+### Data Visualization (client/ directory)
+
+#### Libraries
+- Victory
+- D3.js
+
+#### Patterns
+- Use Victory for high-level chart components
+- Use D3 for custom visualizations and data transformations
+- Ensure visualizations are responsive and accessible
+
+## Project Structure
+- **electron/**: Main process code, system-level operations, background tracking, database interactions
+- **client/**: React client code for the renderer process, UI components, state management, visualization
+- **screenshots/**: Application screenshots for documentation
+
+## Testing
+- **Framework**: Vitest
+- **Patterns**:
+  - Place test files adjacent to the files they test with a .test.ts(x) suffix
+  - Use proper mocking for dependencies
+  - Test components in isolation
+  - Cover edge cases and error handling
+
+## Deployment
+- **Build**: Use electron-builder for packaging
+- **Platforms**: Windows, macOS, Linux
+- **Auto Updates**: Implement using electron-updater
+
+## Development
+
+### Tools
+- **Package Manager**: pnpm
+- **Build Tools**: vite, typescript
+- **Linters**: eslint
+- **Formatters**: prettier
+
+### Workflow
+- **Development**: Run the client/ and electron/ processes separately during development
+- **Building**: Build the client/ first, then package with electron-builder

.github/FUNDING.yml

@@ -1,12 +1,12 @@
 # These are supported funding model platforms
 
 github: MayGo
-patreon: MayGo_
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
+patreon: Tockler
+open_collective: tockler
+ko_fi: maigoerit
 tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
 community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
 liberapay: # Replace with a single Liberapay username
 issuehunt: # Replace with a single IssueHunt username
 otechie: # Replace with a single Otechie username
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
+custom: ['https://paypal.me/maigoerit'] # Replace with your PayPal.me link