Skip to content

BUG: Screen not fully redrawn in some views #1448

Closed
#1620
Closed
BUG: Screen not fully redrawn in some views#1448
#1620
Labels
arch/amd64amd64 / x86_64area/tuiTerminal UI / view layerbugSomething isn't workingneeds-responseWaiting on issue author replyos/linuxLinux-specificos/windowsWindows-specific

Description

@Brixy
Brixy
opened on Jun 6, 2026

Describe the bug

The TUI is not fully redrawn (not quite sure about the correct wording) when entering "View Inbox", please see screenshots below.

Other views (compose, marketplace, settings) are not affected.

I'm using matcha's encryption, so this may be the reason. Currently I cannot turn encryption off due to #684 for testing purposes.

Two ways to force redrawing the TUI

  1. When I go back to matcha's start screen (ESC) and re-enter inbox view everything looks correct.

  2. I'm using Niri or River as windows managers. As soon as I resize the window containing matcha, matcha's TUI is redrawn and everything looks correct.

To reproduce

  1. Enable matcha's encryption(?)
  2. Kill matcha
  3. Start matcha
  4. Enter password
  5. Enter "View Inbox" -> screen looks like shown in the screenshots
  6. ESC
  7. Enter "View Inbox" -> everything looks correct

Expected behavior

I would expect the TUI screen to be fully redrawn when entering any of matcha's views.

Remaining text from the start screen should be removed.

Text like / __ '__ \/ __ '/ __│ ___/ __ \/ __ ' should be removed.

Screenshots

Image Image Image

Matcha version

496a775

Go version

go1.26.4 linux/amd64

OS

Linux

OS version

Void

Architecture

amd64 (x86_64)

Terminal

foot

Additional context

No response

Activity

  1. Brixy
    added
    bugSomething isn't working
    needs-triageAwaiting maintainer review
    on Jun 6, 2026
  2. github-project-automation
    added this to v1 Releaseon Jun 6, 2026
  3. github-project-automation
    moved this to Backlog in v1 Releaseon Jun 6, 2026
  4. floatpanebot
    added
    arch/amd64amd64 / x86_64
    area/configConfiguration / settings
    area/pgpPGP / encryption
    area/senderSMTP send path
    area/tuiTerminal UI / view layer
    os/linuxLinux-specific
    os/windowsWindows-specific
    on Jun 6, 2026

  5. andrinoff commented on Jun 6, 2026

    @andrinoff
    andrinoff
    on Jun 6, 2026
    Member

    @Brixy is this the first version where this occurs? Seems like a weird bug, all elements are stacking on top of each other for the whole screen, leaving almost no space.

    I did see this bug on some older version exclusively on Windows, but this is definitely not the case

  6. floatpanebot
    added
    needs-responseWaiting on issue author reply
    on Jun 6, 2026
  7. andrinoff
    removed
    needs-triageAwaiting maintainer review
    area/senderSMTP send path
    on Jun 6, 2026

  8. 7 remaining items

  9. floatpanebot
    removed
    needs-responseWaiting on issue author reply
    on Jun 7, 2026

  10. andrinoff commented on Jun 7, 2026

    @andrinoff
    andrinoff
    on Jun 7, 2026
    Member

    The best i could replicate this is

    Image"

    trailing W e, i could not get the whole screen (running Linux with foot)

  11. floatpanebot
    added
    needs-responseWaiting on issue author reply
    on Jun 7, 2026

  12. andrinoff commented on Jun 7, 2026

    @andrinoff
    andrinoff
    on Jun 7, 2026
    Member

    found the issue, not full representation. Something happens when daemon is starting, though not at full contrast (like you have).

    I am rather curious, why is daemon stopped on each of your use of matcha?

    I did want to add an option to not auto-start the daemon

  13. Brixy commented on Jun 7, 2026

    @Brixy
    Brixy
    on Jun 7, 2026
    Author

    Thanks a lot for investigating and the fix!

    I can confirm that the disabled daemon from #1450 resolves the issue.

    (I'm not quite sure whether I should close this issue since you mention that it's a temporary fix.)

  14. floatpanebot
    removed
    needs-responseWaiting on issue author reply
    on Jun 7, 2026

  15. andrinoff commented on Jun 7, 2026

    @andrinoff
    andrinoff
    on Jun 7, 2026
    Member

    It's a temporary fix. This will lead to a lot of functionality lost (though you still are loosing it). This is definitely code quality issues, starting a daemon shouldn't break UI

  16. floatpanebot
    added
    needs-responseWaiting on issue author reply
    on Jun 7, 2026
  17. andrinoff
    added 2 commits that reference this issue on Jun 7, 2026

    feat: make daemon optional (#1450)

    3375266

    feat: make daemon optional (floatpane#1450)

    b30febd
  18. github-project-automation
    moved this from Backlog to In review in v1 Releaseon Jun 24, 2026
  19. andrinoff
    closed this as completedin #1620on Jun 24, 2026
  20. github-project-automation
    moved this from In review to Done in v1 Releaseon Jun 24, 2026
  21. floatpanebot
    added a commit that references this issue on Jun 24, 2026

    chore: move daemon start log to debug (#1620)

    82a24e8
  22. andrinoff
    added a commit that references this issue on Jun 24, 2026

    chore: move daemon start log to debug (floatpane#1620)

    7466757
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    arch/amd64amd64 / x86_64area/tuiTerminal UI / view layerbugSomething isn't workingneeds-responseWaiting on issue author replyos/linuxLinux-specificos/windowsWindows-specific

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions