option to use hexcodes instead of img path

[flick0]

can also fix #194

you can now pass hexcodes(0xrrggbb) instead of the img path

swww img 0xffffff --transition-type grow

the colors set through this are cached aswell

[LGFae]

From my understanding, you are building an RBG image and then sending it to the daemon.

I think it would be better if you were to simply use a Clear command instead. Clear will accept an RGB and set it all up directly in the daemon. It would be a lot more efficient, and I think the implementation would be cleaner too. Also, there would be no need to cache it.

[flick0]

but clear doesnt support transitions nor cache, this wud be useful when u want the bg to be a single color but still want transitions and have it be cached

[LGFae]

ah, I see, makes sense then

[LGFae]

Hey, @flick0. Sorry it took me so long to review it in detail, I was fixing some other more pressing bugs first.

In any case, I've tried testing this and got:

$ RUST_BACKTRACE=1 ./target/debug/swww img '0xffffff'                                                                                                                                                                                                                                                        15:57:32
thread 'main' panicked at /home/horus/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/fast_image_resize-2.7.3/src/image_view.rs:195:65:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:144:5
   3: core::option::Option<T>::unwrap
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/option.rs:931:21
   4: fast_image_resize::image_view::ImageView<P>::set_crop_box_to_fit_dst_size
             at /home/horus/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/fast_image_resize-2.7.3/src/image_view.rs:195:21
   5: fast_image_resize::dynamic_image_view::DynamicImageView::set_crop_box_to_fit_dst_size
             at /home/horus/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/fast_image_resize-2.7.3/src/dynamic_image_view.rs:132:42
   6: swww::imgproc::img_resize_crop
             at ./src/imgproc.rs:304:9
   7: swww::make_img_request
             at ./src/main.rs:239:26
   8: swww::make_request
             at ./src/main.rs:190:42
   9: swww::process_swww_args
             at ./src/main.rs:58:25
  10: swww::main
             at ./src/main.rs:52:5
  11: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[flick0]

Wierd, I'm assuming that's because of the quotes? It'll take a while for me to check it tho since I'm not home

[LGFae]

No, I don't think so. The error seems to be coming from the fast_image_resize crate. It seems it is failing to create an image at the correct size from a single pixel. One solution might be creating the image manually ourselves, since we already know what size it should be.

[flick0]

sorry took so long to fix this, was kinda busy.

anyways, i wasnt able to repro the error you got but it should now build a proper image instead of resizing a 1x1 img

[Akida31]

Some small things I would do differently, but feel free to ignore these.
But in general I like this :)

[LGFae]

@flick0, before you do any more work, let's figure out if we will actually go through with #194. I am starting to think this whole thing is rather unnecessary.

EDIT: the only problem is we wouldn't get the transition animations for colors...

[flick0]

@LGFae what do u think about aliasing clear as img <color> with no transition

[LGFae]

what do u think about aliasing clear as img with no transition

I think that's exactly what we should do. If you think this PR is already too big, we can leave it for another PR instead.

[flick0]

ill do it on a new pr later