Re: Snap rewrite #2
On Thu, Dec 02, 2021 at 11:25:07AM -0700, Jaimos Skriletz wrote: > On Thu, Dec 2, 2021 at 10:46 AM Dominik Vogt wrote: > > > > This is about an accident during elastic paging development, but > > it feels "good" to me. I've secretly always hated the "snapping" > > effect of snap attraction. Windows jumping around is confusing, > > especially if the distance is big, e.g. if you use a "100" edge > > resistance. So here is the new idea: > > > > I like it when my window snap to edges/other windows. Though I also > like this idea as well, I can see both being useful. Is this going to > be configurable so a user can use the behavior they prefer? It could be configurable at the cost of complete code duplication. The existing method is only aware of the window's requested position. The new method needs to keep two window positions, the position where it was blocked and the position where it would be if there were no blocking. Apart from the visual annoyance, the conventional method has some usability problems because it's impossible to place windows a few pixels away from other windows, or a little bit over the screen edge. (Of course you can do that with the Alt key, but few people know about the keybindings at all). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Snap rewrite #2
On Thu, Dec 2, 2021 at 10:46 AM Dominik Vogt wrote: > > This is about an accident during elastic paging development, but > it feels "good" to me. I've secretly always hated the "snapping" > effect of snap attraction. Windows jumping around is confusing, > especially if the distance is big, e.g. if you use a "100" edge > resistance. So here is the new idea: > I like it when my window snap to edges/other windows. Though I also like this idea as well, I can see both being useful. Is this going to be configurable so a user can use the behavior they prefer? jaimos
Re: Removig the "Emulate" command
On Thu, Dec 2, 2021 at 6:15 AM Dominik Vogt wrote: > > The command > > emulate mwm > > has almost no effect. I'd like to remove it. There are only > three things it controls: > > 1) The geometry window during move and resize is hard coded to the >center of the screen. > >=> Give the window it's coordinates explicitly. There is already a new GeometryWindow option which can control the location of the geometry window. So this is now fully configurable outside of the emulate options. > > 2) During an interactive placement, to tell fvwm that you want to >resize the window after placement: > mwm mode: press shift + button 1 > fvwm mode: press button 2 > >=> Just allow both. > Is this configurable via some binding. If not we should make the button for this configurable via a binding, and just choose one for the default behavior that can be changed. > 3) Some weirdness about initial drawing of the wire frame. > >=> Remove that special case. It makes zero sense. > > Opinions? I'm unsure of any other problems here. I would just put some other method to configure these aspects if there isn't already one in place. jaimos
Snap rewrite #2
This is about an accident during elastic paging development, but it feels "good" to me. I've secretly always hated the "snapping" effect of snap attraction. Windows jumping around is confusing, especially if the distance is big, e.g. if you use a "100" edge resistance. So here is the new idea: When one window is pushed against another window's border or some other barrier (screen edge, whatever): A +B + C + *| |* | * -+|-+| -+ |+ |+ +|--- -+ -+ -+ -> -> -> It stops in that position while the pointer moves on (* in the image), image B. When the pointer finally moves too far, the window does not jump towards the pointer position but simply resumes moving as if this "blocking" never happened (image C). When moving the window back to the left, it just moves freely without being blocked in any place. Think of the other windows border as a jammed door: To get through, you have to push. This causes pressure, and when that's hight enough, the door opens. Going back is easy because the door is already open. And if you can give up pushing at any time and just walk back. -- To push a window past the screen edge, just keep pushing. Once the edge's resistance is overcome, the window moves as if nothing had happened. When you pull it back, it won't snap back to the screen unless you push it aginst the border again. -- This is now all possible because the elastic paging code keeps the pointer in the middle of the screen (invisible). There may be some tricky situations when top and bottom border are both near obstacles. -- To get a feeling for the new code (maybe 40% complete), check the latest version of the branch "dv/elastic-paging-prototype". It doesn't have paging yet or the new "snap" method. But do try to move windows over screen edges and try pressing Shift/Control during mouse movement. With Shift the window moves much faster (factor 8) and with Conrol slower (factor 0.5). Now that the fixed offset between pointer and window position doesn't exist anymore, it's easy to do things like this. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
