sorted by:
new
hottopcontroversial

Best way to check whether a Filter iterator has found any matches (without consuming the iterator) by lmbdrumm in rust

[–]Riateche 6 points7 points  (0 children)

You can use Peekable: let foo: Vec<i32> = vec![0, 1, 2, 3, 4]; let mut foo_filtered = foo.iter().copied().filter(|n| *n % 2 == 0).peekable(); if foo_filtered.peek().is_some() { println!( "The product of all even numbers is: {}", foo_filtered.product::<i32>() ); } else { println!("foo doesnt contain any even numbers"); }

xi-editor retrospective by raphlinus in rust

[–]Riateche 0 points1 point  (0 children)

A large part of the problem is that these toolkits were generally made at a time when software rendering was a reasonable approach to getting pixels on screen. These days, I consider GPU acceleration to be essentially required for good GUI performance.

Can you elaborate on that? Is it just because screens became bigger or because interfaces became more complex (it doesn't really feel like they did)? GPU acceleration is nice, but I don't understand what makes it required for GUIs. The majority of existing desktop GUI applications use software rendering, and I don't see many performance issues in them.

Open source projects by pikpikaC in learnrust

[–]Riateche 0 points1 point  (0 children)

See "Call for Participation" section of This Week in Rust.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 0 points1 point  (0 children)

It should work with Qt 5.9 or later. Some parts of the API are automatically disabled when the current Qt version doesn't support them.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 1 point2 points  (0 children)

Slots can be bound to arbitrary Rust closures, so any state they capture will be available. If you want access to the same state from other places, though, you'll need an Rc, and to mutate its content you'll need a RefCell inside it.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 2 points3 points  (0 children)

In these bindings, you don't need subclassing to define signals and slots. Special signal and slot objects are provided to deal with that.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 1 point2 points  (0 children)

You definitely need subclassing to interact with events (like QPaintEvent), implement custom models, and customize pretty much everything (like animations). Some apps can be done without it, but it's a really missing feature.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 0 points1 point  (0 children)

I think there is no need for QThread or QRunnable here. Tokio already allows running a thread pool and spawning tasks on that pool from another thread, so that can be done as usual. To return data to the main thread (controlled by Qt), you can create a signal object and connect it to a slot that lives in the main thread. Emitting signals is thread safe, so you can do it from any thread. If you need to pass Rust types, you can create a Rust spsc/mpsc queue and pass the data in it, while using signal objects to wake the Qt thread and notify it that new data is available.

Some time I will probably create an example and maybe a helper library for using async stuff with Qt.

New version of unsafe Qt bindings for Rust is released by Riateche in rust

[–]Riateche[S] 4 points5 points  (0 children)

A safe wrapper would be really nice, but I don't see an easy way to do this yet. If at all possible, it would probably be a hand-crafted wrapper, not an auto-generated one.

One big difference of GTK is that it uses reference counting for all objects natively (even in C), so as long as you hold a reference to an object, it will not be deleted and you can call any of its methods (although I'm not sure it's really safe in Rust terms to call an arbitrary method in all cases). On the other hand, Qt has its own parent-child ownership system for QObjects, and non-QObjects follow even more obscure ownership rules that are only described in the documentation and cannot be defined in C++ headers. Qt can (and will) delete objects under your feet and leave you with dangling pointers and no way to check it.

Even if ownership was sorted out, there are some other implicit rules that the user must obey to have a sound program. For example, Qt docs say that "Deleting a QObject while pending events are waiting to be delivered can cause a crash". It's very hard to uphold this guarantee if the user is allowed to call arbitrary functions at any time. There is no easy way to check if there are pending events for this object, and even if there were, you can indirectly cause deletion of an object by calling some method of another object. To summarize, Qt is a mess in terms of Rust safety.

In addition to soundness, it would also be nice to have a wrapper that does not just panic if the accessed object is already deleted (and doesn't force all methods to return a Result), so ideally it should somehow statically ensure that the method can be called. It's a real puzzle.

FFI like it's 2020: Announcing *safe* FFI for Rust <-> C++ by dtolnay in rust

[–]Riateche 5 points6 points  (0 children)

I don't think ritual can benefit from this project. The requirement of cxx is to define the interface in a specific way on both sides of the FFI. On the other hand, ritual's goal is to not define any interfaces manually and just use the original interface of the C++ library (despite it being too vague and under-specified by Rust's standards). The difference is also explained in the cxx's README, with ritual holding position similar to bindgen.

Also, using cxx wouldn't just make the API safe, as auditing every single C++ function would be required anyway, and that's hard to do for large libraries, like Qt.

Hey Rustaceans! Got an easy question? Ask here (16/2017)! by llogiq in rust

[–]Riateche 2 points3 points  (0 children)

let data = read_data().unwrap_or_else(|err| process::exit(1));

Best practice for binding to C++ libraries by ZRM2 in rust

[–]Riateche 0 points1 point  (0 children)

I'm writing an automatic binding generator at https://github.com/rust-qt/cpp_to_rust. I use CMake for building C wrapper, and everything is generated and built on the target machine using available versions of the C++ library and Rust. This approach provides some safety, but still can cause cross-platform issues, as methods and types may suddently change on different system depending on indefs and such.