4 ms·

X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically f

by dzaima 5y ago

X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically for just opening a file/folder open/save dialog). X11 itself doesn't provide that much beyond opening & managing windows (and the copy&paste mess it provides is, well, a mess.)

stormbrew 5y ago
Sure, but the question wasn't "will a file dialog open at all" it was "will it open in a weird place". If the app was using gtk and you're running it in a chroot with period-appropriate gtk that gtk file open dialog will probably open just fine, and then it's a matter of if you bind mounted your homedir and /etc into the chroot so it'd know where to go. From there it'll open in approximately as weird (or un-weird) a place as it did in 2007. Like, this isn't a problem almost specifically because x11 isn't trying to do anything very clever here. There's no OpenFileDialog along with an OpenFileDialogEx and OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going. If your program had a file dialog then, it has one now. It's probably just ugly. As for copy/paste, it is a bit of a mess but it's a mess that works pretty well for this kind of situation. If the copyer and paster windows are in the same x11 context and use the same (widely used) protocol over x11 window properties, they will be able to copy and paste with each other regardless of if they're running natively, in a chroot, in a vm, or on a remote machine. Incidentally I really miss having the second "select/middle click" copy/paste context when I'm using windows or a mac. It's really frickin' useful and by far more useful than almost any other middle mouse button uses I've ever seen in any non-game. But then I also miss having normal copy/paste in the common linux gui terminal emulators so...
account42 5y ago
You can now provide a DE-agnostic way to get the "native" file dialogs via xdg-desktop-portal. Granted that is faily new. > and the copy&paste mess it provides is, well, a mess. Still much better than any windowing system that only has a single paste buffer.

by dzaima 5y ago

stormbrew 5y ago

Sure, but the question wasn't "will a file dialog open at all" it was "will it open in a weird place". If the app was using gtk and you're running it in a chroot with period-appropriate gtk that gtk file open dialog will probably open just fine, and then it's a matter of if you bind mounted your homedir and /etc into the chroot so it'd know where to go. From there it'll open in approximately as weird (or un-weird) a place as it did in 2007. Like, this isn't a problem almost specifically because x11 isn't trying to do anything very clever here. There's no OpenFileDialog along with an OpenFileDialogEx and OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going. If your program had a file dialog then, it has one now. It's probably just ugly. As for copy/paste, it is a bit of a mess but it's a mess that works pretty well for this kind of situation. If the copyer and paster windows are in the same x11 context and use the same (widely used) protocol over x11 window properties, they will be able to copy and paste with each other regardless of if they're running natively, in a chroot, in a vm, or on a remote machine. Incidentally I really miss having the second "select/middle click" copy/paste context when I'm using windows or a mac. It's really frickin' useful and by far more useful than almost any other middle mouse button uses I've ever seen in any non-game. But then I also miss having normal copy/paste in the common linux gui terminal emulators so...

account42 5y ago

You can now provide a DE-agnostic way to get the "native" file dialogs via xdg-desktop-portal. Granted that is faily new. > and the copy&paste mess it provides is, well, a mess. Still much better than any windowing system that only has a single paste buffer.