[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] Feedback and bugfixes
From: |
Philippe Brochard |
Subject: |
Re: [STUMP] Feedback and bugfixes |
Date: |
Sat, 11 Mar 2006 18:22:21 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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 =-=-