On Wed, Apr 08, 2009 at 09:36:23AM -0700, Don Stewart wrote:

Will you be contributing back changes/modifications/... to the main xmonad source? What else can we do to help your effort?

Oh, one question that just came to mind: What are your suggestions in terms of how to set up the development environment? Are you usually using something like Xnest to test XMonad during development? And is it really necessary to run through the whole 'configure, build, install' process everytime there is a code change, like the 'xmonad development tutorial' on the wiki suggests? Cheers! Jan

On Fri, Apr 10, 2009 at 02:01:27AM +0200, Jan Vornberger wrote:

On Wed, Apr 08, 2009 at 09:36:23AM -0700, Don Stewart wrote:

...

Will you be contributing back changes/modifications/... to the main xmonad source? What else can we do to help your effort?

Oh, one question that just came to mind: What are your suggestions in terms of how to set up the development environment? Are you usually using something like Xnest to test XMonad during development? And is it really necessary to run through the whole 'configure, build, install' process everytime there is a code change, like the 'xmonad development tutorial' on the wiki suggests?

If you only make changes to some .hs files, but you don't add or remove modules, you don't need to run configure. You only build and install. In this case, the build will only recompile modules that are affected by the changes you made. So it is generally pretty fast. Cheers, Norbert

Gwern Branwen wrote:

I don't think that's so bad. Alias the configure-build-install to a single command, and then it's just a matter of alias mod-q.

And if that still isn't enough, you can bind a key to configure-build-install and a subsequent "xmonad --restart", so you're down to one keystroke.

Lol, is this thread a joke! if now i'm willing to put all can I do to help you in your projects, I was trying to go in the same direction but for XMonad being more "open" to newcomers, nothing more. bye! On Wed, Apr 8, 2009 at 2:43 PM, Gwern Branwen wrote:

On Wed, Apr 8, 2009 at 12:23 PM, Jan Vornberger < Jan.Vornberger@informatik.uni-oldenburg.de> wrote:

...

Hello,

my name is Jan Vornberger and I'm a student at the University of Oldenburg (Germany). I would like to introduce myself and the project that I will be working on for the next semester.

As part of my studies I have to work on a semester-long project. I decided to work on the question, how tiling window managers can be made more 'beginner-friendly' and how the barrier to entry can be lowered. I have decided to use XMonad as a basis for implementing my ideas. Therefore I wanted to introduce myself, as I will probably be asking a question here and there in the future. :-)

For those who are interested, here is a rough sketch on what I have in mind for my project: My goal is to create a modern tiling window manager that can be productively used with virtually no training, meaning most core functionality needs to be accessible in an intuitive way or drawing from well-known conventions in more conventional window managers. My target user is someone who wants to give tiling window managers a try, but doesn't want to learn keyboard commands (at least not in the beginning), read a detailed manual or write any sort of configuration file.

I'm planning to decide on a somewhat fixed configuration of XMonad, probably in combination with Gnome as a DE, and then trying to make this functionality available via mouse commands that - hopefully - will be easy to pick up.

I also want to completely rework the whole floating layer thing, as it seems to me to be a fairly foreing concept for a newcomer and it's awkward to use. My current idea is to instead use a floating layout algorithm, that could work similiar to a conventional window manager. It could even be set as the default layout algorithm. That way, the WM could almost be a 'drop-in' replacement for - let's say Metacity - greeting the user with the familiar concept of manipulating windows and then leading him to the tiling paradigm once he switches the layout.

I do believe that eventually the keyboard is a more effective way to control the WM, so I will also investigate the possibility of some kind of help system, that can point out how - for example - the last action, the user did, can be done with keyboard commands instead. Alternatively tooltips could also be used to display key bindings.

...

...

That's it, the project in a nutshell. Any thoughts, pointers, related ideas, doubts or comments are most welcome. :-)

Cheers!

Jan

One idea I've always wondered about is a menubar based tiling WM. The user, say, middle-clicks (hardly anyone uses middle-click), and then a geometrical menu pops up along the lines of XMonad.Actions.GridSelect. In it are all the default operations - 'kill', 'refresh', 'sendMessage NextLayout', etc. The user left-clicks on one and voila.

Further refinements: the menu could be shaped like some of the funky HCI designs (such as the pie ones, or using hyperbolic shrinking); could be sorted by frequency of use; each item could have in very small text the keybound equivalent ('M-Space') - kind of like how Emacs will echo the keybinding of a menu-item if you select it the hard way.

And of course this would be a focus-follows-mouse setup. The nice thing about this is that I think it's doable by one person in a semester (really, the hardest part is stealing the GUI code from GridSelect and making it mouse-enabled*), and should be dead simple for people new to the tiling paradigm to learn. Just middle-click and pick what sounds right. The menubar makes 'visible' the 'invisible'.

* In theory if you wanted to make a menubar that worked with arbitrary keymaps, you'd need some sort of Show equivalent for functions, since you need to be able to have a textual equivalent to whatever crazy things people may do - how could you really foresee my binding of 'runOrRaise "amarok" (className =? "amarokapp")'? - which gets you into complex territory fast. But if you're serious about the default config, you could just write up a static [String]. Which would also let you use more newbie-friendly names: instead of 'spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\""' you could just have 'run Dmenu'.

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

