RE: [Xquartz-dev] code cleanup, combining quartzBlah.c and darwinBlah.c, etc, etc...
For some reason I got a postfix error when I tried to send this the last time. Hopefully it's not a dupe... ---------- Forwarded message ---------- From: Nathaniel Gray <n8gray@gmail.com> Date: Dec 4, 2007 1:49 AM Subject: Re: [Xquartz-dev] code cleanup, combining quartzBlah.c and darwinBlah.c, etc, etc... To: Developer talk about Xquartz <xquartz-dev@lists.macosforge.org> On Dec 3, 2007 11:28 PM, Jeremy Huddleston <jeremyhu@berkeley.edu> wrote:
Unless anyone has an objection, I'm going to spend some time going through, cleaning up header files, adding documentation where I think it's appropriate, and moving around code between files to clean up our layout. I'll probably kill off cr and fullscreen while I'm at it. I need to get a handle on the startup code and events system, and there is alot of cruft getting in the way of my understanding... hopefully by cleaning up some of this stuff, I can clear out dead code and streamline our event pipe a bit.
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... One thing I did to aid my own comprehension of the code was to make a dummy Xcode project and just import "useful" directories. That way you can filter out all the stuff you don't care about, use Xcode's "jump to definition" features and so on. Very handy. Cheers, -n8 --
-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->
--
-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->
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. 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). 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). This cleanup plus associated documentation should help others jump in a little easier. --Jeremy
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
participants (3)
-
Ben Byer
-
Jeremy Huddleston
-
Nathaniel Gray