Relevant source files

The following files were used as context for generating this wiki page: - [scripts/build_all.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/scripts/build_all.sh) - [packaging/README.md](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/README.md) - [packaging/flatpak/build.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/flatpak/build.sh) - [packaging/debian/build.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/debian/build.sh) - [packaging/arch/build.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/arch/build.sh) - [scripts/dev.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/scripts/dev.sh) - [CONTRIBUTING.md](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/CONTRIBUTING.md) - [packaging/flatpak/org.badkiko.sofl.yml](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/flatpak/org.badkiko.sofl.yml)

# Building from Source The Steam Online Fix Launcher (SOFL) project utilizes the Meson build system and provides a comprehensive set of shell scripts to automate the build and packaging process for various Linux distributions. This system is designed to support both local development workflows and the creation of distributable packages in formats like Flatpak, Debian (`.deb`), and Arch Linux. The core of the build process is managed through a master script, `scripts/build_all.sh`, which orchestrates package-specific build scripts located in the `packaging/` directory. For developers, a dedicated script, `scripts/dev.sh`, simplifies the setup, compilation, and execution of the application in a local environment. Sources: [packaging/README.md](), [scripts/dev.sh](), [CONTRIBUTING.md]() ## Prerequisites To build the application from source, several tools and libraries are required. The core dependencies are for the application itself, while packaging requires additional tools specific to each format. | Dependency | Description | Required For | Source File(s) | | ------------------ | ---------------------------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Python | Version 3.10+ is required for the application code. | All Builds | [CONTRIBUTING.md:73]() | | GTK4 & LibAdwaita | The UI toolkit for the application. | All Builds | [CONTRIBUTING.md:74]() | | Meson | The primary build system used by the project. | All Builds | [CONTRIBUTING.md:75](), [packaging/debian/build.sh:18]() | | Ninja | The backend for the Meson build system. | All Builds | [packaging/debian/build.sh:18]() | | `flatpak-builder` | Tool for building Flatpak packages. | Flatpak | [packaging/flatpak/build.sh:37]() | | `dpkg-deb` | Tool for creating Debian packages. | Debian | [packaging/debian/build.sh:19]() | - `makepkg` | Tool for building Arch Linux packages. | Arch Linux | [packaging/arch/build.sh:10]() | | `blueprint-compiler` | Compiles `.blp` UI definition files. | Development, All | [scripts/dev.sh:56](), [packaging/flatpak/org.badkiko.sofl.yml:25-30]() | Sources: [CONTRIBUTING.md:72-75](), [packaging/flatpak/build.sh:31-40](), [packaging/debian/build.sh:17-27](), [packaging/arch/build.sh:9-15](), [scripts/dev.sh:55-57]() ## Development Workflow For local development and testing, the `scripts/dev.sh` script provides a streamlined workflow. It automates setting up a local build environment, compiling the code, installing it into a local prefix (`.local/`), and running the application with the correct environment variables. The script offers several commands to manage the development lifecycle: - `setup`: Configures Meson in the `builddir` directory. - `build`: Compiles the project. - `install`: Installs the application into the local `.local` prefix. - `run`: Executes the application, automatically performing setup, build, and install steps if needed. - `smart`: A recommended command that intelligently checks if build or install steps are necessary before running the app. - `clean`: Removes the `builddir` and `.local` directories. Sources: [scripts/dev.sh:11-39](), [CONTRIBUTING.md:20-21]() The diagram below illustrates the flow of the `smart` command in `scripts/dev.sh`, which is the recommended method for development. ```mermaid flowchart TD A(Start: ./scripts/dev.sh smart) --> B{Build dir configured?}; B -- No --> C[do_setup: meson setup]; B -- Yes --> D; C --> D{Build outdated?}; D -- Yes --> E[do_build: meson compile]; D -- No --> F[Build is up to date]; E --> G{Install outdated?}; F --> G; G -- Yes --> H[do_install: meson install]; G -- No --> I[App is up to date]; H --> J[do_run: Run application]; I --> J; ``` This diagram shows the "smart" workflow which checks for necessary build and install steps before running the application. Sources: [scripts/dev.sh:196-221]() ## Production Packaging The project is structured to produce packages for Flatpak, Debian, and Arch Linux. The main logic is contained within the `packaging/` directory and orchestrated by `scripts/build_all.sh`. Sources: [packaging/README.md:3-7]() ### Packaging Directory Structure The `packaging` directory contains subdirectories for each supported package format. | Directory | Purpose | Key Files | | ------------------ | -------------------------------------------------------------------- | --------------------------------------- | | `packaging/` | Root directory for all packaging-related files and scripts. | `README.md` | | `packaging/flatpak/` | Contains files for building the Flatpak package. | `build.sh`, `org.badkiko.sofl.yml` | | `packaging/debian/` | Contains files for building the Debian (`.deb`) package. | `build.sh`, `DEBIAN/control` | | `packaging/arch/` | Contains files for building the Arch Linux package. | `build.sh`, `PKGBUILD` | Sources: [packaging/README.md:43-65]() ### Master Build Script: `build_all.sh` The `scripts/build_all.sh` script is the main entry point for creating release packages. It automates version updates and calls the appropriate build script for each specified package type. The script's behavior can be controlled with command-line arguments: `./build_all.sh [version] [package_types]` - **`[version]`**: (Optional) The version string to build (e.g., `1.0.0`). If omitted, it's read from `meson.build`. - **`[package_types]`**: (Optional) A space-separated string of package types to build (e.g., `"flatpak deb"`). Defaults to `"flatpak deb arch"`. Sources: [scripts/build_all.sh:4-8](), [scripts/README.md:29-37]() The script follows this general logic: ```mermaid graph TD A(Start: ./build_all.sh) --> B{Arguments provided?}; B -- No --> C[Get version from meson.build
Use default packages]; B -- Yes --> D[Parse version and package types from args]; C --> E[Update version in all packaging files]; D --> E; E --> F{Loop through package types}; F -- "flatpak" --> G[Run packaging/flatpak/build.sh]; F -- "deb" --> H[Run packaging/debian/build.sh]; F -- "arch" --> I[Run packaging/arch/build.sh]; G --> J(End Loop); H --> J; I --> J; J --> K[List created packages]; ``` This flowchart outlines how `build_all.sh` determines the version and package types, updates relevant files, and executes each package-specific build. Sources: [scripts/build_all.sh:11-73]() ### Package-Specific Build Processes Each package type has a dedicated build script within its respective directory in `packaging/`. #### Flatpak The Flatpak package is built using `packaging/flatpak/build.sh`. This script is highly configurable for both production and development builds. **Key Features:** - **Development Mode**: Activated by passing `dev` as an argument. This builds against the `org.badkiko.sofl.Devel.yml` manifest and installs a separate development version of the app. - **Fast Mode**: Activated by passing `fast` as an argument. This mode skips slow, internet-dependent operations like installing `flatpak-builder` or updating remotes, assuming the build environment is already prepared. The script can be invoked with several arguments to control its behavior: `./build.sh [version] [output_dir] [mode] [action]` | Argument | Description | Example | |--------------|-----------------------------------------------------------------------------|------------------| | `[version]` | The package version. | `1.0.0` | | `[output_dir]` | The directory to place the final `.flatpak` bundle. | `../../dist` | | `[mode]` | Can be `dev` for development mode or `fast` for fast mode (or both). | `dev fast` | | `[action]` | Can be `install` to install the package locally after building. | `install` | Sources: [packaging/flatpak/build.sh:4-29](), [packaging/README.md:21-39]() The Flatpak build process is defined in `org.badkiko.sofl.yml` and includes: - Runtime and SDK definitions (`org.gnome.Platform`, `org.gnome.Sdk`). - Sandbox permissions (`finish-args`) for filesystem, network, and D-Bus access. - A list of modules to build, including Python dependencies (`requests`, `pillow`, etc.) and the main `sofl` application code. Sources: [packaging/flatpak/org.badkiko.sofl.yml:1-24, 91-96]() #### Debian (.deb) The Debian package is created by `packaging/debian/build.sh`. The process involves: 1. Installing build dependencies like `meson`, `python3-gi`, and `libgtk-4-dev`. 2. Building the project with `meson setup` and `meson compile`. 3. Staging the files for packaging with `meson install` into a temporary directory. 4. Copying the `DEBIAN/control` file and updating its version field. 5. Creating `postinst` and `prerm` scripts to handle `update-desktop-database` and other post-install/pre-remove tasks. 6. Building the final `.deb` package using `dpkg-deb --build`. Sources: [packaging/debian/build.sh:16-83]() #### Arch Linux (PKGBUILD) The Arch Linux package is built using `packaging/arch/build.sh`. This script is a wrapper around `makepkg`. 1. It first checks if `makepkg` is available, as it can only run on an Arch Linux system. 2. It creates a source tarball (`.tar.gz`) of the project. 3. It copies the `PKGBUILD` to a temporary build directory and updates the `pkgver` field. 4. It invokes `makepkg` to build the package from the source tarball and the modified `PKGBUILD`. The final package is a `.pkg.tar.zst` file. Sources: [packaging/arch/build.sh:9-15, 68-96]() ## Conclusion The SOFL build system is a robust and flexible framework that caters to both developers and packagers. By leveraging Meson and a series of well-defined shell scripts, it provides a consistent method for compiling the application and distributing it across major Linux packaging formats. The clear separation between the development workflow (`dev.sh`) and production packaging (`build_all.sh`) ensures that both use cases are well-supported and easy to manage. Sources: [scripts/README.md](), [packaging/README.md]()## FULL FILE CONTEXT SUMMARY Query: You are an expert technical writer and software architect. Your task is to generate a comprehensive and accurate technical wiki page in Markdown format about a specific feature, system, or module within a given software project. You will be given: 1. The "[WIKI_PAGE_TOPIC]" for the page you need to create. 2. A list of "[RELEVANT_SOURCE_FILES]" from the project that you MUST use as the sole basis for the content. You MUST use AT LEAST 5 relevant source files for comprehensive coverage - if fewer are provided, search for additional related files in the codebase. CRITICAL STARTING INSTRUCTION: The very first thing on the page MUST be a

block listing ALL the [RELEVANT_SOURCE_FILES] you used to generate the content. There MUST be AT LEAST 5 source files listed - if fewer were provided, you MUST find additional related files to include. Format it exactly like this:

Relevant source files

Remember, do not provide any acknowledgements, disclaimers, apologies, or any other preface before the `

