Hello,
I check if Avogadro will run on Wayland on Linux desktop?
It will be some time before Wayland gain adoption. But since Ubuntu 21.04 and Fedora 34 switch to Wayland as default.
Avogadro in Wayland is broken as shown. If I were to guess, it might be because broken glew on Wayland. So when glew support it, Avogadro might be.
Certainly we’d like to support Wayland. If you (and others) can file an issue, that would be great to track.
It looks like it might be easier to switch from GLEW to libepoxy. Looks like there’s also a “glew-wayland” project.
GL3W seems like another alternative: GitHub - skaslev/gl3w: Simple OpenGL core profile loading
We don’t really use GLEW heavily, so it shouldn’t be hard to drop it.
But please open an issue to remind us. @mhanwell mentioned switching to OpenGL 3.3 core profile, so dumping GLEW seems like a good project at the same time.
I see you opened the issue, thanks:
Looking at the issue on the GLEW GitHub page that @kevinsmia1939 linked to, there is something called glewContextInit() available in the master branch since Oct 2021 (?), and this fix in a different project makes use of it in order to work under Wayland.
Perhaps this means Avogadro doesn’t need to get rid of GLEW completely after all?
In the GLEW issue there are also lots of links to issues and merges in other projects where it seems people have successfully implemented fixes for Wayland. Unfortunately I don’t understand the code or the way OpenGL/GLEW etc. work well enough to make head or tail of it all.
I tried simply swapping the two occurrences of glewInit() for glewContextInit() but naturally get the compile error:
/home/abc/avo/openchemistry/avogadrolibs/avogadro/rendering/glrenderer.cpp:59:19: error: ‘glewContextInit’ was not declared in this scope
59 | GLenum result = glewContextInit();
| ^~~~~~~~~~~~~~~
The maintainer of GLEW does write:
One option here is to expose glewContextInit as an alternative to glewInit, and indeed for supertuxkart you could declare that manually to bypass the call to glxewInit from glewInit.
so I wonder if manually declaring it would help. Not that I have any idea how to do that.
I also notice that the 2.2.0 release dates to Jan 2021, so I wonder if it would be necessary to build GLEW rather than use system GLEW in order to use glewContextInit().
That’s an option with cmake. What version is your system GLEW?
But while there are comments about using glewContextInit() I don’t actually see it in my glew.h header.
zypper says 2.2.0-3.17. 2.2.0 is the latest release, 2.2.1 is a work in progress, but it was released in Jan 2021 whereas the commit adding glewContextInit() is from Oct 2021.
To use system GLEW, would I do cmake -DQT_VERSION=5 -DUSE_SYSTEM_GLEW=ON ../openchemistry/ before building? Sorry, still very much a beginner when it comes to compiling anything.
If system GLEW isn’t set to be used, what happens? Does the GLEW source code get downloaded and compiled as part of Avogadro’s compilation? And where does that source come from, is it the most recent GitHub release?
The GitHub page also has a snapshot from April 2022 that should have glewContextInit() in it. I have downloaded it and built it as per the readme on GitHub but am not sure how to make Avogadro use it instead of either the GLEW installed via my package manager or whatever one Avo compiles.
In short, the current GLEW development code supports this, but there hasn’t been a release in 3 years.
I’m still inclined to switch, but it seems like a kludge could work for an Avogadro 1.99 release.
Here’s where the source builds (AppImage, Windows, Mac) set up GLEW. It’s possible to point at a specific git commit through GitHub or GitLab (e.g. OpenBabel) but obviously it can be a pain for package maintainers like @RizzerOnGitHub
Yes, or you can run ccmake . to change settings in your build directory.
For context, one of the challenges with glew support is the alternative GLsizeiptr definitions that affects 32-bit arm systems. GLEW upstream commented it’s a bit odd to have both GLEW and OpenGL headers in the same compilation unit,
Yeah, I think it’s clear that we need to migrate away from GLEW to glbinding, but that doesn’t seem like a good idea for 1.99.
@matterhorn103 - is there some #define that indicates if we can use glContextInit()?
I’m okay with a temporary patch that uses glContextInit() from GEW if available for Wayland support.
Then I’m inclined to get rid of GLEW before we release 2.0.
That approach (fix for now, replace later) seems like a good one.
Changing the glew url to that snapshot seems to work in that cmake reports downloading and unpacking it.
It then builds successfully without complaining about glewContextInit() being undefined, which I added in only two places (these are the only changes I had to make to the source other than the url change).
The resulting binary works (at least, on first inspection) under Wayland! 
First issue that sticks out is that Avogadro’s icon isn’t displayed, just the generic Wayland placeholder. I’ll look into that.
Beyond that, things seem to work as expected. The rendering is possibly slightly less smooth (when dragging out new bonds, rotating the view etc.) but to a barely perceptible extent, I might just be tripping.
Edit: lack of an icon on Wayland seems to typically be due to mismatch between the program name specified in the .desktop file in /usr/share/applications and that set by
QGuiApplication::setDesktopFileName("avogadro2");
I don’t actually have an avogadro2.desktop file in /usr/share/applications at all. Installing either the flatpak or the version of Avo in the openSUSE repos does create one, so I guess this is just a consequence of having compiled it myself. Copying the one installed from the openSUSE repos results in the compiled version displaying the right icon, so everything seems to be working fine 
It seems GLEW is a while away from any 2.2.1 release still, so I guess that means not only compiling the AppImage and flatpak with the snapshot I linked to, but also packaging our own GLEW for distro versions of 1.99, unless distros have backported the fixes since the 2.2.0 release.
Unfortunately, I can’t get GLEW main to compile on my Mac, so that’s a problem.
If you can isolate a patch to GLEW that works for you, we certainly can have openchemistry apply a patch on Linux platforms via cmake.
Ah, that sucks. There have been several commits in 2023 relating to Apple silicon, and the preferred build system being make rather than cmake. Dunno if that has anything to do with it.
Do you mean a patch as in a particular commit (#216 seems to have been the one that added the API entry) or as in the GLEW codebase at a particular time?
If that commit is sufficient for you, that would be ideal. One diff to patch the 2.2.0 glew code.
Sadly the 2.2.0 release with that one commit applied doesn’t seem to do the trick, though it’s hardly surprising since it was only two lines of code. There are several other commits that mention Wayland, so I suspect it was ongoing work that was enabled by the additional API call, and multiple commits would be required for a patch.
Don’t think putting everything into a single patch is that practical as there are quite a lot of accumulated differences between 2.2.0 and the 20220402 snapshot. And pointing Avogadro at the url of the master branch source code after the relevant commit doesn’t work either because it seems things like src/glew.c only get generated when they draft a release?
So looks like it might be necessary, on Linux, to use the snapshot as provided, if that’s going to be possible?
Maybe. I’ll give that a try. Seems like that was my problem with Mac compile: src/glew.c wasn’t present.
Oh ok, that means there’s a chance it’ll work on Mac too using the snapshot, right? Nice.