4 ms·
This is reminiscent of Gnome's PaperWM [0]. Not a Gnome user and just had the chance to try it for less than an hour, but the experience in my head sounded bett
by Gualdrapo 5y ago
This is reminiscent of Gnome's PaperWM [0]. Not a Gnome user and just had the chance to try it for less than an hour, but the experience in my head sounded better than it was in reality - though was more of 'unexpected behavior' things than faults in the concept.
I think this approach tries to solve the 'cramming too much windows in a single virtual desktop' that sometimes can be felt with tiling WMs. For example, when I'm drawing something in Krita I'd want to see some references of what I'm drawing - I'd just scroll a bit to unveil an adjacent Falkon window to browse some images on the internet, do some strokes and scroll back to Krita's window - without having to resize it in half.
[0] https://github.com/paperwm/PaperWM https://github.com/paperwm/PaperWM
- operator-name 5y agoI've sadly had a similar experience with System 76's Pop Shell[0]. That said I suspect graphical workloads and applications designed around conventional sizes and aspec ratios are generally not well suites for TWMs. [0]: https://github.com/pop-os/shell https://github.com/pop-os/shell
- unfocussed_mike 5y agoUnexpected behaviour is exactly the problem -- I can see a lot of potential for it in the demo in the video, which is hard to follow. Not to mention the serious problem with scrolling-within-scrolling. One of those windows could be a browser window, sized too thin so its content scrolls horizontally as well as vertically, and some of the content inside that browser window might scroll vertically or horizontally or both -- perhaps a textarea. Can the UI ever make it clear enough what scroll action is going to be triggered, or will there be a situation where you want to scroll one aspect but end up scrolling the whole desktop? It's better to keep scrolling _out_ of a design, and it's surely better to switch context whole apps at a time, and not have them half-off the screen (which is the exact sort of occlusion irritation that tiling window managers are meant to avoid, surely?)
- dan-robertson 5y agoWell you can just have different scrolling, eg hold the super key and scroll with the mouse or use four fingers at once on a trackpad. I feel like this is asking the question of whether the TAB key will indent or switch controls or switch to a different window or whatever when you have an ordinary wm.
- thfuran 5y agoYes, the tab key has miserable UX.
- unfocussed_mike 5y ago> eg hold the super key and scroll with the mouse This leads to the kind of unexpected behaviour I am talking about, where muscle memory gets tangled up or you're working quickly and you do the action you want for one scroll while accidentally still holding down the modifier key. When there's scrolling at so many levels in e.g. web content, binding yet more things to different modified scrolling motions is a bad idea. If gestures work (big if, in my experience, in a system that unless something has changed really recently still has less than stellar trackpad implementations) then it would be less painful. > I feel like this is asking the question of whether the TAB key will indent or switch controls or switch to a different window or whatever when you have an ordinary wm. Not something that troubles me in ordinary apps on the Mac, at all (because app switching is command-tab) but I concede that this is regularly aggravating on the web.
- tadfisher 5y agoScrolling the desktop is accomplished through keybindings, clicking the screen edges, or three-finger swipes, all of which are configurable. I'm not sure how it would interfere with in-app scrolling, and I use PaperWM primarily.
- HungSu 5y agoPerhaps I'm an outlier but PaperWM is one of the things I miss most dearly about Linux. (I'm on Mac/Win for now) I daily drove PaperWM for months and thoroughly enjoyed it. Quirks were noticed but ignorable, in particular I could not get multiple monitors to work as advertised.