Feature Request: Modular hack-features

[ghost]

I really love some of the functionality the hacks provide.

I don't like the clutter of having all the features (and the UI) - most of which I'll never use. I would really prefer to keep the minimal look on my rm and only add the necessary buttons (if any at all - mostly I am looking to use the features that don't have any UI at all, like changing the sleep screen without a reboot)

Is it at all possible to split the binary patch apart and make an interactive install script where one can chose y/n for each feature?

If it is not possible or not feasible - is it possible for an advanced user to prepare a binary patch by themselves for themselves that only includes the features that they need?

I'm willing to help if workforce is the only thing preventing this from being done.

Thanks and cheers

[linuskoester]

I would like to see that as well +1

[ddvk]

this is not feasable, some part are interdependent and the binary patching cant deal with that

[shovemedia]

it's not feasible because you've assumed that distributing binaries is ok, but distributing source isn't. I've been doing this a long time, and that distinction doesn't hold water IMO. I really want to support this work, but that just ... isn't feasible under this model.

[shovemedia]

To be clear, when I say "support this work" I mean with actual dollars

[martin-braun]

it's not feasible because you've assumed that distributing binaries is ok, but distributing source isn't. I've been doing this a long time, and that distinction doesn't hold water IMO. I really want to support this work, but that just ... isn't feasible under this model.

The readme explains why distributing the source is a no-go for him. You could toggle off some UI in the 2nd icon from the bottom of the side bar, but I agree that it is limited a little bit.

@ddvk Maybe it was possible to give finer control by hacking an option panel into the main menu where you find "My files, Notebooks, PDFs, Ebooks, Favorites, Grid, Trash, Settings"? Maybe it is possible to add another view to the settings itself in which you can toggle off each feature if you wish to? I know, this is quite some work, but it would bypass the issue with modular binary patching. You would always serve the full hack, but people can simply disable features, at least.

Personally, I'm happy the way it is, but I think it would be nice for people who prefer to have a simpler UI, nonetheless. This would also be a nice place to configure which recent-file method to present, as I stated here.

Thanks!

[ddvk]

it's not feasible because you've assumed that distributing binaries is ok, but distributing source isn't. I've been doing this a long time, and that distinction doesn't hold water IMO. I really want to support this work, but that just ... isn't feasible under this model.

this is an interesting topic and my interpretation is the following:

if I were to distribute the whole modified xochitl binary it would not be ok (which was also their feedback). the binaries here are just a diff and my own work and unusable without the original binary.

also: https://news.ycombinator.com/item?id=23487752

[shovemedia]

I don't have any quarrel with the above. I presume doing a build requires an original binary to be present, but that's something that could be inserted by each developer w/o being posted to github. If it's not illegal for ddvk, then it shouldn't be illegal for me.

I certainly understand that some features are so intertwined as to be inseparable. But we're all hackers here; this is the complexity we're supposed to be capable of understanding.

[Eeems]

The main issue is that including source to generate a diff will likely require including context of code where it goes, which is the illegal part.

[martin-braun]

@ddvk @Eeems What about providing a binary patch that injects an interpreter into the binary that would never change? For instance inject LuaJIT into the xochitl binary and let it parse main.lua files within all subfolders of a mod folder that is located on the rM. The patch should expose the entire API of xochitl to Lua.

This way all the features of this repo could be rewritten using Lua which could be open source and people could even start to build their own xochitl hacks. Essentially, the hacks would just be mods in form of Lua files and would require the binary patch that injects the interpreter to work.

It would be the begin of a true open source hacking community where everybody could dig in without the hassle of decompiling the sources of rM and those sources would be protected and not open source.

Long story short: Instead of a binary patch that adds the hacks, we need a binary patch that enables open-source mods.