Allow users to compile builds without flatpak

[tfuxu]

This PR provides a way for developers and distro packagers to compile and ship AdwCustomizer without a need to install flatpak.

Btw, where can I find a source code for material_color_utilities_python library? I couldn't find it on PyPI, and I would be interested to maybe improve it, as its speed for now is atrocious. Never mind, I found it on yours organization profile.

[GradienceBot]

Welcome on Adwaita Manager. 🥳 We really appreciate your pull request. The core team will review your issue as soon as possible.

[0xMRTT]

Hi @tfuxu.

material_color_utilities_python is a port in python of the original one in JavaScript. It's forked from the repo of his creator in AdwCustomizerTeam/material_color_utilities_python.

The problem with the slow is know. It's a goal for the next version.

Currently, I shipped material_color_utilities_python as python package .whl

I need to change the meson architecture for allowing more flexibility (eg using variables for app ID, project name).

For shipping material_color_utilities_python there is two solutions:

• publish on pypi
• include as meson subproject

[0xMRTT]

Your changes on the README are very useful. Thanks.

Do you want to improve the material color utilities?

[tfuxu]

Hi @tfuxu.

material_color_utilities_python is a port in python of the original one in JavaScript. It's forked from the repo of his creator in AdwCustomizerTeam/material_color_utilities_python.

The problem with the slow is know. It's a goal for the next version.

Currently, I shipped material_color_utilities_python as python package .whl

I need to change the meson architecture for allowing more flexibility (eg using variables for app ID, project name).

For shipping material_color_utilities_python there is two solutions:

* publish on pypi

* include as meson subproject

Thanks for reply,
Good to know you guys are working on this problem. I think that including it as a subproject would be the best solution, so that your fork wouldn't collide with original creator's library if he would want to put it on PyPI later on.

[tfuxu]

Your changes on the README are very useful. Thanks.

Do you want to improve the material color utilities?

I would have to check it out first, but maybe I could help improve it later.

[0xMRTT]

You are welcome 🙂.

Reworking the meson architecture is a priority. Thanks 🙏👍 for providing this script.

[tfuxu]

@0xMRTT
Okay, I've fixed conflicts, should be ready to merge :)

[LyesSaadi]

Hello !

Good to know you guys are working on this problem. I think that including it as a subproject would be the best solution, so that your fork wouldn't collide with original creator's library if he would want to put it on PyPI later on.

Please don't. I'm interested in maybe packaging this for Fedora. A subproject, or even two concurrent versions of the same library, would be quite difficult to manage. Wouldn't it be possible to either submit your changes to upstream or to see with the original creator if he wishes to push his project to pypi or even to change the canonical project to your fork?

I know this isn't the best place to discuss this, but, unfortunately, the issue tracker in GradienceTeam/material-color-utilities-python is closed.

[0xMRTT]

I've enabled the issue tracker in the repo

[0xMRTT]

I've submitted a PR but nothing happened

[LyesSaadi]

Thanks !