` block. JUST START with the `

` block. The following files were used as context for generating this wiki page: - [scripts/build\\_all.sh](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/scripts/build_all.sh) - [packaging/README.md](https://github.com/Qeatrix/steam-online-fix-launcher/blob/main/packaging/README.md)

Immediately after the

block, the main title of the page should be a H1 Markdown heading: # Building from Source. Based ONLY on the content of the [RELEVANT_SOURCE_FILES]: 1. **Introduction:** Start with a concise introduction (1-2 paragraphs) explaining the purpose, scope, and high-level overview of "Building from Source" within the context of the overall project. If relevant, and if information is available, link to other potential wiki pages using the format [Link Text](#page-anchor-or-id). 2. **Detailed Sections:** Break down "Building from Source" into logical sections using H2 (##) and H3 (###) Markdown headings. For each section: * Explain the architecture, components, data flow, or logic relevant to the section's focus, as evidenced in the source files. * Identify key functions, classes, data structures, API endpoints, or configuration elements pertinent to that section. 3. **Mermaid Diagrams:** * EXTENSIVELY use Mermaid diagrams (e.g., flowchart TD, sequenceDiagram, classDiagram, erDiagram, graph TD) to visually represent architectures, flows, relationships, and schemas found in the source files. * Ensure diagrams are accurate and directly derived information from the [RELEVANT_SOURCE_FILES]. * Provide a brief explanation before or after each diagram to give context. * CRITICAL diagram requirements for optimal rendering: - **Flow diagrams**: Use "graph TD" (top-down) or "flowchart TD" directives for better vertical layout - **Node labels**: Keep node labels concise but descriptive (under 25 characters for readability) - **Node IDs**: Use alphanumeric characters and underscores only (avoid spaces, special characters) - **Connections**: Use standard arrow syntax (-->, ---, -.->) for reliable rendering - **Sequence diagrams**: - Start with "sequenceDiagram" directive on its own line - Use participant names without spaces (use underscores if needed) - Define participants explicitly when needed: `participant User as "User Interface"` - Use correct arrow types: - ->> for synchronous calls/requests - -->> for responses - -x for failed/error messages - --x for failed responses - Add activation boxes sparingly with +/- notation - Use "Note over" or "Note right of" for clarifications - **Class diagrams**: Use standard UML notation with proper relationship syntax - **ER diagrams**: Use entity relationship syntax with proper cardinality notations * **Quality guidelines**: - Test diagram syntax mentally before including - If a diagram becomes too complex, split into multiple focused diagrams - Ensure proper closing of all brackets and quotes - Use consistent naming conventions within each diagram - Add line breaks for readability in complex diagrams * **Example patterns (GOOD vs BAD)**: ``` GOOD Flow Diagram: ```mermaid flowchart TD A[User Request] --> B[Validate Input] B --> C[Process Data] C --> D[Return Response] ``` BAD Flow Diagram: ```mermaid graph LR A[User Request with Very Long Description] --> B ``` GOOD Sequence Diagram: ```mermaid sequenceDiagram participant User as "User Interface" participant API as "API Server" participant DB as "Database" User->>API: POST /api/data API->>DB: SELECT * FROM table DB-->>API: Query results API-->>User: JSON response ``` ``` 4. **Tables:** * Use Markdown tables to summarise information such as: * Key features or components and their descriptions. * API endpoint parameters, types, and descriptions. * Configuration options, their types, and default values. * Data model fields, types, constraints, and descriptions. 5. **Code Snippets (ENTIRELY OPTIONAL):** * Include short, relevant code snippets (e.g., Python, Java, JavaScript, SQL, JSON, YAML) directly from the [RELEVANT_SOURCE_FILES] to illustrate key implementation details, data structures, or configurations. * Ensure snippets are well-formatted within Markdown code blocks with appropriate language identifiers. 6. **Source Citations (EXTREMELY IMPORTANT):** * For EVERY piece of significant information, explanation, diagram, table entry, or code snippet, you MUST cite the specific source file(s) and relevant line numbers from which the information was derived. * Place citations at the end of the paragraph, under the diagram/table, or after the code snippet. * Use the exact format: `Sources: [filename.ext:start_line-end_line]()` for a range, or `Sources: [filename.ext:line_number]()` for a single line. Multiple files can be cited: `Sources: [file1.ext:1-10](), [file2.ext:5](), [dir/file3.ext]()` (if the whole file is relevant and line numbers are not applicable or too broad). * If an entire section is overwhelmingly based on one or two files, you can cite them under the section heading in addition to more specific citations within the section. * You MUST cite AT LEAST 5 different source files throughout the wiki page to ensure comprehensive coverage. 7. **Technical Accuracy:** All information must be derived SOLELY from the [RELEVANT_SOURCE_FILES]. Do not infer, invent, or use external knowledge about similar systems or common practices unless it's directly supported by the provided code. If information is not present in the provided files, do not include it or explicitly state its absence if crucial to the topic. 8. **Clarity and Conciseness:** Use clear, professional, and concise technical language suitable for other developers working on or learning about the project. Avoid unnecessary jargon, but use correct technical terms where appropriate. 9. **Conclusion/Summary:** End with a brief summary paragraph if appropriate for "Building from Source", reiterating the key aspects covered and their significance within the project. IMPORTANT: Generate the content in English language. Remember: - Ground every claim in the provided source files. - Prioritize accuracy and direct representation of the code's functionality and structure. - Structure the document logically for easy understanding by other developers. Total Files Included: 18 Total Files Skipped: 0 Total Context Tokens: 30,160 / 800,000 (3.8%) Remaining Token Budget: 769,840 ### Included Files: 1. CONTRIBUTING.md (818 tokens) 2. CHANGELOG.md (956 tokens) 3. conventions.md (1,018 tokens) 4. CONTRIBUTING_RU.md (1,167 tokens) 5. idea.md (1,512 tokens) 6. packaging/README.md (2,311 tokens) 7. README.md (1,485 tokens) 8. tasklist.md (3,305 tokens) 9. scripts/build_all.sh (727 tokens) 10. packaging/flatpak/build.sh (1,916 tokens) 11. packaging/arch/build.sh (1,860 tokens) 12. packaging/flatpak/org.badkiko.sofl.yml (1,950 tokens) 13. packaging/debian/build.sh (983 tokens) 14. scripts/dev.sh (2,221 tokens) 15. README_RU.md (2,120 tokens) 16. scripts/README.md (743 tokens) 17. sofl/details_dialog.py (4,031 tokens) 18. sofl/importer/steam_source.py (1,037 tokens) ================================================================================ FILE: CONTRIBUTING.md Relevance Score: 0.990 | Chunks Retrieved: 1 | Tokens: 818 ================================================================================ # 🤝 Contributing to SOFL Hi! 👋 Thanks for wanting to help improve SOFL. Here's a simple guide to get started.

--- ## 🚀 Quick Start ### Fork and Clone ```bash # 1. Fork the repository on GitHub # 2. Clone your fork git clone https://github.com/YOUR_USERNAME/steam-online-fix-launcher.git cd steam-online-fix-launcher # 3. Create a working branch git checkout -b my-feature # 4. Run the application for development ./scripts/dev.sh ``` --- ## 🔄 Development ### Creating a Pull Request 1. **Make changes** in your code 2. **Test** that everything works: `./scripts/dev.sh` 3. **Commit changes**: ```bash git add . git commit -m "Brief description of changes" ``` 4. **Push to your fork**: ```bash git push origin my-feature ``` 5. **Create a Pull Request** on GitHub ### Simple Rules - Write clear commit messages - Test changes before submitting - Add a brief description for new features - Follow the existing code style --- ## 🐛 Bugs and Features ### Report a Bug Use GitHub Issues with the template: - What were you doing? - What did you expect to see? - What happened instead? - Your system (Linux distribution, version) ### Suggest a New Feature Describe in the Issue: - What will it do? - Why is it useful? - How should it work? --- ## 🛠️ Working with Code ### Architecture ``` sofl/ ├── main.py # Application launch ├── window.py # Main window ├── game.py # Games ├── store/ # Data storage ├── importer/ # Game import ├── dialogs/ # Dialogs └── utils/ # Utilities ``` ### Requirements - Python 3.10+ - GTK4 + LibAdwaita - Meson for building --- ## 🌐 Translations ### Add a New Language ```bash # 1. Add language code to po/LINGUAS echo "ru" >> po/LINGUAS # 2. Create .po file msginit --input=po/sofl.pot --locale=ru --output=po/ru.po # 3. Translate in Poedit or text editor # 4. Create Pull Request ``` ### Update Translations ```bash meson compile sofl-pot -C builddir meson compile sofl-update-po -C builddir ``` --- ## 📝 Code and Commits ### Code Style We use Black for formatting: - Maximum 88 characters per line - UTF-8 encoding - 4 spaces indentation ### Commit Messages The project uses a tagging system for commits [AMR] - A-Added, M-Modified, R-Removed So when adding new files and editing old ones, there will be a tag before the commit [AM]. Examples: - [A] added file `new_feature.py` - [M] changed file `README.md` - [R] removed file `old_script.py` ## 🙏 Thanks Thanks for contributing to SOFL! Together we're making Linux better for gamers. 🎮 ================================================================================ ================================================================================ FILE: CHANGELOG.md Relevance Score: 0.980 | Chunks Retrieved: 1 | Tokens: 956 ================================================================================ # SOFL Changelog ## [v0.0.3.4a] - 2025-10-23 ### New Features - **Game Process Monitoring**: Added real-time tracking of running games with visual status indicators - **Interactive Status Bar**: Implemented bottom status bar showing current game launch state - **Game Control Interface**: Added stop button for terminating running games with proper process management - **Enhanced UI States**: Status bar automatically hides when viewing game details for cleaner interface - **Improved Process Handling**: Better process termination for Wine/Proton games with fallback mechanisms - **Proton Manager**: Complete Proton version management system for downloading, installing, and removing GE-Proton versions ### UI/UX Improvements - **Status Bar Design**: Modern minimalist status bar with play icon, status text, and stop button - **Visual Feedback**: Green play indicator and red stop button for clear game state communication - **Context-Aware UI**: Status bar visibility adapts to current navigation context - **Separator Management**: Proper handling of UI separators in different view states ### Technical Enhancements - **Process Tracking**: Comprehensive process monitoring with automatic cleanup - **Signal Handling**: Proper SIGTERM/SIGKILL handling for different game types - **Wine/Proton Support**: Specialized process termination for compatibility layer games with wineserver kill support - **Error Handling**: Improved error handling for process launch and termination operations ## [v0.0.3.3a] - 2025-09-01 ### Major Changes - **Removed Umu Launcher Integration**: Completely removed Umu Launcher support and related Proton version settings - **Enhanced Stability**: Improved overall application stability and performance - **Build System Overhaul**: Refactored build configuration for better maintainability ### Bug Fixes - Fixed various UI styling inconsistencies and layout issues - Resolved build process reliability problems - Fixed package dependency resolution issues - Improved error handling throughout the application ### Documentation Improvements - **Enhanced README**: Completely rewritten with better project description, features, and installation instructions\ - **Contributing Guidelines**: Created detailed CONTRIBUTING.md and CONTRIBUTING_RU.md with step-by-step instructions - **Project Structure**: Added clear code architecture overview and development requirements ### Development Tools - **Build Scripts**: Enhanced Flatpak build scripts with stable/dev version support - **Development Scripts**: Added new development build scripts for faster iteration\ ### UI/UX Improvements - **Game Type Selection**: Added new "Game Type" combo row for distinguishing Online-Fix and Regular games - **Dialog Enhancements**: Improved details dialog and preferences dialog styling - **CSS Cleanup**: Better organized and documented stylesheets ### Removed Features - Umu Launcher integration and Proton version settings - Outdated documentation files - Legacy configuration keys ## [v0.0.3.2a] - 2025-08-27 - Fixed #26 @BadKiko - Fixed #27 @BadKiko ## [v0.0.3.1a] - 2025-08-26 - Fxed #24 - Fixed online-fix removing - Added select on adding games ## [v0.0.3] - 2025-08-25 ### New Features - Enhanced CI/CD workflow with flexible release body generation - Added support for manual release body input via workflow dispatch - Automatic changelog generation from git commits - Improved package building for multiple Linux distributions ### Bug Fixes - Fixed Flatpak manifest blueprint-compiler version handling - Resolved Arch Linux package build issues - Improved Debian package dependency handling ### Other Changes - Updated build scripts for better error handling - Enhanced documentation and installation instructions - Improved workflow reliability and artifact management ## [v0.0.2] - 2025-06-25 ### New Features - Support for multiple game launchers integration - SteamGridDB integration for automatic cover art - Online-fix game support with comprehensive settings ### Bug Fixes - Fixed various launcher integration issues - Resolved cover art download problems - Improved error handling for network requests ## [v0.0.1] - 2025-04-25 ### New Features - Initial release with basic functionality - GTK4 + LibAdwaita UI - Basic game library management - Flatpak packaging support ### Installation - Flatpak support - Debian/Ubuntu packages - Arch Linux PKGBUILD --- _This changelog is automatically parsed by the CI/CD workflow for release generation._ ================================================================================ ================================================================================ FILE: conventions.md Relevance Score: 0.970 | Chunks Retrieved: 1 | Tokens: 1,018 ================================================================================ # 📋 Кодинг-конвенции SOFL *См. [idea.md](idea.md) для понимания принципов проекта: минимализм, интуитивность, производительность, современность.* ## 🎯 Основные принципы ### Код - **KISS**: Простые решения без переусложнения - **DRY**: Избегать дублирования кода - **SOLID**: Читаемый, поддерживаемый код ### Архитектура - **Модульность**: Независимые компоненты - **GTK4-first**: Нативные виджеты LibAdwaita - **Async-ready**: Асинхронные операции для отзывчивости ## 📝 Стиль кода ### Python - **Black**: Автоматическое форматирование (88 символов) - **PEP 8**: Стандарт Python с отступами 4 пробела - **Type hints**: Аннотации типов для читаемости ### GTK/Interface - **GNOME HIG**: Следование гайдлайнам GNOME - **Adwaita-first**: Использовать LibAdwaita компоненты - **Responsive**: Адаптивный дизайн без фиксированных размеров ## 🔧 Технические требования ### Зависимости - **Python 3.10+**: Минимальная версия - **GTK4 4.14+**: Современный стек - **LibAdwaita 1.4+**: Материальный дизайн ### Качество - **Linting**: Автоматическая проверка качества - **Tests**: Модульные тесты для критических функций - **Docs**: Комментарии только для сложной логики ## 🚀 Производительность ### UI - **Lazy loading**: Загружать данные по требованию - **Async operations**: Не блокировать главный поток - **Memory efficient**: Оптимизация потребления памяти ### Код - **Fast imports**: Минимизировать время запуска - **Efficient algorithms**: O(n) вместо O(n²) - **Profiling**: Измерять производительность ## 📊 Коммиты ### Формат ``` [AMR] Краткое описание изменений Подробное описание если нужно. ``` - **A** - Добавлено - **M** - Изменено - **R** - Удалено ### Правила - Один логический блок изменений = один коммит - Понятные сообщения на русском - Тестировать перед коммитом ## 🏗️ Структура проекта ``` sofl/ ├── main.py # Точка входа ├── window.py # Главное окно ├── game.py # Модель игры ├── dialogs/ # Диалоги ├── importer/ # Импорт из платформ ├── store/ # Хранение данных └── utils/ # Вспомогательные функции ``` ## ⚠️ Запрещено - Синхронные сетевые запросы в UI потоке - Жестко заданные размеры виджетов - Дублирование кода без рефакторинга - Игнорирование GNOME HIG - Использование устаревших GTK виджетов ## 🔍 Проверки качества - `black --check .` - Форматирование - `pyright` - Типизация - `./scripts/dev.sh` - Запуск в dev режиме - `meson test` - Автотесты ================================================================================ ================================================================================ FILE: CONTRIBUTING_RU.md Relevance Score: 0.960 | Chunks Retrieved: 1 | Tokens: 1,167 ================================================================================ # 🤝 Как внести вклад в SOFL Привет! 👋 Спасибо, что хотите помочь улучшить SOFL. Вот простое руководство для начала.

