On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff wrote:

A bluetileConfig could also play a role similar to the template config in providing a reference for people picking and choosing parts of the bluetile configuration, or wanting to activate them all plus a few customizations.

Thanks for bearing with the long-winded saying of: * Yes I agree they should continue as synced separate projects. * Some of the bluetile server commands should be available from contrib. * There should be a bluetileConfig providing all but the dock and greeter bits from bluetile. As much as possible normal Config.Foo customization methods should work, and any deviations be well documented and include integration helper functions if needed.

regards, -- wmw

Here's something I've been thinking. What if we came up with an xmonad.hs that included all the stuff everybody asks for and the obvious newbie aids like a first-run xmesage prompt? (Let's call this a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.) Then we could take the current xmonad package, rename it 'xmonad-core'*; the new 'xmonad' would be basically a cabal file depending on xmonad-core and xmonad-contrib, and an executable reading 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main = xmonad standardConfig'. (xmonad-core's executable would be left alone of course.) If we get ambitious, the new xmonad main could do more. Perhaps we could check for XineRama in main and then modify our standardConfig to use SmartBorders or not? This, I think, could make everyone happy: - The people concerned about keeping the core minimal and pure can tell anyone suggesting 'hey, let's make SmartBorders the default layout' to change the standardConfig and leave the core alone. The tension between a default that is on par with TWM or raw X and a bloated failing awesome-like core goes away. - People who really want the stripped down xmonad have a name which makes it very clear which one of 'xmonad', 'xmonad-core', and 'xmonad-contrib' they want. - Distro & package maintainers bear very small costs since the package is really small and simple. Quite possibly it may not need updating for years or indefinitely once we get dynamic linking. (Since, if I understand the idea right, the compiled program would not hardwire the xmonad libraries but point to libxmonad.so or something, and would get new versions of 'xmonad' and 'standardConfig' everytime the respective libraries were changed.) - The majority of our users' lives will be easier: by installing 'xmonad', they get the core and -contrib as dependencies, and they don't have to struggle to get a comfortable setup. Sane defaults. I think we could make a standardConfig which is competitive with fluxbox or ratpoison. Even if a user doesn't want the spartan -core, but dislikes the standardConfig, they could still be better off, since it's unlikely they dislike the entire thing or even most of it. It seems to me that most people tend to dislike 1 or 2 things; if a person dislikes only 1 thing, they ideally will only have to change one thing. - People with existing configs are entirely unaffected. Because module names are split from package names, their xmonad.hs will never know the difference. (Presumably the new xmonad executable will see the xmonad.hs and recompile/run it rather than continue with standardConfig.) - This idea is better than some separate 'bluetile' executable package. dons and others have spent years publicizing xmonad. People who want xmonad install 'xmonad'. The people who would benefit from it are almost by definition the people who would not know about it until too late. Nor can we add an executable section to XMonadContrib for exactly the same reason. Someone just trying out XMonad may well never install -contrib or even know about it until they begin complaining. If you knew little about Xmonad and saw the Debian description at http://packages.debian.org/sid/xmonad would you be able to instantly infer 100% of the time that "Xmonad is configured in Haskell, and custom layout algorithms may be implemented by the user in config files" implies that there is an enormous collection of extensions & customizations called xmonad-contrib? I mean, -contrib isn't even a recommended or suggests! The major downsides I can think of: - hardcore minimalists might complain that they have to relearn to 'install xmonad-core' rather than 'install xmonad', lest they pull in -contrib as well. But then, these tend to be the people best able to bear the costs; I cannot weep for them. - the documentation might become misleading in places. Perhaps not majorly; many problems will be averted by the fact that the old 'xmonad' executable could always be reached as 'xmonad-core', and to do anything programming-wise would require using module names, and since the new xmonad depends on xmonad-core, there'd be no breakage. To be consistent, we might want to rename the darcs repo to .../xmonad-core; but then, the new 'xmonad' is so small we could just tuck it away in its own directory, or make the repo have 2 top-level folders, xmonad-core & xmonad. - this requires effort and approval from many people. (How many distro maintainers do we have? 3 or 4? Toss in another 3 for the -core devs, and then maybe a few more for people in favor of the general idea of a default userfriendly config but really couldn't we just make it another XMC module or something. Hard to have a consensus or get anything done with 10 people complaining, and this doesn't work if the official xmonad package doesn't change. It can't be done as a fork, as I covered above.) * this is what everybody in #xmonad seems to say to distinguish the core package from contrib, anyway -- gwern

Joachim Breitner writes:

Well, dynamic linking is just about to enter ghc, and it has no ABI guarantees: Expect the distro maintainers to have to re-build the xmonad package everytime one of the libs changes for years or indefinitely. :-)

It's quite likely that in Gentoo, we won't be enabling dynamic linking (or if we do, as a user-beware USE flag). We've already got a tool to rebuild packages when a dependency gets upgraded (source-based rolling-upgrade distro; kinda need it :p ); I can give you a link to the source if you want to have a look to see if you can adapt it for Debian, etc. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Hi, Am Dienstag, den 08.12.2009, 14:29 -0500 schrieb Gwern Branwen:

...

I’d not use a one-file-cabal file for the xmonad binary, but just copy that file to the debian package, but that’s an implementation detail on my side and not visible (besides by the fact that the Debian xmonad package will have the version number of the -contrib package it was built with, which probably makes sense anyways).

That's interesting. I was thinking about how to simplify the distribution process; if there's no cabal file, how will people know what this random .hs is or what it needs to be built and what name it should be built under? With a one-file-cabal I reasoned distro people would just have to run their magic cabal2deb tool a third time after xmonad-core and xmonad-contrib and everything would Just Work.

sorry, my wording was unclear: With „I’d not use“ I mean that I would not use it for the Debian package. It still makes sense to have a one-file-cabal package for the users of “cabal install”. The point for Debian is that there is still quite a lot of manual work to be done when creating and updating a package. Simply put, packages are not cheap. This is quite different from the Haskell situation on hackage. Therefore, I’d prefer to build the binary along the library sources. But that is, as I said, an implementation detail and should not affect your proposal in either way. Greetings, Joachim, -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On Tue, Dec 8, 2009 at 5:00 PM, wrote:

Quoting Gwern Branwen :

...

SmartBorders conditional on no-Xinerama

This is sort of tangential, but why do people keep making this conditional?  SmartBorders already disables itself when there are multiple visible workspaces.

~d

It does? I had been under the impression from years back that one of the key reasons SmartBorders was not in -core was that it didn't work well for multiple monitors, and this is the first I've heard about it already having a conditional in it. If it does, then that's great... -- gwern

On Mon, Dec 07, 2009 at 07:27:31PM -0500, Gwern Branwen wrote:

Here's something I've been thinking. What if we came up with an xmonad.hs that included all the stuff everybody asks for and the obvious newbie aids like a first-run xmesage prompt? (Let's call this a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.)

Then we could take the current xmonad package, rename it 'xmonad-core'*; the new 'xmonad' would be basically a cabal file depending on xmonad-core and xmonad-contrib, and an executable reading 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main = xmonad standardConfig'. (xmonad-core's executable would be left alone of course.)

If we get ambitious, the new xmonad main could do more. Perhaps we could check for XineRama in main and then modify our standardConfig to use SmartBorders or not?

I also think this is a good idea! I was playing around with the same thought, but as you said, it will need a number of people behind this effort as it requires some restructuring. Maybe one should go as far as move all the xmonad.hs-detection and -compiling code from xmonad-core to this new xmonad. Now that I think about it, it is actually necessary, isn't it? Because the standardConfig should only be invoked, if there is no user-xmonad.hs. But I think that would be a better separation anyway. Have this new xmonad be the single entry point, which decides to run a standardConfig or compile and run a xmonad.hs. Then xmonad-core could just be a library and this somewhat confusing - in my opinion at least - hybrid nature of an executable as well as a library would stop. The disadvantage would be, that you could no longer run xmonad-core on its own. You would have to write an explicit, minimal xmonad.hs. Just a few thoughts on this idea. I also remember that - I think - Don was thinking of maybe doing some sort of popularity module to figure out what stuff from contrib is used most often. I think that sort of information could be really interesting in deciding what to put into a standardConfig. But that's maybe just an optional extra step. Regards! Jan

On Mon, Dec 07, 2009 at 05:43:29PM +0100, Jan Vornberger wrote:

Joachim has already touched on the question of releasing a new version of xmonad and xmonad-contrib, so that Bluetile can depend on them. That would be my next question as well, as that would allow me to get rid of the bluetilebranch-stuff on hackage.

In the past we've saved all new features for major releases, with these releases fairly far apart. The next major release of xmonad is 1.0, which is potentially months away considering some of the things we have in mind. My hunch is that you'd rather not wait so long. What I propose that we break with precedent a bit and make a 0.9.1 minor release with new features. For a while we've talked about making contrib releases independent of core, now seems like a good time to start. We could make a minor release as soon as 1-2 weeks, with more releases on a monthly basis as needed.

But before that, it might be good to get a shared understanding of how Bluetile's future should look like.

I think some people feel that Bluetile should just be completely merged into xmonad-contrib and cease to exist as a separate project. I can understand why they would like to 'tidy' things up, but I have to say that I think that this approach is completely incompatible with Bluetile's goals.

Burying Bluetile somewhere in xmonad-contrib isn't my idea of a 'gentle learning curve'. Even if it becomes as easy as writing

main = xmonad $ bluetileConfig

Yes, as a practical matter Bluetile needs to be a 'cabal install' or binary package manager invocation away, no other configuration required.

If it indeed stays as a separate project, the only question is how much code remains only in Bluetile's repository. For now I have moved pretty much everything over to xmonad-contrib, except for a few things:

The Bluetile dock application - this is very specific to Bluetile's config, so not really very flexible. It also requires gtk2hs. So I'm not sure it makes sense to put this in xmonad-contrib. It would add gtk2hs as a requirement to xmonad-contrib.

Yes, we shouldn't depend on on gtk2hs in contrib.

The module BluetileCommands. This is pretty much just a list of hard-coded commands that are passed to ServerMode to give the dock a way to control Bluetile.

The module BluetileDock. This writes status information to a pipe so that the Bluetile dock can receive it and display things like the current layout etc.

The inclusion of these depends on whether it is feasible to run the dock outside of a Bluetile session. If this is possible and desirable, they could be included in XMonad.Config.Bluetile. Otherwise, if the dock is very closely tied to Bluetile, then these modules should be in Bluetile rather than contrib.

Bluetile's actual config, making use of these three things and Bluetile-related stuff from xmonad-contrib.

Could this, or a slightly stripped down version of this, be in contrib?

It seems like a good division to me, because all the very Bluetile-specific stuff is in the Bluetile repository and the more-or-less reusable modules have been moved over to xmonad-contrib.

But maybe it would be a good idea to provide XMonad.Config.Bluetile in xmonad-contrib for someone who wants to move from Bluetile to xmonad proper and start out with the same configuration - albeit without Bluetile's dock.

I do think we ought to have XMonad.Config.Bluetile. I'm certain that at least some Bluetile users will want to configure it a bit, so we'll need an upgrade path. Cheers, Spencer Janssen

On Mon, Dec 07, 2009 at 07:18:44PM -0500, Adam Vogt wrote:

* On Monday, December 07 2009, Spencer Janssen wrote:

...

In the past we've saved all new features for major releases, with these releases fairly far apart. The next major release of xmonad is 1.0, which is potentially months away considering some of the things we have in mind. My hunch is that you'd rather not wait so long.

What I propose that we break with precedent a bit and make a 0.9.1 minor release with new features. For a while we've talked about making contrib releases independent of core, now seems like a good time to start.

You intend to release contrib with all the changes requiring the addition of ExtensionClass to core stripped out? That's going to be quite a bit of useless work, cosidering how widespread the use of XMonad.Util.ExtensibleState in contrib is: - 8 modules directly import ExtensibleState - 3 indirectly through XMonad.Util.PositionStore

Of course, you could temporiarily implement ExtensibleState (missing serialization) using unsafePerformIO and an IORefs, to be compatible with the 0.9 core, but we've already discussed how unpleasant that solution is.

-- Adam

Actually, I think the bluetile patches need ExtensibleState as well, so we'd need to make a release of core as well. I think that's the only feature related patch in or pending for core at the moment. Cheers, Spencer Janssen

Hey! On Mon, Dec 07, 2009 at 05:53:29PM -0600, Spencer Janssen wrote:

In the past we've saved all new features for major releases, with these releases fairly far apart. The next major release of xmonad is 1.0, which is potentially months away considering some of the things we have in mind. My hunch is that you'd rather not wait so long.

[...]

We could make a minor release as soon as 1-2 weeks, with more releases on a monthly basis as needed.

Your hunch is right. :-) But a timeframe of 1-2 weeks sounds great.

