cryze / livesplit-one-desktop Goto Github PK

Prototype implementation of LiveSplit One for the Desktop.

Rust 100.00%

livesplit-one-desktop's Introduction

LiveSplit One

This repository hosts the Desktop version of LiveSplit One. LiveSplit One is a version of LiveSplit that uses the multiplatform livesplit-core library to create a new LiveSplit experience that works on a lot of different platforms.

The Web Version is available here.

Build Instructions

In order to build LiveSplit One you need the Rust Compiler. You can then build and run the project with:

cargo run

In order to build and run a release build, use the following command:

cargo run --release

livesplit-one-desktop's People

Contributors

Stargazers

Watchers

Forkers

kitlith davidegiovannini jcapucho p1n3appl3 aspedrosa savage13 chtboner metroxe alexknauth bastisawesome samjo3

livesplit-one-desktop's Issues

Move this repository into the LiveSplit organization

This is blocked by a bunch of cleanup. #8 #7 #10 and possibly #6

Also we may just want to name this "LiveSplit One" (in whatever snake case or pascal case fashion), so we may need to rename the web version to something else.

Switch to wgpu or other high level crate on top of gfx-hal

Directly working with the extremely low level and unsafe API of gfx-hal shouldn't be necessary for our use case. The reason why we use gfx-hal is its modern and cross platform nature. Higher level crates that built on gfx-hal such as wgpu and rendy seem more suitable for usage in LiveSplit One.

Implement Support for Auto Splitters

There is a work in progress branch over here: https://github.com/CryZe/livesplit-one-desktop/tree/auto-splitting

Set up GitHub Actions as the CI

We want automatic builds for Windows, Linux and macOS. We probably want to ship early versions of the desktop version soon, so we should do the builds in CI and automatically publish them to GitHub Releases.

Clean up the master branch

It shouldn't have any random VSCode config files flying around, shouldn't have livesplit-core as a submodule and shouldn't have any random experiments in the code.

Questions about autosplitting

Hello there! I apologize if this is the wrong place for it, but I had some questions about how autosplitting works with LiveSplit One. I can see in the config.yaml that there's an auto-splitter section, so I assume there's probably some sort of autosplitting support. However, the extension is ".wasm" instead of ".asl", and I'm not really sure...how to get a working auto-split file. Are ASL files compatible with LiveSplit One? How do you make a WASM file? Is there a way to convert ASL files? Also, since the autosplitting (presumably) happens in the library, does that mean it can also be accessed through OBS? Would I be able to auto-split with the OBS plugin?

Sorry for all the questions, but I'm just very confused right now. Thanks!

EDIT: I'm on Arch Linux, BTW.

Linux: Unusable on both Gnome Wayland and Xorg

Running on Fedora 35 Silverblue

I know this is a prototype but I thought I'd give some feedback if it could help.

Both: There's no way to access sub-menus. Right clicking does nothing so I can't load any splits or themes, ~~and I cannot start the timer either. I assume this is related to issue #27~~ Ran as root and it did fix the hotkey issue, so yes it's related.

Wayland specific: Running normally from terminal gives the error "Failed to create server-side surface decoration: Missing", therefore Livesplit has no titlebar, so the window can't be moved. However that can be worked around by running it like this under Wayland

env -u WAYLAND_DISPLAY ./livesplit-one

This will force it to run under XWayland, which will fix the titlebar issue, but again, it's currently unusable on my system.

Implement a fallback OpenGL based renderer

Not everyone may have Vulkan, Metal or co. on their system (especially in VMs, which is important for testing purposes). So we definitely want some kind of OpenGL fallback. I don't think gfx-hal's / wgpu's OpenGL implementation are usable, so we likely just want to bring our own implementation.

Optimize debug profile once Rust 1.41 is out

In Rust 1.41 you can specify profile overrides for dependencies. This will allow us to drop back down to opt-level = 0 for the debug profile and use opt-level = 3 and debug-assertions = false for the dependencies where performance is critical, such as wgpu and cranelift. This should result in faster compilations and faster runtime performance.

Feature Request: Basic Documentation Markdown or Wiki?

I compiled this on Linux last night and found it very easy to build and run. However, judging from tutorials I found, the interface doesn't seem to work like the "classic" Livesplit (i.e. right-clicking the interface does nothing) nor are there configuration buttons to add splits like on the Livesplit One web site.

After pressing every key on the keyboard, I've been able to determine are that 1,3,5,8, and 9 on the numeric keypad have various effects, I've never used any version of Livesplit before - and without being able to get to a settings/hotkeys menu it's not intuitive how to do anything beyond a marathon timer.

Is there documentation that I've just missed? Or has this project not gotten to that point because an interface to set up splits and/or change hotkeys is not yet implemented?

