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)
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
#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
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.
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)
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...
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
> 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:
I'll wait for Preview 3 since there are several outstanding bugs.