14151617September, 2007DayDate
Date Sep 14, 2007 8:17:18 AM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromAndrea Rossato <mailing_list@istitutocolli.org>
Reply-Tomailing_list@istitutocolli.org
Toxmonad@haskell.org
Date Sep 14, 2007 12:24:27 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromSpencer Janssen <sjanssen@cse.unl.edu>
Toxmonad@haskell.org
On Friday 14 September 2007 05:56:34 Xavier Maillard wrote:
Hi,

Each time I try to update xmonad (from darcs), my Config.hs is broken. This
is, for me, the major drawback of xmonad. I do not understand any a line of
Haskell and thus I am lost after each upgrade.

Although I love xmonad, it is useless since I can't benefit of any upgrade
without boring you about my new Config.hs's problems...

Am I alone in this situation or not ? How haskell rookies like do ?

_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad

Config.hs has been called our Haskell trojan horse -- perhaps it is time to
learn Haskell? ;)

I think there are some steps you can take to alleviate your problem. First,
you can upgrade less often. I think running the stable 0.3 release is a good
idea -- it is robust and has nearly all of the features of the current
development version. If you stick to stable releases you shouldn't have to
update your Config.hs more than once a month.

Next, I think judicious use of a nice diff/merge tool will help. I'd use
'vimdiff xmonad-0.2/Config.hs xmonad-0.3/Config.hs', where the first is an old
version with all your customizations, and the second is a pristine Config for
the new version. Gradually port your customizations from left to right, and
compile frequently to catch mistakes early.

Finally, if you're having trouble with a contrib module, check the usage info
at the top of that module. Every module should have a working Config example
(please report a bug if it does not!).


Cheers,
Spencer Janssen

_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 1:09:55 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromDon Stewart <dons@galois.com>
ToSpencer Janssen <sjanssen@cse.unl.edu>
CCxmonad@haskell.org
sjanssen:
On Friday 14 September 2007 05:56:34 Xavier Maillard wrote:
Hi,

Each time I try to update xmonad (from darcs), my Config.hs is broken. This
is, for me, the major drawback of xmonad. I do not understand any a line of
Haskell and thus I am lost after each upgrade.

Although I love xmonad, it is useless since I can't benefit of any upgrade
without boring you about my new Config.hs's problems...

Am I alone in this situation or not ? How haskell rookies like do ?

_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad

Config.hs has been called our Haskell trojan horse -- perhaps it is time to
learn Haskell? ;)

I think there are some steps you can take to alleviate your problem. First,
you can upgrade less often. I think running the stable 0.3 release is a good
idea -- it is robust and has nearly all of the features of the current
development version. If you stick to stable releases you shouldn't have to
update your Config.hs more than once a month.

Next, I think judicious use of a nice diff/merge tool will help. I'd use
'vimdiff xmonad-0.2/Config.hs xmonad-0.3/Config.hs', where the first is an old
version with all your customizations, and the second is a pristine Config for
the new version. Gradually port your customizations from left to right, and
compile frequently to catch mistakes early.

Finally, if you're having trouble with a contrib module, check the usage info
at the top of that module. Every module should have a working Config example
(please report a bug if it does not!).

Should we add an FAQ on this, for how to manage Config.hs ?

Examples include:
* run the stable brance
* diff with vimdiff or meld (another visual diff tool)
* record your changes locally in darcs

-- Don
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 4:46:38 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromDon Stewart <dons@galois.com>
ToAlex Tarkovsky <alextarkovsky@gmail.com>
CCxmonad@haskell.org
alextarkovsky:
Spencer Janssen wrote:
Config.hs has been called our Haskell trojan horse -- perhaps it is time to
learn Haskell? ;)

This is also an unspoken assumption in many of the replies to the OP,
and there's an important point there which everyone seems to be brushing
aside: Users who have absolutely no interest in programming or learning
how to program (the majority of computer users -- and yes, even of Linux
users) are going to be put off by xmonad and move on to some other
window manager that's easier to configure. That's regrettable because I
believe xmonad could benefit more than just programmers.

