elkowar / eww

ElKowars wacky widgets
https://elkowar.github.io/eww
MIT License
9.44k stars 384 forks source link

feat: update to 1.80.1 toolchain; dependency updates #1144

Closed w-lfchen closed 2 months ago

w-lfchen commented 3 months ago

Description

specific details on some crate updates can be found below motivated by and closes #1141 closes #1156 motivated by NixOS/nixpkgs#332957 (eww is currently building in nixpkgs through a lockfile patch) supersedes #1137 (patch has been applied in a004136779fb0dd0a710d7947158f928e7a8a140) supersedes #809 (see below), therefore also closes #808 basic functionality tested (systray not tested, my config does not contain one) reduces build times by dropping ~40 crates in the dependency tree

dbusmenu-glib breaks when automatically updating the missing dependencies

i don't know enough about this to even attempt to fix it, but i'd love to integrate a fix before opening this pr.

after 4cf9d2d7e460af8f0ff5fcc5378615be95d3ed0e

running cargo update --dry-run yields the following:

    Updating crates.io index
     Locking 6 packages to latest compatible versions
      Adding gdk-pixbuf-sys v0.20.0
      Adding gio-sys v0.20.0
      Adding glib v0.20.0
      Adding glib-macros v0.20.0
      Adding glib-sys v0.20.0
      Adding gobject-sys v0.20.0
note: pass `--verbose` to see 63 unchanged dependencies behind latest
warning: not updating lockfile due to dry run

When adding these crates by simply running cargo update, dbusmenu-glib fails to compile:

error[E0433]: failed to resolve: could not find `ObjectExt` in `glib`
   --> <home>/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dbusmenu-glib-0.1.0/src/auto/client.rs:203:15
    |
203 |         glib::ObjectExt::property(self.as_ref(), "dbus-name")
    |               ^^^^^^^^^ could not find `ObjectExt` in `glib`
    |
help: a struct with a similar name exists
    |
203 |         glib::Object::property(self.as_ref(), "dbus-name")
    |               ~~~~~~
help: consider importing this trait
    |
6   + use glib::prelude::ObjectExt;
    |
help: if you import `ObjectExt`, refer to it directly
    |
203 -         glib::ObjectExt::property(self.as_ref(), "dbus-name")
203 +         ObjectExt::property(self.as_ref(), "dbus-name")
    |

there are multiple errors like this one, since the dbusmenu-gtk3 crate and a few others that seem to be linked to it are auto-generated, something probably needs to be adjusted in the generation process.

before 4cf9d2d7e460af8f0ff5fcc5378615be95d3ed0e

running cargo update --dry-run yields the following:

     Locking 4 packages to latest compatible versions
      Adding gdk-pixbuf-sys v0.20.0
      Adding gio-sys v0.20.0
      Adding glib-sys v0.20.0
      Adding gobject-sys v0.20.0
note: pass `--verbose` to see 90 unchanged dependencies behind latest
warning: not updating lockfile due to dry run

note that everything seems to work without them and that gdk-pixbuf-sys seems to depend on the other 3. When adding these crates, dbusmenu-glib fails to compile:

    |
586 |             FromGlibPtrContainer::from_glib_none(ffi::dbusmenu_menuitem_get_children(self.as_ref().to_glib_none().0))
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `glib::translate::FromGlibPtrArrayContainerAsVec<_, *mut glib_sys::GList>` is not implemented for `menuitem::Menuitem`, which is required by `Vec<menuitem::Menuitem>: glib::translate::FromGlibPtrContainer<_, *mut glib_sys::GList>`
    |
    = help: the following other types implement trait `glib::translate::FromGlibPtrArrayContainerAsVec<P, PP>`:
              <menuitem::Menuitem as glib::translate::FromGlibPtrArrayContainerAsVec<*mut DbusmenuMenuitem, *const *mut DbusmenuMenuitem>>
              <menuitem::Menuitem as glib::translate::FromGlibPtrArrayContainerAsVec<*mut DbusmenuMenuitem, *mut *mut DbusmenuMenuitem>>
    = note: required for `Vec<menuitem::Menuitem>` to implement `glib::translate::FromGlibPtrContainer<_, *mut glib_sys::GList>`

there are multiple errors like this one.

re-enable grass default features

80a5a453c71f697f23822b2aa59945ccf126c803 re-enabled default features. running cargo clean && cargo build produced the exact same compilation times for me, so the argument brought up in #606 no longer holds.

derive_more v1.0.0

the most notable breaking change is that now, all features should be enabled manually, which i've done.

Checklist

w-lfchen commented 3 months ago

everything should be up to date at the time of writing this

elkowar commented 2 months ago

Thank you so much for your work!