Page 1 of 1

Technical grounds for presumed widgets dissimilarity from native

Posted: Tue Aug 25, 2020 10:41 am
by swxw77
Based on my (small) experience with WxWidgets, and the WxWidgets main technical point, WxWidgets does use native widgets.

An HN reader posted some screenshots (see https://i.imgur.com/LjDhPOv.png), concluding that "I submit that Wx implements its own non-native widgets.".

Somebody gave an interesting explanation, stating that "It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show.".

Can anybody give a technical explanation about the discrepancies? I guess that even with native widgets there are aesthetical issues, but I'm interesting in understanding the matter with exactness:

- are all the widgets provided by WxWidgets native?
- are the widgets in the screenshots posted (https://i.imgur.com/LjDhPOv.png) native?
- if they are, which are the technical grounds for the (supposed/perceived) discrepancies with native?
- is there a bigger picture that it's missing, for somebody who doesn't have expertise (ie. widgets look/feel is complicated because...)

For reference, the discussion is here: https://news.ycombinator.com/item?id=24250588.

Thanks!

Re: Technical grounds for presumed widgets dissimilarity from native

Posted: Tue Aug 25, 2020 4:02 pm
by doublemax
First of all: The "VZ" who wrote in the thread you linked, is Vadim Zeitlin, the core maintainer of wxWidgets. His word is the highest authority in the wxWidgets world.

My 2 cents:
are all the widgets provided by WxWidgets native?
No. But if a native implementation of a control exists on a specific platform, it will be used (i can't think of any exceptions right now, but it's possible there are a few).

Most widgets are native on all platforms, e.g. wxButton, wxTextCtrl, etc.

Then there are widgets that are only native on some platforms. E.g. wxDataViewCtrl. Is has native implementations on OSX and GTK, but as no such control exists under Windows, a generic implementation is used there.

Then there are widgets that have no native implementations at all, e.g. wxGrid.

In general, wxWidgets just gives you the toolset to develop crossplatform GUIs. That doesn't guarantee that they'll look good everywhere out of the box. This also requires "good" behavior of the developer. E.g. they should not use absolute values of controls' sizes and positions, but use wxSizers (the wxWidgets layout system) instead. Lately they must also be prepared for high-dpi screens, good support for that is only available in wxWidgets for a few weeks now.

Also, many open source developers only develop on one platform and hardly ever or never test on other platforms. Often they just don't want to invest more time to make their application look good everywhere.

Regarding https://imgur.com/LjDhPOv

wxHexEditor uses wxAUI, this is not native anywhere. The window with the hexdisplay could be custom drawn, there is no control that does this out of the box. Or it might be a wxGrid, hard to say.

wxMP3gain looks fine to me

easyMP3Gain seems to be one of the cases where the developer just didn't care to make it look good.

Re: Technical grounds for presumed widgets dissimilarity from native

Posted: Wed Aug 26, 2020 12:05 pm
by swxw77
Thanks for the very detailed answer. I think there's some confusion around about this subject, in particular, (not) knowing that "native" doesn't automatically imply "good/proper looking" (I would have thought so myself).

Re: Technical grounds for presumed widgets dissimilarity from native

Posted: Wed Aug 26, 2020 7:20 pm
by ONEEYEMAN
Hi,
Please define what do you mean by saying ""native" doesn't automatically imply "good/proper looking"".

You need to examine the software and see what exactly it uses in order to definitively say whether it is a native or generic control.

Thank you.