For the record, from an email I sent Sahil on the topic of welding on Windows on 2024-10-21:

In case of MS Windows, I can generally think of 2 potential options:

1) work on Qt welding on Windows
2) work on welding using native Windows widgets


For 1), Jan-Marek Glogowski started working on that several years, ago. There's a WIP branch called called `feature/macOS-weld`, so rebasing that onto latest master (or checking what in the branch is still relevant) might give interesting insights.

Whether using Qt on Windows more generally would be beneficial/a good option in the long run is something that would still need to be explored and discussed more widely if somebody is interested in looking into that. Rafael e.g. mentioned the idea during LibOCon, as he saw that you had to implement things multiple times for your color customization project (once for GTK, once for Qt, once for Win, once for macOS).

It would most likely need more changes besides "just" rebasing the above branch, e.g. likely needs a better solution for rendering. (Cairo is currently used for rendering with the Qt VCL plugins on Linux. IIUC, on Windows, LO's experimental QPainter rendering path would be used, which likely has all kinds of issues. Exploring alternatives, like using Skia could be an idea, for which code should generally exist in LO, but not integrated with Qt at this point in time.)

From an a11y perspective, using Qt should e.g. also give us UIA support via Qt, without having to implement a UIA bridge ourselves. (But would most likely require fixing things in Qt or adding API there,..., and also require a transition from IAccessible2 to UIA in the assistive technology, e.g. adapting the LO app module in the NVDA screen reader.)


For 2), that could probably be implemented similar to the way that it is done for GTK (and now partially for Qt), but using the widgets provided by the Windows platform API, which I'm personally not very familiar with.


1) could have the advantage of being able to share code and avoid having to implement/maintain the "same things" multiple times.
2) might give more flexibility, and avoid a dependency on Qt.


In any case, I think that good starting points to learn about welding could be these:

* Earlier email discussion about Omkar's Outreachy project on Qt welding. See thread starting here:
https://lists.freedesktop.org/archives/libreoffice/2023-December/091281.html

* corresponding Bugzilla ticket and related commits already in master so far:
https://bugs.documentfoundation.org/show_bug.cgi?id=130857

The general idea/approach for Qt now is to look into one dialog at a time, implement what's needed for that one, then add it to an explicit list of .ui files for which the native Qt implementation gets used (s. e.g. recent commits for an example).

Microsoft has moved on from win32, and unlikely we can afford to port it all over to native WinUI framework.

Qt/win32 toolkit seems a reasonable alternative for welding "cross platform" even though GTK3/4 has gone native.

Though kind of seems worthwhile to consider moving UI further onto a skia lib based toolkit, like skui, and moving project away from cairo libs for vcl plugins, and performant graphics primitives.

(In reply to V Stuart Foote from comment #2)
> Microsoft has moved on from win32, and unlikely we can afford to port it all
> over to native WinUI framework.
> 
> Qt/win32 toolkit seems a reasonable alternative for welding "cross platform"
> even though GTK3/4 has gone native.
> 
> Though kind of seems worthwhile to consider moving UI further onto a skia
> lib based toolkit, like skui, and moving project away from cairo libs for
> vcl plugins, and performant graphics primitives.

Per https://github.com/nextcloud/desktop/pull/7416#ref-issue-2778934395, Qt6 now implements a Fluent Design application style, so in the absence of proper WinUI2 or 3 support (which would be the much better choice than "Win32" – whether WinForms or otherwise) Qt probably covers this case too.

> 1) work on Qt welding on Windows

I would prefer this one

Set to NEW because Sahil wants to realize it

Congrats Sahil for undertaking this. Improving the look/polish on Windows is important for attracting new users and addressing complaints ("Why does the UI seem old?")

Two layperson's questions:

Q1: Does "native win32 widgets" mean the widgets will look different on different Windows versions? Or will they be the same widgets on all Windows versions, but - a set of widgets which all versions of Windows offer natively?

Q2: Can someone put up some screenshots of what the "current" and "intended" widgets look like?

(In reply to Michael Weghorn from comment #1)
> In case of MS Windows, I can generally think of 2 potential options:
> 
> 1) work on Qt welding on Windows
> 2) work on welding using native Windows widgets

Speaking as a non-GUI-developer and non-LO-developer... Why is option (1.) relevant? Don't we already have a Qt backend? Which uses the same widgets that would be used here?

