Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option to use hexcodes instead of img path #195

Merged
merged 13 commits into from
Jun 11, 2024
Merged

option to use hexcodes instead of img path #195

merged 13 commits into from
Jun 11, 2024

Conversation

flick0
Copy link
Contributor

@flick0 flick0 commented Jan 11, 2024

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
Copy link
Owner

LGFae commented Jan 16, 2024

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
Copy link
Contributor Author

flick0 commented Jan 16, 2024

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
Copy link
Owner

LGFae commented Jan 19, 2024

ah, I see, makes sense then

@LGFae
Copy link
Owner

LGFae commented Feb 16, 2024

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
Copy link
Contributor Author

flick0 commented Feb 17, 2024

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
Copy link
Owner

LGFae commented Feb 17, 2024

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
Copy link
Contributor Author

flick0 commented Mar 1, 2024

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

Copy link
Contributor

@Akida31 Akida31 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

src/cli.rs Outdated Show resolved Hide resolved
src/cli.rs Show resolved Hide resolved
src/main.rs Outdated Show resolved Hide resolved
@LGFae
Copy link
Owner

LGFae commented Mar 11, 2024

@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
Copy link
Contributor Author

flick0 commented May 30, 2024

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

@LGFae
Copy link
Owner

LGFae commented May 31, 2024

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
Copy link
Contributor Author

flick0 commented Jun 1, 2024

ill do it on a new pr later

@LGFae LGFae merged commit ceb6306 into LGFae:main Jun 11, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

change name of clear arg to color
3 participants