How many non-programmers are using tiling window managers in X11 though?

Xmonad should be explicitly advertised as a "window manager you need to
learn minimal Haskell to configure" unless a conventional configuration
scheme is planned. Otherwise it's just wasting the time of users who
would have chosen some other window manager had they known ahead of time
what they were getting into. Frustrating such users on the off chance
that one or two may decide to join the ranks of Haskellers is an unfair
trade-off IMO.

We use Haskell as the configuration language for expressivity only --
leading to the amazing explosion of extensions.

Similar window managers make their own choices:

ion -- you need to learn lua
dwm -- you need to learn C
wmii -- you need to write shell (or ruby)
emacs -- you need to learn lisp

Simple configuration of xmonad requires no Haskell skills, and we've
had very very few complaints about config files not type checking, so
all in all, I'm not terribly convinced the use of Haskell has been
problematic.

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

-- Don
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 5:36:23 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromAlex Tarkovsky <alextarkovsky@gmail.com>
Toxmonad@haskell.org
Don Stewart wrote:
How many non-programmers are using tiling window managers in X11 though?

Why should a tiling window manager preclude use by non-programmers?

Given that xmonad (and other window managers like it) allows you to use
a mouse, the UI part of xmonad's learning curve is still gentle enough
to appeal to a more general audience. Also, users with disabilities may
be attracted to xmonad's truly first-class keyboard navigation support,
something which Gnome and KDE don't offer. I can also envision novel
uses of xmonad in setups for media center PCs, multimedia presentations,
and media production workstations. These domains aren't exclusive to
programmers.

At the very least I hope you can agree that one needn't be a programmer
to loathe traditional desktop environments. ;)

We use Haskell as the configuration language for expressivity only --
leading to the amazing explosion of extensions.

Extensions written by users who happen to be programmers. ;)

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

Ideally a GUI-based configuration utility could be offered -- xmonad is
an X11 application after all. If designed well, it could capture the
flexibility of Config.hs. As for text file based configuration, the
traditional UNIX option=value style is probably too limiting, so I
concede that Config.hs should probably stick around for the more
intrepid users.

--
Alex Tarkovsky
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 5:40:54 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
From"Michael F. Lamb" <mike@datagrok.org>
Toxmonad@haskell.org

How many non-programmers are using tiling window managers in X11 though?

I don't think that line of thinking is the right direction to go. I've liked the idea of a tiling window manager before I began using or hacking on it. I don't think there's anything inherently more programmer-ish about a window management scheme which deviates from the de facto "piles of crap" layout.

So, I'd agree with Alex on this, but on the other hand I would also recoil a bit at the suggestion that this feature be added to the core, since there are bound to be many differing opinions on what is best.

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

Gah! Scary.

Might it not be possible for there to exist something in XMonadContrib that contains all the bloat necessary to provide a gtk (or qt) gui configuration tool? That way, (in addition to Don being able to avoid this question altogether,)

- Distributors could enable it in Config.hs and compile it for the "non-programmers," while the rest of us are happy with our lean, efficient core XMonad.

- Various configuration fronts could be contributed and selectively enabled/ignored (GTK storing data in the gconf registry thing, QT however the KDE people store application data, vimscript, .muttrc, etc.)

I'm not enough of a Haskell/XMonad hacker to fully think this through though... I expect it might even sound quite naive. I'm sure I'll be able to learn a lot from your replies.
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 5:44:13 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromDon Stewart <dons@galois.com>
To"Michael F. Lamb" <mike@datagrok.org>
CCxmonad@haskell.org
mike:

How many non-programmers are using tiling window managers in X11 though?

I don't think that line of thinking is the right direction to go. I've
liked the idea of a tiling window manager before I began using or
hacking on it. I don't think there's anything inherently more
programmer-ish about a window management scheme which deviates from the
de facto "piles of crap" layout.

