Since building a lot of the rust code felt more like an experiment, I’ve not kept it very well organized. I need to go through each model and rust module and organize them well and then decide what needs to be publicly available or not.
One major way to work on this is to pass less items back to rust and just their indexes instead. This leads to knowing which item and letting rust find the item. Another solution is to allow qml to pass a QVariantMap to rust when adding items, and loop through the map to find all matches and build the item.
modified src/rust/service_item_model.rs
@@ -314,10 +314,18 @@ use self::service_item_model::{
use super::service_item_model::service_item_model::ServiceItemModel;
+#[derive(Clone, Debug)]
+pub enum ItemType {
+ Song,
+ Video,
+ Image,
+ Presentation,
+}
+
#[derive(Clone, Debug)]
pub struct ServiceItem {
name: QString,
- ty: QString,
+ ty: ItemType,
audio: QString,
background: QString,
background_type: QString,This represents an example of what it’d look like to add better types. If I can ensure to model things better I could leave out all the extra pieces in the ServiceItem struct and the Slide struct and include an ItemType. This would then let me jump to the appropriate db and get the right info for each item.
Since the slide_object is merely supposed to be the view of the current slide, deciding which slide to switch to should be entirely on the slide_model, not the slide_object. This way slide_object doesn’t need to know anything about the which slide is next and instead have a function to update everything to the slide returned from slide_model’s new slide.
This is something I couldn’t get right in my head and plans and I hope rust will help me to solve it.
I’ve got a sorta working concept. It hinges on MPV’s –start and –end properties. We’ll use this to make sure the video has the right settings. But, when switching to another video, we’ll need to reset it.
It does reset, but doesn’t if the video we are switching to is the same video, but different start and end times. This could be problematic if the user wanted to have two sections of the same video loaded. For say a teaching moment or something like that.
file:~/dev/lumina/src/qml/presenter/SongEditor.qml::function updateLyrics(lyrics) { The core problem with this is that when we set the song, the index to get the item is the index of the item in the vector, not the ID in the DB. So, when we get a song, we can’t use that index to update things, we need to make sure we are using the id so that all the new work in updating the right item is done correctly.
Find all references to the ID and make sure to be passing around the db id instead of the one found in the index to make sure we are finding the right song for every operation
The problem was compounded in that we are getting the ID through the proxy model too, which is different from the model index in rust. By setting the songID to the id found within the returned song, the rust model will have the same id meaning when we use that id, we are using the right one. Need to maybe find a way to ensure we are always passing around the id in the db so that we aren’t using the wrong one anywhere.
~/dev/lumina/src/rust/songs/song_model.rs
Sometimes it seemed that things would update, other times it would seem that after jumping to present view and then back that things wouldn’t be updated.
I’ve been thinking about my design of the service item model and slide model classes and believe I’ve used way too many properties for these models than is necessary. Instead I would really only need to have the title, type, and ids of the various items in the other models, then find a way to look them up when requesting them for the slide_object.
In doing this, I think I’ve started to come up with a basic design.
Since I haven’t gotten nested objects to work just yet, I think what I might do is move more connections into QML. This way I can run a basic javascript wrapper around the signal and slots connections to make sure I’m getting the correct info from the correct places.
Basically a workflow could look like this.
Add an item from the library to the servicelist. This will add the item in either by inserting or appending. Inserting uses the proper index, and insterts only the name, type, background(a generated one that is either from ffmpeg or the actual bg), and id within the corresponding model for that type of content.
This will call the itemInserted signal which will connect to the slideModels’ insertItem slot. This slot is essentially the same as the serviceItem, except it’ll only track the name, type, id within corresponding model, and index of the current item of the service item. This enables us to make sure that each serviceItem can hold multiple slides still, especially for songs.
Then when we want to load that into the slideObject, we simply grab the item from the slideModel, find the item in the corresponding types model, then use the index from the slideModel to make sure we are using the right item.
To display all the slides…
Actually as I type this out, I’m starting to think that the slide_model still needs all the metadata that the slide_object will have. The reason being that I’d like to have details in the slide preview system that can only come from having all the info available to QML. This makes the QML preview system a lot easier to reason with because you can use property binding rather than needing to create a custom building system for each arbitrary detail we want to add the to the previews. All that said, what properties does the slide_object and slide_model really need then? Is there a way for the model to have fewer props?
https://github.com/KDAB/cxx-qt/blob/main/examples/qml_features/rust/src/nested_qobjects.rs
But, I can’t seem to get it to compile. I’ll keep tinkering but this would be huge for allowing me to have a single object that can get passed into functions of other objects to be able to call inner functions from the outer call. This would mean I could have obs and slides talk. I could have the slide_object talk to the model. And more…
Maybe an alternative to this would be connecting them through signals, but idk yet....
Another alternative would be to try to use rust mods to make sure it is in scope of the qobject mod block.
For me, building lumina presentations through the ui is cumbersome. I’d like to improve it but honestly, it works great for the normal person use case, maybe for now as I get more of it matured. I’ll consider developing an emacs interface and connect it. Maybe even develop a server/client architecture so that I can build presentations quickly through a myriad of ways too.
file:~/dev/lumina/src/rust/image_model.rs::impl FromStr for Role {
I’ve done a sample of this in the image_model.rs file. But, I essentially want to make sure I can ask that each piece of data is associated with an enum so that I am ensuring to protect myself. Now that I think about it more though, I’m not 100% sure why or what to do it with, so I need a clear reason before just “It’s more rust-like!!!”
Here is an example
impl FromStr for Role {
type Err = ();
fn from_str(input: &str) -> Result<Role, Self::Err> {
match input {
"id" => Ok(Role::IdRole),
"title" => Ok(Role::TitleRole),
"path" => Ok(Role::PathRole),
_ => Err(()),
}
}
}Apparently this doesn’t work with cxx_qt right now....
And I think it’s been improved by allow Q_ENUMs to be made. So, perhaps I’ll figure out how to register those enums to QML and can pass them back into the rust side to stop using so many random ints.
The basic implementation is done. In order to make use of it in the odd broken QT way, i needed to implement clone on my stuct, but it worked out.
Once the model of OBS scenes is created, we can select a scene to add it to the service item. Then hopefully activate will take that scene and set it inside obs when switching slides.
Since sometimes in a presentation you’d possibly want different obs scenes, lets instead make these changes on the slides rather than on the service_items. That way each slide can have an associated obs scene and do some trickerydo to determine if we need to change it.
I need to properly update them yet, it would seem I never assigned the obs scene to the slides and then obs wouldn’t have anything to change to. I’m trying to change it now.
This has been really tricky since there is something of a bug when using runtime.block_on() rather than having a single cohesive tokio runtime. So, perhaps I need to figure out if I can’t make a runtime that works for the whole app so that I can manage these a little better.
file:~/dev/lumina/src/qml/presenter/Slide.qml::id: web
When moving service items around and thus slides, sometimes the WebEngineView causes a segfault
Maybe I need to use a timer function before loading the WebView? That way while moving things around, we aren’t loading anything and wait until moving is over?
ACTUALLY, if I can just generate thumbnails, I won’t even need the WebEngineView in the PreviewSlideListDelegate anyway, which seems to fix it.
file:~/dev/lumina/src/qml/presenter/MainWindow.qml::function getRevealThumbs(file) {
This site is very helpful: https://html2canvas.hertzen.com/configuration/
I could use html2canvas in order to render the file in a canvas and pick it’s size. Then I could take images of a slide, check to see if there are more slides, take another after changing and so on. This will likely need to be a lengthy script and I’ll need to toy with how to load both html2canvas and this script into the QML webengine
file:~/dev/lumina/src/qml/presenter/Slide.qml::/* function moveToSlideIndex(index) { */
file:~/dev/lumina/src/qml/presenter/SlideEditor.qml::Presenter.Slide {
This file can house all the logic for the editor and propogate the changes to the Slide.qml better. This way it can talk more directly to the song_model if done properly.
This could also help to separate more concerns in Rust and allow me to fix some small problems from the complications of Rust to C++ to QML. Maybe I can setup the changes to certain data pieces more cleanly this way.
Need to experiment with it more.
~/dev/lumina/src/rust/song_model.rs
~/dev/lumina/src/rust/song_model.rs
From what I can gather, sometimes an orm is just too hard to work around rather than doing raw sql queries. The only issue is that my queries have been rather small. I only really need to select everything into the app and then run it from there. However, it could still be a consideration as things age. Perhaps when there are hundreds or even thousands of items in the database, it’ll be more effective to use something like SQLx.
https://www.reddit.com/r/QtFramework/comments/11plifj/qhot_now_with_qt6_support/
~/dev/lumina/src/qml/presenter/Library.qml
For this to work I’ll need to use a vector of indexes. Somehow I’ll need to figure out what QML can pass to Rust and then cycle through all of them and remove each item.
A 1.0 release may be achievable soon as long as I can figure out what is good to have in and what isn’t. Then figure out what outstanding bugs and odd workflows exist and fix them. Then figure out deploying the package to various distros, windows, and mac.
A large portion of the back I am refactoring to create a slide class with a slide object for QML to look at as the master slide. Then a slide model for us to use to know for sure what the next slide will look like always and jump to it better within listviews and gridviews. Then use a serviceitemmodel that is aware of the slidemodel to know which slides belong to it. A lot of the UI will need to be refactored a bit to point to the new objects properly.
Could start working on moving slide.h and slide.cpp to a slide.rs. Then creating a slide_object.rs. Then maybe a service_item.rs. Creating these very basic classes in Rust would mean I start learning more and more Rust, and I would be preventing more memory bugs.
Some of the special effects and things that I wanted to do could perhaps hold off. A lot of the things that I want to do to help make this really special could hold off. Blur, Color Adjustments, and Shadows for backgrounds and text and stuff can hold off for now. More of the special propresenter kind of things.
I had some scope creep. While working on a handful of things I started to transition things over to using Rust instead of C++ with CXX-QT. In the end, I believe this to be a MUCH better move since so much of C++ is dangerous in a lot of ways and I am not confident in my abilities as a developer to make sure I’m not creating memory bugs.
In some ways, this made things harder, Rust does things differently and doesn’t have quite as many niceties as QT’s built in stuff, but in the end, I do think it’ll mean good things. Also, having this built this way may pave the way for others to build QT apps in Rust.
Others:
- Detail Layout
- Effects
- Overall Search
I need to make the UI fit so much better. A lot of making the UI work is going to start being top priority. So for starters.
Since moving to Rust, I’m going to include that all of the models except maybe the serviceitemmodel should be finished in Rust in order for this to be ready to release.
Others:
- Multi Drag? Maybe…
- Adding the ability to use Librepresenter in other wayland compositors - Need to address the QWindow problem. Fixed.
Drag and Drop of ServiceListthis is fixed, but now I need to move the slides around as you change the serviceItemModel- UI Blocking when saving
file:~/dev/church-presenter/src/cpp/slidemodel.cpp::void SlideModel::insertItemFromService(const int &index, const ServiceItem &item) { I THINK THIS IS DONE?!
file:~/dev/church-presenter/src/cpp/slidemodel.cpp::void SlideModel::removeServiceItem(const int &index, const ServiceItem &item) {
There is still a bug in inserting items to the service list. The listview starts to stack items ontop of each other.
Need to figure out multi delete of libraries. Selection is working but after 1 item is deleted, the model resets and then breaks my selection list…
I think i need deletion functions in all models
I’ll need to make sure I’m removing the right slide after a serviceItem is removed and then move them as well.
file:~/dev/church-presenter/src/rust/slide_model.rs::for (i, slide) in slides_iter.clone().enumerate() {
Either their index in the vector is wrong or their service_item_id is wrong. So my next approach will be to move slides individually rather than all at once?
This still needs ported to Rust. It’ll be the hardest of the library models since it includes the song lyric parsing functions.
This needs to get ported to rust so that I can start adding more features to it soon. This is a blocker for the start and end times I believe
This is now a much higher priority since I need to get this done before a lot of other things are even possible. Video times and presentation indexes will probably rely on this.
Maybe the first approach is to scan through the rest of the C++ code and see what I can easily move to rust fast. Things like moving items are a more involved set of steps.
Start with select, deselect, select_items, and deactivate. Then either move onto save or move things…
- [X] Select
- [X] Activate
- [X] Deselect
- [ ] Select Items Multiple items will be next. This will allow me to edit things much faster, and is necessary for releasing this.
- [X] Deactivate
- [X] Load
- [X] Save
- [ ] Linux Need to figure out if I can use Nix to deploy in various fashions. Maybe I’ll need to handcraft my own things for Arch, flatpak, and or snap.
- [ ] Windows
- [ ] Macos
This function will need to include parsing through the HTML of the results page. Finding the first “song-result”, then “song-result-title”, and inside that tag is the name. In the URL is the CCLI number.
Lyrics will probably be better to grab from genius lyrics.
Create a setting for holding static slides and audios :feature: ~/dev/church-presenter/src/qml/presenter/Settings.qml
This still needs a lot of work.
This still needs a lot of work. Mostly error handling.
This is waiting till we get the service_item_model.rs finished so we can use rust threads.
I could add this by adding a bool as a gallery option in the ImageSqlModel. Then add a loop bool as well. Then perhaps I’d ask if this image item contains a gallery and if so, make sure to loop through all of the filePaths as they could be saved as a list instead of a single filepath. Then decide on the last one whether or not to loop back to the beginning based on the loop bool in the image item.
file:~/dev/church-presenter/src/qml/presenter/Presentation.qml::Controls.ToolBar {
file:~/dev/church-presenter/src/qml/presenter/SongEditor.qml::Controls.ToolBar {
- [X] alignment
- [X] font - Need to finish the UI portion of it
- [X] fontsize - Need to finish the UI portion of it
- [ ] effects?
For effects, I’m not 100% sure how to do this in an easy to build out way. Should I just do them the same as the other attributes or have effects be individually stored? Which effects to use?
I’m thinking shadows for sure for readability on slides. Also, maybe I should have an effect of like glow? But maybe I’ll come back to this after more of the core system is finished.
WAIT nix-shell needs a little bit of work perhaps yet. But may be working under plasma just not minimal window managers using qt5ct.
https://discourse.nixos.org/t/developing-kirigami-applications/19947/17 This thread helped a lot
All of the models need to be editable from the outside so that the editor pages a can appropriately change the properties of each item. I’ll go in this order.
Songs will be the hardest so I’ll save them for last. They are not even using the rust models yet anyway. The key that I figured out is that instead of relying on the proxy model to map to the appropriate id inside the rust model. I’ll store an id in the sqlite database and use that as a way to find each item. I’ll need to keep tinkering with the best way to do that as right now I looped through all the items and that may get inefficient as models grow.
Another big blocker in this process is to make sure that all properties are accessed appropriately on the QML side. I need to update a lot of QML code yet.
Almost done here, but I can’t get the data to emit the change and therefore inform the proxyModel of the changes and change it in the list view.
~/dev/church-presenter/src/rust/song_model.rs
Right now some of the paths are hardcoded and I need to fix that very fast so that everything will work on other machines.
file:~/dev/church-presenter/src/qml/presenter/MainWindow.qml::Presenter.Slide {
Starting this by creating a slide singleton that will carry the variables for the current visible slide in the presentation.
May need to think about making this a slide class for all possible slides and a presentation singleton which carries the slide, but first I’ll work out if this implementation works instead.
The left dock doesn’t carry the change from the arrow buttons and the video on the actual presentation doesn’t load.’
All pieces working now
“Lumina” is a word derived from Latin, which means “lights” or “illuminations.” It can be associated with brilliance, radiance, or the glow of light. In the context of a church presentation software, “Lumina” could represent the concept of shedding light, enlightenment, or guiding through visual presentations.
Let’s rename everything to that.
Both PDFs and reveal.js presentations think every slide is the first one. I need a way of finding the individual components and then properly switching to the next one.
Switching to the next slide in reveal.js may be tricky since I’ll need to push into the WebEngineView the next reveal function and then get back how many more slides and fragments there are.
I need to figure out how to make saving asynchronous in order to not lock the ui thread while saving.
Tokio seems to not be working the way I expected....
Works much better with spawning an os thread.
Still needs some form of ui to indicate that saving is in progress.
file:~/dev/lumina/src/qml/presenter/SongEditor.qml::Controls.SplitView {
file:~/dev/lumina/src/rust/service_item_model.rs::pub fn move_rows( Since cxx-qt is having trouble compiling beginMoveRows for rust, I tried a wrapper function in C++ but that’s causing an overflow in the slide_model after the signal. Actually I don’t think a wrapper function should even work since the Rust model is the one that should be calling beginMoveRows, not the C++ model.
All that said, the real solution is to figure out how to get beginMoveRows to compile for rust, until then, implementing some wrapper functions and using beginResetModel instead will work for move_up and move_down.
ALMOST DONE!! I only now need to figure out and fix whatever is happening to the seg fault that happens when moving things fast.
round 1 of errors done.....
now round 2 There were more after this too… some thousands of them I suppose
This was a doozy. Apparently the way that cmake links things together changed in cxx_qt 6.0. So, I had to rename a lot of the library linking to ${APP_NAME}_lib instead of using the ${CRATE} name. So, basically it changed from liblumina to lumina_lib I believe.
Like this..
target_link_libraries(${APP_NAME} PRIVATE ${APP_NAME}_lib)file:~/dev/lumina/src/qml/presenter/Slide.qml::WebEngineView {
In order to achieve this, I have to do some of the logic in qml as opposed to rust. Rust just is too far abstracted I think… Unless maybe I can have some form of slide signal pieces that the slide can react to and pass the necessary pieces into rust. I’ll need to experiment with this, but I’ve found that it is all possible, so I’ll keep playing.
- First in JS
- Now need to see if I can do more logic in Rust instead.
- Maybe signal handlers?
I’ve written this with signal handlers now. It’s working sorta.
file:~/dev/lumina/src/qml/presenter/SlideEditor.qml::Item {
file:~/dev/lumina/src/qml/main.qml::function save() {
file:~/dev/lumina/src/qml/presenter/SongEditor.qml::function updateBackground(backgroundType) {
Quite by accident, I discovered how I may be able to fix this bug. Even though in QML I cannot show the window on demand, apparently in C++ I can still do it. So I will attempt to show the window by subclassing QQuickView in Rust and assign it’s source through a QML file that is the PresentationWindow.qml
FIXED!
file:~/dev/church-presenter/src/rust/song_model.rs::.expect(“Error loading songs”);
Need to handle the error and create the database in case it doesn’t exist with the proper setup.
I’ve got diesel migrations to work and can essentially use that to initialize the database for me.
I think songs are loaded first
Simply having diesel load the database creates one if there isn’t one there
Once the migration is done, the rest just loads since it’s in the setup function of the songs.
~/dev/church-presenter/src/rust/song_model.rs This is the big one. Previous implementation in cpp is here: file:src/cpp/songsqlmodel.cpp::QStringList SongSqlModel::getLyricList(const int &row)
This is possible with a toggle in the presenter but it’d be even better to have that built into the video model so that videos remember whether they should repeat. This would make sense in things like countdowns or video slideshows.
This allows us to drag multiple to service list and delete multiple. final part to this is allowing for multiple select and multiple move in service list or library
This is mostly done, just need to include the ability to multi select and then figure out multi drag.
I switched back to using Kirigami.dragHandler and properly implemented moveRows in the serviceItemModel
Fix broken append when importing River song
Let’s test this, because I think I fixed it. still extra bits on last slide
file:~/dev/church-presenter/src/qml/presenter/DragHandle.qml::function arrangeItem() {
- [X] Basic fixed drag n drop
- [ ] Allow for a less buggy interaction I think one of the major problems has to do with moving the item while I am still draggin it. This means that I am then shifting the item’s id whilst dragging and causing some unsuspected behavior? Not sure, need to maybe consult some one else if possible.
- [ ] Need to check for edge cases
file:~/dev/church-presenter/src/qml/presenter/SongEditor.qml::Presenter.SlideEditor {
- [X] Initial ListView with text coming from
getLyricList - [X] Depending on this Need to make getLyricList give back the verses with empty lines as separate slides
- [X] Need to perhaps address the MPV crashing problem for a smoother experience.
Essentially, mpv objects cause a seg fault when we remove them from the qml graph scene and are somehow re-referencing them. Using
reuseItems, I can prevent the seg fault but then we are storing a lot of things in memory and will definitely cause slowdowns on older hardware. So far I haven’t seen too many problems with thereuseItemspiece yet.Apparently, I still have crashing
Setting a really high
cacheBufferin the ListView seems to have fixed the crashing, but will result in higher memory use. As of right now we are using 1.1Gb total, so I may think of a better solution later, but for now, that’ll have to work. - [X] There is also a small hiccup in switching between songs. I appears as if songs that don’t have any slides will have ghost slides from the previously selected song.
- [X] Another issue I discovered was that when switching to a song with videoBackgrounds, the mpv object doesn’t ALWAYS load the first frame of the slide. Can I let the video play a tiny bit longer to make sure frames ALWAYS get loaded? That didn’t work..
- [X] There is one other issue with videoBackgrounds now going black on the second slide after switching to a slideModel. I need to check if the videos are the same and if so do nothing. fixed.
Maybe I’ll need to change something else but what?
Being selected means that those items can be dragged or deleted or moved together. Being active, means that the singular item is the currently displayed item.
Check audio and background first, if they don’t exist, grab the file in the archive and put it in the local folder and use that path to create the serviceitem
file:~/dev/church-presenter/src/qml/presenter/Presentation.qml::function nextSlide() {
- [ ] Check to make sure this works in all conditions but I believe it works ok.
To finish the UX of which item is active, the Presentation needs to switch to the active slide in the preview system.
- To make this work I think I’ll need to make serviceitemmodel able to signal when a particular item is active and give it’s index so the list can follow suit. nevermind, I can just check if it’s active in the delegate.
file:~/dev/church-presenter/src/qml/presenter/Slide.qml::fillMode: Image.PreserveAspectCrop I didn’t save the aspect, but I applied it based on type of item first, we can change that later.
file:src/videosqlmodel.cpp::if (!query.exec(“CREATE TABLE IF NOT EXISTS ‘videos’ (”
Make sure the video gets changed in a proper manner to not have left over video showing from previous items
~/dev/church-presenter/src/qml/presenter/Presentation.qml
- [X] Build a basic system that changes to black first and then switches to the video
- [ ] Build out a loading system that will load the next video if it needs to and then the switch can be instant.
The second option is the best, but requires a lot more work. I have the first already working so I’ll come back to this once I have more of an idea of how to do it.
- [X] Add audio file to model
- [X] add ui for adding audio file
- [X] add extra mpv piece to slide to play audio file
Believe I’ve fixed this
- [X] Basic droparea
- [X] Determine which library to add to based on extension.
- [X] Add a presentation model so that presentations can be added this way.
file:~/dev/church-presenter/src/videosqlmodel.cpp::QVariantList VideoSqlModel::getVideo(const int &row) {
Bug in mpv race condition with selecting with the presenter but not with the actual PresentationWindow.
when selecting an item in the ServiceList, if the PresentationWindow isn’t visible, it seems to prompt mpv to show a window of it’s own with the video playing if the item contains a video.
file:~/dev/church-presenter/src/qml/presenter/Slide.qml::property real textSize: 50
This may not be as needed. Apparently the text shrinks to fit it’s space.
file:~/dev/church-presenter/src/songsqlmodel.cpp:://TODO make sure to split empty line in verse into two slides
file:~/dev/church-presenter/src/qml/presenter/Presentation.qml::function changeSlide() {
slides are inconsistent in changing from one slide to the next or previous. Both functions need looked at.
Maybe my best solution would be to architect a model or class for both the presentation controller and the presentation window to follow and do all the heavy lifting in there.
Finished the arrows working through a proper c++ class
file:~/dev/church-presenter/src/qml/presenter/LeftDock.qml::function appendItem(name, type, background, backgroundType, text, itemID) {
This was due to the song not having a vorder. Need to protect from edge cases of the user inputing the formatted text that doesn’t fit what’s expected in code.
file:~/dev/church-presenter/src/qml/presenter/Presentation.qml::function nextSlide() {
- [X] Create a Model
- [X] Create a class that we’ll make a list of in the model
file:~/dev/church-presenter/src/videosqlmodel.h::ifndef VIDEOSQLMODEL_H
file:~/dev/church-presenter/src/qml/presenter/LeftDock.qml::Layout.fillHeight: trueor at least turns the entry above it into the same as itself while retaining it’s title?
file:~/dev/church-presenter/src/qml/presenter/Presentation.qml::function nextSlideText() {
file:~/dev/church-presenter/src/qml/presenter/SongEditor.qml::FileDialog {
file:~/dev/lumina/src/rust/service_item_model.rs::println!(“tar-written: {:?}”, &lf);
file:~/dev/lumina/src/rust/service_item_model.rs::println!(“tar-written: {:?}”, &lf);
I’m considering porting from using QML and CXX-QT to something like Iced or Slint and thus doing the entire app in a far more “Rust” way. The issues with this include:
- Rewrite almost the entire thing
- Most of the logic is fairly tied to the UI
- Will be using the current state of the app for a long time until it’s nearly feature parity
Having rewritten a lot of the logic once already to Rust, I think it’ll go faster, but I’m afraid of continuing to have FOMO in picking a library that isn’t quite up to snuff. Iced seems to be a good contender to be around for a while since System 76 is taking it on as their library to build COSMIC in. However, I just don’t think I like the way you build UI’s in Iced.
Slint on the other hand is basically like QML but for Rust, which is the whole reason this project started. QML and therefore Slint, are perfect for designing UI’s. It’s a powerful Object Tree that the code will nearly tell you in it’s form how the UI should look since objects are nested. Slint also seems a bit more finished.
Slint is also GPL3. So that means its protected. Good for me, not for others. Iced seems to have more community backing. Slint does have a dual license though and that is a bit scary.
I think I might just use Slint. Maybe it’s easier to contribute to than CXX-QT?
Let’s also list the problems I’ve had with CXX-QT…
- A lot of types that need to cross the boundary are specific to QT and therefore cause a lot of duplicated memory.
- The specific QT types are different and not “Rust” like.
- It’s complicated to inherit from QT types to build models. And that’s the only way to work with collections of data in QML. Models.
- Some things listed in the docs just don’t seem to compile.
- APIs are changing. They are still trying to land on a model for how things should look to the user of the library.
Slint and Iced both are a more nailed down API. However, QT is a far more mature system....