bscreensaver/dialog-gtk3/Cargo.toml

[package]
name = "bscreensaver-dialog-gtk3"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1"
bscreensaver-util = { path = "../util" }
chrono = "0.4"
gethostname = "0.4"
glib = { version = "0.18", features = ["log"] }
gtk = "0.18"
gtk-sys = "0.18"
gdk-sys = "0.18"
gdkx11 = "0.18"
log = "0.4"
pam-client = "0.5"
shell-words = "1"

[build-dependencies]
# pam-sys specifies default-features = false, which drops the 'runtime'
# feature; this ends up conflicting with the xkbcommon-sys build in another
# module, which causes pam-sys to fail to build
bindgen = { version = "0.69", features = ["runtime"] }
Initial import. Most things seem working. This includes an abortive attempt to do a gtk4 dialog (which I don't think is possible, as gtk4 doesn't allow embedding toplevels anymore), and an iced dialog, which I just never started writing. 2022-05-04 00:05:06 +00:00			`[package]`
			`name = "bscreensaver-dialog-gtk3"`
			`version = "0.1.0"`
			`edition = "2021"`

			`[dependencies]`
			`anyhow = "1"`
			`bscreensaver-util = { path = "../util" }`
			`chrono = "0.4"`
Update all dependencies 2024-08-02 18:21:48 +00:00			`gethostname = "0.4"`
			`glib = { version = "0.18", features = ["log"] }`
			`gtk = "0.18"`
			`gtk-sys = "0.18"`
			`gdk-sys = "0.18"`
			`gdkx11 = "0.18"`
Initial import. Most things seem working. This includes an abortive attempt to do a gtk4 dialog (which I don't think is possible, as gtk4 doesn't allow embedding toplevels anymore), and an iced dialog, which I just never started writing. 2022-05-04 00:05:06 +00:00			`log = "0.4"`
Use PAM properly, which allows us to handle other auth types Previously I was just presenting a static username/password box, and then running PAM with pre-set credentials. This works just fine when PAM is expecting a username and password, but if it's expecting something like a fingerprint scan or a hardware security token, this wouldn't entirely work right. Well, it would "work", but the username/password dialog would be displayed, and then hitting "Unlock" would start a different auth process with no visible feedback as to what's supposed to happen. This also means I need to switch PAM wrapper crates; the one I was using before did not allow passing a fixed username to the underlying pam_start() call, which meant that PAM would try to prompt the user for it, which is not what we want. 2022-08-15 05:17:58 +00:00			`pam-client = "0.5"`
Add 'New Login' button to unlock dialog 2022-05-04 07:22:00 +00:00			`shell-words = "1"`
Update all dependencies 2024-08-02 18:21:48 +00:00
			`[build-dependencies]`
			`# pam-sys specifies default-features = false, which drops the 'runtime'`
			`# feature; this ends up conflicting with the xkbcommon-sys build in another`
			`# module, which causes pam-sys to fail to build`
			`bindgen = { version = "0.69", features = ["runtime"] }`