I do think we ought to have XMonad.Config.Bluetile. I'm certain that at least some Bluetile users will want to configure it a bit, so we'll need an upgrade path.

I agree, so I just pushed two patches, one of them containing XMonad.Config.Bluetile and the other BluetileCommands, which I previously mentioned is used to remote-control Bluetile. So the only thing not in xmonad-contrib is now the dock application, which won't go in anyway, because of the gtk2hs dependency. But except for that, with XMonad.Config.Bluetile you can now get pretty much the same thing as with the 'real' Bluetile, providing a good upgrade path. Judging from the discussion, I feel that most people agree with me that Bluetile should continue to exist as a separat project to be able to provide the easiest possible installation process. So it would be great if a 0.9.1 minor release of xmonad and xmonad-contrib could be made, to allow for Bluetile to be packaged. Combined with XMonad.Contrib.Bluetile it is then an easy step for Bluetile users to switch to xmonad should they want to start tinkering with the configuration. Cheers! Jan

Hi! On Wed, Dec 09, 2009 at 08:17:59PM +0100, Joachim Breitner wrote:

The dock application seems to be self-contained, i.e. has no dependency on xmonad code. It probably is useful on its own, e.g. for people doing their own configuration, right? But I guess it is not useful for non-xmonad-users, right?

It isn't very flexible at the moment. But yes, I suppose it could be useful for xmonad-users on its own in some cases.

