Currently when a window is resized, we always start a transaction. However it is not necessary to start a transaction when the window wasn't actually resized. This is especially important for layer-shell windows which will always have their dimensions updated for each surface commit.

The current application gallery behaves somewhat awkwardly and doesn't ideally maximize space usage. So instead a slightly different design approach should be taken.

Android / Gnome Mobile might be more clutter-free application galleries to look at instead:

Only the left half of windows is rendered in landscape mode.

When the display is rotated, the framebuffer is not copied correctly anymore. Instead of having a buffer that has its dimensions swapped in landscape mode, the dimensions are kept and the buffer written to it is upside down it the center of it.

The gesture handle is always visible and cannot be drawn over by any application. Because of this we should skip trying to draw it whenever possible.

Going through the application drawer every time when switching between applications can be a bit of a hassle, especially when quickly switching back and forth between two specific applications.

To make this a little easier, it should be possible to swipe left/right at the bottom of the screen to switch between running apps.

When starting a gesture on the gesture handle, the touch events are still propagated to the active surface. However the active surface should logically be cleared since the gesture handle is outside of any window bounds.

As a result even in tiled mode the primary window can be scrolled by touching the gesture handle, which is very unexpected.

Currently a touch is determined to be within a surface when it was made within the surface's geometry, however it is possible to remove part of a surface's input region using set_input_region.

To ensure clients with intentionally reduced input regions behave properly, we should check for the presence of input regions.

When dragging up from the gesture handle in the application overview, all windows are minimized and the background is shown.

To make this a little more clear, it should be hinted what this action does by moving up all the visible overview windows at the same time while the gesture is performed.

Risks

With only a single window open, it might be difficult to distinguish this to the "close window" drag.

Based on current testing, it seems to take about 25ms to render each frame. As a result the average framerate would be about 40 FPS, dipping below 30 FPS consistently.

While the PinePhone's GPU isn't particularly strong, I'd hope we can improve on this.

After some time with the display disabled, the phone should enter a low-power state to preserve more power than just running at full tilt with the screen disabled.

Since sleep is very quick to recover from, entering after a relatively low timeout should be fine. Probably something like 30-60s.

When rotating the output in the application overview, layer shell windows don't seem to be resized appropriately. This can be seen since epitaph stays in landscape mode even after rotating back to portrait mode.

Once leaving the overview the window is appropriately resized again, indicating an issue with catacomb's overview rather than epitaph.

When clearing focus by touching the gesture handle, it is not possible to regain focus again by touching the application itself.

Currently the post_start script is run as a daemon, however this creates problems when the Catacomb process is killed or crashes. Since the new parent is PID 1, it will keep running even after the compositor died.

This is especially problematic when the script tries to continuously restart applications like while true; do keyboard; done, instead of just quitting after it's done.

Due to an unknown issue, calling pre_exec on the Command spawned by daemonize::spawn causes a runtime panic inside of STD. Because of that the daemonization was removed temporarily.

While fitting for Catacomb's name, we should fix this and reintroduce proper daemonization to avoid dragging around zombies.

When closing the terminal emulator while virtboard is open, the terminal closes correctly but virtboard stays open with no way to close it (even when clicking on the gesture handle to remove focus).

To validate that damage tracking is working properly and ensure the compositor is updating efficiently, there should be a debug option which marks the damage in a bright, easily noticeable color.

When the screen is turned off, the polling rates of certain timers can be reduced drastically or disabled completely.

The orientation polling for example usually happens twice per second and it can be disabled completely while the display is off. Then on wakeup these timers can be resumed immediately and updated info will still be applied immediately while hopefully having saved some energy.

This should help with battery usage, though since the currently suspend timeout is very quick (30 seconds), it likely wouldn't change much. At the very least an investigation into the possible benefits seems warranted though.

Open 2 applications, close one, and try to focus the the other one with gestures.
The overview won't popup unless you focus something.

It is possible that a background window like swaybg is completely occluded by other windows. Still rendering it in that scenario is inefficient. Similar to #40, we should avoid drawing these occluded windows.

Whenever a frame doesn't render anything because there is no damage, an artificial vblank is spawned that will kick off rendering again once the output's frame interval has been reached. However it is not necessary to keep trying at every frame interval since we know that only surface commits or Catacomb UI changes could introduce new damage that requires rendering.

Instead of staging a new frame manually immediately, rendering should be paused indefinitely until a new surface commit is received. Ideally that surface commit should also be checked for damage, but it would likely be fine either way. To avoid freezing we also need to ensure Overview/D&D are taken into consideration.

Currently when a window emits damage beyond its bounds, it will cause unnecessary redraws of other windows. Since windows are clamped to within their bounds, we should do the same for their damage.

Currently there's only "snap back" behavior for the first and last window in the application overview.

To prevent people from reaching a "useless" state where they find themselves between two different windows, neither of which clearly have focus, the overview should automatically snap back to the nearest integer position to always keep one window as the clear center while no touch events are going on.

When a layer shell window moves position by changing its anchor, we currently do not damage the new or previous region. The new region is damaged only if its buffer has also changed and appropriate damage is reported.

In theory this movement would require us to damage the entire old plus the entire new geometry, but since we merge per-window damage anyway this would always damage the entire screen. So we can just make sure that the entire screen is damaged and move on with our lives.

The same thing applies to a layer shell window which have shrunk in size. We need to damage its old size to ensure the content is cleared properly. Here it might not be necessary to mark the frame as fully damaged.

Note that this is not relevant for windows with exclusive zones since these are already covered by transactions and thus cause a full redraw anyway.