Thanks.

https://i.imgur.com/oZoUaws.png

How do you save splits?

I've noticed that there seem to be no buttons to save pb's etc. and when restarting the program everything is back to 0. Is there any way so save splits for now or do I just have to manually put them into the .lss file?

Set up a license

We may potentially want to use GPL here instead of MIT. I'm not sure yet, but we definitely need a license.

livesplit-one panics immediately when running as normal user

Hi,
I can't run livesplit-one as a normal user. It worked fine when I compiled and ran it a while back (early December, I think) but now when I run it, it panics:

$>cargo run                                                                                                                                                                                                                                                   
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/livesplit-one`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failed to create window, "Failed to setup X IM via XOpenIM."', src/main.rs:32:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and same when running it from the release v0.0.2 binary (here with the RUST_BACKTRACE=1):

$>RUST_BACKTRACE=1 ./livesplit-one
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failed to create window, "Failed to setup X IM via XOpenIM."', src/main.rs:32:44
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::result::unwrap_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5
   3: livesplit_one::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
zsh: IOT instruction (core dumped)  RUST_BACKTRACE=1 ./livesplit-one

The binary release runs fine when running with sudo, but I would like to avoid running it with root privileges.

I'm on arch linux with realtime kernel:

uname -a
Linux 3900x 5.17.1.17.realtime2-3-rt #1 SMP PREEMPT_RT Mon, 23 May 2022 14:59:14 +0000 x86_64 GNU/Linux

Any help would be much appreciated.

Thanks in advance

Right clicking dont work

I'm just running the linux binary from my desktop and when I right click in the window nothing happens

Output is Build Failed, already used "cargo build --release -p cdylib" and just "cargo build" on an Livesplit Core clone, what do i do?

Write a README

Splits and Layouts NOT A ISSUE

not a issue but how would i customize it or use splits thanks :)

Crash on Startup

Running on Endeavor OS, based off of Arch Linux. (Not sure if that's super relevant but I wanna add as much info as I can about this.) Everything compiled fine after running cargo run but whenever it tries to launch, it just does a small blip for the window, opening then closing immediately. It gives me this in the terminal: thread 'main' panicked at 'called `Result::unwrap()` on an Err value: Timeout', src/renderer/mod.rs:448:57 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Aborted (core dumped)

Splits dont seem to work (not an issue)

I have a split file but it doesnt seem to affect it
i've added it to the config.yaml file but it doesnt work
running manjaro linux

The following warnings were emitted during compilation

Trying to build on a MacBook 2020 (M1) and run into the follow issue when cargo run'ing, pretty sure it'll be something I've missed or done wrong 😅:

The following warnings were emitted during compilation:

warning: In file included from src/native/macosx/MacMiniFB.m:1:
warning: In file included from src/native/macosx/OSXWindow.h:1:
warning: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
warning: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
warning: /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
warning: - (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
warning: ~~~~~~~~~~~~~~ ^ ~
warning: /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
warning: #define NS_FORMAT_ARGUMENT(A) attribute ((format_arg(A)))
warning: ^ ~
warning: src/native/macosx/MacMiniFB.m:426:38: warning: unused parameter 'window' [-Wunused-parameter]
warning: void mfb_set_cursor_visibility(void *window, bool visibility)
warning: ^
warning: 1 warning and 1 error generated.

error: failed to run custom build command for minifb v0.20.0

Caused by:
process didn't exit successfully: /Users/USER_NAME/Downloads/livesplit-one-desktop-0.0.2/target/release/build/minifb-ed2f79e2cde48f8b/build-script-build (exit status: 1)
--- stdout
TARGET = Some("aarch64-apple-darwin")
OPT_LEVEL = Some("3")
HOST = Some("aarch64-apple-darwin")
CC_aarch64-apple-darwin = None
CC_aarch64_apple_darwin = None
HOST_CC = None
CC = None
CFLAGS_aarch64-apple-darwin = None
CFLAGS_aarch64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = None
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-arch" "arm64" "-Wall" "-Wextra" "-mmacosx-version-min=10.10" "-o" "/Users/USER_NAME/Downloads/livesplit-one-desktop-0.0.2/target/release/build/minifb-3d6b41cc18cb96a1/out/src/native/macosx/MacMiniFB.o" "-c" "src/native/macosx/MacMiniFB.m"
cargo:warning=In file included from src/native/macosx/MacMiniFB.m:1:
cargo:warning=In file included from src/native/macosx/OSXWindow.h:1:
cargo:warning=In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
cargo:warning=In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
cargo:warning=/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
cargo:warning=- (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
cargo:warning= ~~~~~~~~~~~~~~ ^ ~
cargo:warning=/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
cargo:warning= #define NS_FORMAT_ARGUMENT(A) attribute ((format_arg(A)))
cargo:warning= ^ ~
cargo:warning=src/native/macosx/MacMiniFB.m:426:38: warning: unused parameter 'window' [-Wunused-parameter]
cargo:warning=void mfb_set_cursor_visibility(void *window, bool visibility)
cargo:warning= ^
cargo:warning=1 warning and 1 error generated.
exit status: 1

--- stderr

error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-arch" "arm64" "-Wall" "-Wextra" "-mmacosx-version-min=10.10" "-o" "/Users/USER_NAME/Downloads/livesplit-one-desktop-0.0.2/target/release/build/minifb-3d6b41cc18cb96a1/out/src/native/macosx/MacMiniFB.o" "-c" "src/native/macosx/MacMiniFB.m" with args "cc" did not execute successfully (status code exit status: 1).

warning: build failed, waiting for other jobs to finish...
error: build failed

I did also download the v0.0.2 release (livesplit-one-v0.0.2-x86_64-apple-darwin.tar.gz) which opens fine (I can see the GUI) but I can edit anything/add splits etc,. I do get some Terminal/command line feedback when I try and drag the width/height of the GUI:

AGX: Texture read/write assertion failed: (yoffset + height) <= ALIGNGRAN_NPOT(getViewLevelHeight(mipmapLevel), block_height) && "Region height OOB"

Any help would be greatly appreciated!

Hotkeys not working at all on Linux

I'm trying to run the release build of v0.0.2 on Manjaro Linux KDE/X11, but I'm unable to get any hotkeys working. I've added the hotkeys to my config.yaml file, and I know it's set because using an invalid key name does not load the splits. However, when I press the hotkeys (either in the app or outside), the splits are not triggered. I've tried changing the keys multiple times to no avail. Is there something I'm missing?

Support downloading the splits from splits.io

This is basically just for testing the integration with the splits-io-api crate with the desktop version of LiveSplit One and in general to see how an async runtime would integrate there.

Find the UI library that we'll use

LiveSplit One on the Desktop will need to use a UI library as some point. It is really important to us that the library that we are choosing is sufficient for the use cases that we need it for and also is easy to compile and distribute. So while Qt and Gtk may be sufficient for all the use cases, they may make it hard to contribute, compile and distribute the application in the end. So this choice is fairly non-trivial as the more complex a UI library gets, the higher the chance it is sufficient for our use cases, but also the higher the chance it may be hard to compile and distribute.

The following libraries are an option:

kas: I have no idea what this one is. I just randomly saw this and it looks like it has a reasonable text box implementation, which is the hardest part. The screenshots look pretty bad, but the themes are supposedly very customizable. It also has nice rust-only dependencies.
OrbTk: This one seems like one of the furthest UI crates so far, but it seems hard to use at first glance (this might've improved though, as they've been writing documentation) and its text boxes are fairly simplistic and don't respect the keyboard layout.
druid: This one is also one of the furthest UI crates. It has a dependency on GTK, Cairo and co., which is suboptimal. The textboxes seem fairly advanced, but not quite as advanced as iced. Combo boxes seem to be missing. Layouting seems better than iced at first glance, but I didn't look much into it.
iced: This one is coming up, looks decent and has really good textbox support. It's still too immature when it comes to layouting, but this is a decent option.
azul: This is what I've been using before and this had by far the best layout and rendering, but the textboxes were almost non-existent and required you to manage their state in some weird separate way. Also the crate is semi-dead now, so yeah.
Flutter: Google's new UI framework. This is probably really big and complex and so far it seems like the performance isn't that great yet (although they've been saying that this is only because of the debug builds they've been using). If it's easy enough to set up, we might go with this if the Rust only options don't work out for us.
Electron: Just ship a browser lol. Not the greatest option, but at least it does proper text rendering, proper text boxes, has great layout and co. We'll use this if everything else won't work out.
GTK: This works reasonably well on Linux, but looks bad on everything else. However the Rust bindings are supposedly fairly good. Setup is probably fairly painful on non-Linux systems. It also forces us to use the -gnu toolchain.
Qt: This is pretty decent, but the Rust bindings are supposedly bad. So you have to use C++ for the frontend code, which I don't really want to do. Additionally the setup is probably painful.
.NET MAUI: Might be too focused on apps. But seems to support all the desktop platforms.
React Native for Desktop: Doesn't seem to support Linux atm.

Will there be a .app file for mac?

Explore wasmtime for the autosplitters

We haven't entirely settled on wasmer yet and it has some flaws that haven't been resolved yet. wasmtime now implements some of the things we definitely need, such as the ability to terminate execution at will, which is important as otherwise a faulty autosplitter could consume 100% of some thread as it gets stuck in some infinite loop and you couldn't do anything about it.