Is bluetilemockwin useful for anyone but developers creating screencasts?

Yes, the greeter application allows you to open a few windows which starts a few of these bluetilemockwins. The idea is, that you can then start playing around with the layouts and see the effect very clearly. So it should be part of bluetile-utils.

For Debian, I’d say I create bluetile-utils package from the bluetile hackage package, containing bluetiledock and bluetilegreet, and build the bluetile package from the xmonad-contrib source, which then depends on bluetile-utils. This way, I would not have to recompile bluetiledock or bluetilegreet just because a part of the xmonad code gets upgraded. Does this make sense?

For the most part yes - but Bluetile has it's own Main.hs and it is a little bit more elaborated then just doing 'main = xmonad bluetileConfig'. For example, it also checks if gnome-terminal is available and falls back to xterm if that is not the case. It also starts the helper applications and displays some start-up information. So I think it would be better to build the bluetile package from the bluetile hackage package. (About the terminal thing: That might be an opportunity to use Debian's x-terminal-emulator or some such thing. Let me know if I can make such 'debanization' easier in any way.) I hope that's not confusing? You can have a look at the current state of the code here: http://code.haskell.org/~jav/bluetile/ This is the new version that depends on xmonad mainline. (On the website the old repositories are still linked, because that's what is on hackage at the moment). If I may ask: You seem to be doing a lot of cutting and slicing. :-) I trust you know what you are doing, as you have experience with packaging for Debian, but does this really make things easier? A release of xmonad will always require a release of bluetile, so why not just keep the helper applications in that same package and just recompile them in the same go. It doesn't hurt, does it? Actually, the helper applications did live in an extra repository called bluetile-utils at some point. So I guess we are thinking alike. :-) But then I decided to just merge them into one repository to have less things to manage. It also opens the possibility to integrate the dock closer with the rest of the code. Right now it's self-contained, but at some point I might make it aware of things like how many workspaces are configured in bluetileConfig to adjust accordingly. That would break the bluetile vs. bluetile-utils separation, I suppose, and I don't want to create extra work for you. So yeah, just curious what your motivation behind it is? But do as you see fit and let me know how I can help! :-) Regards, Jan