When touching an overlay window in the application overview, the touch is ignoring the layer shell window and going straight to the overview. Thus it's possible to close windows without the windows being visible at all.

This issue has been observed when opening the overview after pulling down Epitaph's drawer.

Instead of just nuking everything, we should properly call all the destructors on SIGTERM to make sure we leak as little as possible.

Currently a clear is performed when drawing for the entire damaged area, completely ignoring any opaque windows overlapping the damaged area.

To improve performance, we should try to skip clearing entirely when we can determine that the damaged area is fully occluded.

The compositor is now in a state where it should be mostly usable for simple tasks. However this means that some previously unnecessary features are now reachable. One of these features is fullscreen applications.

It should be possible to fullscreen a browser window and have it behave properly without any issues. This should include opaque region checking, proper damage tracking, and responding to rotation without breaking.

When holding the power button (not just pressing it) to launch Tzompantli, it seems like sometimes the screen just turns off instead.

Currently catacomb uses a very specific fixed set of Smithay features. I don't remember why so probably good to check which ones are actually required.

Currently the transaction timer relies on the display's rendering to time out its transactions. However the refresh rate of the monitor can vary and ideally it should be able to suspend entirely. To work around this currently stalling is prevented while a transaction is still active, but especially with long-running transactions that might cause unnecessary energy usage.

Instead of looping with the vblank frequency, a timer should be used to kick-off rendering again only if it is actually necessary and the transaction has timed out. This allows completely getting rid of this code.

Currently whenever a transaction is updated the entire frame is just marked as fully damaged. This is somewhat unfortunate because transactions are usually just used to open/close windows where only the involved windows are damaged not the entire screen.

There's an issue with the virtual keyboard where clicking on it will cause the XDG window to lose focus. As a result, trying to make any input on the virtual keyboard will just close the virtual keyboard.

Currently there's one primary window and one secondary window which are always presented first in the application overview. If another window is opened, the layout of the primary/secondary window is discarded.

Instead of this, the layout of applications should be preserved. When a new application is opened, the old primary/secondary windows should stay grouped and be visible as such in the application overview. When cycling through applications with #19, it is possible to cycle through multiple tiled layouts and the overview can have multiple primary/secondary window combinations.

This way it's possible to keep windows grouped forever, so the user doesn't have to always set their stuff back up again. The only problematic thing is opening these grouped views in the overview, since just clicking on primary/secondary likely wouldn't work out. The easiest solution is likely that a click in the middle opens the group, a click at the top opens just the primary one as primary and a click at the bottom opens just the secondary one as primary. Alternatively it might also be fine to force users to use the D&D to destroy groupings.

This is likely best implemented as a follow-up to #19.

When the screen is turned off for more than a fraction of a second, rendering will break.

Currently it seems like the overview is redrawing permanently and not able to detect when no damage is present. This is due to the overview.animating_drag(self.layouts.len()) check always claiming an animation is in-progress.

Turning the display on/off is one of the most frequently used actions on a phone, it should be convenient and quick. Intuitively this should probably be put on a single-click of the power button.

The application launcher can be put somewhere else temporarily, or alternatively it can be kept on the power button and one of the two can be moved to long-press/double-click or similar.

When opening a layer shell overlay window like the Epitaph drawer, not all touch events seem to be forwarded properly. It's impossible to close the drawer again by "dragging" up from the bottom since these inputs are apparently forwarded to the virtual keyboard, which is visually ordered behind the drawer.

Currently when a window is dragged to be closed, it just disappears once it exceeds a specific threshold and the drag touch event is released. To make things feel a little more natural, the animation should continue until the window is completely off the screen.

67ce986 introduced a change which prevents gestures from being started when they originate on a layer shell surface. However this prevents gestures from being used while the keyboard is open.

The gestures should either be reenabled even when starting on a layer shell surface, which would mean that a different solution needs to be found for https://github.com/chrisduerr/epitaph, or there might be a keyboard solution which easily allows closing the keyboard so gestures can be used again.

It might also be interesting to see how modern Android/iOS systems behave while a keyboard is open.

Popups are broken

It should be possible to remove focus from the visible applications, so virtual keyboards which are based on focus can be closed by the user when they are not interested in inputting text.

The most sensible way to do this is by removing application focus whenever the gesture handle is tapped.

If the application is tapped again after focus was removed by tapping the gesture handle, the focus should be returned back to the application.

It seems like having multiple windows tiled seems to be utterly broken on master due to 4ed501a.

When starting catacomb after the Smithay rewrite, the screen always stays black until the power button is pressed twice. This seems to indicate that the vblanking might not be setup appropriately.

Currently when nothing has rendered in a frame the rendering is stalled indefinitely until additional damage is done. Since some applications might rely on receiving frames it would likely be safer to periodically send frame requests to applications.

Currently I haven't encountered any application that would necessitate this and it would also likely affect energy usage negatively. So this seems to be somewhat optional.

Currently while a transaction is active, no windows' buffers are imported. Effectively this is the same as not redrawing at all, making the current transaction logic an unnecessarily complicated implementation.

Instead we should keep updating unaffected clients, while only skipping imports for buffers affected by the transaction.

A horizontal drag in the application overview should mean that the dragged window moves at the same pace as the finger dragging horizontally on the display.

Currently the acceleration between the two is mismatched, making the horizontal drag feel "unnatural".

When a virtual keyboard is restarted while an application is running, then input cannot be made into that window anymore.

The XDG shell handler's toplevel_destroyed method should always be called when a window's surface.alive() state changes, however currently this is not the case. As a result windows do not die unless a transaction is started in a separate manner.