Google Summer of Code 2010 Project
Hello, I'm a student interested in participating in GSoC 2010 and I would like to submit an idea for a coding project to X.org. I've already suggested it on their mailing list but I don't know yet if it is feasible because of technical difficulties or proprietary source code issues with Apple. My project would concern in providing a better Mac OS and X server integration in some key user-oriented aspects such as: - Separate every application window in its own dock icon and make it fully featured, including drag and drop files, exposé, etc. - Transform X windows into "native" windows, so they accept features such resize and move using Universal Access and dragging content into it. - Provide smoother scrolling via mouse/trackpad. - Maybe some other nice features :) This would benefit mostly users of GTK or wine applications like me. I don't know about X11 implementation. Does someone know if it a reasonable project? Any comment will be appreciated. Regards, -- Marcelo Galvão Póvoa
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. 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). 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. 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. Thanks, Jeremy On Mar 25, 2010, at 21:02, Marcelo Galvão Póvoa wrote:
Hello, I'm a student interested in participating in GSoC 2010 and I would like to submit an idea for a coding project to X.org. I've already suggested it on their mailing list but I don't know yet if it is feasible because of technical difficulties or proprietary source code issues with Apple.
My project would concern in providing a better Mac OS and X server integration in some key user-oriented aspects such as: - Separate every application window in its own dock icon and make it fully featured, including drag and drop files, exposé, etc. - Transform X windows into "native" windows, so they accept features such resize and move using Universal Access and dragging content into it. - Provide smoother scrolling via mouse/trackpad. - Maybe some other nice features :)
This would benefit mostly users of GTK or wine applications like me.
I don't know about X11 implementation. Does someone know if it a reasonable project?
Any comment will be appreciated.
Regards, -- Marcelo Galvão Póvoa _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
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
Hello Jeremy, I'm about to write my application for X.org and would like some more information. Unfortunately, you have not replied to my last email, so I'm quite confused on whether I have a reasonable project idea or not. Since you also stated that I may be claiming too much work, I would like to ask you to suggest which aspects are more feasible to include in my application. Sorry for any inconvenience. Regards, Marcelo Galvão Póvoa Em 26 de março de 2010 10:11, Marcelo Galvão Póvoa <marspeoplester@gmail.com> escreveu:
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
participants (2)
-
Jeremy Huddleston
-
Marcelo Galvão Póvoa