On Mon, Jul 19, 2004 at 06:30:56AM -0600, Matthew Kettlewell wrote: > > It makes little sense with resizing. Most applications demand a > > certain resize step size (e.g. the font width or height). You can > > only rarely snap them to adjacent windows without moving them. > > For me it goes hand-in-hand with productivity, a feature that I've > been looking for for quite some time. So for me it makes perfect > sense. > > For example, lets say that I ( obviously I'm doing things different > from others ) want to have 3 terminal windows for various compiles on > the same page. For me, I quite often like to have them stacked > horizontally one right on top of the other, taking up roughly 1/3 of > the available screen space (better readablity of output on multiple > terms that I can resize if I need the whole context). This task would > be much easier to accomplish by dragging a window to the bottom (move > operation) then resizing it to the left and right screens (snapping > being the key) and then having the other 2 terminals snap to the > terminal and screens through resize operations.
Is this the layout you have in mind? +----------------------+ <-- screen | | | | | | | | | | |+--------------------+| <-- compile windows, all with the same || || size and position |+--------------------+| +----------------------+ I don't see what SnapAttraction would buy you here. And in any case, the same effect can be achieved much easier with Maximize. For example, I have key q tsfw maximize toggle 100 0 Whenever I want to have a window span all the page width, I just press ctrl-meta-q. No fiddling with the mouse required. Or you could bind it to a decoration button. mouse 3 2 n maximize toggle 100 0 I think the real productivity issue is that you're resizing your windows manually :-) With 2.5.11 (i.e. the current version with a fix that I have just committed), also allows the same effect without maximizing: resizemove frame 100 keep 0 -0 You may also want to take a look at the "grow" option to Maximize. > Yes I could create a script that gets called through a menu op or a > key binding, but I'm quite know for just shuffling things around, so > this would never really solve my problems. > > I haven't looked at the code, but it seems to me that the issue of > resize-stepsize could be methodically handled in a reasonable fashion. > > I was only looking to see if there were any plans on updating this > feature, not to implement it myself, but now I've gotten a bit > curious. You seem to know a bit about this section of code, If you > could point me to the base files that deal directly with this, I just > might take a peek and see if I can implement something on my system > that will work. fvwm/move_resize.c Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED]
pgphgviS0EWFg.pgp
Description: PGP signature
