Implement `push`, `remove` and `insert` methods on arrays in slint by uAtomicBoolean · Pull Request #11614 · slint-ui/slint

uAtomicBoolean · 2026-05-04T15:03:47Z

I took a shot at implementing the push, remove and insert methods on the arrays in Slint but it is not complete as it is missing the C++ implementation. However, I'd like to have a first review if possible.

In order to do that, I added three new methods in the Model trait: push_row, insert_row and remove_row.
However, while implementing these methods in the different models, I came across code duplications with:

the Javascript ArrayModel which already implements a push methods that takes a list of values and a remove method.
the Python ListModel which implements an append method.

So I have the following questions:

What should I do regarding the code duplication in the JS ArrayModel and Python ListModel ?
What should be the values in inline_expressions.rs ? (I temporarily set all three methods to 50)

Fixes #9412

Fully works on Rust. Add basic implementation in interpreter (not final). All three methods are not implemented yet in C++. Add tests for the rust, c++ and js interpreter drivers.

Add new methods in the Model trait and implements where necessary. This introduce duplicated methods in the Javascript API (pushRow -> push, etc), this should be fixed.

Improves Rust code generation to use directly the new Model methods. Implements the methods in VecModel.

Add missing branch in C++ generator with todo!().

ogoffart

Thanks a lot for the PR.