(In reply to Eyal Rozenberg from comment #5)
> (In reply to Michael Weghorn from comment #1)
> > In case of MS Windows, I can generally think of 2 potential options:
> > 
> > 1) work on Qt welding on Windows
> > 2) work on welding using native Windows widgets
> 
> Speaking as a non-GUI-developer and non-LO-developer... Why is option (1.)
> relevant? Don't we already have a Qt backend? Which uses the same widgets
> that would be used here?

The Qt VCL plugins on Linux currently mostly use VCL widgets (i.e. widgets from LO's own UI toolkit), just draw them to look mostly like "real" Qt widgets. Using actual Qt widgets is still work in progress, see tdf#130857.

That work could in theory be done on any platform if Qt was used by LO on that platform. So it is true that if this gets implemented on Linux, implementing the use of native widgets wouldn't have to be done again for each widget type on Windows. However, LO on Windows currently doesn't use Qt, so adding support for using Qt on Windows inside LO would still be a prerequisite *if* going/evaluating that route (s. WIP branch from jmux mentioned in my comment 1).

(In reply to Eyal Rozenberg from comment #5)
> Q1: Does "native win32 widgets" mean the widgets will look different on
> different Windows versions? Or will they be the same widgets on all Windows
> versions, but - a set of widgets which all versions of Windows offer
> natively?

Version 25.8 drops support for Win 7 and 8/8.1, so things are a bit simpler now.

The VCL approach has been to use the "platform's native widget toolkit". This creates a lot of work in the form of the vcl plugins. I would be lying if I say "I don't want to go Qt", but people say Qt is bad, really bad :). 

They have some licensing mess which I don't understand fully, but the overall picture that I get is that things are the way they are for a reason:
  - if "Qt Group" doesn't play nice, we will have options.
  - this approach is used by big game engines and is the preferred approach for big projects, considering they have the man hours to do it well.

I have been reading/writing/scared-enough-times-by the vcl/qt welding code since mid January of this year, and I can say that "I understand the problem and the action items".

It seems very much possible to implement it in win32, which is my current plan. This wouldn't make much difference to the "looks" of the application, but would act as a rock solid native UI for libreoffice on windows.

I looked into other native widget toolkits for winodws like WinUI3 and WinRt, but they are quite new/slow/not-widely-used-and-supported?? So in the next few weeks (1-2 hopefully), I expect to have the first native dialogs out. currently I am working on the message loops (whether the application processes the dialog messages, or the dialog has a separate message loop). on the win32 side of things, I am creating wrapper classes for Dialog, Button, Label etc around win32.

patch : https://gerrit.libreoffice.org/c/core/+/182707

After the win32 implementation, I will look into WinUI3 and WinRt to have another implementation for windows to have "Modern Looking UI". The goal statement for me is "Make LibreOffice look modern(winui or winrt)/not-old-school(win32) on Windows" (how matters less -- qt or win32 or winrt or..)

(In reply to Sahil Gautam (allotropia) from comment #8)
> I would be lying
> if I say "I don't want to go Qt", but people say Qt is bad, really bad :). 

Who says that? :)

> They have some licensing mess which I don't understand fully, but the
> overall picture that I get is that things are the way they are for a reason:
>   - if "Qt Group" doesn't play nice, we will have options.

Since LO is open source, we can go with the open source option for Qt.
It's true that Qt being in the hand of one company places some risk, but then, there's also the KDE Free Qt Foundation [1] to secure the availability of Qt for open source projects.
I personally tend to think that if the Qt Group were ever to "not play nice", there would probably be a fork. (That's the advantage of open source - they can't prohibit/prevent that, as the license allows it.)

[1] https://kde.org/community/whatiskde/kdefreeqtfoundation/

> It seems very much possible to implement it in win32, which is my current
> plan. This wouldn't make much difference to the "looks" of the application,
> but would act as a rock solid native UI for libreoffice on windows.

That's up to you to decide. If I had to implement something, I would first look into Qt, but if you plan to go another route and are willing to maintain it, that's fine for me, too.

I would also have a go with Qt first. I saw a lot of projects using Qt, being more flexibile and offering a nice modern interface.

If you feel the win32 option would look better on Windows, we can go with that, but I think that going with Qt will benefit all platforms and will be less differences between Windows and others.