Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WxWidgets 3.2

wxwidgets.org

Post reply on HN
Print view View original

41–50 of 84 posts

Re: WxWidgets 3.2

#41

Post by raphlinus »

72deluxe wrote: post #12
wslh wrote: post #10

Earlier quoted context omitted.

The same for a MS-DOS Clipper [1] application written 30 years ago. Sorry, with all due respect to the wxWidgets contributors, aesthetically wxWidgets (like many other UI libs) is not for 2022. [1] https://en.wikipedia.org/wiki/Clipper_(programming_language)

But it just wraps the native controls...? You're effectively saying that native controls are not for 2022...

A serious question: what are native controls on Windows? Is the Windows XP era where each control is its own HWND (and usually drawn with GDI+)? Is it Windows 7 era where the drawing is Direct2D? Windows 8 where the elements of the app come together with DirectComposition? Or maybe Windows 10 style which is an evolution of UWP (now rebranded WinUI), with drawing in Win2D?

Re: WxWidgets 3.2

#42

Post by mwcampbell »

gen2brain wrote: post #20

wxWidgets are a perfect choice if you want cross-platform native controls. Just a reminder, Qt doesn't use native controls, it just emulates the native look and feel. Besides wxWidgets I know only IUP that uses system native controls (though Cocoa is a work in progress), and IUP deals with just UI, wx is like a Qt, a lot more.

Eclipse's SWT for Java also uses native controls, and IIRC it does so more consistently across platforms than wx. In 2015 I wanted to develop a desktop app in Python, but use SWT, so I did a hacky mongrel setup where I used the pyjnius Python package to load the Avian lightweight JVM into my CPython process so I could use SWT. Avian is dead now, so if I ever have to port that app to ARM64 for Apple Silicon Macs (right now it runs fine under emulation), I'll be in trouble. But at least for now, the app has a reasonably lightweight cross-platform UI.

Re: WxWidgets 3.2

#43

Post by mwcampbell »

tut-urut-utut wrote: post #19

WxWidgets is nice, used it in the past at one ocasion. It's just that I don't have any desire to touch anything C/C++. If it had a Java wrapper so I can use it with Clojure, it would be another topic.

For something like wxWidgets that runs on the JVM, check out Eclipse's SWT.

Re: WxWidgets 3.2

#44

Post by phkahler »

api wrote: post #35
heavyset_go wrote: post #31

Earlier quoted context omitted.

LGPL stipulates that you should be able to link against your own version of the LGPL library you're integrating, that's to say a user should be able to run an app with their own version of the LGPL library if they want to. For some app distribution channels, like with iOS apps, that can be difficult to impossible to actually implement given the control Apple has over app packaging and distribution. Otherwise, you sho…

Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out? You theoretically can.

>> Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?

You also have to offer them source code, or just ship it along with.

Re: WxWidgets 3.2

#45

Post by mwcampbell »

raphlinus wrote: post #41
72deluxe wrote: post #12

Earlier quoted context omitted.

But it just wraps the native controls...? You're effectively saying that native controls are not for 2022...

A serious question: what are native controls on Windows? Is the Windows XP era where each control is its own HWND (and usually drawn with GDI+)? Is it Windows 7 era where the drawing is Direct2D? Windows 8 where the elements of the app come together with DirectComposition? Or maybe Windows 10 style which is an evolution of UWP (now rebranded WinUI), with drawing in Win2D?

For lightweight utilities, I think the user32 controls (HWND per control, drawn with GDI) are still a reasonable choice. That's the one GUI toolkit that's guaranteed to already be in the working set on all versions of Windows, thus minimizing the impact on startup time and memory footprint. Do those controls just look hideous to modern users? I obviously can't judge that for myself. Or is there a problem with the way they render text on high-DPI displays?

Re: WxWidgets 3.2

#46

Post by phkahler »

justin66 wrote: post #33
diego_moita wrote: post #21

wxWidgets has a sublime idea: an api that is just a wrapper over native controls. For cross platform frameworks it is fast and light. The very opposite of bloatware. But it also has a terrible flaw: its heavy-templated C++ api, hard to port to other languages. I don't want to get stuck on C++. I want to use Go and Rust. And all the wxWidgets ports to those languages suck, big time. Show me a solid wxWidgets for Rust…

This isn't really a fault in WxWidgets. It's not like there are any good Go or Rust UI toolkits.

>> This isn't really a fault in WxWidgets. It's not like there are any good Go or Rust UI toolkits.

GTK-rs is decent for rust on Linux. Not sure how it does on other platforms.

Re: WxWidgets 3.2

#47

Post by SloopJon »

For those thinking that this is just another version, note that 3.2 is a stable version, with 3.0 having been first released almost nine years ago. In the interim, I'm sure many people have used 3.1, but now you get all of the fun enhancements without an asterisk.

Re: WxWidgets 3.2

#48

Post by KronisLV »

They do have a nice page of screenshots that demonstrate some of the projects out there that use wxWidgets: https://wxwidgets.org/about/screenshots/

That said, I find myself wishing that they'd have a page of screenshots and code snippets for each components, like web development frameworks typically have, for example: https://www.primefaces.org/primevue/calendar

Of course, you cannot run those components live, but might at least have screenshots of each component on each supported platform.

Re: WxWidgets 3.2

#49

Post by justin66 »

phkahler wrote: post #46
justin66 wrote: post #33

Earlier quoted context omitted.

This isn't really a fault in WxWidgets. It's not like there are any good Go or Rust UI toolkits.

>> This isn't really a fault in WxWidgets. It's not like there are any good Go or Rust UI toolkits. GTK-rs is decent for rust on Linux. Not sure how it does on other platforms.

As a user GTK typically feels a little funky on Windows, although I don't know how much of that is a fault with the toolkit and how much of it is a function of Windows definitely not being those developers' primary target.

I'm delighted to hear Rust programmers have got something worth using.

Re: WxWidgets 3.2

#50

Post by badsectoracula »

raphlinus wrote: post #41
72deluxe wrote: post #12

Earlier quoted context omitted.

But it just wraps the native controls...? You're effectively saying that native controls are not for 2022...

A serious question: what are native controls on Windows? Is the Windows XP era where each control is its own HWND (and usually drawn with GDI+)? Is it Windows 7 era where the drawing is Direct2D? Windows 8 where the elements of the app come together with DirectComposition? Or maybe Windows 10 style which is an evolution of UWP (now rebranded WinUI), with drawing in Win2D?

The HWND-based ones that come with Windows would be the native controls as this is how the underlying window system works. The WPF/UWP/etc UI stacks are built on top of HWND stuff pretty much the same way as Java Swing or JavaFX were made that largely (especially the latter) ignore the underlying window system.

Of course since they come with the OS you might as well use those instead of bundling a separate UI toolkit, but IMO if you consider them as native as the HWND stuff then might as well consider everything native - AFAIK Windows even comes with a shared Electron/Chromium instance applications can use so in that case you could say anything that uses Electron is native on Windows :-P.

Post reply on HN