So, I'd agree with Alex on this, but on the other hand I would also
recoil a bit at the suggestion that this feature be added to the core,
since there are bound to be many differing opinions on what is best.

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

Gah! Scary.

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool? That way, (in addition to Don being able to avoid
this question altogether,)

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

I'm not enough of a Haskell/XMonad hacker to fully think this through
though... I expect it might even sound quite naive. I'm sure I'll be
able to learn a lot from your replies.

I'm text console-y enough I didn't even consider a gui tool. But that
would be lovely. Being an FP guy I immediatley assumed the OP was
looking for a new configuration language :)

Andrea, perhaps you'd like to play with gtk2hs to write a tool to modify
Config.hs ? Or anyone else interested -- I'm happy to guide people on
this matter, and it could be quite robust and workable, I suspect.

-- Don
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 6:55:27 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromAlex Tarkovsky <alextarkovsky@gmail.com>
Toxmonad@haskell.org
Michael F. Lamb wrote:
de facto "piles of crap" layout.

Thanks, I don't think I've heard the classic WIMP paradigm described so
eloquently. ;)

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

I also think contrib is where it belongs.

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

Distros such as Ubuntu would most likely bundle it by default, but more
flexible and technically-oriented distros like Gentoo would keep it
optional (just as Gentoo does with xmonad extensions).

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

Agreeing with Don that this is a perfect project for Gtk2Hs, I must also
caution against storing anything in GConf. From a usability standpoint
GConf is an abomination, and I believe it only exists to placate critics
of Gnome's many boneheaded nips and tucks to various interfaces. From a
backing store standpoint, Gnome proper and Gnome-targeted applications
(not general GTK+ applications) remain the only consumers of GConf
services to date, so why not just use a single configuration data format
that all platforms can use without the GConf dependencies?

It wouldn't be wise to have the GUI molest Config.hs either though,
which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

--
Alex Tarkovsky
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 6:59:20 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromDon Stewart <dons@galois.com>
ToAlex Tarkovsky <alextarkovsky@gmail.com>
CCxmonad@haskell.org
alextarkovsky:
Michael F. Lamb wrote:
de facto "piles of crap" layout.

Thanks, I don't think I've heard the classic WIMP paradigm described so
eloquently. ;)

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

I also think contrib is where it belongs.

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

Distros such as Ubuntu would most likely bundle it by default, but more
flexible and technically-oriented distros like Gentoo would keep it
optional (just as Gentoo does with xmonad extensions).

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

Agreeing with Don that this is a perfect project for Gtk2Hs, I must also
caution against storing anything in GConf. From a usability standpoint
GConf is an abomination, and I believe it only exists to placate critics
of Gnome's many boneheaded nips and tucks to various interfaces. From a
backing store standpoint, Gnome proper and Gnome-targeted applications
(not general GTK+ applications) remain the only consumers of GConf
services to date, so why not just use a single configuration data format
that all platforms can use without the GConf dependencies?

It wouldn't be wise to have the GUI molest Config.hs either though,
which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Spencer has a possible architecture based on ghci, which would give us
zero-compile reloading, using just the bytecode interpreter.

-- Don
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 14, 2007 8:58:14 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromSpencer Janssen <sjanssen@cse.unl.edu>
Toxmonad@haskell.org
Date Sep 14, 2007 9:12:25 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromSpencer Janssen <sjanssen@cse.unl.edu>
Toxmonad@haskell.org
On Friday 14 September 2007 17:55:27 Alex Tarkovsky wrote:
Michael F. Lamb wrote:
de facto "piles of crap" layout.

Thanks, I don't think I've heard the classic WIMP paradigm described so
eloquently. ;)

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

I also think contrib is where it belongs.

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

Distros such as Ubuntu would most likely bundle it by default, but more
flexible and technically-oriented distros like Gentoo would keep it
optional (just as Gentoo does with xmonad extensions).

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

