gmane.comp.lang.haskell.xmonad

Re: Issue 548 in xmonad: Feature request: greedyFocusWindow

2013-06-19T07:09:09

Comment #2 on issue 548 by yurac...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Feature request:  
greedyFocusWindow
http://code.google.com/p/xmonad/issues/detail?id=548

Seems like the greedy2 function you propose is the more generic and useful  
solution

Thanks!

Re: Issue 548 in xmonad: Feature request: greedyFocusWindow

2013-06-19T06:15:12

Updates:
Status: Accepted
Owner: vogt.a...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
Labels: Component-Core Component-Contrib Type-Enhancement Priority-Low

Comment #1 on issue 548 by vogt.a...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Feature request:  
greedyFocusWindow
http://code.google.com/p/xmonad/issues/detail?id=548

Yes these are useful. A good question is whether these versions/copies  
belong alongside the versions based on W.view, or maybe there's a better  
approach:

It should be possible to write a function which corrects which workspaces  
are on each screen after some other action runs (which is slightly bad  
because then you have two calls to `XMonad.Operations.windows'):

greedy :: X () -> X ()


It could do something similar to the following:

greedy2 :: (Eq s, Eq i) => (W.StackSet i l1 a1 s sd1 -> W.StackSet i l a s  
sd) -> W.StackSet i l1 a1 s sd1 -> W.StackSet i l a s sd
greedy2 f ws0 = let
         swap a b = W.greedyView a . W.view b
         s0 = W.screen $ W.current ws0

Re: darcs patch: DynamicBars-use-ExtensibleState

adam vogt — 2013-06-19T05:03:31

Applied, thanks.

On Tue, Jun 18, 2013 at 3:50 AM,  <gopsychonauts-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

darcs patch: DynamicBars-use-ExtensibleState

2013-06-18T07:50:55

1 patch for repository http://code.haskell.org/XMonadContrib:

Tue Jun 18 17:47:55 EST 2013  gopsychonauts-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
  * DynamicBars-use-ExtensibleState
  
  Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack (
  http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar
  state. Since ExtensibleState exists to solve these sorts of problems, I've
  switched the file over to use unsafePerformIO instead.
  
  Some functions' types had to be changed to allow access to XState, but the
  public API is unchanged.

Issue 548 in xmonad: Feature request: greedyFocusWindow

2013-06-18T07:29:33

Status: New
Owner: ----

New issue 548 by yurac...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Feature request: greedyFocusWindow
http://code.google.com/p/xmonad/issues/detail?id=548

It would be nice to have a greedy counterpart of the focusWindow function.
I work with two screens, one of which is my main screen and the other one
used occasionally. I use WindowGo.runOrRaise to focus my browser window and  
I expect the focusing to be greedy. Currently I use the following code  
(with focusWindowGreedy being a copy of focusWindow with view replaced by  
greedyView).
If you find this relevant, I can provide a patch.

Thanks!

focusWindowGreedy :: (Eq s, Eq a, Eq i) => a -> W.StackSet i l a s sd ->  
W.StackSet i l a s sd
focusWindowGreedy w s | Just w == W.peek s = s
                 | otherwise        = fromMaybe s $ do
                     n <- W.findTag w s
                     return $ until ((Just w ==) . W.peek) W.focusUp  
(W.greedyView n s)

raiseGreedy :: Query Bool -> X ()
raiseGreedy = raiseMaybeGreed

Re: Issue 547 in xmonad: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible

2013-06-17T03:01:50

Updates:
Status: Fixed

Comment #3 on issue 547 by daniel.w...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: XMonad.Prompt.Shell does  
not open a prompt if a directory in PATH is inaccessible
http://code.google.com/p/xmonad/issues/detail?id=547

Applied, thanks!

Re: Issue 547 in xmonad: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible

2013-06-16T23:08:47

Comment #2 on issue 547 by ttue...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: XMonad.Prompt.Shell does not  
open a prompt if a directory in PATH is inaccessible
http://code.google.com/p/xmonad/issues/detail?id=547

You're quite right, there seems to be no reason to catch other exceptions.  
Here's a new patch.

Attachments:
catch-exceptions-when-finding-commands-on-path-in-prompt_shell.dpatch  8.8  
KB

Re: Issue 547 in xmonad: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible

2013-06-16T02:25:48

Comment #1 on issue 547 by daniel.w...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: XMonad.Prompt.Shell does  
not open a prompt if a directory in PATH is inaccessible
http://code.google.com/p/xmonad/issues/detail?id=547

Is it enough to catch IOExceptions? If so, maybe it would be good to blend  
in with the surrounding style and use "`E.catch` econst []" instead of  
defining errHandler.

Other than that, the patch looks good to me.

Issue 547 in xmonad: XMonad.Prompt.Shell does not open a prompt if a directory in PATH is inaccessible

2013-06-15T22:50:13

Status: New
Owner: ----

New issue 547 by ttue...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: XMonad.Prompt.Shell does not open a  
prompt if a directory in PATH is inaccessible
http://code.google.com/p/xmonad/issues/detail?id=547

What steps will reproduce the problem?
1. Add a directory to PATH that user does not have permission to access.
2. Try to open a shell prompt.

What is the expected output? What do you see instead?
The prompt does not appear. I would expect a prompt to open, although tab  
completion obviously will not know about commands below the inaccessible  
directory.

What version of the product are you using? On what operating system?
xmonad-0.11, xmonad-contrib-0.11.1

Solution:
If a directory in the PATH is inaccessible, getDirectoryContents will throw  
an exception. The exception prevents the tab completion list from being  
compiled and the prompt from being opened. If an exception is encountered  
accessing any element of PATH for any reason, I think the response should  
simply be to r

Re: Issue 527 in xmonad: Google Hangouts screen sharingcrashes

2013-06-14T14:19:36

Comment #1 on issue 527 by tob...-JfKjbdOXF1/z+pZb47iToQ< at >public.gmane.org: Google Hangouts screen  
sharing crashes
http://code.google.com/p/xmonad/issues/detail?id=527

Same here

Re: Getting xmonad working with GNOME 3.8?

Ben Boeckel — 2013-06-14T02:21:20

There was discussion on #xmonad to use a pure Haskell implementation of
the protocol rather than binding the C code. I haven't seen any actual
progress though.

I started on a library[1] to try to extract out the pure data structures
from XMonad (and attempted to fix bug #4 as well), but haven't had time.
The goal was to rebase XMonad onto it so that xmonad-contrib could use
be used for both, just switching the monad would be needed (some modules
would obviously need to be DM-specific).

--Ben

[1]https://github.com/mathstuf/data-wm

Re: Getting xmonad working with GNOME 3.8?

Jens Petersen — 2013-06-13T09:25:32

Hi - a late reply!:

GNOME 3's Mutter and xmonad don't play nice together, so in the past xmonad

That is not quite accurate - yes there is a "GNOME Classic" session with
3.8 but it is not fallback mode ie it requires 3d graphics like regular
gnome-shell: so basically gnome-session seems to assume 3d now.
In fact Classic is just a modification of gnome-shell using various
extensions to make it feel more like gnome2 or fallback mode.



You can use XMonad with MATE if you like (a gnome2 fork).

Anyway things are only going to get more "interesting" with the coming move
to Wayland replacing X11.
It would be cool to rewrite xmonad as a wayland/weston compositor or at
least to write one in Haskell - probably first a binding to libwayland is
needed I suppose.

Jens

Re: Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-06-03T01:15:10

Comment #5 on issue 546 by ch...-kUVU1bYo9AgXC2x5gXVKYQ< at >public.gmane.org: Suggested improvement to  
CycleRecentWS for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

My version acts like the existing version with regard to the other screen;  
it won't ever swap the workspaces like greedyView, it just moves the focus  
to the other screen.

I agree that people will want different behaviour, and it might be best to  
have a couple of versions.  (In fact, I think I like byorgey's version  
better than mine.)

Re: Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-06-02T05:29:24

Comment #4 on issue 546 by hanswc...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Suggested improvement to  
CycleRecentWS for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

Thanks for the answer. My question should have been directed at the  
original poster since I tested out your modification already, sorry for not  
making it clearer.
(I don't know much Haskell so I don't know how to adapt OP's code to my  
xmonad.hs.)

I agree with your point and, as said, would be happy to see some  
alternative versions.

Re: Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-05-31T11:08:34

Comment #3 on issue 546 by byor...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Suggested improvement to  
CycleRecentWS for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

With my version, it will ignore workspace 1 because it is shown on another  
screen.  And this is exactly the way *I* want it.  I have a different  
keybinding to swap the two visible workspaces.  But wanting it to switch  
back is entirely reasonable, too.

This is my point -- there are lots of reasonable choices that could be  
made, and no one choice is best for everyone.  So I think that changing the  
definition of cycleRecentWS will not really accomplish anything.  But I'd  
certainly be OK with sticking in a couple alternate versions, with some  
clear documentation explaining what the different versions do.  If someone  
wanted to code up a patch I would review and apply it, or I will probably  
get around to this eventually if no one else does.

Re: Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-05-31T04:48:37

Comment #2 on issue 546 by hanswc...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Suggested improvement to  
CycleRecentWS for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

What happens if you swap the workspaces (with greedyView), e.g.
[1*][2] -> [2*][1]

Will the new cycleRecentWS switch back to [1*][2], or ignore workspace 1  
because it is shown on another screen?

Personally I like to think of my monitors as independent. That means that  
the functionality of CycleRecentWS (and also ToggleWS from X.A.CycleWS)  
should not change because of workspaces on other screens, so in my example  
it should switch back to [1*][2]. I would love to see this implemented in  
xmonad.

Re: Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-05-31T01:09:48

Comment #1 on issue 546 by byor...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org: Suggested improvement to  
CycleRecentWS for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

I actually already have something similar to this in my xmonad.hs, defined  
like this:

cycleRecentWS' = cycleWindowSets options
  where options w = map (W.view `flip` w) (recentTags w)
        recentTags w = map W.tag $ W.hidden w ++ [W.workspace (W.current w)]

Mine actually *excludes* the visible but non-focused workspaces from the  
cycle.  I guess my worry is that there are quite a few different ways to do  
this sort of thing, and if we change cycleRecentWS it will be what some  
people want but not others.  However, I would be OK with including some  
variants like the ones above, with names like  cycleRecentHiddenWS and so  
on.

Multi-display layout help

Mark Watts — 2013-05-30T12:33:00

Hi,

I have two monitors and I'd like to configure Xmonad so that if I switch to
a workspace and it's on a different monitor from the one with the currently
focused window, the workspace gets pulled to that monitor, BUT when I leave
that workspace it should return to the monitor it was pulled from. Is there
a layout that already handles this?

Issue 546 in xmonad: Suggested improvement to CycleRecentWS for multiple screens

2013-05-30T02:25:49

Status: New
Owner: ----

New issue 546 by ch...-kUVU1bYo9AgXC2x5gXVKYQ< at >public.gmane.org: Suggested improvement to CycleRecentWS  
for multiple screens
http://code.google.com/p/xmonad/issues/detail?id=546

XMonad.Action.CycleRecentWS defines a function to cycle through workspaces  
according to how recently they were shown.  The code specifically puts the  
current workspace at the end (although it is technically the most recent),  
which is a good idea.

With multiple screens, the visible workspace on the other screen is then  
considered to be the most recent visible workspace, so it switches there  
first.  I reckon it should not do this, and instead that workspace should  
be demoted to the end of the list, just like the current one.

Here is my suggested change to cycleRecentWS.  I can't be really confident  
that I fixed it the right way, but it does seem to work for me.

cycleRecentWS = cycleWindowSets options
  where options w = map (view `flip` w) (recentTags w)
        nscreens w = length (screens w

Re: patches to use data-default

adam vogt — 2013-05-29T14:09:46

Hi Carlos,

The reason data-default uses def is probably because default is a
keyword in haskell. What's your expected use for a default XState?
Those couldn't be the real initial state in most cases, since they
depend on the corresponding defaultConfig / defaultXPConfig.

--
Adam

_______________________________________________
xmonad mailing list
xmonad< at >haskell.org
http://www.haskell.org/mailman/listinfo/xmonad

Re: patches to use data-default

Carlos López Camey — 2013-05-29T10:45:33

Hello Daniel, I like this on xmonad-contrib. I would suggest the name
`default` instead of `def` though.

What do you think about having Default instances for states? e.g. for
XState and/or XPState.
They would be considered to be the initial state of course.