TODO

[dylanaraps]

If anyone wants to contribute, feel free to tackle anything below.

• Args
  • -a
  • -f
  • -n
  • -o
  • -q
    • out() function needs to be re-added.
    • A global variable may be needed to use the -q value globally.
  • -x No longer needed. Imported schemes use all 16 colors.
• Optimization
  • Look into running specific tasks in parallel.
    • Sending sequences to all open terminals.
  • Look into running specific tasks asynchronously.
    • Wallpaper setting.
• Tests
  • Write some tests.
    • Any help is appreciated as I've never done this before. :)
• Images
  • wal still calls imagemagick as a system command. Nothing I can do about this.
    • Look into libraries to perform the same task.
  • Picking a random image from a directory currently looks for all files instead of just images.
• Wallpaper
  • Identify the desktop environment.
• Error Handling
  • Check that the user has imagemagick installed.
• Other
  • Add fold markers to blocks of functions like in the original script.
  • Make wal.py a pip package eventually.
  • Drop the _colors from file names.
    • They're redundant.

[stav121]

I have a suggestion about your " Picking a random image from a directory currently looks for all files instead of just images." issue.

You could use tuples and check for the extensions of the loaded files in a directory, something like this:

extensions = ['.jpeg\n','.png\n','.jpeg','.png']
if <filename_here>.endswith(tuple(extensions)):
#(rest of your code)

I've used this method before and it works superb, I don't have the time to look through your code and implement it myself but this might be a good way to fix this issue.

[dylanaraps]

That's already been implemented! The entire TODO list is almost complete minus tests and the pypi package. :)

https://github.com/dylanaraps/wal.py/blob/master/wal#L134

[stav121]

Oh that seems fine to me, close to the one I suggested as well. I'll be sure to test it sometime soon and see the results.

[danielx]

Would you be interested in a pull request changing how pywal handle setuptools distribution?

I was thinking that changing wal from a python script to a module would make it easier to write tests later on.

[dylanaraps]

Sure! I looked into this when I initially ported wal to python and I had some trouble. I then settled on a one file script as it was before.

…

On Mon, 26 Jun 2017 at 1:43 am, Daniel ***@***.***> wrote: Would you be interested in a pull request changing how pywal handle setuptools distribution? I was thinking that changing wal from a python script to a module would make it easier to write test later on. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGfAa14Fi7NbUlHjwj2nRQQpZWmKGpQ8ks5sHoA0gaJpZM4N8ogg> .

[SethBarberee]

Out of curiosity, why did you take out the -x argument? I was kinda curious since the full 16-color pallete was nice to have.

[dylanaraps]

The 16 colors generated by wal can't just be applied to colors 0-16 in the terminal. The colors 1-8 are almost always too dark or too low contrast compared to the background. The colors 9-15 are instead applied since they're full of highlights and brighter colors.

We finally hard-code color 8 based on the brightness of color 0 since none of the colors in 1-8 are consistently bright enough to act as a dark grey. They're either too light or too dark.

-x only really ever worked with -f and -f was removed as well so it was pointless keeping it around.

[SethBarberee]

Oh ok! That's a good enough reasoning for me. I noticed that it was removed was only curious. Thanks for the clarification!

…

Sent from my iPhone

On Jun 28, 2017, at 12:42 AM, Dylan Araps ***@***.***> wrote: The 16 colors generated by wal can't just be applied to colors 0-16 in the terminal. The colors 1-8 are almost always too dark or too low contrast compared to the background. The colors 9-15 are instead applied since they're full of highlights and brighter colors. We finally hard-code color 8 based on the brightness of color 0 since none of the colors in 1-8 are consistently bright enough to act as a dark grey. They're either too light or too dark. -x only really ever worked with -f and -f was removed as well so it was pointless keeping it around. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.