On Tue, Aug 25, 2009 at 10:01:30AM -0700, Don Stewart wrote:

Anyone interested in contacting the developer, and seeing how far they want to proceed with the patch imports?

He already answered in the other thread.

gwern0:

On Tue, Aug 25, 2009 at 1:01 PM, Don Stewart wrote:

...

gwern0:

...

So to conclude this whirlwind tour: I see a lot of valuable stuff.

The greeter is something that could definitely be in core (although I think the gtk2hs dep is untenable, so I expect a better idea would be to run an xmessage prompt with a list of keybindings). The dock is a nice alternative to the ridiculously baroque setups for xmobar and dzen - those may be really nice and customizable, but they are absolutely unsuitable for beginners, and even setting up a Gnome panel is a bit much for non-intermediate or advanced XMonaders.

Ok. So a good contrib module.

No, not a good contrib module at all. If the idea is to help beginners, then putting it in contrib makes it useless.

It'd be like writing a Haskell guide for beginners, except the first 10 chapters assume you know GADTs and System F - something to help beginners must be by default and not optional. If it was optional, it will either go unused or will be used by users savvy enough to know about it, track it down, and enable it, users who likely don't need it.

xmobar and dzen aren't in core. why should greeter be in core? its the xmonad microkernel -- you don't go bloating it without reason. i'm all in favour of easier user experiences. -- Don

Hi, 2009/8/26 Thomas Friedrich : [...]

I agree, please don't mess up the Xmonad-Core.  I like Xmonad because its so different to any other WM.. simple, clean, elegant, customizable, and did I mention clean?

Same here. I really think that telling people about tiling is a good idea, and having a more "beginner friendly" branch like bluetile is also a good thing. I'm not sure how to put it without sounding rude or arrogant, but I like xmonad because of the reasons Thomas stated above, which, for me, includes (or rather means) the absence of "beginner friendly" features.

From my point of view there are many window managers that deal with "beginner friendly" features. Extending xmonads default configuration in this way would mean that it's "just another WM". It all comes down to packaging anyway. There are some cool configurations in the Wiki, why not create a package xmonad-gnome or xmonad-kde for example? I've to disagree with Gwern here: A normal user who doesn't know about xmonad probably doesn't want it. So in case someone selects xmonad as his window manager of choice, there should at least be some basic knowledge of xmonad and the way it deals with windows.

Christian

On Tue, Aug 25, 2009 at 9:19 PM, Don Stewart wrote:

xmobar and dzen aren't in core. why should greeter be in core?

They could be a bad idea to put in XMonad for dozens of reasons: they aren't maintained, they do way too much, they're hundreds or thousands of lines, they bring in further dependencies, they aren't as well-coded or well-tested or well-documented as they could be, etc. A greeter could be as short as 3 (non-golfed) obviously correct lines: 1 line to do the 'if (not fileExists) $ spawn xmessage ++ helpMsg; a 2nd line to touch the file; and a 3rd line to define helpMsg. What the helpMsg would be is something worth discussing. I'd like something like the Ratpoison help that briefly covers the mod key issue ('all XMonad commands are keystrokes which start by holding the modifier key; the default modifier key is mod1Mask, usually your Alt or Meta key') and then lists all the default keybindings, but this might be hard to do in a non-copypaste fashion (it should be easy to call show on the list of keys, yes, but how does one do Show on the X() functions those keys correspond to?). But maybe a shorter help might work - perhaps a hyperlink to the docs like http://haskell.org/haskellwiki/Xmonad/Config_archive/Template_xmonad.hs ?

its the xmonad microkernel -- you don't go bloating it without reason.

i'm all in favour of easier user experiences.

-- Don

I think giving first-time users crucial information is not bloating the microkernel 'without reason'; I don't see how keeping the kernel static or shrinking it even more could lead to an easier user experience. -- gwern

On Fri, Aug 28, 2009 at 10:09 AM, Adam Vogt wrote:

There is a typeclass-based approach, implemented in XMonad.Util.NamedActions (darcs contrib), which may be worth consideration.

That's interesting. I see that the guts of it, defaultKeysDescr, take the copying approach, though, and don't reuse the original Config. But after all, if you're willing to copy, then a much easier approach is possible - have a Config which is [((Keymask,KeySym), String, X())]... -- gwern

Hi! (Sorry to be replying to an old thread, but I am catching up.) On Fri, Aug 28, 2009 at 01:01:11AM -0400, Gwern Branwen wrote:

