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

51–60 of 84 posts

Re: WxWidgets 3.2

#51

Post by smasher164 »

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…

wxPython is the only maintained alternative there. I think there’s an opportunity to create bindings to other languages with libClang nowadays. However, it’s gotta be done selectively, since there’s so much surface area in the API to fill in the gaps for C++’s standard library.

Re: WxWidgets 3.2

#52

Post by tut-urut-utut »

mwcampbell wrote: post #43
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.

SWT has its set of issues. Last time I had to do desktop UI, I went with Swing. Other option is going a JavaFX way, which even has a nice Clojure bindings.

Unfortunately, they are both non-native options.

Re: WxWidgets 3.2

#53

Post by ziotom78 »

butz wrote: post #37

Which version of GTK does WxWidgets use? Overview mentions "2.6 or higher", but Wayland support hints at GTK3, or am I wrong?

In the "Platform details" page [1] they say that GTK 3 is the default since WxWidgets 3.1.4, but if you want you can link against GTK 2 by calling `configure` with the flag `--with-gtk=2`.

[1] https://docs.wxwidgets.org/3.2/page_port.html#page_port_wxgt...

Re: WxWidgets 3.2

#54

Post by raphlinus »

mwcampbell wrote: post #45
raphlinus wrote: post #41

Earlier quoted context omitted.

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…

It used to be they didn't render high-dpi text correctly, but fixes went in for that. Even so, it's a hack and often not pixel perfect. If you're trying to do visually sophisticated things (soft shadows, fading animations), GDI+ is inadequate. So basically it looks antiquated. It might be fine for simple form-like programs.

My main point is that "native" covers a lot of ground, and "native legacy compatibility" and "native modern" are radically different technology stacks on Windows.

Re: WxWidgets 3.2

#55

Post by raphlinus »

badsectoracula wrote: post #50
raphlinus wrote: post #41

Earlier quoted context omitted.

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…

UWP is most definitely not HWND per control, and doing so would be incredibly limiting. I don't know the UWP (WinUI) internals, but on mac it's generally a CALayer per widget, and Core Animation is doing the compositing. On Windows, the Windows 8 equivalent is DirectComposition, but I think the WinRT Windows.UI.Composition interface has some capabilities not exposed through winapi.

Re: WxWidgets 3.2

#56

Post by corrral »

wslh wrote: post #10
tgv wrote: post #7

Earlier quoted context omitted.

I wrote a (simple) accounting/billing application for my inlaws' shop some 20 years ago wih wxWidgets. I developed it on a mac, but it ran on a PC. The PC was very modest even back then (some 486, at best), but the application ran like lightning.

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)

Users care a lot less about looks than designers and PMs (seem to) wish they did.

They like consistent, reliable, fast operation. Especially those first two things.

The things that make them most unhappy are: 1) programs that behave unpredictably—a predictable, consistent bug that happens every single time is preferable to an operation that fails 5% of the time, randomly, or a button that fails to register about half of all clicks, or anything like that and 2) changes to an interface they've already learned—because your new thing probably isn't 1/10 as "intuitive" as you think it is, so it's just another annoying arbitrary thing they have to deal with for no good reason, when they already had the last annoying, arbitrary thing figured out.

Now, where it might make a difference (maybe—but I'm skeptical) is screenshots on sales pages. Which I suppose is why design continues to be so anti-user.

Re: WxWidgets 3.2

#57

Post by wslh »

ale42 wrote: post #13
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)

> aesthetically wxWidgets (like many other UI libs) is not for 2022 wxWidgets applications are supposed to look native on every platform... what's the issue? Personally, I find apps with weird GUIs that don't look at all like the rest of the system very irritating. I would prefer developers to spend more time implementing features, and less making bling-bling UI things.

Using the native UI libs doesn't mean you have native UX experience. It is not only about the visual objects but also the interactions and flow.

Re: WxWidgets 3.2

#58

Post by jpmattia »

KronisLV wrote: post #48

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 m…

> I find myself wishing that they'd have a page of screenshots and code snippets for each components

The samples folder in the distribution pretty well fills this need. See eg https://docs.wxwidgets.org/3.2/page_samples.html

Re: WxWidgets 3.2

#59

Post by KronisLV »

jpmattia wrote: post #58
KronisLV wrote: post #48

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 m…

> I find myself wishing that they'd have a page of screenshots and code snippets for each components The samples folder in the distribution pretty well fills this need. See eg https://docs.wxwidgets.org/3.2/page_samples.html

That is nice to see and honestly probably what you'd be after in most cases, given the fact that you'd be developing locally anyways.

Re: WxWidgets 3.2

#60

Post by [deleted] »

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?

[deleted]
Post reply on HN