Render-engine instead of platform's widgets

[top-master]

Last time I checked, wxWidgets was using the operating-system's native-widgets, like old deprecated Java API,
but Qt was and is using custom render-engine and theme, without using a single native-widget, like new recommended Java API, while having fully native-looking GUI (which even new Java API did never fully accomplish).

Hence I am using Qt since then (around 10 years),
but due to LGPL-3 license's limitations that new Qt versions have,
I would like to switch to wxWidgets.

However, I ask to enhance all GUI components and/or views to use such render-engine and theme (instead of native GUI components).

[vadz]

Sorry, this is really not an issue. I'm not sure what exactly are you trying to say (the references to Java don't help), but please consider posting your questions as advised in another issue you opened.

[top-master]

¯\(ツ)/¯ As said "I ask to enhance" and/or add feature, of course this is not an issue report.

My Java references are a precedence case, and prove that any GUI library and/or API that does not support said feature should be marked as deprecated in README.md file, and for example, redirect people to Qt or Flutter instead.

[vadz]

It's ok to add issues for adding features, but it's not really clear which feature do you mean, sorry. I.e. I just have absolutely no idea what could the "resolution" of this "issue" even be, I sincerely don't understand what are asking for.

But then this is not the best medium for discussing things, which is why I recommend using something else.

[top-master]

Native-looking GUI vs Native GUI

Use of the operating-system's native GUI-components is actually really bad, which is why the old Java API got deprecated and/or removed.

For example:

• In Microsoft Windows operating-system, every single GUI-component and/or child-view, like a button, has it's own separate real sub-window.

  Where "real" means the child-view being managed by operating-system to some extent, and the child-view having own separate handle (i.e. hWnd).

• But Qt and "new Java API" both create such real window only for root-view.

  Where "root-view" means the Window with 3 buttons at it's top (i.e. the minimize, maximize and close buttons).

• That's possible because in Java and Qt, all child-views are virtual, meaning they are positioned and managed by framework's layout-engine and render-engine, with native-looking Theme, instead of relying on operating-system for Theme.

The efforts Java and Qt put into layout-engine and render-engine ensures that custom child-views look exactly the same across all operating-systems, and never get affected by operating-system's inconsistency.

In other words, wxWidget users need to manually test GUI for each platform, on each change, unless they use wxQt !?

I think above explains without much discussion ;-)

[vadz]

We already have wxQt as you know. We also have, since a long time, wxUniv which doesn't use native widgets. Both of them require more work (a lot of it, in wxUniv case). Neither of them is the primary focus of this project, but contributions to both are welcome.

[top-master]

The problem with "wxQt" is Qt's new (L)GPL version 3 license, which does not allow hardware protected binary (Tivoization).
Unless wxWidgets uses Qt 5.6 or older (which allows LGPL 2.1)?

But I could not find "wxUniv" license, can you provide me URL?

Nevertheless, sorry that I was thinking of wxWidgets as a fully featured and complete alternative to Qt, while it seems that's not wxWidgets's focus.

[oneeyeman1]

@tabe ,
From the very beginning wxWidgets paradigm was "using native stuff whenever possible".
So if you want something non-native - you best bet is Qt/Java(sucks).

Yes, wxQt is for using Qt 5.x because of the license. However, what else people will be using in 2022+?

wxUniv have exactly same license as wxWidgets. Why should it be any different?
All you do is compile the library with --enbale-inoversal
But as Vadim said - it will require a lot of work to bring this port up to speed.

However, I don't know why you want anything that belongs to Qt to be implemented inside WxWidgets. They are completely independent libraries with different targets , paradigms and users.

Can you explain (preferably in plain English) what do you need exactly? Maybe it's already being done?

Thank you.

[vadz]

wxUniv is under the same licence as the rest of wxWidgets.

wxQt is documented to work Qt 5.2 and later. I'm not sure if it still does build with such old versions but it probably wouldn't be too difficult to fix it even if it can't.