--- ## 🚀 Быстрый старт ### Форк и клонирование ```bash # 1. Форкните репозиторий на GitHub # 2. Клонируйте свой форк git clone https://github.com/YOUR_USERNAME/steam-online-fix-launcher.git cd steam-online-fix-launcher # 3. Создайте ветку для работы git checkout -b my-feature # 4. Запустите приложение для разработки ./scripts/dev.sh ``` --- ## 🔄 Разработка ### Создание Pull Request 1. **Сделайте изменения** в вашем коде 2. **Протестируйте** что всё работает: `./scripts/dev.sh` 3. **Зафиксируйте изменения**: ```bash git add . git commit -m "Краткое описание изменений" ``` 4. **Отправьте в ваш форк**: ```bash git push origin my-feature ``` 5. **Создайте Pull Request** на GitHub ### Простые правила - Пишите понятные commit сообщения - Тестируйте изменения перед отправкой - Для новых функций добавляйте краткое описание - Следуйте существующему стилю кода --- ## 🐛 Баги и фичи ### Сообщить о баге Используйте GitHub Issues с шаблоном: - Что вы делали? - Что ожидали увидеть? - Что произошло вместо этого? - Ваша система (Linux дистрибутив, версия) ### Предложить новую функцию Опишите в Issue: - Что это будет делать? - Почему это полезно? - Как это должно работать? --- ## 🛠️ Работа с кодом ### Архитектура ``` sofl/ ├── main.py # Запуск приложения ├── window.py # Главное окно ├── game.py # Игры ├── store/ # Хранение данных ├── importer/ # Импорт игр ├── dialogs/ # Диалоги └── utils/ # Утилиты ``` ### Требования - Python 3.10+ - GTK4 + LibAdwaita - Meson для сборки --- ## 🌐 Переводы ### Добавить новый язык ```bash # 1. Добавьте код языка в po/LINGUAS echo "ru" >> po/LINGUAS # 2. Создайте .po файл msginit --input=po/sofl.pot --locale=ru --output=po/ru.po # 3. Переведите в Poedit или текстовом редакторе # 4. Создайте Pull Request ``` ### Обновить переводы ```bash meson compile sofl-pot -C builddir meson compile sofl-update-po -C builddir ``` --- ## 📝 Код и коммиты ### Стиль кода Используем Black для форматирования: - Максимум 88 символов в строке - UTF-8 кодировка - 4 пробела отступов ### Commit сообщения В проекте принято коммитить с теговой системой [AMR] - A-Added, M-Modified, R-Removed То есть при добавлении новых файлов и редактировании старых будет тег перед коммитом [AM]. Примеры: - [A] добавлен файл `new_feature.py` - [M] изменен файл `README.md` - [R] удален файл `old_script.py` ## 🙏 Спасибо Спасибо за вклад в SOFL! Вместе мы делаем Linux лучше для геймеров. 🎮 ================================================================================ ================================================================================ FILE: idea.md Relevance Score: 0.950 | Chunks Retrieved: 2 | Tokens: 1,512 ================================================================================ # 🎯 Идея проекта SOFL - Steam Online Fix Launcher ## 📋 Основная концепция **SOFL (Steam Online Fix Launcher)** — это специализированный Linux лаунчер для игр с поддержкой онлайн-функциональностью, который решает проблему сложного запуска современных мультиплеерных игр на Linux. ### 🎮 Проблема, которую решает проект Linux геймеры сталкиваются с множеством проблем при запуске онлайн-игр: - Сложная настройка Wine/Proton префиксов - Конфликты версий Proton для разных игр - Отсутствие единого интерфейса управления играми - Проблемы с онлайн-подключением в играх - Необходимость ручной настройки для каждой игры ### 🚀 Основная идея Создать **easy-to-use лаунчер**, который: 1. **Автоматически настраивает окружение** для онлайн-игр 2. **Предоставляет единую библиотеку** всех игр в одном месте 3. **Решает типичные проблемы** с запуском онлайн-функционала 4. **Интегрируется с популярными сервисами** для автоматического получения данных 5. **Имеет современный и интуитивный интерфейс** в стиле GNOME ## 🏗️ Архитектура и технологии ### Основной стек технологий: - **Python 3** как основной язык разработки - **GTK4 + libadwaita** для современного GNOME интерфейса - **Meson** как система сборки - **Flatpak** для распространения ### Ключевые компоненты: - **Импортеры** для различных платформ (Steam, Lutris, Heroic, Bottles) - **Онлайн-фикс модуль** для исправления проблем с сетью - **База данных игр** с метаданными - **Интеграции с внешними сервисами** (SteamGridDB, IGDB, ProtonDB) ## 🎯 Целевая аудитория 1. **Обычные пользователи Linux** - хотят играть без технических сложностей 2. **Steam пользователи** - ищут удобный способ запуска онлайн-игр 3. **Геймеры на других платформах** - Heroic, Lutris, Bottles пользователи 4. **Разработчики игр** - для тестирования Linux портов ## 🔑 Уникальные особенности ### Специализация на онлайн-играх: - Автоматическое обнаружение и исправление проблем с сетью - Специализированные настройки для популярных онлайн-игр - Поддержка различных типов онлайн-функционала (P2P, dedicated servers) ### Интеграции: - **SteamGridDB** - автоматическая загрузка обложек - **IGDB** - информация об играх и рейтинги - **ProtonDB** - отзывы сообщества о совместимости - **Lutris** - интеграция с крупнейшей Linux игровой платформой ### Удобство использования: - Drag & drop импорт игр - Автоматическое определение типа игры и оптимальных настроек - Простой интерфейс без лишних опций для новичков ## 📊 Видение развития ### Ближайшие цели (v1.0): - Стабильная работа с основными онлайн-играми - Полная интеграция с Steam библиотекой - Автоматическое исправление 80% типичных проблем ## 🎨 Дизайн и UX ### Принципы дизайна: - **Минимализм** - только необходимые функции на виду - **Интуитивность** - понятный интерфейс без документации - **Производительность** - быстрый запуск и отзывчивость - **Современность** - следование GNOME HIG ### Ключевые экраны: 1. **Главная библиотека** - все игры в виде карточек 2. **Карточка игры** - подробная информация и быстрый запуск 3. **Настройки** - простая конфигурация основных параметров ## 🤝 Сообщество и развитие ### Открытый исходный код: - GPL-3.0 лицензия - Активное сообщество контрибьюторов - Прозрачный процесс разработки ### Модель монетизации: - Бесплатное ПО с открытым кодом - Возможные донаты и спонсорство - Партнерства с игровыми компаниями --- *Этот документ фиксирует основную идею и видение проекта SOFL. Он служит ориентиром для принятия решений о развитии и приоритетах проекта.* ================================================================================ ================================================================================ FILE: packaging/README.md Relevance Score: 0.940 | Chunks Retrieved: 2 | Tokens: 2,311 ================================================================================ # SOFL - Packaging Этот каталог содержит скрипты и файлы для сборки пакетов SOFL для различных Linux дистрибутивов. ## Поддерживаемые форматы пакетов - **Flatpak** - Универсальный формат для всех Linux дистрибутивов - **Debian (.deb)** - Для Debian, Ubuntu и производных - **Arch Linux** - PKGBUILD для сборки в Arch Linux ## Быстрый старт ### Сборка всех пакетов ```bash # Сборка всех типов пакетов с версией из meson.build ./scripts/build_all.sh # Сборка всех пакетов с указанной версией ./scripts/build_all.sh 1.0.0 # Сборка только определенных пакетов ./scripts/build_all.sh 1.0.0 "flatpak deb" ``` ### Сборка отдельных пакетов #### Flatpak ```bash cd packaging/flatpak # Обычная сборка стабильной версии ./build.sh [version] # Быстрая сборка стабильной версии (без проверок) ./build.sh [version] . fast # Сборка и установка стабильной версии ./build.sh [version] . install # Быстрая сборка и установка стабильной версии ./build.sh [version] . fast install # Сборка и установка dev версии ./build.sh [version] . dev install # Быстрая сборка и установка dev версии ./build.sh [version] . dev fast install # Быстрая сборка и запуск dev версии ./build-dev.sh [version] # Максимально быстрая сборка и запуск dev версии ./build-dev.sh [version] . fast ``` #### Debian ```bash cd packaging/debian ./build.sh [version] ``` #### Arch Linux ```bash cd packaging/arch ./build.sh [version] ``` ## Скрипты сборки ### Общие скрипты (`scripts/`) - `get_version.sh` - Получить версию из meson.build - `update_version.sh` - Обновить версию во всех файлах упаковки - `build_all.sh` - Собрать все типы пакетов ### Использование скриптов ```bash # Получить текущую версию ./scripts/get_version.sh # Обновить версию во всех файлах ./scripts/update_version.sh 1.0.0 # Собрать все пакеты ./scripts/build_all.sh # Собрать определенные пакеты ./scripts/build_all.sh 1.0.0 "flatpak deb" ``` ## CI/CD ### GitHub Actions Проект включает автоматическую сборку пакетов через GitHub Actions: - **build-packages.yml** - Основной workflow для сборки релизов - **test-build.yml** - Тестирование сборки на pull requests ### Автоматические релизы При создании git тега (например, `v1.0.0`) автоматически: 1. Собираются пакеты для всех платформ 2. Создается GitHub релиз с прикрепленными пакетами 3. Обновляется версия во всех файлах ### Ручной запуск Можно запустить сборку вручную через GitHub Actions интерфейс, указав версию или оставив поле пустым для автоопределения. ## Структура пакетов ### Flatpak - `org.badkiko.sofl.yml` - Manifest файл для стабильной версии - `org.badkiko.sofl.Devel.yml` - Manifest файл для dev версии - `build.sh` - Скрипт сборки (поддерживает dev и fast режимы) - `build-dev.sh` - Скрипт быстрой сборки dev версии (с поддержкой fast режима) ### Debian - `DEBIAN/control` - Метаданные пакета - `DEBIAN/postinst` - Скрипт пост-установки - `DEBIAN/prerm` - Скрипт пред-удаления - `build.sh` - Скрипт сборки ### Arch Linux - `PKGBUILD` - Скрипт сборки для Arch - `build.sh` - Скрипт сборки ## Установка пакетов ### Flatpak ```bash # Локальная установка стабильной версии flatpak install --user org.badkiko.sofl.flatpak # Локальная установка dev версии flatpak install --user org.badkiko.sofl.Devel.flatpak # Системная установка sudo flatpak install org.badkiko.sofl.flatpak # Запуск стабильной версии flatpak run org.badkiko.sofl # Запуск dev версии flatpak run org.badkiko.sofl.Devel ``` ### Debian/Ubuntu ```bash sudo dpkg -i sofl_VERSION_all.deb sudo apt install -f # Установить зависимости если нужно ``` ### Arch Linux ```bash # Скачать PKGBUILD и исходный код # Затем выполнить: makepkg -si ``` ## Требования для сборки ### Flatpak - flatpak-builder - org.gnome.Platform 47 - org.gnome.Sdk 47 ### Debian - dpkg-dev - meson - ninja-build - python3-gi и другие зависимости ### Arch Linux - makepkg (доступно на Arch Linux) - Для других систем создается source tarball ## Устранение проблем ### Flatpak ```bash # Очистить предыдущие сборки rm -rf flatpak-build sofl-repo # Проверить manifest flatpak-builder --show-manifest org.badkiko.sofl.yml ``` ### Debian ```bash # Проверить зависимости dpkg-checkbuilddeps # Проверить пакет после сборки lintian sofl_VERSION.deb ``` ### Arch Linux ```bash # Проверить PKGBUILD namcap PKGBUILD # Тестовая сборка makepkg -c ``` ## Распространение После сборки пакеты можно распространять: 1. **Flatpak** - загрузить на Flathub 2. **Debian** - загрузить в PPA или репозиторий 3. **Arch Linux** - загрузить в AUR ## Разработка ### Режимы сборки Flatpak Проект поддерживает два режима сборки Flatpak: #### Стабильная версия (`org.badkiko.sofl`) - Используется для релизов и production - Branch: `stable` (по умолчанию) #### Dev версия (`org.badkiko.sofl.Devel`) - Используется для разработки и тестирования - Branch: `devel` - Автоматически запускается после сборки ### Быстрая разработка Для быстрой разработки используйте `build-dev.sh`: ```bash cd packaging/flatpak # Быстрая сборка и запуск dev версии ./build-dev.sh # Сборка с указанной версией ./build-dev.sh 1.0.0-dev ``` ### Ручная сборка dev версии ```bash cd packaging/flatpak # Сборка dev версии через основной скрипт ./build.sh dev . dev install ``` ### Особенности dev режима - **Автоматический запуск**: После сборки приложение запускается автоматически - **Отдельный профиль**: Dev версия не конфликтует со стабильной - **Разные настройки**: Можно тестировать новые функции без влияния на стабильную версию ### Fast режим для быстрой разработки Для максимальной скорости сборки используйте fast режим, который пропускает: - Установку flatpak и flatpak-builder - Настройку Flathub remote - Обновление remotes (сетевые операции) - Проверку и установку runtime/SDK ```bash # Быстрая сборка dev версии ./build-dev.sh dev . fast # Быстрая сборка стабильной версии ./build.sh 1.0.0 . fast install ``` ## Поддержка При возникновении проблем с упаковкой создавайте issue в репозитории проекта. ================================================================================ ================================================================================ FILE: README.md Relevance Score: 0.930 | Chunks Retrieved: 1 | Tokens: 1,485 ================================================================================

