Is there a way to deactivate the active X11 window when XDarwin isn't in the foreground?
>Is there a way to deactivate the active X11 window when XDarwin isn't in the foreground?
No. This is filed as a bug with out bug tracker here. Unfortunately, this is unlikely to be fixed in time for XFree86 4.2.
This is possible only with window manager support or possibly a cooperating X11 program.
OroborOSX does this }:-p
I'll have to investigate to see if I can change the appearance of oroborOSX. The default one isn't usable.
Why is that? Is it to do with the click-to-focus? Or the first click not being sent through to background windows? (Something I'm going to allow with an option, since there are the odd few X11 apps which seem to have somehow 'congealed from the primeval soup' with this requirement...)
One of the things I'm considering how to do is support other window managers -by having a 'SwitchWM' menu (or something) which lists various window managers (OroborOSX would search for them when it is first launched).
When a window manager is chosen from the list, OroborOSX will switch off its own window manager and start up the chosen one.
There are some difficult issues with this (like how to still intercept the X11 windows when OroborOSX is no longer the window manager...) but it's an interesting thought!
Another thing you could do is check out the themes directory in the application bundle. The folder(s) in there contain loads of pixmaps which are used for the window widgets.
You could fairly easily fiddle around with them to get something to your liking. -Somebody has created a 'graphite' theme for me which I will include with the next release.
Note that the first line of the oroborosxrc file (in the app bundle somewhere) gives the name of the theme folder to use...
Anyway, I'm really interested to know what it is you'd like to see changed -I want to make it as flexible as possible!
I actually prefer click-to-focus and eating the focus click (not sending it through). I set wmaker to do this.
The problem I have is OroborOSX tries to make X11 windows look like aqua. I'm trying to convert the oroborus next theme for OroborOSX using GraphicConverter. This shoudn't take long. If it works well I'll send you the theme.
As for the behavior of OroborOSX, it seems to be very good. I like being able to select a specific window from the Dock. One problem is I don't keep XDarwin.app in /Applications. Perhaps Oroborus should keep a copy of XDarwin in it's own bundle now that it doesn't have to be in /Applications. I have mine in /Applications/Extras and it works fine. This would remove the requirement of running that terminal script.
>If it works well I'll send you the theme.
Got it! -but gunzip (and MacGzip) claims it's not in gzip format...?
Anyway, Stuffit Expander in OSX did it OK...
>One problem is I don't keep XDarwin.app in /Applications.
As it happens, I'm working on removing this requirement!
The only problem I have is to do with the 'xinit' command. This uses the links in /usr/X11R6/bin which point to the 'real' location of XDarwin (/Applications/XDarwin.app/Contents/MacOS/XDarwin). -Maybe I'll have to require that users set this up correctly...?
Currently, in the alpha 4 version I'm working on, once XDarwin is actually running then everything is fine -I have it check for its location. The interleave/uninterleave can then be toggled from the Options menu item (-that's been there since v0.7! But it does require a restart of XDarwin...)
I just have to sort out this rather out-of-date WaitNextEvent loop I'm using, replacing it with Carbon Events, and then interface with the nib-based password dialog box (which has also been there since v0.7)...
>Perhaps Oroborus should keep a copy of XDarwin in it's own bundle
I've been thinking about this -even supplying a modified version that guarantees interleaving works 100% (it's not too hard to fiddle the source code to do this).
The main issues I can see, apart from keeping it up-to-date with 'normal' XDarwin, are that it could somehow mess with 'the real thing' (...?) and it would mean supplying the modified source code as part of the building process.
There's also the issue of whether, technically, this modified code has to be committed to the XFree CVS...? I'm a complete newcomer to all this, so I just don't know... can anyone clarify?
>>One problem is I don't keep XDarwin.app in /Applications.
>As it happens, I'm working on removing this requirement!
You should be able to use Launch Services to find the application bundle for org.xfree86.XDarwin. As long as the user puts XDarwin.app in a place that is somewhat sensible for Mac OS X applications or launches XDarwin.app once manually, Launch Services should be able to find it. This is eventually how XDarwinStartup will work, so the XDarwinQuartz soft link will no longer be needed.
>The main issues I can see, apart from keeping it up-to-date with 'normal' XDarwin, are that it could somehow mess with 'the real thing' (...?) and it would mean supplying the modified source code as part of the building process.
It would require building XDarwin for yourself, which requires keeping around the (rather large) XFree86 source. Note, there is no requirement to supply the modified source code to anyone else.
>There's also the issue of whether, technically, this modified code has to be committed to the XFree CVS...?
It does not have to be committed to XFree86 CVS and probably should not be. You don't have to share your modifications with anyone, although you are welcome to. The preferred way to make your modifications available would be as a bunch of patches to the top of the tree of XFree86 CVS, which you would have to update from time to time.
The main problem with this approach is just that it adds a lot of overhead to keep in sync with XFree86, which is a big moving target. However, since OroborOSX is likely to change greatly in the next few months once XDarwin absorbs many of its features, you may decide that this is the best short term solution.
He doesn't have to use Launch Services or whatever to find the XDarwin.app bundle if he just bundles his own copy of XDarwin in this own app. Right now he has to modify the XDarwin.app bundle which renders it useless as a stand-alone app. For this and other reasons I think it would be better just to bundle his own copy of XDarwin.app in OroborOSX.app
As to the first question, I didn't know you used xinit. XDarwin 1.0.4 doesn't appear to care where I put the app. For weeks I had XDarwin.app in a non-traditional location (and nothing in the traditional location) and it worked fine. As a side-note I don't like Apple or anybody else telling me where to put my apps. I noticed that the 10.1.1 update created some Mail.app-related files in my /Applications directory which weren't placed correctly just because I put Mail.app somewhere else. Ugh, damn UNIX.
Anyway I don't think it would be a problem if you just embed a copy of XDarwin in the OroborOSX app bundle. I think this is a good idea for not only this problem, but also the fact that OroborOSX is designed for a specific version of XDarwin and upgrading them both at once will reduce incompatibilities in the future.
As for code submission, there is no problem because OroborOSX doesn't link to XDarwin. They are separate applications. The only code you would have to submit is if you made changes to the XDarwin source (which if you made any I'm sure you would want to do anyway)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.