search

gtk-rs / gtk4-rs

Rust bindings of GTK 4
https://gtk-rs.org/gtk4-rs/
MIT License
1.89k stars 174 forks source link

gtk: Implementable implementation for AccessibleText #1789

Closed felinira closed 2 weeks ago

felinira commented 4 months ago

I am a little unsure if it's ever ok to return null in get_contents(_at) or not. Should I return an empty gbytes instead?

bilelmoussaoui commented 4 months ago

I don't have the time to review this right now but two questions:

felinira commented 4 months ago

is it important for you to have this in the next release or waiting till a future .x would be okay?

We can postpone it for now.

do you think you could add an example of how it could be used?

Sure, that makes sense. It's quite an involved interface.

felinira commented 3 weeks ago

There is still one thing here that I don't particularly understand: The 'bytes' return value is supposed to be a glib::Bytes that sometimes contains '\0' bytes and sometimes it doesn't. calling contents() on gtk::TextView will return a \0 byte, but it won't with contents_at().

felinira commented 3 weeks ago

Maybe two wrapper objects for (range, attr, value) triples wouldn't be such a bad idea. When writing the example it was very cumbersome to change attributes, adding attributes by constants, etc.

bilelmoussaoui commented 3 weeks ago

Maybe two wrapper objects for (range, attr, value) triples wouldn't be such a bad idea. When writing the example it was very cumbersome to change attributes, adding attributes by constants, etc.

I think we can do that as a second step :) but yes, having to deal with constants is not ideal. But also not sure how we can do something that wouldn't be too far away from the original API.

Maybe we can make those attributes an enum? then you would only have a Vec<(Range, TextAttribute)>