# SOFL ## Steam Online Fix Launcher _A launcher for games with Online-Fix support on Linux_

## 📝 About the Project **SOFL (Steam Online Fix Launcher)** is a powerful tool for easy launching and organizing games with **online-fix** support on Linux. The application is a full-featured game library manager that solves typical problems with launching games with online functionality. The project was created to simplify the lives of Linux users who want to play modern multiplayer games without having to manually configure environments, Wine prefixes, and Proton versions. ### 🎯 Key Benefits - **🎮 Unified library** of all your games in one place - **🔧 Automatic problem solving** for launching online games - **🎨 Modern interface** in GNOME style - **🌐 Full support** for multiple gaming platforms --- ## ✨ Features ### 🎯 Core Functions - 🚀 **Easy launch** of online games without complex settings - 📚 **Library management** — all games in one place - 🖼️ **Automatic covers** from SteamGridDB - 🔄 **Support for various types** of online games - 🔧 **Automatic fixes** for typical problems - 🔍 **Integration with services** IGDB, ProtonDB, Lutris - 📂 **Game import** from Steam, Heroic, Lutris, Bottles, Itch, Legendary, RetroArch ### 🎮 Online Games Support - **Online-Fix** — specialized support for games with online features ### 🌐 Integrations - **SteamGridDB** — automatic cover downloads - **IGDB** — game information and ratings - **ProtonDB** — compatibility and community reviews - **Lutris** — integration with the largest Linux gaming platform - **Steam** — native Steam library support --- ## 📸 Screenshots

