Instead of #phosh I'm using a test client to hack on #phoc's gesture support. The red bar basically maps to phosh's top-panel. Red meaning `folded`, green `moving` and blue `unfolded`. The first prereqs for this are already merged and I hope to submit more over the next weeks. Animations need more work as does cancelation, etc but it's moving forward. The way it's implemented works for other kinds of gestures too and also for mouse and laptop touchpad gestures.
...and here's the same thing using #phosh. Needs more work and polishing but just to give an idea. It works pretty well with thumb only too but that's hard to record.
@agx Nice! Personally I'd be more interested in swiping up from the bottom so Phosh stops switching away from the focused application when I accidentally tap the bottom bar when pressing the keyboard's space bar.
@be that's the same concept, just turn the video upside down.
@be It's likely that the #phosh's top-bar becomes swipeable first though since the #phosh side needs more work in the app-grid to make this pleasant to use. The #phoc side doesn't care though.
In the matching phosh I have swiping enabled for both but the vertical scrolling in #phosh needs to become horizontal scrolling for that to be usable.
@agx Well whatever comes first I am looking forward to it and hope you will keep up the step for step development process because from what I can tell it allows you guys to make Phosh as stable as it is and add new features. In terms of features alone Plasma mobile could be ahead by now but it's very buggy in my experience and that's not at all mend as insult to any dev. The strategy is what we know from the Plasma team and usually works great for them but I daily drove Phosh for a reason :)
@agx what is the difference between those swipe gestures in Phosh compared to GTK apps that have swipe gestures, why does the compositor need to be involved?
@Alexmitter Imagine you want a swipe up with two fingers to close the application or a 3 finger horizontal swipe to switch to the next application: there's not GTK surface in these cases at all. Same goes e.g. for the case when you drag in a totally invisible surface (like in fullscreen). The fact that we have a tiny bit of top-bar / home button to pull in from is basically an implementation detail.
@agx Ah okay got it, thank you for the explanation.
@agx This already looks super nice and smooth!
@joao The demo shows what works somewhat. Need to fix the parts that don't work yet 🔧 🔨 👩🔧 👨🔧 first
@agx that looks so good!
@agx
Yes! Now the same gestures I use on android will work on Phosh! Tapping the bars was one of the most jarring things about moving over.
@agx Yes, please! 🤩
@agx I think the interaction should be with the window/app and not with the drawer.
Seems a little outdated.
@agx Well done, its looking super smooth, curious how the refactor of drawer and overview would look in this context, would it show more favourite icons in the drawer or would it keep the same 4 favourites and show the icons of the apps running in the overview so that information isn't lost switching from large to small screen.
@agx what could be neat is to have icons in the drawer to switch between different tiled display modes if displaying icons for running or recent applications is off the table. Clicking a button would be much faster than manually adjusting 4-8 adaptive apps. Lots of ways to approach it. :P
@oilipheist We have plenty of ideas - it's coding hands & minds that we're lacking 😎
If you want to hack on tiling irmprovements #phoc's repo has some issues already https://gitlab.gnome.org/World/Phosh/phoc/-/issues?scope=all&state=opened&search=tiling
With the current cleanups coming in this should even be fun to implement.
I should add that the client tells the compositor which surfaces are dragable and how so it's not hardcoded in #phoc. E.g. #phosh would mark the top panel and bottom bar dragable.