Less dependence on /usr/X11R6?

2001-08-13
2001-08-16
  • Paul Bayley

    Paul Bayley - 2001-08-13

    Has anybody seen an implementation of XFree86 which wasn't installed in /usr?

    I found that re-installing X11 is a pain in the butt compared to other OS X apps. Instead of just dragging an app and maybe a couple frameworks I have to copy stuff in /usr and make symlinks as root.

    Ideally X11 would be bundled in a framework in X11.framework/Versions/R6/ with headers in Headers and the other files in Resources. This framework could then be placed in one of these locations:

    /Library/Frameworks
    ?network/Library/Frameworks
    ~/Library/Frameworks
    AppBundle/Contents/Library/Frameworks

     
    • Greg Parker

      Greg Parker - 2001-08-14

      In a perfect world, that would be great, and mapping X11 into a framework+application actually works well. Ideally, X11 would be an umbrella framework with other X11 libraries as sub-frameworks.

      The problem that it's incompatible with every configure and Makefile in the world, which expect X11 to live in one of a few expected locations. No program or library would install without changing various -I and -L options to -framework X11. It would also break binary compatibility with Xtools.
      A package manager like fink might be able to do it, as long as nothing but those packages are used. Adding a symlink from /usr/X11R6 to X11.framework and some symlinks inside the framework (e.g. X11.framework/libs -> X11.framework/Libraries, X11.framework/include -> X11.framework/Headers) would preserve binary compatibility.

       
    • Torrey T. Lyons

      Torrey T. Lyons - 2001-08-14

      As Greg said, this would be the case in a perfect world, but unfortunately X11 has a huge amount of legacy. On most platforms X11 is an essential part of the OS, not an add on application. Its design and use has evolved with this in mind. As Greg mentioned, it would be easy to move everything into one bundle, but the bundle wouldn't be very useful. You would have to go through and change every single X11 application out there to get it to work with this non-standard X11 distribution. This would be a ton of work, for not a great amount of payoff. In this respect, we ultimately should take our lead from Apple. Apple dropped putting legacy libraries in Frameworks, as it meant that every application using the library had to be modified. Their current policy is that frameworks are for new projects. For legacy stuff where a well known usage is already in place, they don't use frameworks. An example is the TCL stuff which used to be in a framework, but moved to /usr/include and /usr/lib for Mac OS X 10.0.

       
      • Paul Bayley

        Paul Bayley - 2001-08-15

        Yes, but why did Apple do that instead of making the linker a little smarter instead.

        I don't like where everything is headed, which is to say 30 years ago. It sucks. It really really sucks.

        Consider two examples:

        Qt for OS X is classic (I hate Qt for OS X, but it's only an example). Instead of making a Qt.framework they made a .dyldlib.3.0.0 (gawd I love the /usr/lib versioning madness) and told people to install this in the lib, then edit your .profile or whatever to change env variables so Qt could find all it's resources and crap! Interesting that Frameworks solve ALL THIS CRAP without having to mess with /usr or with env variables.

        SDL from the cvs can be built either as a framework or as a .dyldlib.0.1.2.234f6 or whatever. Now how long will it be before SDL developers start making installers which mess around in /usr to install the dyldlib.0.1.2.blah version instead of a framework?

        You know how easy it is to maintain several boot volumes and one ~/Library? Very easy, until programs start looking for crap in /usr/lib

         
        • Greg Parker

          Greg Parker - 2001-08-15

          Yes, frameworks are a convenient organizational system. However, changing to frameworks requires modifications to the preprocessor, the compiler, the linker, makefiles and configuration scripts for every program, and all third-party libraries.

          XDarwin must work portably and backward-compatibly. Frameworks are neither. We are using twenty year old techniques because we are trying to work with twenty year old software.

           
    • Paul Bayley

      Paul Bayley - 2001-08-15

      And let me say I don't mind cleaning up some code to make the framework work, just for my own personal use.

      I didn't mind it for system files in System.framework in public beta.

       
    • Patrik Montgomery

      I've been thinking some about this, and I'm forced to agree with Greg and Torrey. This would make it a lot harder to compile stuff for X on Darwin/Mac OS X - unless we make symlinks for all the directories, which rather defeats the purpose of making it easier to install.

      If we're on the subject of making X more Mac-like, would it be possible to make it an app without an interface, the settings in System Preferences? At least we could get rid of show/hide menubar in rootless. You could quit if from the Dock icon, and it should be possible to add a Hide command to that menu as well (at least in 10.1).

       
      • Paul Bayley

        Paul Bayley - 2001-08-15

        I think making a preference panel would be a complete waste of time, not to mention a pain in the butt to use.

        Implementing hide and windows in XDarwin sounds useful however.

         
        • Patrik Montgomery

          What I want is to completely remove the menubar in rootless mode, because I keep using hide/show on it. If the prefs dialog could be brought up by right-clicking the dock, fine.

           

Log in to post a comment.