why demand filechoosers to be native while all other widgets are not?
Announcement
Collapse
No announcement yet.
GTK+ 3.19.2, More CSS Changes For The Toolkit
Collapse
X
-
-
Originally posted by Delgarde View Post
More than that - along with OSX, it's just about the only test case. The idea of a native file chooser makes sense on Windows and OSX, where for a given build of Gtk+, there's a single native toolkit to support. Not so much on Linux, where a single binary would have to adapt at runtime to whatever desktop it was running in, and with some ability to link to every single other toolkit that might be providing a chooser. That's a lot less feasible to implement...
at least as i see it, portal like service could be used even out of sandboxing. in the end it is nothing but IPC api. would be even better if DEs put their heads together and declare that common IPC. not only they could create their own custom API, DE could be in charge which service provider is used for that. and this way all DEs would always get their native dialogs and access to file even if native vfs does not provide it
Comment
-
Originally posted by justmy2cents View Post
you're kind of right about not making sense implementing it directly.
at least as i see it, portal like service could be used even out of sandboxing. in the end it is nothing but IPC api. would be even better if DEs put their heads together and declare that common IPC. not only they could create their own custom API, DE could be in charge which service provider is used for that. and this way all DEs would always get their native dialogs and access to file even if native vfs does not provide it
Comment
-
-
Originally posted by bitman View Post
That. Tbh native file chooer/folder chooser/probably smth else should have been part of xdg spec.
- Likes 1
Comment
Comment