Agreeing with Don that this is a perfect project for Gtk2Hs, I must also
caution against storing anything in GConf. From a usability standpoint
GConf is an abomination, and I believe it only exists to placate critics
of Gnome's many boneheaded nips and tucks to various interfaces. From a
backing store standpoint, Gnome proper and Gnome-targeted applications
(not general GTK+ applications) remain the only consumers of GConf
services to date, so why not just use a single configuration data format
that all platforms can use without the GConf dependencies?

It wouldn't be wise to have the GUI molest Config.hs either though,

Yeah, modifying Config.hs directly is surely a path towards destruction,
generating a boilerplate Main.hs which parses some sort of text database seems
perfectly reasonable, though. (see notes about this in my other email)

which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Note that it's possible to run modifications without recompiling at all, just
make a script (cd $xmonaddir; runghc Main.hs) called xmonad in your path.

I think the current static configuration is okay, we just need to make
restarts more seemless. Who says we can't write out a new Config.hs and
restart xmonad each time a user clicks on a checkbox?


Cheers,
Spencer Janssen

_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 16, 2007 1:18:26 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
FromDavid Roundy <droundy@darcs.net>
Toxmonad@haskell.org
On Fri, Sep 14, 2007 at 08:12:25PM -0500, Spencer Janssen wrote:
which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Note that it's possible to run modifications without recompiling at all, just
make a script (cd $xmonaddir; runghc Main.hs) called xmonad in your path.

I think the current static configuration is okay, we just need to make
restarts more seemless. Who says we can't write out a new Config.hs and
restart xmonad each time a user clicks on a checkbox?

I disagree about the desirability of runtime configuration, but note that
we already support quite a bit of runtime configurability, with
runtime-configurable layouts (which can be abused to configure all sorts of
other things). This is all transiently configurable, but that something
we're keen to fix, by adding show and read capabilities to layouts.

Just about the only thing that *isn't* runtime configurable is key
bindings, and I'd definitely be glad to have that made configurable. For
instance, it might be nice to be able to define a layout in which almost
all key-bindings are available to the applications, which one could use for
running emacs, for instance.

In a language such as Haskell, it's hard to see why *any* configuration
should be made static. What would be the benefit of this? Sure, it's not
too hard to restart xmonad (and it would be nice to make this even less
painful), but why require it at all?
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad
Date Sep 17, 2007 2:09:53 PM (more headers)
SubjectRe: [Xmonad] [HUMOR] xmonad useless without programming skills ?
From"Michael F. Lamb" <mike@datagrok.org>
Toxmonad@haskell.org

Agreeing with Don that this is a perfect project for Gtk2Hs, I must also
caution against storing anything in GConf. From a usability standpoint
GConf is an abomination, ...

I wasn't advocating for GConf per se, only for the idea that whatever configuration format such a GUI-configurator might use stay separate and modular from XMonad base.

It wouldn't be wise to have the GUI molest Config.hs either though,

Speaking very abstractly (which may of course be completely vacuous,) I think the strong Haskeller should be able to write (in Config.hs) code which queries configuration information from a GUI configuration tool plugin, rather than have a configuration tool which manipulates the XMonad state directly by writing a Config.hs or the like. That keeps things modular, allows various GUI builders to design however they like, and doesn't take any power away from a power user.

I notice that when I restart XMonad with alt+q, it somehow keeps its state. Having not investigated the code very deeply and only seeing what happens to the description in my process list, it looks like the current state is (pardon my vocabulary) serialized into a string which is passed to the new process and interpreted. Is this right?

Please correct me if I have this wrong (because I would love to know exactly how it works.) If it's about right, would it also be possible to do the same thing with the "state" of the GUI configurator? To be specific, serializing its state to a text file when changes are made, and loading it when initialized?

Does there exist an elegant pattern among Haskell programs for state serialization over multiple invocations?
_______________________________________________
Xmonad mailing list
Xmonad@haskell.org
http://www.haskell.org/mailman/listinfo/xmonad