Revamped user interface for Windows

[AliveDevil]

Please take part in our interface redesign polls

• 14507

  • 14508

  • 14509

  • 14510

• 14511

• 14512

• 14513

• 14514

  • 14515

  • 14516

Cyberduck interface is currently implemented with Windows Forms UI stack on .NET Framework 4.x. This imposes limitations regarding past and future improvements in Windows operating systems since 8.0.

Features not available, due to external or internal influence:

• High DPI scaling
  • ObjectListView, which hasn't been updated in ages for recent high dpi scenarios (missing development resources to improve the situation here)
  • Custom Control-Renderers, menus, labels, etc. - mixed signals from Microsoft how to really provide High DPI support for Windows Forms. There is a plethora of combinations of High DPI scenarios which need to be tested.
  • What High DPI Scenarios should be supported? 100%, 125%, 150%, 200%, 250%, 500%. Custom 359%?
• Dark Mode
  • Limitation of Windows Forms. There is no way of supporting this easily or reasonable^1
  • Classic Win32 desktop apps don't support this either (which WinForms is based on)

These features should be supported with a user interface rewrite on Windows, based on feedback, feature alignment with macOS and Windows Explorer experience:

• High DPI scaling, (native)
• Dark Mode, (native)
• Quick Look-feature
• Tabbed-interface
  • Discuss: Dragging between windows/out of tab-groups supported?
• Quick-navigation left sidebar, detail (list) view in content
• Multiple windows support
• Replace Sparkle Updater with MSIX Auto Update feature

Possible candidates: WPF, UWP, WinUI/Windows App SDK

WPF Native High DPI, implementation of quick look, tabs, etc. easily accomplished. Dark Mode is out of reach entirely, as there is no reason to rewrite all control styles just to get a dark mode, which has to support accent colors as well.^2

UWP: Deprecated.

WinUI Specifically WinUI3 with Windows App SDK: High DPI Scaling, Dark Mode, (possibly) Quick Look, tabs, quick navigation Not supported until Windows App SDK 1.1: Local toast notifications, multiple Windows

WPF XAML Islands with UWP/WinUI sounds just as bad as it is.

In order to implement these features, following things need to be completed before this can be implemented:

• Upgrade to .NET 6 (LTS)
  • Base Dependency Requirement: IKVM runs on .NET Framework 4.x only. Requires patching for .NET 6 support
• For our current supported platforms XCopy-deployment would be appreciated^3
  • still provide EXE/MSI installers? Migrate to MSIX entirely resolves the issue here

Issues, with workarounds:

• IKVM is not working on .NET 6: https://github.com/iterate-ch/cyberduck/issues/13036#issuecomment-1466166575 This would allow us to buy more time, and make the backend/glue more resilient As this is Windows-specific, I don't see an issue with mixing Framework and Core here.
  • log4j: With the glue code and interop-layer between frontend/backend, we can eliminate this issue

Blocking issues:

• ~MSIX Auto Update is currently out of service~ // Internal prototypes support auto-update (through various means)

  The ms-appinstaller scheme(protocol) has been disabled. This means App Installer will not be able to install an app directly from a web server and it will need to be downloaded first.

• ~IKVM is not working on .NET 6~
• ~There are issues with IKVMc on .NET 6 with log4j^5, rendering it unusable~
• ~Windows App SDK 1.1 isn't released yet~ Released.

With a new user interface following will apply:

• No support for any Windows Client operating system older than build 17763 (version 1809/October 2018 Update)
  • Dropping Windows 7 (EOL 2020), 8 (EOL 2016), 8.1 (mainstream EOL 2018) entirely
• No support for any Windows Server operating system older than Windows Server 2019
  • Dropping support for Windows Server 2008R2 (EOL 2020), 2012 (mainstream EOL 2018), 2012R2 (mainstream EOL 2018), 2016 (mainstream EOL 2022)
• No bundled support for Bonjour (install separately?)

[AliveDevil]

Food for thoughts:

There is the WinRT-interop layer, that is supported by both, .NET Core (through CsWinRT) and .NET Framework (native), we could provide a WinRT-interop library that glues a .NET Core (WinUI) frontend to a .NET Framework backend.

Thus eliminating the blocking dependency on .NET Core support for IKVM.

// Reason for glue-code: If I assume, that .NET Core works, how I think it works, it may work without this WinRT-layer, when hosting .NET Framework inside .NET Core. As I didn't check, what would happen if we're mixing Framework and Core in the same process.

[dkocher]

We have a poll regarding a new layout in #14507.

[jaimedelano]

Add image/video thumbnails, large icons, grid layout, etc

[AliveDevil]

Thumbnails won't be possible, unless you want to preemptively download every single file from any remote, generate the thumbnail, and trash the downloaded file.

[dkocher]

Thumbnails won't be possible, unless you want to preemptively download every single file from any remote, generate the thumbnail, and trash the downloaded file.

Relates to #13401.

[dkocher]

🎉 The new UX prototype from @janwaelti98 can be found in janwaelti98/UXForCyberduck

[thefunkyjoint]

I've been a Cyberduck user for years, but after moving to a Windows machine and having to deal with the absent of dark mode, today it's time to say goodbye to another app that has dark mode. Thank you .

[PeterTucker]

@thefunkyjoint Which SFTP client did you find that supports dark mode?

[BMurri]

WinForms is getting dark mode in .NET 9 (it's in with several bugs in 9-rc1 out now). It would require moving from Framework to net 10 in late 2025 to get a robust version of it, though.

WPF is also getting in-box support for dark mode in .NET 9, with likely fewer bugs than WinForms, although 3rd parties have provided reasonably robust dark mode solutions for WPF for the better part of the last decade, several of which work in Framework also. Microsoft will not likely backport either of those fixes to Framework, though.

[AliveDevil]

I'm impressed Microsoft cares about these, nice find 👍 @BMurri

We are already moving core components to .NET 8, and decided to move away from WinForms/WPF to WinUI 3 once the .NET 8 code here has stabilized. The changes necessary to get Cyberduck WinForms code to anything .NET Core is not trivial, and several third party components have not maintainer anymore.