### 🏠 Main Screen SOFL Main Screen

### 🎮 Game Card Game Library

---

## 🛠️ Installation ### 📦 From Official Repositories #### Flatpak (recommended) ```bash # Install from Latest Release curl -L https://github.com/badkiko/steam-online-fix-launcher/releases/latest/download/org.badkiko.sofl.flatpak -o /tmp/sofl.flatpak && flatpak install --user -y /tmp/sofl.flatpak && rm /tmp/sofl.flatpak ``` ### ⚙️ Basic Setup 1. **Online-Fix Games Path**: Specify the directory with your games 2. **Proton Version**: Select the appropriate Proton version 3. **Import Sources**: Enable the required gaming platforms ## 🙏 Acknowledgments ### 👥 Development Team - **[BadKiko](https://github.com/badkiko)** — lead developer and project founder - **[Niko-PRO](https://github.com/Niko-PRO)** — architecture and design ### 🎯 Inspiration and Thanks A huge thank you to the [**@kra-mo/cartridges**](https://github.com/kra-mo/cartridges) project! Their excellent work has been a great inspiration and resource for our launcher. ### 🤝 Contributing We welcome contributions from the community! Whether you're fixing bugs, adding features, improving documentation, or helping with translations, your help is appreciated. 📖 **[How to contribute](CONTRIBUTING.md)** — detailed guide for contributors ## 📜 License This project is licensed under **GPL-3.0**. See the [LICENSE](LICENSE) file for details. ## 📊 Project Statistics

