ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
waxwing99d ago
Linux desktop stuff is such a mystery to me. This honestly seems batshit insane, but in GTK3, it appears that if you use a FilePicker, something like (Rust here but w/e): rfd::FileDialog::new().set_directory(&my_specific_dir).pick_folder() ... it refuses to open the file picker in your specified directory. It just flat out ignores you, and *always* opens the dialog in its "Recent Items". So not complaining about a default (though it's a terrible one honestly), but the baffling decision to just ignore the developer's setting. I would love to find any justification of this anywhere, but I can't. This "documentation" ( https://docs.gtk.org/gtk3/method.FileChooser.set_current_… ) just points at a non-existent other documentation section to justify why you shouldn't use the function (Not "deprecated" but "warning, you'd better not use this function, but we won't tell you why!"). The code itself basically defaults to recent items, and that can *only* be overwritten with a GTK setting, outside of the developer's control, and here's the best bit: if you somehow get your user to override it, they can *only* change the location the FilePicker opens in, to $HOME! Your directory setting will still get ignored! Btw this restriction did not exist in the previous GTK version; they actively added it as an improvement. #linux
💬 3 replies

Replies (3)

Matt Corallo99d ago
But nothing documents that it simply does not work at all. Probably worth filing a bug, maybe they broke it accidentally but at least docs should be updated.
0000 sats
waxwing99d ago
Pretty sure it's deliberate. Despite quite a few people (especially users!) complaining about it.
0000 sats
Matt Corallo98d ago
Ugh
0000 sats