OroborOSX v0.8 preview

  • Adrian

    Includes a modified version of XDarwin, to allow some nifty new features, and means it  no longer messes with the standard installed XDarwin...

    Minimise-to-dock; autofocus window interleaving; inactive window translucency and/or dimming; inactive titlebar translucency; background mouse tracking; smoother window resizing (slightly faster, too, perhaps?); "hot swapping" of interleaving; ssh-agent support; window-resize/movement indicators in titlebar; more information available directly from menus; lots more... (see the history web page).

    Released as a preview version, since I expect the new interaction between the modified XDarwin and OroborOSX will throw up some issues, and also because some of the info files and new menu items still need translating.



    • On exit, this version crashes ("has unexpectedly quit") systematically. Here is the output of the crashreporter:

      Date/Time:  2002-03-28 14:00:00 +0100
      OS Version: 10.1.3 (Build 5Q45)
      Host:       hilbert.univ-rennes1.fr

      Command:    OroborOSX
      PID:        18069

      Exception:  EXC_BAD_ACCESS (0x0001)
      Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xffffa913

      Thread 0 Crashed:
      #0   0x004bffe8 in 0x4bffe8
      #1   0x00cf00e8 in 0xcf00e8
      #2   0x0029afc8 in _XFlush
      #3   0x00283974 in XFlush
      #4   0x00020ac4 in SendSimpleHackCommand
      #5   0x000203d0 in DoEvent
      #6   0x0001fadc in EventLoop
      #7   0x000021bc in main2
      #8   0x0000225c in main
      #9   0x00001d40 in _start
      #10  0x00001b70 in start

      Thread 1:
      #0   0x70000978 in mach_msg_overwrite_trap
      #1   0x70005a04 in mach_msg
      #2   0x70026a2c in _pthread_become_available
      #3   0x70026724 in pthread_exit
      #4   0x70020550 in _pthread_body

      PPC Thread State:
        srr0: 0x004bffe8 srr1: 0x0000f030                vrsave: 0x00000000
         xer: 0x00000004   lr: 0x002b5f0c  ctr: 0x004bffeb   mq: 0x00000000
          r0: 0x004bffeb   r1: 0xbffffaf0   r2: 0xbfffb6f0   r3: 0x00223cb0
          r4: 0x01c22840   r5: 0x00000040   r6: 0xfffffc18   r7: 0x00000014
          r8: 0x00000003   r9: 0x00019afb  r10: 0x01c2286c  r11: 0x00349170
         r12: 0x004bffeb  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
         r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00000000
         r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
         r24: 0x00000000  r25: 0xbffffeb4  r26: 0x00000000  r27: 0x00000040
         r28: 0x01c25be0  r29: 0x00000040  r30: 0x01c22840  r31: 0x0029af24

      • Adrian

        OK, I know what's happening here.

        Basically, it's getting and processing the QUIT AppleEvent before it has come out of the menu selection routine. Then it does one last call to the X server, which obviously fails.

        It's not 100% likely to happen (I don't get it very often on mine, just occasionally) which I expect is because it does get out of the menu selection and call XFlush before it processes the QUIT event...

        Anyway, at least I can easily clear up this one.



    • philipp

      Hello Adrian,
      I have a Dual Monitor Dual Display Card setup.
      When Xterm starts, as soon as I try to grab the Xterm-Window with the mouse, it will disappear.
      If I try to grab the Xeyes Window, it will disappear and reappear on the upper right of the screen.
      left: second screen, 1024x768
      right: main screen 1600x1000

      left screen is placed (regarding the vertical position) in about the center of the main screen)

      • Adrian

        Yes, this is the "mouse-warping" with Xinerama that I mention on the web site.

        I've now ripped out the horrific hack I was using to send messages from XDarwin to OroborOSX (using false mouse events), and replaced it with sockets.

        It seems to work as well as before for me (actually, better in some ways, because I don't have to inhibit the events like I did before under some circumstances), so I will release "preview 2" soon...



    • Paul Bayley
      Paul Bayley

      I love the changes, even if they are buggy at this time (trying Preview 2). I opened an xterm and it froze |-). Also un-shading my 'nextish' themed window caused weird effects |-).

      I love the fact that you're using your own copy of XDarwin now. In the future all I'll have to do is install the xfree base from Fink and OroborOSX.

      It also takes a looong time to launch. Hopefully now that you use your own XDarwin copy this can improve.

      XDarwin and OroborOSX and .orobxinitrc appear to be using idle CPU.

      Anyway rock on

    • Adrian

      > I opened an xterm and it froze

      Ouch! -let me know if the "sleep" thing helps with that. (Not sure why it should, but you never know...)

      > using your own copy of XDarwin now

      Sure bumps up the download size. About 75% of it is just the XDarwin executable (not even the rest of the XDarwin app bundle!)

      > un-shading my 'nextish' themed window caused weird effects

      Can you describe? Or post a screen shot (URL or attach a section to an email)?

      Ah! Maybe you mean that it did not all draw correctly? I suspect this is related to the drawing glitch for non-shaped windows (mentioned in the version history for the upcoming preview 3).

      Try replacing the XDarwin executable with this one:


      It should replace the executable in the private XDarwin app's bundle:


      This should fix the drawing glitch which occurs with non-shaped windows, so let me know if it sorts out the "weird effects".

      > It also takes a looong time to launch.

      This extra wait for the display number (from xinitrc) does add to the time. It seems to take XDarwin a very long time to get around to running the xinitrc script.

      There's a thread over at the OroborOSX "Open Discussion" forum that has a little more on this.

      > XDarwin and OroborOSX and .orobxinitrc appear to be using idle CPU.

      .orobxinitrc should not really be noticeable while idle - I suspect this will go away once the "sleep" thing is fixed.

      OroborOSX does have to do numerous checks while "idle", unfortunately. (Since it queries XDarwin about certain things, XDarwin uses some time too.)

      I'm soliciting more feedback about this over in the discussion forum, too. If you want to contribute any CPU percentages (via "top" or process viewer) check it out:




      • Paul Bayley
        Paul Bayley

        I'll wait for Preview 3 since there are several outstanding bugs.