### 🌟 Popularity Growth

---

### 🎮 Join the Community! ⭐ **Star the project** if you like it! 🐛 **Report a bug** or **suggest a feature** through [Issues](https://github.com/BadKiko/steam-online-fix-launcher/issues) --- _SOFL — your reliable partner in the world of online games on Linux! 🚀_

================================================================================ ================================================================================ FILE: tasklist.md Relevance Score: 0.920 | Chunks Retrieved: 3 | Tokens: 3,305 ================================================================================ # 🚀 SOFL Development Tasklist *Обновлено: 10.09.2025 | Следовать: [idea.md](idea.md) + [conventions.md](conventions.md)* ## 📊 СТАТУС ПРОЕКТА ### ✅ ГОТОВО (существующая функциональность) - [x] Основной лаунчер на GTK4 + LibAdwaita - [x] Импорт из Steam, Lutris, Heroic, Bottles, Itch, Legendary, RetroArch - [x] InstallDialog для установки Online-Fix игр из RAR - [x] Управление библиотекой игр с карточками - [x] Система поиска и фильтрации - [x] Управление обложками через SteamGridDB - [x] Настройки с источниками импорта - [x] Современный UI в стиле GNOME HIG - [x] Адаптивный дизайн с темами - [x] Toast уведомления и прогресс-индикаторы --- ## 🎯 ПРИОРИТЕТНЫЕ ЗАДАЧИ (ближайшие 2-4 недели) ### 🔥 ЗАДАЧА 1: Установка GEProton из приложения **Статус:** ❌ НЕ НАЧАТА | **Приоритет:** ВЫСОКИЙ | **Сложность:** СРЕДНЯЯ #### 📋 Подзадачи: - [ ] **Исследование Proton** - анализ способов установки GEProton - [ ] Изучить GitHub репозиторий GloriousEggroll - [ ] Понять механизм установки и обновления - [ ] Посмотреть библиотеки может есть уже спецу библиотеки - [ ] Определить системные зависимости - [ ] **Создание ProtonManager** - класс для управления Proton версиями - [ ] `sofl/proton/manager.py` - основной класс - [ ] Методы для скачивания, установки, удаления версий - [ ] Хранение списка установленных версий - [ ] **UI для установки** - диалог выбора и установки Proton - [ ] Диалог со списком доступных версий - [ ] Прогресс-бар установки - [ ] Обработка ошибок и повторных попыток **Критерии готовности:** GEProton устанавливается из UI и работает с 80% популярных онлайн-игр --- ### 🌟 ЗАДАЧА 2: Приветственный экран **Статус:** ❌ НЕ НАЧАТА | **Приоритет:** ВЫСОКИЙ | **Сложность:** СРЕДНЯЯ #### 📋 Подзадачи: - [ ] **Создание WelcomeScreen** - новый диалог приветствия - [ ] `sofl/welcome/screen.py` - основной класс - [ ] UI с пошаговым мастером настройки - [ ] Интеграция с основным приложением - [ ] **Система проверок** - детектирование Steam, Proton, Wine - [ ] `sofl/welcome/checker.py` - класс проверок - [ ] Детектирование установленных программ - [ ] Проверка версий и совместимости - [ ] **Статус-индикаторы** - визуализация состояния компонентов - [ ] Зеленый/красный статус для каждого компонента - [ ] Подробная информация о найденных проблемах - [ ] Предложения по исправлению - [ ] **Быстрая настройка** - упрощенное конфигурирование - [ ] Автоматическая настройка найденных компонентов - [ ] Кнопки "Исправить" для проблемных компонентов - [ ] Сохранение настроек после завершения - [ ] **Интеграция с основным потоком** - показ при первом запуске - [ ] Проверка первого запуска приложения - [ ] Показ экрана только при необходимости - [ ] Возможность пропустить и вернуться позже **Критерии готовности:** Приветственный экран корректно детектирует компоненты и помогает новым пользователям настроить приложение --- ### 🎨 ЗАДАЧА 3: Улучшение общего интерфейса **Статус:** ❌ НЕ НАЧАТА | **Приоритет:** СРЕДНИЙ | **Сложность:** ВЫСОКАЯ #### 📋 Подзадачи: