input on input
just checking in really 😄 I know you had the axis proposal on your plate still but that’s obviously not too urgent. If you wanted to help out with code you could take input off my hands but again if not I’ll keep crying trying.
12 Replies
id love to! other than life etc etc the only reason i havent started is i have no clue where to even begin or how any of silks stuff works at all
well good news, there is no stuff yet!
you get to define all that
yippee!
I’ve obviously implemented windowing already, but other than that it’s basically the API that we’ve just (erm…. many months ago) worked our asses off to get into a good state!
I’ll push what I’ve got so far
obviously the "for now" solution is to effectively use SDL and wrap its APIs
in the future once we've put work into the axis proposal we can always go ahead and think about making this axis based
there will probably be a few places where you'll find yourself scratching your head on the API we've approved, as I have, e.g.:
- our vibration motors API is just not fit for purpose
- cursor configuration is window-specific in SDL but silk hasn't defined it as such, I'm hoping we can just get away with using
SDL_GetGrabbedWindow where things need a window.
- text input API could do with work given that you can't e.g. set a text area or receive IME things
but all of those can probably be resolved in extensions in a future proposal
for now, I think what we've got in the Multi-Backend Input document is fairly implementable, just a lot of work to do so
I've pushed up what I started on here
been mostly focusing on the backend side, I don't think I've even broken ground on InputContext yet
feel free to check it out and scope out the work, if you're happy to explore it then I would welcome it with open arms
and I'd be able to pick up some of the generator work which has also been progressing more slowly than is ideal (we have so many people waiting for 3.0 but noone helping lmao)
there is some allowance in adding stuff to the API that isn't in the proposal, it has always been the position of the team that small utilities that don't really change the concepts or API ergonomics at play don't need to go through the proposal process, but anything that is conceptually and logically additive should be in a proposal (basically if it's big enough to cause arguments we could do with having ahead of time)the forever curse
im not home atm but this seems like a great launching point for getting started
ill lyk id i have any questions
but yeah if me doing this lets you work on the generator then im doubly all for it
re: the axis proposal, i think i did all the low hanging fruit, with the Outputs section needing a groupthink session to work out IIRC
hey @my name is literally dom, did you manage to have a look at this yet?
happy to give you write access to the repo so you can just continue on that branch if you'd like
hey! not really, but i did clone it 😄 been a ton of work and struggling on this last bit of assembly shit for tooll/tixl. but thatd be hella convenient! though dont let it stop you from chiming in with feedback pre-PR if u are so inclined
no worries, it’s more figuring out what I should work on this weekend
input or generator stuff
input is the preview 1 blocker so it is priority, but at the same time I will have more output if I work on something that I actually enjoy
i imagine there's a lot of work remaining - when are you trying to get preview 1 out?
no date set, but would be good to do everything we can to speed it along
gotchu gotchu
ill probably get started poking around tomorrow
the other stuff seems to be resolving nicely
goddamn this is one hell of a codebase
im surprised how much you put in here already!
im literally just starting for the past hour or so but i got the input backend running (until its first update lmao) - was missing a reference to the Sdl Instsance. im not sure what exactly constitutes a crime against code here and i certainly havent committed any yet, but im sure ill have a bunch of questions
reviving thread