[Xquartz-dev] code cleanup, combining quartzBlah.c and darwinBlah.c, etc, etc...

[Ben Byer]

On Dec 4, 2007, at 12:36 PM, Jeremy Huddleston wrote:
>
>> I'd say killing off fullscreen is probably not a great idea since we
>> do want to get it working at some point.  I'm also not thrilled about
>> killing off cr, since I think it's actually potentially a better way
>> of doing the server.  It's not like you really have to *look* in  
>> those
>> dirs...
>
> Sorry, I sent that email long before it actually got through and  
> just assumed apathetic response and killed them off (we can bring  
> them back easily if they're ever needed).
>
> Fullscreen support would be great (and is a high priority), but the  
> code in fullscreen/ is not how to do it.  AFAICT, that code never  
> even worked.

Correct.  Fullscreen support in Tiger worked because our graphics team  
put lots of hooks in lots of places to get it working such that you  
could switch back and forth;  the breakage happened when XDarwin tried  
to clean those hooks up and restore abstraction.   So, if anything, we  
would want our code to be more like the Tiger X11.app than XDarwin.

> As for cr, I agree it would be neat to use native windows maybe and  
> lightening the responsibility of quartz-wm... but I think that would  
> be best for a bigger rewrite at some point down the line (and be  
> kdrive based).

nonononono
I *think* this is a misunderstanding of the nature of cr -- although  
its simplicity might seem attractive in the face of weird event  
issues, it is not what you want to do.  If anything, we want to get  
Xplugin enhanced so that we can integrate *more* with Quartz -- so  
further in the direction of xpr.

> If I actually am misunderstanding some understanding here (QUITE  
> possible), please let me know and I'll bring them back.  I agree cr  
> could be useful and I was most hesitant about getting rid of it (it  
> was removed from the official xorg-server tarballs but still in git,  
> so I decided just to kill it off for consistency).
>
> ---
>
> The main reason I'm doing this is the dependencies, headers, etc are  
> all garbled up.  We've got just about every .c file pretty much  
> including every .h file and making their own prototype declarations  
> and extern declarations.  I'm going to clean this up a bit.   
> Additionally, I'm going to put the function prototypes for interface  
> functions (DarwinModeBlah) into their own header file (like  
> darwinKeyboard_interface.h) which will be included by the  
> implementer (like quartz/quartzKeyboard.c) rather than  have  
> quartzKeyboard.c include all of darwin.h and darwinKeyboard.h. ...  
> and similarly for quartz's interface to xpr (or cr or a future  
> kdrive based version).


Yeah.  Most of the cruft is from the aforementioned abstraction -- as  
in almost anything with Mode or Bundle in the function name.
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer