/Qeatrix/steam-online-fix-launcher

Wiki directory

Browse AI-generated documentation for any repository.

Building from Source

Relevant source files

The following files were used as context for generating this wiki page:

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.

Generating architecture diagram...

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:

Generating architecture diagram...

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:

Installing build dependencies like meson, python3-gi, and libgtk-4-dev.
Building the project with meson setup and meson compile.
Staging the files for packaging with meson install into a temporary directory.
Copying the DEBIAN/control file and updating its version field.
Creating postinst and prerm scripts to handle update-desktop-database and other post-install/pre-remove tasks.
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.

It first checks if makepkg is available, as it can only run on an Arch Linux system.
It creates a source tarball (.tar.gz) of the project.
It copies the PKGBUILD to a temporary build directory and updates the pkgver field.
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:

The "[WIKI_PAGE_TOPIC]" for the page you need to create.
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 <details> block. JUST START with the <details> block.
The following files were used as context for generating this wiki page:

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]:

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.
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.
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:
```

Generating architecture diagram...

   BAD Flow Diagram:

Generating architecture diagram...

   GOOD Sequence Diagram:

Generating architecture diagram...

```

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.

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.
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](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/filename.ext%3Astart_line-end_line) for a range, or Sources: [filename.ext:line_number](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/filename.ext%3Aline_number) for a single line. Multiple files can be cited: Sources: [file1.ext:1-10](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/file1.ext#L1-L10), [file2.ext:5](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/file2.ext#L5), [dir/file3.ext](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/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.
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.
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.
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:

CONTRIBUTING.md (818 tokens)
CHANGELOG.md (956 tokens)
conventions.md (1,018 tokens)
CONTRIBUTING_RU.md (1,167 tokens)
idea.md (1,512 tokens)
packaging/README.md (2,311 tokens)
README.md (1,485 tokens)
tasklist.md (3,305 tokens)
scripts/build_all.sh (727 tokens)
packaging/flatpak/build.sh (1,916 tokens)
packaging/arch/build.sh (1,860 tokens)
packaging/flatpak/org.badkiko.sofl.yml (1,950 tokens)
packaging/debian/build.sh (983 tokens)
scripts/dev.sh (2,221 tokens)
README_RU.md (2,120 tokens)
scripts/README.md (743 tokens)
sofl/details_dialog.py (4,031 tokens)
sofl/importer/steam_source.py (1,037 tokens)

Hi! 👋 Thanks for wanting to help improve SOFL. Here's a simple guide to get started.

🚀 Quick Start

Fork and Clone

# 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

Make changes in your code
Test that everything works: ./scripts/dev.sh

Commit changes:

git add .
git commit -m "Brief description of changes"

Push to your fork:
```
git push origin my-feature
```
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

# 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

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. 🎮

================================================================================

[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.

================================================================================

См. 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 - Автотесты

================================================================================

Привет! 👋 Спасибо, что хотите помочь улучшить SOFL. Вот простое руководство для начала.

🚀 Быстрый старт

Форк и клонирование

# 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

Сделайте изменения в вашем коде
Протестируйте что всё работает: ./scripts/dev.sh

Зафиксируйте изменения:

git add .
git commit -m "Краткое описание изменений"

Отправьте в ваш форк:
```
git push origin my-feature
```
Создайте 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 для сборки

🌐 Переводы

Добавить новый язык

# 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

Обновить переводы

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 лучше для геймеров. 🎮

================================================================================

📋 Основная концепция

SOFL (Steam Online Fix Launcher) — это специализированный Linux лаунчер для игр с поддержкой онлайн-функциональностью, который решает проблему сложного запуска современных мультиплеерных игр на Linux.

🎮 Проблема, которую решает проект

Linux геймеры сталкиваются с множеством проблем при запуске онлайн-игр:

Сложная настройка Wine/Proton префиксов
Конфликты версий Proton для разных игр
Отсутствие единого интерфейса управления играми
Проблемы с онлайн-подключением в играх
Необходимость ручной настройки для каждой игры

🚀 Основная идея

Создать easy-to-use лаунчер, который:

Автоматически настраивает окружение для онлайн-игр
Предоставляет единую библиотеку всех игр в одном месте
Решает типичные проблемы с запуском онлайн-функционала
Интегрируется с популярными сервисами для автоматического получения данных
Имеет современный и интуитивный интерфейс в стиле GNOME

🏗️ Архитектура и технологии

Основной стек технологий:

Python 3 как основной язык разработки
GTK4 + libadwaita для современного GNOME интерфейса
Meson как система сборки
Flatpak для распространения

Ключевые компоненты:

Импортеры для различных платформ (Steam, Lutris, Heroic, Bottles)
Онлайн-фикс модуль для исправления проблем с сетью
База данных игр с метаданными
Интеграции с внешними сервисами (SteamGridDB, IGDB, ProtonDB)

🎯 Целевая аудитория

Обычные пользователи Linux - хотят играть без технических сложностей
Steam пользователи - ищут удобный способ запуска онлайн-игр
Геймеры на других платформах - Heroic, Lutris, Bottles пользователи
Разработчики игр - для тестирования Linux портов

🔑 Уникальные особенности

Специализация на онлайн-играх:

Автоматическое обнаружение и исправление проблем с сетью
Специализированные настройки для популярных онлайн-игр
Поддержка различных типов онлайн-функционала (P2P, dedicated servers)

Интеграции:

SteamGridDB - автоматическая загрузка обложек
IGDB - информация об играх и рейтинги
ProtonDB - отзывы сообщества о совместимости
Lutris - интеграция с крупнейшей Linux игровой платформой

Удобство использования:

Drag & drop импорт игр
Автоматическое определение типа игры и оптимальных настроек
Простой интерфейс без лишних опций для новичков

📊 Видение развития

Ближайшие цели (v1.0):

Стабильная работа с основными онлайн-играми
Полная интеграция с Steam библиотекой
Автоматическое исправление 80% типичных проблем

🎨 Дизайн и UX

Принципы дизайна:

Минимализм - только необходимые функции на виду
Интуитивность - понятный интерфейс без документации
Производительность - быстрый запуск и отзывчивость
Современность - следование GNOME HIG

Ключевые экраны:

Главная библиотека - все игры в виде карточек
Карточка игры - подробная информация и быстрый запуск
Настройки - простая конфигурация основных параметров

🤝 Сообщество и развитие

Открытый исходный код:

GPL-3.0 лицензия
Активное сообщество контрибьюторов
Прозрачный процесс разработки

Модель монетизации:

Бесплатное ПО с открытым кодом
Возможные донаты и спонсорство
Партнерства с игровыми компаниями

Этот документ фиксирует основную идею и видение проекта SOFL. Он служит ориентиром для принятия решений о развитии и приоритетах проекта.

================================================================================

Этот каталог содержит скрипты и файлы для сборки пакетов SOFL для различных Linux дистрибутивов.

Поддерживаемые форматы пакетов

Flatpak - Универсальный формат для всех Linux дистрибутивов
Debian (.deb) - Для Debian, Ubuntu и производных
Arch Linux - PKGBUILD для сборки в Arch Linux

Быстрый старт

Сборка всех пакетов

# Сборка всех типов пакетов с версией из meson.build
./scripts/build_all.sh

# Сборка всех пакетов с указанной версией
./scripts/build_all.sh 1.0.0

# Сборка только определенных пакетов
./scripts/build_all.sh 1.0.0 "flatpak deb"

Сборка отдельных пакетов

Flatpak

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

cd packaging/debian
./build.sh [version]

Arch Linux

cd packaging/arch
./build.sh [version]

Скрипты сборки

Общие скрипты (`scripts/`)

get_version.sh - Получить версию из meson.build
update_version.sh - Обновить версию во всех файлах упаковки
build_all.sh - Собрать все типы пакетов

Использование скриптов

# Получить текущую версию
./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) автоматически:

Собираются пакеты для всех платформ
Создается GitHub релиз с прикрепленными пакетами
Обновляется версия во всех файлах

Ручной запуск

Можно запустить сборку вручную через 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

# Локальная установка стабильной версии
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

sudo dpkg -i sofl_VERSION_all.deb
sudo apt install -f  # Установить зависимости если нужно

Arch Linux

# Скачать 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

# Очистить предыдущие сборки
rm -rf flatpak-build sofl-repo

# Проверить manifest
flatpak-builder --show-manifest org.badkiko.sofl.yml

Debian

# Проверить зависимости
dpkg-checkbuilddeps

# Проверить пакет после сборки
lintian sofl_VERSION.deb

Arch Linux

# Проверить PKGBUILD
namcap PKGBUILD

# Тестовая сборка
makepkg -c

Распространение

После сборки пакеты можно распространять:

Flatpak - загрузить на Flathub
Debian - загрузить в PPA или репозиторий
Arch Linux - загрузить в AUR

Разработка

Режимы сборки Flatpak

Проект поддерживает два режима сборки Flatpak:

Стабильная версия (`org.badkiko.sofl`)

Используется для релизов и production
Branch: stable (по умолчанию)

Dev версия (`org.badkiko.sofl.Devel`)

Используется для разработки и тестирования
Branch: devel
Автоматически запускается после сборки

Быстрая разработка

Для быстрой разработки используйте build-dev.sh:

cd packaging/flatpak

# Быстрая сборка и запуск dev версии
./build-dev.sh

# Сборка с указанной версией
./build-dev.sh 1.0.0-dev

Ручная сборка dev версии

cd packaging/flatpak

# Сборка dev версии через основной скрипт
./build.sh dev . dev install

Особенности dev режима

Автоматический запуск: После сборки приложение запускается автоматически
Отдельный профиль: Dev версия не конфликтует со стабильной
Разные настройки: Можно тестировать новые функции без влияния на стабильную версию

Fast режим для быстрой разработки

Для максимальной скорости сборки используйте fast режим, который пропускает:

Установку flatpak и flatpak-builder
Настройку Flathub remote
Обновление remotes (сетевые операции)
Проверку и установку runtime/SDK

# Быстрая сборка dev версии
./build-dev.sh dev . fast

# Быстрая сборка стабильной версии
./build.sh 1.0.0 . fast install

Поддержка

При возникновении проблем с упаковкой создавайте issue в репозитории проекта.

================================================================================

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

🎮 Game Card

🛠️ Installation

📦 From Official Repositories

Flatpak (recommended)

# 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

Online-Fix Games Path: Specify the directory with your games
Proton Version: Select the appropriate Proton version
Import Sources: Enable the required gaming platforms

🙏 Acknowledgments

👥 Development Team

BadKiko — lead developer and project founder
Niko-PRO — architecture and design

🎯 Inspiration and Thanks

A huge thank you to the @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 — detailed guide for contributors

📜 License

This project is licensed under GPL-3.0. See the 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

SOFL — your reliable partner in the world of online games on Linux! 🚀

================================================================================

Обновлено: 10.09.2025 | Следовать: idea.md + conventions.md

📊 СТАТУС ПРОЕКТА

✅ ГОТОВО (существующая функциональность)

Основной лаунчер на GTK4 + LibAdwaita
Импорт из Steam, Lutris, Heroic, Bottles, Itch, Legendary, RetroArch
InstallDialog для установки Online-Fix игр из RAR
Управление библиотекой игр с карточками
Система поиска и фильтрации
Управление обложками через SteamGridDB
Настройки с источниками импорта
Современный UI в стиле GNOME HIG
Адаптивный дизайн с темами
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: Улучшение общего интерфейса

Статус: ❌ НЕ НАЧАТА | Приоритет: СРЕДНИЙ | Сложность: ВЫСОКАЯ

📋 Подзадачи:

Building from Source

Relevant source files

The following files were used as context for generating this wiki page:

Sources: packaging/README.md, scripts/dev.sh, CONTRIBUTING.md

Prerequisites

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

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.

Generating architecture diagram...

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:

Generating architecture diagram...

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:

Installing build dependencies like meson, python3-gi, and libgtk-4-dev.
Building the project with meson setup and meson compile.
Staging the files for packaging with meson install into a temporary directory.
Copying the DEBIAN/control file and updating its version field.
Creating postinst and prerm scripts to handle update-desktop-database and other post-install/pre-remove tasks.
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.

It first checks if makepkg is available, as it can only run on an Arch Linux system.
It creates a source tarball (.tar.gz) of the project.
It copies the PKGBUILD to a temporary build directory and updates the pkgver field.
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

You will be given:

The "[WIKI_PAGE_TOPIC]" for the page you need to create.
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

Relevant source files

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]:

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.
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.
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:
```

Generating architecture diagram...

   BAD Flow Diagram:

Generating architecture diagram...

   GOOD Sequence Diagram:

Generating architecture diagram...

```

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.
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](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/filename.ext%3Astart_line-end_line) for a range, or Sources: [filename.ext:line_number](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/filename.ext%3Aline_number) for a single line. Multiple files can be cited: Sources: [file1.ext:1-10](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/file1.ext#L1-L10), [file2.ext:5](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/file2.ext#L5), [dir/file3.ext](https://github.com/Qeatrix/steam-online-fix-launcher/blob/HEAD/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.
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.
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.
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:

CONTRIBUTING.md (818 tokens)
CHANGELOG.md (956 tokens)
conventions.md (1,018 tokens)
CONTRIBUTING_RU.md (1,167 tokens)
idea.md (1,512 tokens)
packaging/README.md (2,311 tokens)
README.md (1,485 tokens)
tasklist.md (3,305 tokens)
scripts/build_all.sh (727 tokens)
packaging/flatpak/build.sh (1,916 tokens)
packaging/arch/build.sh (1,860 tokens)
packaging/flatpak/org.badkiko.sofl.yml (1,950 tokens)
packaging/debian/build.sh (983 tokens)
scripts/dev.sh (2,221 tokens)
README_RU.md (2,120 tokens)
scripts/README.md (743 tokens)
sofl/details_dialog.py (4,031 tokens)
sofl/importer/steam_source.py (1,037 tokens)

Hi! 👋 Thanks for wanting to help improve SOFL. Here's a simple guide to get started.

🚀 Quick Start

Fork and Clone

# 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

Make changes in your code
Test that everything works: ./scripts/dev.sh

Commit changes:

git add .
git commit -m "Brief description of changes"

Push to your fork:
```
git push origin my-feature
```
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

# 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

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. 🎮

================================================================================

[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.

================================================================================

См. 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 - Автотесты

================================================================================

Привет! 👋 Спасибо, что хотите помочь улучшить SOFL. Вот простое руководство для начала.

🚀 Быстрый старт

Форк и клонирование

# 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

Сделайте изменения в вашем коде
Протестируйте что всё работает: ./scripts/dev.sh

Зафиксируйте изменения:

git add .
git commit -m "Краткое описание изменений"

Отправьте в ваш форк:
```
git push origin my-feature
```
Создайте 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 для сборки

🌐 Переводы

Добавить новый язык

# 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

Обновить переводы

meson compile sofl-pot -C builddir
meson compile sofl-update-po -C builddir

📝 Код и коммиты

Стиль кода

Используем Black для форматирования:

Максимум 88 символов в строке
UTF-8 кодировка
4 пробела отступов

Commit сообщения

В проекте принято коммитить с теговой системой

[A] добавлен файл new_feature.py
[M] изменен файл README.md
[R] удален файл old_script.py

🙏 Спасибо

Спасибо за вклад в SOFL! Вместе мы делаем Linux лучше для геймеров. 🎮

================================================================================

📋 Основная концепция

🎮 Проблема, которую решает проект

Linux геймеры сталкиваются с множеством проблем при запуске онлайн-игр:

Сложная настройка Wine/Proton префиксов
Конфликты версий Proton для разных игр
Отсутствие единого интерфейса управления играми
Проблемы с онлайн-подключением в играх
Необходимость ручной настройки для каждой игры

🚀 Основная идея

Создать easy-to-use лаунчер, который:

Автоматически настраивает окружение для онлайн-игр
Предоставляет единую библиотеку всех игр в одном месте
Решает типичные проблемы с запуском онлайн-функционала
Интегрируется с популярными сервисами для автоматического получения данных
Имеет современный и интуитивный интерфейс в стиле GNOME

🏗️ Архитектура и технологии

Основной стек технологий:

Python 3 как основной язык разработки
GTK4 + libadwaita для современного GNOME интерфейса
Meson как система сборки
Flatpak для распространения

Ключевые компоненты:

Импортеры для различных платформ (Steam, Lutris, Heroic, Bottles)
Онлайн-фикс модуль для исправления проблем с сетью
База данных игр с метаданными
Интеграции с внешними сервисами (SteamGridDB, IGDB, ProtonDB)

🎯 Целевая аудитория

Обычные пользователи Linux - хотят играть без технических сложностей
Steam пользователи - ищут удобный способ запуска онлайн-игр
Геймеры на других платформах - Heroic, Lutris, Bottles пользователи
Разработчики игр - для тестирования Linux портов

🔑 Уникальные особенности

Специализация на онлайн-играх:

Автоматическое обнаружение и исправление проблем с сетью
Специализированные настройки для популярных онлайн-игр
Поддержка различных типов онлайн-функционала (P2P, dedicated servers)

Интеграции:

SteamGridDB - автоматическая загрузка обложек
IGDB - информация об играх и рейтинги
ProtonDB - отзывы сообщества о совместимости
Lutris - интеграция с крупнейшей Linux игровой платформой

Удобство использования:

Drag & drop импорт игр
Автоматическое определение типа игры и оптимальных настроек
Простой интерфейс без лишних опций для новичков

📊 Видение развития

Ближайшие цели (v1.0):

Стабильная работа с основными онлайн-играми
Полная интеграция с Steam библиотекой
Автоматическое исправление 80% типичных проблем

🎨 Дизайн и UX

Принципы дизайна:

Минимализм - только необходимые функции на виду
Интуитивность - понятный интерфейс без документации
Производительность - быстрый запуск и отзывчивость
Современность - следование GNOME HIG

Ключевые экраны:

Главная библиотека - все игры в виде карточек
Карточка игры - подробная информация и быстрый запуск
Настройки - простая конфигурация основных параметров

🤝 Сообщество и развитие

Открытый исходный код:

GPL-3.0 лицензия
Активное сообщество контрибьюторов
Прозрачный процесс разработки

Модель монетизации:

Бесплатное ПО с открытым кодом
Возможные донаты и спонсорство
Партнерства с игровыми компаниями

================================================================================

Этот каталог содержит скрипты и файлы для сборки пакетов SOFL для различных Linux дистрибутивов.

Поддерживаемые форматы пакетов

Flatpak - Универсальный формат для всех Linux дистрибутивов
Debian (.deb) - Для Debian, Ubuntu и производных
Arch Linux - PKGBUILD для сборки в Arch Linux

Быстрый старт

Сборка всех пакетов

# Сборка всех типов пакетов с версией из meson.build
./scripts/build_all.sh

# Сборка всех пакетов с указанной версией
./scripts/build_all.sh 1.0.0

# Сборка только определенных пакетов
./scripts/build_all.sh 1.0.0 "flatpak deb"

Сборка отдельных пакетов

Flatpak

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

cd packaging/debian
./build.sh [version]

Arch Linux

cd packaging/arch
./build.sh [version]

Скрипты сборки

Общие скрипты (`scripts/`)

get_version.sh - Получить версию из meson.build
update_version.sh - Обновить версию во всех файлах упаковки
build_all.sh - Собрать все типы пакетов

Использование скриптов

# Получить текущую версию
./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) автоматически:

Собираются пакеты для всех платформ
Создается GitHub релиз с прикрепленными пакетами
Обновляется версия во всех файлах

Ручной запуск

Структура пакетов

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

# Локальная установка стабильной версии
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

sudo dpkg -i sofl_VERSION_all.deb
sudo apt install -f  # Установить зависимости если нужно

Arch Linux

# Скачать 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

# Очистить предыдущие сборки
rm -rf flatpak-build sofl-repo

# Проверить manifest
flatpak-builder --show-manifest org.badkiko.sofl.yml

Debian

# Проверить зависимости
dpkg-checkbuilddeps

# Проверить пакет после сборки
lintian sofl_VERSION.deb

Arch Linux

# Проверить PKGBUILD
namcap PKGBUILD

# Тестовая сборка
makepkg -c

Распространение

После сборки пакеты можно распространять:

Flatpak - загрузить на Flathub
Debian - загрузить в PPA или репозиторий
Arch Linux - загрузить в AUR

Разработка

Режимы сборки Flatpak

Проект поддерживает два режима сборки Flatpak:

Стабильная версия (`org.badkiko.sofl`)

Используется для релизов и production
Branch: stable (по умолчанию)

Dev версия (`org.badkiko.sofl.Devel`)

Используется для разработки и тестирования
Branch: devel
Автоматически запускается после сборки

Быстрая разработка

Для быстрой разработки используйте build-dev.sh:

cd packaging/flatpak

# Быстрая сборка и запуск dev версии
./build-dev.sh

# Сборка с указанной версией
./build-dev.sh 1.0.0-dev

Ручная сборка dev версии

cd packaging/flatpak

# Сборка dev версии через основной скрипт
./build.sh dev . dev install

Особенности dev режима

Автоматический запуск: После сборки приложение запускается автоматически
Отдельный профиль: Dev версия не конфликтует со стабильной
Разные настройки: Можно тестировать новые функции без влияния на стабильную версию

Fast режим для быстрой разработки

Для максимальной скорости сборки используйте fast режим, который пропускает:

Установку flatpak и flatpak-builder
Настройку Flathub remote
Обновление remotes (сетевые операции)
Проверку и установку runtime/SDK

# Быстрая сборка dev версии
./build-dev.sh dev . fast

# Быстрая сборка стабильной версии
./build.sh 1.0.0 . fast install

Поддержка

При возникновении проблем с упаковкой создавайте issue в репозитории проекта.

================================================================================

Steam Online Fix Launcher

A launcher for games with Online-Fix support on Linux

📝 About the Project

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

🎮 Game Card

🛠️ Installation

📦 From Official Repositories

Flatpak (recommended)

# 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

Online-Fix Games Path: Specify the directory with your games
Proton Version: Select the appropriate Proton version
Import Sources: Enable the required gaming platforms

🙏 Acknowledgments

👥 Development Team

BadKiko — lead developer and project founder
Niko-PRO — architecture and design

🎯 Inspiration and Thanks

A huge thank you to the @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 — detailed guide for contributors

📜 License

This project is licensed under GPL-3.0. See the 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

SOFL — your reliable partner in the world of online games on Linux! 🚀

================================================================================

Обновлено: 10.09.2025 | Следовать: idea.md + conventions.md

📊 СТАТУС ПРОЕКТА

✅ ГОТОВО (существующая функциональность)

Основной лаунчер на GTK4 + LibAdwaita
Импорт из Steam, Lutris, Heroic, Bottles, Itch, Legendary, RetroArch
InstallDialog для установки Online-Fix игр из RAR
Управление библиотекой игр с карточками
Система поиска и фильтрации
Управление обложками через SteamGridDB
Настройки с источниками импорта
Современный UI в стиле GNOME HIG
Адаптивный дизайн с темами
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: Улучшение общего интерфейса

Статус: ❌ НЕ НАЧАТА | Приоритет: СРЕДНИЙ | Сложность: ВЫСОКАЯ

Building from Source

Prerequisites

Development Workflow

Production Packaging

Packaging Directory Structure

Master Build Script: build_all.sh

Package-Specific Build Processes

Flatpak

Debian (.deb)

Arch Linux (PKGBUILD)

Conclusion

Included Files:

🚀 Quick Start

Fork and Clone

🔄 Development

Creating a Pull Request

Simple Rules

🐛 Bugs and Features

Report a Bug

Suggest a New Feature

🛠️ Working with Code

Architecture

Requirements

🌐 Translations

Add a New Language

Update Translations

📝 Code and Commits

Code Style

Commit Messages

🙏 Thanks

[v0.0.3.4a] - 2025-10-23

New Features

UI/UX Improvements

Technical Enhancements

[v0.0.3.3a] - 2025-09-01

Major Changes

Bug Fixes

Documentation Improvements

Development Tools

UI/UX Improvements

Removed Features

[v0.0.3.2a] - 2025-08-27

[v0.0.3.1a] - 2025-08-26

[v0.0.3] - 2025-08-25

New Features

Bug Fixes

Other Changes

[v0.0.2] - 2025-06-25

New Features

Bug Fixes

[v0.0.1] - 2025-04-25

New Features

Installation

🎯 Основные принципы

Код

Архитектура

📝 Стиль кода

Python

GTK/Interface

🔧 Технические требования

Зависимости

Качество

🚀 Производительность

UI

Код

📊 Коммиты

Формат

Правила

🏗️ Структура проекта

⚠️ Запрещено

🔍 Проверки качества

🚀 Быстрый старт

Форк и клонирование

🔄 Разработка

Создание Pull Request

Простые правила

🐛 Баги и фичи

Сообщить о баге

Предложить новую функцию

🛠️ Работа с кодом

Master Build Script: `build_all.sh`

Общие скрипты (`scripts/`)

Стабильная версия (`org.badkiko.sofl`)

Dev версия (`org.badkiko.sofl.Devel`)