Re: [STUMP] Feedback and bugfixes

[Philippe Brochard]

Shawn Betts writes:

> Philippe Brochard <address@hidden> writes:
>
>> I don't know what you plan to add in stumpwm, but I'd like to add some
>> little stuff :
>>
>> - A maximize/minimize current frame so the current frame pop-up to
>>   maximize-x, maximize-y, maximize-width, maximize-height. And
>>   vice-versa.
>
> I don't quite follow this one. Do you mean to have a frame that when
> unfocused reduces it's size to some specified amount and when focused
> returns to it's full size?
>
I mean to have all frames spliting as usual, but you can maximize just
a frame when you want to work only on it.

I've implemented this as this:

-- ~/.stumpwmrc ------------------------------------------------------
(defvar *maximized-frame-size* (make-frame :x 0 :y 0 :width 1024 :height 768))
;;; For a dual screen maximized frame on second screen.
;;(defvar *maximized-frame-size* (make-frame :x 1024 :y 0 :width 2048 :height 
768))
(defvar *current-frame-size* (make-frame :x 0 :y 0 :width 0 :height 0))
(defvar *current-maximized-frame* nil)

(defun maximize-frame (screen frame)
  (when *current-maximized-frame*
    (minimize-frame screen))
  (setf (frame-x *current-frame-size*) (frame-x frame)
        (frame-y *current-frame-size*) (frame-y frame)
        (frame-width *current-frame-size*) (frame-width frame)
        (frame-height *current-frame-size*) (frame-height frame))
  (setf *current-maximized-frame* frame)
  (setf (frame-x frame) (frame-x *maximized-frame-size*)
        (frame-y frame) (frame-y *maximized-frame-size*)
        (frame-width frame) (frame-width *maximized-frame-size*)
        (frame-height frame) (frame-height *maximized-frame-size*))
  (sync-frame-windows screen frame)
  (focus-frame screen frame))

(defun minimize-frame (screen)
  (when *current-maximized-frame*
    (setf (frame-x *current-maximized-frame*) (frame-x *current-frame-size*)
          (frame-y *current-maximized-frame*) (frame-y *current-frame-size*)
          (frame-width *current-maximized-frame*) (frame-width 
*current-frame-size*)
          (frame-height *current-maximized-frame*) (frame-height 
*current-frame-size*))
    (sync-frame-windows screen *current-maximized-frame*)
    (setf *current-maximized-frame* nil)
    (focus-frame screen (screen-current-frame screen))))

(defun toggle-minmax-frame (screen frame)
  (if *current-maximized-frame*
      (minimize-frame screen)
      (maximize-frame screen frame)))


(define-stumpwm-command "max" (screen)
  (maximize-frame screen (screen-current-frame screen)))

(define-stumpwm-command "min" (screen)
  (minimize-frame screen))

(define-stumpwm-command "toggle" (screen)
  (toggle-minmax-frame screen (screen-current-frame screen)))
----------------------------------------------------------------------

And I have add a minimize-frame in all part of user.lisp which use
frames.

(defun horiz-split-frame (screen)
  (minimize-frame screen)
  ...)

Idem for vert-split-frame and choose-frame-by-number.


I use it as this: I split my screen with a frame for each group of
applications (a frame for mail/net, a frame for testing stumpwm, a
frame to work on another project etc...) and I maximize the frame I'm
currently using. With a minimize-frame in choose-frame-by-number it
behave like an exposé on MacOSX :)
=> No need for multiworkspaces.


>> - A save layout as the emacs windows register so you can switch from a
>>   view to another. I think this can be done by saving each frames (x,
>>   y, width, heigth) and each window number in each frames. Or maybe a
>>   better way is to save *screen-list*.
>
> Yes, I think this would be useful. If you feel like putting something
> together I'll have a look at it. If you're able, come by the #stumpwm
> channel once you have a patch and we can discuss it faster than email.
>
Well, now I have maximize/minimize, I don't know if I really need
saving layout. Hum, I have to use stumpwm with maximize to see if that
hurt me to not have it :)

>> - Maybe a way to place a frame at x,y, width, height (but this break
>>   the stumpwm philosophie and I'm not sure it's a good idea).
>
> At this point I don't intend to formally support that. But it's
> possible and I'm not going to stop you from doing it. Perhaps at some
> point we might want to look into having "workspaces" or "virtual
> desktops" which have a window managing theme (tiled, non-managed, etc).
>
No, I agree with you, I don't want that too. I have had this idea with
The Gimp in mind (ie: to place each windows at a place). But as I can
split frames with diffrents ratios, I'm happy with the standard
stumpwm way.

>> - A way to select window/frame with keyboard up/down or with the
>>   mouse. (this can be simply an dialog window with all frames/windows).
>
> Have you looked at fselect? It's bound to C-t f.
>
Yes, I know it. What I mean is a way to select a frame or a window
with a nice little window that show all choices and that I can select
with my mouse or simply with the cursor keys. This is when I don't
need to be efficient and I want to use my mouse :)


>> I can hack some of this stuff if you want.
>>
>>
>> For now, I've add a little command to select a window by number but
>> with the windows list displayed (I just move the window list a little
>> below the input dialog). You can find this stuff here if you're
>> interested :
>>
>>    http://hocwp.free.fr/temp/stumpwmrc
>
> This seems like a useful command. Why not just display the window list
> and then read a command from a kmap that has 0-9 mapped to "pull N"
> (where N is 0-9)? There could be other useful commands one might want
> to have the window list visible for that one could add to this keymap.
>
Yes, but sometimes I have more than 10 windows on my screen (standard
app mail/net + apps on my machine + apps on remote machine...)
So, I'm happy with this command. But a way to select directly a window
by its number with the windows list displayed may be a good thing.

>> PPS: Also stumpwm crash when I use links2 in graphic mode (problems
>> with geometry-hints).
>>
>>      http://links.twibright.com/
>
> Ah okay. I'll look into it. Thanks.
>
Ok, thanks. I havn't had time to debug this part to be more precis.


Philippe

-- 
Philippe Brochard    <address@hidden>
                      http://hocwp.free.fr

-=-= http://www.gnu.org/home.fr.html =-=-