Hello xmonad users, this is my first post to this list after several weeks of lurking around. I switched to xmonad after being a long time ion3 user. A friend of mine showed me xmonad, and since I wanted to give functional programming a try, I though I could give xmonad a try, too. Needless to say that I fell in love with it easily and fast. ;-) I followed this - and the other suggestion thread - with quiet some interest. So I thought I step right into the discussion. :-) [...]

Traditional UI's aim to be intuitive to non-experts and, in doing so, completely forget to provide the functionality that is needed for efficient computer use once one is beyond the learning stage.

I have to disagree here. What we define as "intuition" is often just some kind of "trained knowledge": People have to learn how to use the first GUI, regardless of how it works. In the future they expect other GUIs to work in the same way, and because they don't need to think about it, they consider it to be "intuitive". This is a rather complex topic and might better be branched of into another thread. I'm doing all kind of "computer support" for what seems to be ages, and I just recently stopped supporting my friends and families with their windows machines. Some of them got a windows pc because they never thought about what system might suit them best. They got their windows because their friends use windows. During these "support" sessions, that regularly meant to show them how to use their computer, sometimes repeatedly talking about the same things over and over again, I reckoned that there is no such thing as "intuition" in regard to computers. And, what is even more important when it comes to xmonad: People seem to have problems with the concept of resizable windows at all. This is why I think that basically a tiling window manager like xmonad is more suitable for those people than a traditional one. Most people maximize a window the instance it pops up. What's worse, there are many computer users out there who have problems with the concepts of switching windows, closing the entire application every time instead. Workspaces seem to be a better approach, but I have to admit that I never actively introduced them to my people, except for my wife, who seems to use them sometimes. This means that xmonads tiling approach is a cool thing, and I hope that it might be the default window manager on some Linux or BSD distribution in the future, maybe bundled with GNOME or KDE. That might be in the long run, thou... Additionally in my experience most novice users are overwhelmed by all the options and applications offered by their operating system. So, the reduction of visible features as done by xmonad is a good thing and probably reduces the fear users might have during their first time with a system. For example, most people only need a Web browser, some office, some software to store and download their digital images, email and probably a calendar software. So I started to use a Linux distribution with xfce, and only placed buttons for the above mentioned software titles on screen. This reduces the need for menus, and for xmonad would mean that an easy to use application launcher is a good choice. One that probably handles shutdown, hibernate and sleep, too. When it comes to features and options, I think that a "layered" approach might be a good idea: Start with a basic configuration that should be suitable for most users, and offer a central location where to look for additional options and features. (Microsoft tried something the other way round with their newer versions of Office, but IMO failed miserably. Options disappear without the user noticing or being told, so it is as if they never existed.) So, xmonad could come with some workspaces enabled, one for example being configured as gridIM and the proper roster configuration. Yes, this would mean that it would be cool to have xmonad 1. figure out that there is an IM installed, and 2. configure a workspace correctly. Well, it mustn't be xmonad, some helper application to create the configuration would be an option, too. So, in case a user would like to use additional layouts, he could simply activate some, including a key combination for switching the layouts. This could be extended to other things with regard to hooks, window placement policies, etc. I see three big tasks to make xmonad suitable for "non power users": * A "library" would be great, listing "misbehaving" software (doesn't work nicely with tiling) as well as information about applications in general. For example to make the most of gridIM/withIM one has to know how to put the roster in the correct place. For xmonad being used by novice users, this has to be done in advance so that there's no need for the user to investigate. During my times with ion3 I configured a workspace for the gimp that took care of every window automatically. I placed most of them based on their size, and using tabbing I was able to switch between them. This helped a lot. I reckon that it would be great to such a specialized layout to appear automatically when needed, e.g. being created when gimps windows are added to the window stack. * a configuration has to be determined that can be used as a start. Maybe not only one configuration but several, so that the user can switch between them, getting an impression of what xmonad can do. If these configurations consists of different modules it would be possible for the user to create his/her first own configuration based on the different modules. * There's probably the need for a GUI the user can call to configure xmonad and all acompanied tools. I'm really a novice haskell programmer (in fact I wouldn't call it "programming", I'm working in chapter 4 of RWH), but from what I've seen so far xmonad.hs is a good candidate to being generated automatically. And the contrib library adds to this, of course... Cheers, Christian

Gwern Branwen writes:

One idea I've always wondered about is a menubar based tiling WM. The user, say, middle-clicks (hardly anyone uses middle-click), and then a geometrical menu pops up along the lines of XMonad.Actions.GridSelect. In it are all the default operations - 'kill', 'refresh', 'sendMessage NextLayout', etc. The user left-clicks on one and voila.

If people don't use middle click, then how do they paste text in X11? Other than that minor nitpick, this idea seems fairly interesting, I sometimes want to be able to use my computer with only the mouse, rather than only the keyboard.

* In theory if you wanted to make a menubar that worked with arbitrary keymaps, you'd need some sort of Show equivalent for functions, since you need to be able to have a textual equivalent to whatever crazy things people may do - how could you really foresee my binding of 'runOrRaise "amarok" (className =? "amarokapp")'? - which gets you into complex territory fast. But if you're serious about the default config, you could just write up a static [String]. Which would also let you use more newbie-friendly names: instead of 'spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\""' you could just have 'run Dmenu'.

This is easily solved by having keybindings be a tuple of a name and a function, the name being what you use for Show. Ideally, there'd be a typeclass or something for functions so people can skip the names if they don't use these features, and that would simply cripple this particular UI.