Announcement

Collapse
No announcement yet.

GTK+ 3.19.2, More CSS Changes For The Toolkit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    why demand filechoosers to be native while all other widgets are not?

    Comment


    • #12
      Originally posted by pal666 View Post
      why demand filechoosers to be native while all other widgets are not?
      You can theme widgets to adapt the typical look of the operating system. But a windows themed gtk+ file chooser still looks alien on the windows platform.

      Comment


      • #13
        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...
        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


        • #14
          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
          That. Tbh native file chooer/folder chooser/probably smth else should have been part of xdg spec.

          Comment


          • #15
            Originally posted by oleid View Post
            You can theme widgets to adapt the typical look of the operating system. But a windows themed gtk+ file chooser still looks alien on the windows platform.
            any complex widget will look alien or require extensive theming

            Comment


            • #16
              Originally posted by bitman View Post

              That. Tbh native file chooer/folder chooser/probably smth else should have been part of xdg spec.
              making it standard IPC API would probably make more sense. you can build anything on that, even xdg spec and being run as bus service would make it user interchangeable. not everything that could use it interacts with xdg

              Comment

              Working...
              X