Cross-platform issues...

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Post Reply
cbowen
In need of some credit
In need of some credit
Posts: 3
Joined: Thu Nov 03, 2011 12:48 am

Cross-platform issues...

Post by cbowen »

I'm teaching a course with about 250 Computer Science students creating wxWidgets applications. This is the first time we've tried to run this course as a truly cross-platform course with Windows and Mac users and CMake. In the process we have discovered some cross-platform issues that I would like to recommend be changed and I am certainly open to discussion. A users should be able to develop a program on one platform and be reasonably confident that it will build and run on the other platform. Since we routinely have graders on a different platform than the students they are grading, we're finding some issues that really could be easily resolved. I'm planning to look into doing some of them when I have time.

1. wx/graphics.h is automatically included on Macs and not on Windows. This tends to lead to students forgetting to include it and graders and grading scripts getting errors.

2. Menu id's of 0 are valid under Windows, but cause a runtime error on a Mac. This can be easily fixed with an assert, so the runtime error is consistent. It's a common student error that they create their ID's wrong, omitted wxID_HIGHEST. It will work on Windows, but not on a Mac.

3. Microsoft is really bad about including a bazillion excessively large headers. They are also really bad about polluting the global namespace. If you create a class named Polygon, a reasonable class name, it will work just fine on a Mac, but fail on Windows. wxWidgets should be able to encapsulate those massive Microsoft headers so they don't pollute the global namespace of user applications.

Thoughs?
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: Cross-platform issues...

Post by PB »

Firstly, this is a user forum, you will not reach the core developers here. You can communicate with the devs for example at https://groups.google.com/g/wx-users

Secondly, to be honest, to me it seems mostly like non-issues. In fact, it could be useful, to actually teach good habits to new C++ users. You know, learning from mistakes and such... Whether we like it or not, C++ is not very forgiving and the sooner people develop the good habits the better. I agree that a good framework should minimize the chance of shooting oneself in the foot, but it can go only so far, particularly if it is an OSS project not backed by company, with scarce resources.
cbowen wrote: Sun Dec 05, 2021 2:38 am 1. wx/graphics.h is automatically included on Macs and not on Windows. This tends to lead to students forgetting to include it and graders and grading scripts getting errors.
Well, isn't it that it just happens to work by accident on MacOS, where AFAIK wxDC basically is wxGC (unlike on MSW where it is GDI vs GDI+ and D2D)?
cbowen wrote: Sun Dec 05, 2021 2:38 am 2. Menu id's of 0 are valid under Windows, but cause a runtime error on a Mac. This can be easily fixed with an assert, so the runtime error is consistent. It's a common student error that they create their ID's wrong, omitted wxID_HIGHEST. It will work on Windows, but not on a Mac.
wxWidgets docs clearly states that IDs 0 and 1 should not be used, so I guess this could be asserted. OTOH, as always there could be people complaining about breaking their code which used to work (e.g., see the invalid sizer flags asserts introduced a couple years ago).
cbowen wrote: Sun Dec 05, 2021 2:38 am 3. Microsoft is really bad about including a bazillion excessively large headers. They are also really bad about polluting the global namespace. If you create a class named Polygon, a reasonable class name, it will work just fine on a Mac, but fail on Windows. wxWidgets should be able to encapsulate those massive Microsoft headers so they don't pollute the global namespace of user applications.
I believe that wxWidgets policy has been that platform headers cannot be included from public wxWidgets headers (that is why there are no WinAPI types in public headers, only their WX* equivalents such as WXHWND). Looking into this now, I was surprised that Windows headers are in severeal places pulled in on purpose such as here (unlike other platforms headers?). OTOH, I have no idea whether including file such as <windows.h> can be realistically avoided. I would not be surprised if this is by necessity, as the users got used to rely on having basic WinAPI functions available without including <windows.h> back then and for backwords compatibility reasons this cannot be changed...
cbowen
In need of some credit
In need of some credit
Posts: 3
Joined: Thu Nov 03, 2011 12:48 am

Re: Cross-platform issues...

Post by cbowen »

I would very much disagree with these comments. The only reason wxWidgets exists is to support cross-platform development. Every effort should be made to avoid "write once, test everywhere". Developers should be confident that something they write on Windows is going to work on a Mac. I do have to test everything I develop for my course on both platforms right now. Some of that is compiler issues, which is not wxWidget's fault at all, but some of it is not.

A simple fact of life is that most programmers let the compiler tell them what headers need to be included. wxWidgets is a large library. Some of the components require you to include headers and some are included by wx.h. If someone is writing an application on a Mac and use wxGraphicsContext they probably are not going to include wx/graphics.h. Then the Windows user who tries to build the application gets errors and has to fix it. I imagine this is something that is easily fixed. The menu ID issue is also easily fixed. It's not going to break anything. If someone's code no longer works, the code was already broken and they just didn't know it.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4182
Joined: Sun Jan 03, 2010 5:45 pm

Re: Cross-platform issues...

Post by PB »

(Disclaimer: I am not college-educated, I am self-taught about computers and just have had a bit of experience with programming in past 30 or so years)
cbowen wrote: Mon Dec 06, 2021 2:35 pm I would very much disagree with these comments. The only reason wxWidgets exists is to support cross-platform development. Every effort should be made to avoid "write once, test everywhere".
You must be confusing C++ with Java with its "Write once, run anywhere" slogan. ;) I do not think it worked as advertised even there. Compile-time issues are easy to fix, in particular any decent project these days uses CI. More importantly, as wxWidgets wraps the native controls (unlike most other GUI libraries such as Qt, Dear ImGUI, JUCE, or Electron), there may be subtle differences between platforms in how some controls behave. That's where the real fun starts.

Also, as I wrote above and you forgot to address, it often simply boils down to (lack of) resources. It is very easy to write things like "Every effort should be made to ..." but there must be someone willing to donate their time and energy to actually do "..." which is usually much less easy. As we all know, in non-company-backed OSS it is more often than not about scratching our own itches. I guess no one's itch for the issues you listed was strong enough in the whole 20+ years of wxWidgets development, which also may say something about their importance.
cbowen wrote: Mon Dec 06, 2021 2:35 pm A simple fact of life is that most programmers let the compiler tell them what headers need to be included.
Yes, but IMO this is pure laziness, relying on undocumented behaviour. It may work or it may not work, in which case your broke the build and have to pay for it. wxWidgets documentation clearly lists which header to include for which class.
cbowen wrote: Mon Dec 06, 2021 2:35 pm The menu ID issue is also easily fixed. It's not going to break anything. If someone's code no longer works, the code was already broken and they just didn't know it.
Do you have a long-term experience with being a maintainer of a library with similar size and history as wxWidgets? I do not but I have been observing it from outside for a long time. People are not fond of changes which for no good reason (from their viewpoint) break their code and they can be very loud about it. The maintainers have to carefully consider pros and cons of such decisions to not needlessly alienate the user base.

Well, you asked for thoughts, so ... :P

And I did not even say anything about C++ suitability for GUI development in 2022. ;P
Post Reply