Contributing

[Gaibhne]

As a programmer, I would be interested in contributing, assuming the languages in play are something I either know or can learn. I could not find information about where the patches come from; I understand that they are not open source, but can you share any information about how one would go about making (or learning to make) their own patches ?

I have various ideas that I think might be awesome for people using their rM* like me, but it doesn't feel appropriate just asking you to do all the work. Nevertheless, I will also create issues for those ideas in order for people to discuss them and provide input.

[1gn1t10n]

I'm interested as well in experimenting.

The documentation and previous answers #94 #154 are stiffling the discussion.

Developers who wish to contribute to the project understand the licensing restrictions. I think there's been a misunderstanding. Sharing every step and automation tool is not what people look, rather some pointers to reduce searching along unfruitful paths.

I don't own the source

We agree on that. What would help is to understand the approach. That way, those who wish to contribute can judge for themselves the barrier for entry wrt what they already know.

The process is

1. [dev] Generate xochitl_modified
2. [dev] Generate diff using bsdiff and publish
3. [user] Download diff and patch xochitl_orig using bspatch

Those seeking to contribute are interested in step 1. Here are a couple of yes/no question that could help contributors get started. Note that these refer to step 1) of your development approach.

1. Is xochitl the only file that is used in reverse engineering?
2. Do you edit directly on the binary?
3. Do you translate to an intermediate representation?
4. Are the modifications only in QML files?
5. Is the generation process reproducible? I.e.: Does changing some constant like touch sensitivity result in the same xochitl_modified using your method regardless of how many times you generate it?
6. Does your approach use cross-compiling?
7. Does your approach require more than re-generation between minor versions of xochitl_orig?

Users would also benefit from the project having a higher bus-factor.

[deMontfort]

I am not a programmer, which is why I came here. I posted a couple basic Planning/Life-Organizing feature ideas hoping some programmers would want to pick up the projects.

I, and a lot of people wished their Remarkable had come with more Planning/Organizing functionality, and were disappointed it didn’t. For me, I am a single dad juggling kids, projects, work, side hustles, and going back to school, so being able to manage basic projects, life goals, a calendar... and notes, is what I was going for. The low-stimulus e-ink is much better for mu focus. I see it as the perfect platform... if it also had some essential productivity.

I believe these two Planning/Organizing additions would truly make Remarkable, remarkable, staying true to the design, and staying simple. If any of you end up accepting the challenge, feel free to assume ownership and charge a little money for creating it.

[ddvk]

I'm interested as well in experimenting.

The documentation and previous answers #94 #154 are stiffling the discussion.

Developers who wish to contribute to the project understand the licensing restrictions. I think there's been a misunderstanding. Sharing every step and automation tool is not what people look, rather some pointers to reduce searching along unfruitful paths.

I don't own the source

We agree on that. What would help is to understand the approach. That way, those who wish to contribute can judge for themselves the barrier for entry wrt what they already know.

The process is

1. [dev] Generate xochitl_modified

2. [dev] Generate diff using bsdiff and publish

3. [user] Download diff and patch xochitl_orig using bspatch

Those seeking to contribute are interested in step 1. Here are a couple of yes/no question that could help contributors get started. Note that these refer to step 1) of your development approach.

1. Is xochitl the only file that is used in reverse engineering? yes
2. Do you edit directly on the binary? yes
3. Do you translate to an intermediate representation? no
4. Are the modifications only in QML files? yes
5. Is the generation process reproducible? I.e.: Does changing some constant like touch sensitivity result in the same xochitl_modified using your method regardless of how many times you generate it? no, because there are timestamps
6. Does your approach use cross-compiling? no
7. Does your approach require more than re-generation between minor versions of xochitl_orig? yes

Users would also benefit from the project having a higher bus-factor. i've given access to some trusty