Re: How can I start urxvt as fullscreen ?



On Thu, 23 Jul 2009 12:50:50 -0500
Jeremy Hankins <nowan nowan org> wrote:

> Teika Kazura <teika lavabit com> writes:
> > On Thu, 16 Jul 2009 10:22:28 -0500, Jeremy Hankins wrote:
> >> But I'm not sure how to do the new-viewport one because I'm not
> >> sure how to check to see if a given viewport is empty.
> 
> Ok, first, I've written a match setter for new-viewport, since at the
> very least it completes the symmetry with new-workspace.  This also
> includes a minor fix to new-workspace, and puts both in the placement
> section of the ui.
> 
> -------------------------------
> diff --git a/lisp/sawfish/wm/ext/match-window.jl
> b/lisp/sawfish/wm/ext/match-window.jl index 4a7ea50..9986d9b 100644
> --- a/lisp/sawfish/wm/ext/match-window.jl
> +++ b/lisp/sawfish/wm/ext/match-window.jl
> @@ -77,7 +77,9 @@
>         (depth (number -16 16))
>         (placement-weight number)
>         (fixed-position boolean)
> -       (maximized (choice all vertical horizontal)))
> +       (maximized (choice all vertical horizontal))
> +       (new-workspace boolean)
> +       (new-viewport boolean))
>        (focus ,(_ "Focus")
>         (raise-on-focus boolean)
>         (focus-when-mapped boolean)
> @@ -109,8 +111,7 @@
>         (auto-gravity boolean)
>         (shade-hover boolean)
>         (transients-above (choice all parents none))
> -       (ignore-stacking-requests boolean)
> -       (new-workspace boolean))))
> +       (ignore-stacking-requests boolean))))
>  
>    ;; alist of (PROPERTY . FEATURE) mapping properties to the lisp
>    ;; libraries implementing them
> @@ -395,10 +396,32 @@
>     (lambda (w prop value)
>       (declare (unused prop))
>       (when value
> -       (let ((space (car (workspace-limits))))
> -         (while (not (workspace-empty-p space))
> -          (setq space (1+ space)))
> -            (set-window-workspaces w (list space))))))
> +       (unless (window-get w 'placed)
> +        (let ((space (car (workspace-limits))))
> +          (while (not (workspace-empty-p space))
> +            (setq space (1+ space)))
> +          (set-window-workspaces w (list space)))))))
> +
> +  (define-match-window-setter 'new-viewport
> +    (lambda (w prop value)
> +      (declare (unused prop))
> +      (when value
> +       (unless (window-get w 'placed)
> +         (let ((row 0)
> +               (col 0)
> +               (nomatch t))
> +           (while (and nomatch (< row (cdr viewport-dimensions)))
> +             (setq col 0)
> +             (while (and nomatch (< col (car viewport-dimensions)))
> +               (if (null (viewport-windows col row))
> +                   (setq nomatch nil)
> +                 (setq col (1+ col))))
> +             (if nomatch
> +                 (setq row (1+ row))))
> +           ;; TODO: handle the nomatch case more intelligently?
> +           (unless nomatch
> +             (set-screen-viewport col row)
> +             (set-window-viewport w col row)))))))
>  
>    (define-match-window-setter 'fullscreen-xinerama
>     (lambda (w prop value)
> -------------------------------
> 

Thanks for your efforts, Jeremy!

> This depends on viewport-windows (which I guess should be put in
> viewport.jl?).  It's a bit heavier than I'd like, especially as used
> in new-viewport since it's called for each viewport (until and empty
> one is found) and each call checks each window.  It's not a problem
> for my setup, but I don't use all that many windows.  Perhaps someone
> more skilled than I could improve it's efficiency, or improve the way
> it's used in new-viewport.  Or maybe I'm just a worry-wart.
> 
> (define (viewport-windows col row #!optional workspace)
>   "Provide a list of windows that can be seen (completely or
> partially) from the specified viewport."
>   (let* ((ws (or workspace current-workspace))
> 	 (width (screen-width))
> 	 (height (screen-height))
> 	 (left (+ (- viewport-x-offset) (* col width)))
> 	 (right (+ left (1- width)))
> 	 (top (+ (- viewport-y-offset) (* row height)))
> 	 (bottom (+ top (1- height))))
>     (filter-windows (lambda (w)
> 		      (let ((pos (window-position w))
> 			    (dims (window-frame-dimensions w)))
> 			(and (window-in-workspace-p w ws)
> 			     (not (or (<= (+ (car pos) (car dims))
> left) (<= (+ (cdr pos) (cdr dims)) top)
> 				      (>= (car pos) right)
> 				      (>= (cdr pos) bottom)))))))))

Yep, to be in sawfish.wm.viewports

> Also, there's a bug in infinite-desktop: the cursor isn't repositioned
> properly when moving up or to the left; here's a fix:
> 
> -------------------------------
> diff --git a/lisp/sawfish/wm/ext/infinite-desktop.jl
> b/lisp/sawfish/wm/ext/infinite-desktop.jl index d97d9d8..549a557
> 100644 --- a/lisp/sawfish/wm/ext/infinite-desktop.jl
> +++ b/lisp/sawfish/wm/ext/infinite-desktop.jl
> @@ -91,7 +91,7 @@
>              (< (+ viewport-x-offset dist) minx))
>         (setq dist (- minx viewport-x-offset)))
>      (set-viewport (+ viewport-x-offset dist) viewport-y-offset)
> -    (move-cursor (max dist cdist) 0)))
> +    (move-cursor (- (max dist cdist)) 0)))
>  
>  (define (infinite-desktop.move-top)
>    (let ((dist (- infinite-desktop.move-distance))
> @@ -102,7 +102,7 @@
>              (< (+ viewport-y-offset dist) miny))
>         (setq dist (- miny viewport-y-offset)))
>      (set-viewport viewport-x-offset (+ viewport-y-offset dist))
> -    (move-cursor 0 (max dist cdist))))
> +    (move-cursor 0 (- (max dist cdist)))))
>  
>  (define (infinite-desktop.move-bottom)
>    (let ((dist infinite-desktop.move-distance)
> -------------------------------

Thanks.

> > Glad to see new-workspace (superb!), but I doubt that viewport is
> > not for such aim. The meaning of viewport as "enlarged screen with
> > scroll by screen-size" is getting vaguer with infinite-desktop
> > which is shipped in Sawfish-1.5. Read my other email of today on
> > this issue.
> 
> The point of infinite-desktop, as I understand it, is (a) to be
> flexible about viewport boundaries (i.e., the "infinite" part), and
> (b) to use the mouse to move around.  I'm personally not interested
> in the mousey part, but dynamic viewport boundaries make sense to
> me.  But to do it right it should update viewport-dimensions, etc,
> and interact properly with the pager.
> 
> > But if someone insists new-viewport, one resort I propose is to
> > expand the viewport dimension. :P
> 
> The new-viewport above just punts; if there's no empty viewport it
> does nothing.  That's probably not ideal, but I'm unclear enough on
> the big picture that I'm not sure what the best behavior would be.
> 

You would need to add a new line and place the window into the first
free row/viewport of that new line, if you ask me.

Keep up your Contributions ;)

Chris 

Attachment: signature.asc
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]