Hello, thank you very much for your reply. 2010/3/26 Jeremy Huddleston <jeremyhu@apple.com>:
Hi Marcelo,
Thanks for contacting us. XQuartz itself does not participate in the GSoC, but Xorg does. I'd certainly be willing to mentor you in this process through the Xorg GSoC.
First of all, check out http://wiki.x.org/wiki/SummerOfCodeIdeas for the application process. I think you have taken on quite a number of goals which might not all be possible to tackle in a single summer. I would love to chat with you sometime to get a sense of your background and what you might be able to accomplish during the summer.
I'm afraid that it is true. Unfortunately, I don't have an idea of how much work this will require. It is important to discuss which improvements are more feasible to do.
Using quartz-wm to better interface between OSX and X11 has been a longstanding goal, but it has been difficult to tackle because we've mainly been playing catchup to get our DDX working on master (finally achieved that at this past XDC) and playing wack-a-mole on issues that have been cropping up.
Right now, the two biggest sore-spots (IMO) are still GLX and copy/paste. Both of these are leaps and bounds better than they were in the 2.2.x days (and so much more so than what shipped with Leopard), but there are still major issues that need to be addressed in both of those subsystems.
COMPOSITE, EXA, RandR, and increased WM functionality in quartz-wm are probably the four biggest blank-slate projects that we have. The Quartz EXA driver is probably the easiest to implement of those three. Supporting COMPOSITE would certainly be the most challenging.
The windows are actually native windows, but not NSWindows. They should resize and move using Universal Access... if they don't, can you tell me how to test that (I don't have much experience with Universal Access other than my research into getting the window title reported).
Sorry, I was not very specific about this. Actually, you may resize and move manually through Universal Access using "mouse keys", which is useful. However, I guess the resizing and moving using "assistive devices" does not work for X11 windows, as you may see by testing through scripts (such as the one I have attached) or window handling softwares, like BetterTouchTool or Cinch. I don't know what causes this limitation.
The separate dock icon is probably the most difficult to handle. I've given some thought to this, and it comes down to this:
1) Each icon in the corresponds to a different process. 2) quartz-wm would need to act like a gnome/kde/xfce taskbar for X * I don't know this protocol myself, but it should be on X.org
quartz-wm would probably need to fork itself to create a new process which registers with the Dock for each X11 taskbar icon: When that forked process is killed, it would need to xkill the client. When that forked process is activated through the Dock, it would need to force X11 to become the active app and then move its associated window to the front.
The down side is this could result in a ton of icons (one per xterm), so you could do grouping where you let similar processes correspond to one forked quartz-wm-taskbar-manager process.
As a workaround for a missing dock icon, I've created a simple wrapper to my favorite GTK text-editor using a bash script inside an .app to launch the binary target with file arguments or simply bring X11 window to front. It doesn't have all the features I wanted, though. Maybe a simpler solution would be implementing a nice wrapping utility function which exports an .app given a binary file. So, only the wanted applications would have a separate dock icon, others would stay in X11 one.
I'm not sure a good task-bar manager to look at for example code. I think the big three (Gnome, XFCE, and KDE) are all GPL, right?
Anyways, that's probably a bit more detail than you need right now. Let me know if you have time to chat 1-on-1 about this sometime this coming week.
Yes, I guess we could do that. I am awake usually between 11 a.m. to 1 a.m. UTC. This next Monday is a good option to me. Regards, -- Marcelo Galvão Póvoa