[Xquartz-dev] Google Summer of Code 2010 Project

[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 at gmail.com> escreveu:
> Hello, thank you very much for your reply.
>
> 2010/3/26 Jeremy Huddleston <jeremyhu at 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
>