incrediblers
Joined 2 months ago
Karma
6
Submissions
15
Member since
Aug 16
Recent submissions
Comment · 10 days ago
What I was saying is that I think a "flipped pattern" where anything that sets something sometime somewhere is the word and anything that reads is a get_* makes this fine distinction unnecessary... and that makes life easier... I came to Rust from JS where one can overload methods... I understand from other comments that the set_* convention may have arrived from C++... In any case, consistency I think beats specifics.
Comment · 10 days ago
They are setters. They modify an element after instantiation. Mostly as part of the initial build, but then also in the event closure. Under the hood, a struct with interiorly mutable fields.
Comment · 10 days ago
My use case is a TUI framework (https://www.incredible.rs/). The setters configure elements in a chain-able manner. I grappled with the rust convention and decided to go the other way. Rational as mentioned.
But this made me think...
> "The getter ought to have a shorter name since it is probably called more frequently"
So i checked. Rough agent driven counts:
https://github.com/ronilan/incredible-flappy 407 setters and 183 getters.
https://github.com/ronilan/rusticon 546 setters and 5 getters
https://github.com/ronilan/shape-sorting 688 setters and 33 getters.
And in a code editor with a lot of ui configurations based on reusable elements 2865 setters and 206 getters.
In reactive apps on state handlers call on setters with state values. No getters involved...
Comment · 10 days ago
Getters and setters is the one I'm most at disagreement with.
// Mine
let label = Label.text("Hello Wold");
let label_text = label.get_text();
// Theirs
let label = Label.set_text("Hello Wold");
let label_text = label.text();
Comment · 17 days ago
TIL - there was business in TUIs that actually warranted “acquisitions”. Always considered developing them a hobby…
Comment · 29 days ago
Thanks. All noted.
“Text selection should highlight a character when the mouse is beyond mid point and not after the whole character.”
This one’s interesting regarding event trigger because selection is at the TUI level where there are no more pixels just chars.
Comment · 1 month ago
I tried to methods to get that effect and both cases it felt worse than the current. Will circle back to that sometime maybe. Touch support in a TUI framework is little of an edge case..
Comment · 1 month ago
A new one that is still not done 90% done and is still considering what license to go with.
Comment · 1 month ago
Comment · 1 month ago
thanks. will consider.
Comment · 1 month ago
Are you on mobile? What browser?
I am aware of issues. Note that this is not a "website" in the regular sense of the word. This is actually a TUI app written in rust and compiled to wasm (and other platforms too: https://github.com/ronilan/incredible/releases) as parrt of alpha testing of the Incredible TUI framework.
Creating the screen, reading a markdown file, laying out the text, colouring it, enabling the scroll, managing it, changing the mouse pointer over the scroll bar, responding to the drag on said scroll bar, underlining the links, colouring them when they are hovered, removing colour when they are not, inverting them when they are clicked, loading the next markdown page, changing the browser URL hash, the keyboard shortcuts, Ctrl+e to select all, Ctrl+c to copy, etc. - it's all coming from Incredible TUI framework, not the browser.
Feedback on all aspects much appriciated.
https://www.incredible.rs/