On Thu, Dec 10, 2009 at 11:55:12AM +0100, Joachim Breitner wrote:

Am Donnerstag, den 10.12.2009, 00:07 +0100 schrieb Jan Vornberger:

...

It also starts the helper applications and displays some start-up information.

Any chance to have this bit of code in the module that exports bluetimeConfig, e.g. as bluetileStartup.

From Bluetile's perspective xmonad and xmonad-contrib are libraries. If I understand you correctly, you are asking if all pieces of Bluetile can be moved somewhere into those libraries, so that the original Bluetile executable can be reconstructed with a simple recipe from the libraries alone. I see how that would make it possible to build everything from Debian's xmonad source packages, but I find it a little like craming things into

I fear that's not easily possible. This code uses things like 'getBinDir' provided by cabal to determine where it has been installed and find the helper applications. If it would be moved to xmonad-contrib, those calls would return the information for xmonad-contrib instead. Bluetile's main also does things like argument parsing and some extra code for proper restarting is required, because xmonad normally calls out to the binary 'xmonad' which obviously isn't want I want in this case. With some hacking it might be possible to move all this to some module called BluetileMain in xmonad-contrib. But I'm not really sure I want to go down this path, to be honest. places where they shouldn't be. Like moving all pieces of xterm into libncurses to be able to build both from just ncurses - to name a random example. Or do you feel this analogy doesn't hold here? Maybe because Bluetile is such a small program and mostly just uses xmonad and xmonad-contrib for the heavy lifting? But still, Bluetile is more then just bluetileConfig, even if just for technical reasons. Regards! Jan