(Coincidentally, someone else is working on something similar: #11564)

This is definitively the right direction IMHO.

I'd like to see more tests:
Doing these operations on read only model.
Doing these operations with invalid indexes. (negative or too high)
Doing these operations on empty model.
Or anything creative.

Also checking that repeater gets instantiated
(extend tests/cases/model.slint to do the same as what was done in rust, but through functions in slint)

Also syntax test that checks that pushing data of different type correctly errors out.

API wise, we have the choice between push and push_row for the Slint and Rust function. Should they be the same in Rust and Slint? Is the _row suffix useful? (it is consistant with the row_data/set_row_data functions)

the Javascript ArrayModel which already implements a push methods that takes a list of values and a remove method.

This is maybe an argument to just name it push
now the question is whether that would work to have thatfunction only take one argument in the interface, and more argument on the instance?

the Python ListModel which implements an append method.

I don't know the python convention much. We could have both doing the same thing, or keep only append.

ogoffart · 2026-05-06T05:46:02Z

+                let model = &#model;
+                let index = #index as usize;
+
+                if index < model.row_count() {


I'd say we could leave remove_row to take care of this condition in order to simplify the generated code (same in ArrayInsert)

ogoffart · 2026-05-06T06:06:13Z

+    ///
+    /// If the model can update the data, it should also call [`ModelNotify::row_changed`] on its
+    /// internal [`ModelNotify`].
+    fn push_row(&self, _data: Self::Data) {


API-wise, i wonder if this should be called push or push_row
I can see argument for both

And should we perhaps return bool for faillure?

(And same question for other methods)

@tronical : opinions?

I think the _row suffix is a great idea. 👍

For the prefix, my preference is append, which is closer to being the opposite of
removal (the opposite of push is pull or perhaps pop) - but call it a preference :)

To summarize:

My preference is append_row, remove_row, and insert_row - those are in perfect symmetry to me.
But I'd also be okay with push_row, remove_row, and insert_row.

ogoffart · 2026-05-06T06:09:05Z

            format!("slint::private_api::model_length({})", a.next().unwrap())
        }
+        BuiltinFunction::ArrayPush => {
+            todo!()


I guess the way to implement that is to add private function, similar to model_length before that.
One tricky part is that the default implementation of model generated by slint cannot be re-allocated. So we will have to get rid of this optimization. (use VectorModel instead of ArrayModel)

ogoffart · 2026-05-06T06:13:04Z

+            .or_else(|| f("push", member_macro(BuiltinMacroFunction::ArrayPush)))
+            .or_else(|| f("remove", member_macro(BuiltinMacroFunction::ArrayRemove)))
+            .or_else(|| f("insert", member_macro(BuiltinMacroFunction::ArrayInsert)))


This new API make sense.

But we could also argue for push_row/remove_row/insert_row to be consistent with the Rust API.

ogoffart · 2026-05-06T06:19:52Z

+    ArrayPush: (Type::Model) -> Type::Void,
+    ArrayRemove: (Type::Model, Type::Int32) -> Type::Void,
+    ArrayInsert: (Type::Model, Type::Int32) -> Type::Void,


Well, this is missing the data argument.
I am unsure if this type is used anywhere. (Maybe for function signature in the LSP I think.)
Maybe you can just use Type::Void or Type::InferredProperty or just some placeholder with a comment.

Worth making a completion or signature test in slint-lsp.

ogoffart · 2026-05-06T06:21:52Z

+    let element_type = match args[0].0.ty() {
+        Type::Array(t) => (*t).clone(),
+        _ => {
+            diag.push_error(format!("push() was called on a non-array: {:?}", args[0].0), node);


I think we can never get this error, otherwise the lookup would fail, right?

ogoffart · 2026-05-06T06:23:22Z

+    diag: &mut BuildDiagnostics,
+) -> Expression {
+    if args.len() != 2 {
+        diag.push_error(


Could you add syntax tests for this errors? (no arguments, too many arguments, also arguments of wrong type)

(also for other functions)

uAtomicBoolean force-pushed the model-modify-operations branch from 62f1cbe to ec5fd74 Compare May 4, 2026 15:13

uAtomicBoolean added 6 commits May 4, 2026 17:27

Add push(), remove() and insert() methods

2262ca8

Fully works on Rust. Add basic implementation in interpreter (not final). All three methods are not implemented yet in C++. Add tests for the rust, c++ and js interpreter drivers.

A proper implementation for new methods for Javascript

b11e564

Add new methods in the Model trait and implements where necessary. This introduce duplicated methods in the Javascript API (pushRow -> push, etc), this should be fixed.

Add Python implementation

f48df48

Add live preview implementation and add error management

ce641b7

Improves Rust code generation to use directly the new Model methods. Implements the methods in VecModel.

Rename python tests for better clarity

3fd590f

Fix PyModelShared implementation of push_row and insert_row

3c93859

uAtomicBoolean force-pushed the model-modify-operations branch from a30465a to 3c93859 Compare May 4, 2026 15:28

uAtomicBoolean marked this pull request as ready for review May 4, 2026 15:29

autofix-ci Bot and others added 3 commits May 4, 2026 16:17

[autofix.ci] apply automated fixes

fd5cafd

Remove unused variable

deab2e1

Add missing branch in C++ generator with todo!().

Add new methods in PyModelBase

7216737

uAtomicBoolean force-pushed the model-modify-operations branch from f97810f to 7216737 Compare May 4, 2026 18:02

ogoffart reviewed May 6, 2026

View reviewed changes

Apply first batch of fixes

bb0bcde

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement `push`, `remove` and `insert` methods on arrays in slint#11614

Implement `push`, `remove` and `insert` methods on arrays in slint#11614
uAtomicBoolean wants to merge 10 commits into
slint-ui:masterfrom
uAtomicBoolean:model-modify-operations

uAtomicBoolean commented May 4, 2026 •

edited

Loading

Uh oh!

ogoffart left a comment

Uh oh!

ogoffart May 6, 2026

Uh oh!

Uh oh!

Uh oh!

ogoffart May 6, 2026

Uh oh!

tronical May 6, 2026

Uh oh!

ogoffart May 6, 2026

Uh oh!

ogoffart May 6, 2026

Uh oh!

ogoffart May 6, 2026

Uh oh!

ogoffart May 6, 2026

Uh oh!

ogoffart May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

uAtomicBoolean commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ogoffart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

uAtomicBoolean commented May 4, 2026 •

edited

Loading