> So, at first it sounds like they're making a technical argument against anyone who would choose to use Electron, but I think what they're actually doing is instead expressing some kind of economic disappointment in your situation.
This is a fair assessment. Still, this disappoinment is worth expressing as it makes it clear the current situation (lack of high-quality, mature, cross-platform toolkit using native widgets) is frustrating. You shouldn't be choosing between spending a lot of resources doing things right and spending a reasonable amount producing an inneficient monster that drains your users' system resources.
That's the gist of it. However, I feel the assessment often flies in the face of Parkinson's law. Economics of software development are funny - particularly if software is a part of a bigger company, there's enough inefficiency in both software teams and the greater organization, that Electron vs. 3x native shell + shared core could not be a noticeable difference in terms overall resource expenditure.
The particularly annoying part about economics here is the "limited oxygen" nature of software products. If you and I both develop a software tool, but I decide to rush it with Electron while you take it slow with native app per platform, I get to (assuming the tool is a-ok) "suck the oxygen out of the space" by releasing first, and you may lose the motivation/market to create the better tool.
Which is to say, "good today" may be better than "perfect next week", but the big reason why software products suck so badly is that "shitty today" is considered better than "good tomorrow".
I don't buy it, something doesn't add up. The look and feel is somewhat out of place, one can tell with one glance it's not native. https://i.imgur.com/LjDhPOv.png
• The scrollbars are too narrow and have only a down arrow at the bottom instead of a combined up and down arrow.
• The font size is wrong in some places in the hex editor.
• The tab in the tab bar is crooked, not rectangular, and lacks a close button.
• The text has too cramped kerning, most noticable in the word "File".
• The underline for key shortcuts is placed too high.
• The ribbing in the lower-right corner is larger.
• Contrast around the menu bar is too harsh.
• The icon bar does not lock (context menu), and always displays a grabber.
• Menu bar and icon bar do not have a context menu.
• The ribbing on the left-right split bar is different.
• The MDI panel only has a close button but not a detach button. There's a obtrusive gradient in the panel title.
• The progress bar does not have the stripe pattern.
I submit that Wx implements its own non-native widgets.
> I submit that Wx implements its own non-native widgets.
It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform.
OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.
Not the person you responded to, but can you explain why if they're using native widgets, every single example application here [1] looks horribly integrated into the desktop? Is wx just really hard to use and every developer screws it up? Does wx use the native widgets correctly but screw up things like padding and highlights? Is the subset of widgets that are supported on every platform too limited, so everyone is forced to use non-native widgets (which apparently always look bad in wx)?
PoEdit comes the closest to looking genuinely native, but the MacOS implementation is clearly flawed.
There are many screenshots here, I'm not sure which one do you mean. But do keep in mind that some of these screenshots (maybe even most of them) are 10, or 20, years old, so what seems non-native to you today might be just the way things used to look.
I really do mean basically every screenshot. But take ECMerge for example. If you switch back and forth between Linux (GTK?) and Win7, you'll see that for example the toolbar is exactly the same color on each. It doesn't integrate with the Windows environment at all. But surely Windows has a native toolbar widget? And possibly even a native icon theme that you could use instead of the GTK icons. And even if not, surely wxWidgets could choose the color of the toolbar based on the desktop theme, and not just fall back to the same default colors?
Or check "Game Develop". The primary interface is a kind of weird rip-off of the MS Office ribbon, but I assume this is a custom widget. There's also a tab interface though, and this doesn't work on either the Windows or GTK versions: it's weird and has a gradient background.
In general, small details like the padding, coloration, and borders drawn around widgets seem to be slightly off on most platforms with just about very wx based GUI I've seen.
ECMerge seems to use standard wxToolBar which is definitely a native control, so I don't know why it has the same background on all the screenshots. Perhaps they've explicitly changed it to make them more similar, I really can't say. But if you create a toolbar out of the box, it will look exactly the same as in any other native application. As for the icons, wx does provide a limited set of stock icons, but this will almost never be enough, so you need to either get high quality icons in the style of each platform you support, which is obviously difficult for an open source/free program, or use the same, typically Linux-style, icons everywhere just because this is what is there, for free.
The rest of the controls (ribbon, tabs) are indeed non-native and there are no native equivalents for them, so there is not much to say here.
Generally speaking, there shouldn't be any problem with the colours unless you change them explicitly, which is a bad idea for the native controls. Not sure what is wrong with the padding and borders.
Sorry, I don't know what is this supposed to prove, but I can definitely assure you that all the mentioned controls, and many others, are exactly native controls under the 3 first tier platforms (MSW, GTK and macOS).
> Do you have any proof?
Proof of absence of something is hard to make, all I can say is that you can go through MSDN, GTK and Cocoa documentation to convince yourself.
Wxmp3gain is from more than 8 years ago, and (it seems) you're basing your judgment on a screenshot, which is not a very solid ground. Using a modern, live, application would be a good test (keeping in mind, that some widgets may not exist in a given O/S).
Regardless, since you're accusing a very old and widespread project of lying ("it uses the platform's native API rather than emulating the GUI" on their front page, versus "I submit that Wx implements its own non-native widgets."), you should directly ask on an official channel, and have an authoritative answer.
I mentioned look and feel, and testing out the absence of context menus. This should tell you that I am not judging on a screenshot, but from live applications. I made that screenshot yesterday, and the applications depend on 3.0.4 which is from 2018.
> since you're accusing a very old and widespread project of lying
But anyway, let them defend themselves; veritas liberabit vos. FWIW I don't think malicious or intentional lies are involved, although a mighty good explanation is required to square their claim against the evidence that it is plain to see.
It would have been more productive to spend the time to find a technical answer, rather than arguing for the sake of arguing. I did search, and the answer is at the bottom.
Note that one of the posters you've been arguing with ("VZ"; argument here: https://news.ycombinator.com/item?id=24259040), turned out to be the WxWidgets maintainer. According to the comment though, mentioning this constitutes a cheap trick <rolling eyes>.
Regardless, there is a very interesting concept in the explanation: using native widgets through WxWidgets (and possibly, widget toolkits in general) requires following specific guidelines. Failing to do so will make the widgets look bad, even if they're native.
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 wxWidget
s 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, i
t will be used (i can't think of any exceptions right now, but it's possible the
re 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. wxDataViewCt
rl. 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 it that they'll look good everywhere out of the box. This
also requires "good" behavior of the developer. E.g. they should not use absolu
te values of controls sizes and positions, but use wxSizers (the wxWidgets layou
t 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 o
r 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 hexdisp
lay 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 case where the developer just didn't care to
make it look good.
This is a fair assessment. Still, this disappoinment is worth expressing as it makes it clear the current situation (lack of high-quality, mature, cross-platform toolkit using native widgets) is frustrating. You shouldn't be choosing between spending a lot of resources doing things right and spending a reasonable amount producing an inneficient monster that drains your users' system resources.