idea: split XConfig definition into its own file
Hi all, How do people feel about splitting the definition of XConfig out of Core.hsand into its own file, XConfig.hs? (It could then be re-exported from Core.hs, of course, so no changes would be required to anything else.) The point of this would be so people who are trying to write their xmonad.hs and want to see what fields are available don't have to wade through all of Core.hs to find it. Such an XConfig.hs would also be a good place to provide some nice, detailed Haddock documentation explaining what each of the different fields are, and how to use them. I'd be happy to make the changes myself, just thought I'd run it by the list first to see what people think. -Brent
On Sat, Nov 17, 2007 at 11:40:55AM -0500, Brent Yorgey wrote:
Hi all,
How do people feel about splitting the definition of XConfig out of Core.hsand into its own file, XConfig.hs? (It could then be re-exported from Core.hs, of course, so no changes would be required to anything else.) The point of this would be so people who are trying to write their xmonad.hs and want to see what fields are available don't have to wade through all of Core.hs to find it. Such an XConfig.hs would also be a good place to provide some nice, detailed Haddock documentation explaining what each of the different fields are, and how to use them. I'd be happy to make the changes myself, just thought I'd run it by the list first to see what people think.
I don't think that the present location of XConfig is a barrier to a good haddock documentation. Do I miss something? (btw, I documented each record field of XConfig in a patch that has been committed yesterday, and I've just discovered that the darcs version of haddock[1] properly deals with newtype deriving, which means that everyone may be generating the haddock documentation.) Did you see the work I'm doing with documenting all this stuff[2]? Andrea [1] http://code.haskell.org/haddock/ [2] http://gorgias.mine.nu/xmonad/xmonad-contrib/Documentation.html
I don't think that the present location of XConfig is a barrier to a good haddock documentation. Do I miss something?
Not technically, except that if XConfig is in Core.hs, the haddock documentation for XConfig will be buried at the end of a very long haddock page for Core.hs. The general idea was to separate documentation for things that the casual user (doesn't know much Haskell but thinks xmonad is cool and just wants to get xmonad working as easily as possible) cares about, such as XConfig, from things that the power user (knows Haskell and wants to contribute their own extension modules, etc.) cares about, such as Core. In general, I strongly believe that the presentation of information is just as important as the actual content.
(btw, I documented each record field of XConfig in a patch that has been committed yesterday, and I've just discovered that the darcs version of haddock[1] properly deals with newtype deriving, which means that everyone may be generating the haddock documentation.)
oh, excellent, I didn't see that yet.
Did you see the work I'm doing with documenting all this stuff[2]?
I did! I think it's great. And I assume you saw the e-mail I just sent with my thoughts on the matter. -Brent
On Saturday 17 November 2007 10:40:55 Brent Yorgey wrote:
Hi all,
How do people feel about splitting the definition of XConfig out of Core.hsand into its own file, XConfig.hs? (It could then be re-exported from Core.hs, of course, so no changes would be required to anything else.) The point of this would be so people who are trying to write their xmonad.hs and want to see what fields are available don't have to wade through all of Core.hs to find it. Such an XConfig.hs would also be a good place to provide some nice, detailed Haddock documentation explaining what each of the different fields are, and how to use them. I'd be happy to make the changes myself, just thought I'd run it by the list first to see what people think.
-Brent
The problem here is that the X monad carries XConfig as part of its state, and XConfig refers to X in some of its components. We should avoid cyclic dependencies as much as possible, I think. Cheers, Spencer Janssen
On Nov 17, 2007 5:58 PM, Spencer Janssen
On Saturday 17 November 2007 10:40:55 Brent Yorgey wrote:
How do people feel about splitting the definition of XConfig out of
Core.hsand into its own file, XConfig.hs?
The problem here is that the X monad carries XConfig as part of its state,
and XConfig refers to X in some of its components. We should avoid cyclic dependencies as much as possible, I think.
Oh, good point! OK, fair enough, no splitting of XConfig. =) -Brent
participants (3)
-
Andrea Rossato -
Brent Yorgey -
Spencer Janssen