Jan.Vornberger:

Hey!

On Mon, Dec 07, 2009 at 05:53:29PM -0600, Spencer Janssen wrote:

...

In the past we've saved all new features for major releases, with these releases fairly far apart. The next major release of xmonad is 1.0, which is potentially months away considering some of the things we have in mind. My hunch is that you'd rather not wait so long.

[...]

We could make a minor release as soon as 1-2 weeks, with more releases on a monthly basis as needed.

Your hunch is right. :-) But a timeframe of 1-2 weeks sounds great.

...

I do think we ought to have XMonad.Config.Bluetile. I'm certain that at least some Bluetile users will want to configure it a bit, so we'll need an upgrade path.

I agree, so I just pushed two patches, one of them containing XMonad.Config.Bluetile and the other BluetileCommands, which I previously mentioned is used to remote-control Bluetile.

So the only thing not in xmonad-contrib is now the dock application, which won't go in anyway, because of the gtk2hs dependency. But except for that, with XMonad.Config.Bluetile you can now get pretty much the same thing as with the 'real' Bluetile, providing a good upgrade path.

Judging from the discussion, I feel that most people agree with me that Bluetile should continue to exist as a separat project to be able to provide the easiest possible installation process. So it would be great if a 0.9.1 minor release of xmonad and xmonad-contrib could be made, to allow for Bluetile to be packaged.

Combined with XMonad.Contrib.Bluetile it is then an easy step for Bluetile users to switch to xmonad should they want to start tinkering with the configuration.

This sounds like a great approach. We should decide how the projects refer to each other. I'd like to strengthen our joint communities, rather than fragment them. (Which I think will mean sharing as many resources as make sense, and have cross-cutting components (such as bluetile modules in XMC). -- Don