phosh issueshttps://source.puri.sm/Librem5/phosh/-/issues2021-08-09T08:20:51Zhttps://source.puri.sm/Librem5/phosh/-/issues/505Phosh doesn't show CLOSE ICON when APP is minimized (and no mouse is connected)2021-08-09T08:20:51ZErdinc AyPhosh doesn't show CLOSE ICON when APP is minimized (and no mouse is connected)I am well aware that Purism has decided to not show the exit button on the right upper corner when the app is minimized to close it. But I do not like swipe actions, I do not like how Apple structured the Apps on their OS and therefore o...I am well aware that Purism has decided to not show the exit button on the right upper corner when the app is minimized to close it. But I do not like swipe actions, I do not like how Apple structured the Apps on their OS and therefore on Android. Swiping is not very precise, me and several other users want an CLOSE ICON so that we can just click on it. Phosh should have a configuration to turn swiping on or off, but clicking should always work. Please use square icons, round icons are harder to hit.
PS: I am willing to help in development if needed.https://source.puri.sm/Librem5/phosh/-/issues/410should support search2021-08-09T08:20:47ZGuido Gunthershould support searchwe should support searching for documents, etc. via search providers (see !303, https://developer.gnome.org/SearchProvider/)we should support searching for documents, etc. via search providers (see !303, https://developer.gnome.org/SearchProvider/)https://source.puri.sm/Librem5/phosh/-/issues/327Rework PhoshActivity and PhoshOverview2021-08-09T08:20:45ZSebastian KrzyszkowiakRework PhoshActivity and PhoshOverviewCurrently `PhoshOverview` manually manages the relationship between `PhoshToplevel` (a representation of xdg-foreign-toplevel) and `PhoshActivity` (a display-only widget with an activity card), by tracking them with `g_object_{set/get}_d...Currently `PhoshOverview` manually manages the relationship between `PhoshToplevel` (a representation of xdg-foreign-toplevel) and `PhoshActivity` (a display-only widget with an activity card), by tracking them with `g_object_{set/get}_data}`, requesting and passing window thumbnails etc.
This is far from ideal - `PhoshOverview` is already quite a messy thing having multiple responsibilities. However, the most obvious way of fixing that - letting `PhoshActivity` consume and handle `PhoshToplevel` by itself - isn't good either, since 1:1 relationship between `PhoshActivity` and `PhoshToplevel` is very temporary (see #324; and potentially other things in the future like splash screens or suspended activites).
We need a new entity responsible for representing and managing a single activity. I'd propose renaming current `PhoshActivity` into `PhoshActivityCard`, and creating a new `PhoshActivity` class that would then handle any actual logic by itself, allowing `PhoshOverview` to not care about activity implementation details.
This way, `PhoshActivityCard` could just represent the state of any `PhoshActivity` given to it, regardless of its internal implementation, freeing `PhoshOverview` from unwanted responsibilities. This also opens a path for compositing multiple thumbnails onto a single activity, as needed for window stacks (#324), without cluttering classes that shouldn't need to care about it, since this whole logic could be then properly contained in implementation of `PhoshActivity`.
This may also touch `PhoshThumbnail`, since currently it sits in a rather awkward place between Overview, Toplevel and Activity.https://source.puri.sm/Librem5/phosh/-/issues/282show application names for the pinned / top applications2021-08-09T08:20:43ZMartin Kepplingershow application names for the pinned / top applicationsI'm always wondering why the "top" pinned applicaions don't show the name while all others do. IMO this should be consistent for all app icons.
We could also hide all and make the name for an app visible on "touch==1" so that it's visib...I'm always wondering why the "top" pinned applicaions don't show the name while all others do. IMO this should be consistent for all app icons.
We could also hide all and make the name for an app visible on "touch==1" so that it's visible while holding the finger down. Then one can choose to swipe away (move the whole overview drawer in the future I guess) or remove the finger in order to complete the "tap" and start the application.https://source.puri.sm/Librem5/phosh/-/issues/223Only show favorite apps in overview2021-08-09T08:20:42ZTobias BernardOnly show favorite apps in overviewThe app cards in the overview are currently smaller than they should be, and we show a scrolling version of the app grid below that, which is a bit weird.
We could move the overview a bit closer to the designs relatively easily, if we m...The app cards in the overview are currently smaller than they should be, and we show a scrolling version of the app grid below that, which is a bit weird.
We could move the overview a bit closer to the designs relatively easily, if we make the app cards larger, and only show the first row of apps below that. Swiping down or clicking the search entry would move down to the full app grid.
This intermediate state would look something like this:
![intermediate](/uploads/e18ac767f02dd6261cd07e4392be12d9/intermediate.png)
Longer-term design direction for reference:
![overview](/uploads/7981d44951da5ee088c9bd803889e97e/overview.png)https://source.puri.sm/Librem5/phosh/-/issues/61Group Dialogs with the appliation main window2021-08-09T08:20:40ZGuido GuntherGroup Dialogs with the appliation main windowApplication modal dialogs should not show up as separate windows in the window list (this needs support from the compositor).
See https://source.puri.sm/Librem5/chatty/issues/89Application modal dialogs should not show up as separate windows in the window list (this needs support from the compositor).
See https://source.puri.sm/Librem5/chatty/issues/89