A greeter could be as short as 3 (non-golfed) obviously correct lines: 1 line to do the 'if (not fileExists) $ spawn xmessage ++ helpMsg; a 2nd line to touch the file; and a 3rd line to define helpMsg. What the helpMsg would be is something worth discussing.

I really do agree. XMonad is now in a variety of distributions and can be installed by clueless users in a click-or-two. Later one, when they happen to break their GNOME session, it sounds like a good idea to give at least an idea on what is going on when XMonad finally shows up from distant memories. For this use case, I think the message should at least document how to quit. It was 13 years ago (damn.), but the very first time I started "vi" on a Slackware, Ctrl+C did not quit, and I had no other clue so I just pushed the reboot button. After the next boot, I had the same experience with "emacs". A few reboots later, eventually, someone told me a little bit more on how to edit, quit and save… but the software itself could probably have helped me as well. When started without any parameters "vim" displays not so much (9 lines of text), but among others: type :q<Enter> to exit type :help<Enter> or <F1> for on-line help But maybe it is a change that I should look forward to see added to the Debian package instead… Cheers, -- Jérémy Bobbio .''`. lunar@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-

On Tue, Aug 25, 2009 at 7:09 PM, Jan Vornberger wrote:

...

- XMonad.Hooks.WorkspaceByPos     No idea. What I did notice is that it looks like it could use the Maybe monad!

WorkspaceByPos is only useful in dual-head setups. If you open a new window it looks at the position where it wants to go and moves it to the correct workspace - as opposed to just assigning it to the active workspace. That's also very helpful when starting up in a dual-head setup. If you already have windows open and then start Bluetile, they are correctly assigned to the two visible workspaces, instead of all being moved onto one workspace.

Hm. The one it 'wants to go' to? You mean some apps detect that there are multiple physical screens and choose to go to #2 instead of #1, or something? (What apps do this, and why?)

...

- XMonad.Layout.WindowSwitcherDecoration    looks like a module to use a mouse to 'drag' a window onto another and swap their positions

That's correct.

Cool. I could actually use that one since I don't always remember what the exact right command is to move stuff around. -- gwern

Quoting Gwern Branwen :

On Tue, Aug 25, 2009 at 7:09 PM, Jan Vornberger wrote:

...

...

- XMonad.Hooks.WorkspaceByPos     No idea. What I did notice is that it looks like it could use the Maybe monad!

WorkspaceByPos is only useful in dual-head setups. If you open a new window it looks at the position where it wants to go and moves it to the correct workspace - as opposed to just assigning it to the active workspace. That's also very helpful when starting up in a dual-head setup. If you already have windows open and then start Bluetile, they are correctly assigned to the two visible workspaces, instead of all being moved onto one workspace.

Hm. The one it 'wants to go' to? You mean some apps detect that there are multiple physical screens and choose to go to #2 instead of #1, or something? (What apps do this, and why?)

When an X window appears, it has a chance to request a particular geometry (size and shape on the screen). There are lots of good reasons for this to happen. Some apps have a "-geometry" argument on the command line, some detect the shape of the screen and try to show up in the center of the screen (or the center of one of the screens, if their developers are Xinerama-savvy), some request the same geometry as when they were closed the last time, and so on. I assume WorkspaceByPos detects which screen an app "wants to go to" by where the requested geometry would put it. With these use cases in mind, it seems useful, and perhaps even a nice feature. ~d

2009/8/28 Jan Vornberger :

On Fri, Aug 28, 2009 at 01:29:40AM -0400, wagnerdm@seas.upenn.edu wrote:

...

When an X window appears, it has a chance to request a particular geometry (size and shape on the screen).  There are lots of good reasons for this to happen.  Some apps have a "-geometry" argument on the command line, some detect the shape of the screen and try to show up in the center of the screen (or the center of one of the screens, if their developers are Xinerama-savvy), some request the same geometry as when they were closed the last time, and so on.  I assume WorkspaceByPos detects which screen an app "wants to go to" by where the requested geometry would put it.

That's absolutely correct and a much better explanation than my "where it wants to go to". :-)

...

With these use cases in mind, it seems useful, and perhaps even a nice feature.

I'm not entirely happy about WorkspaceByPos in its current version:

The way which WorkspaceByPos detects windows that do not have a requested geometry is by checking for the request for position 0,0. This seems to work fine, but I wonder if there is another, more 'proper' way to figure this out.

You should be looking at the Gravity of the window to determine this, if not already doing so. -- Thomas Adam