azul: Azul doesn't work on macOS due to "not yet implemented" error (missing implementation of shared OpenGL contexts)

I’m finished fixing the callbacks, now they don’t segfault anymore, so fixing the dependencies is probably the next thing on my list. I still have my problems with cargos algorithm, but as azul now requires a fairly recent compiler (which was the main point about switching to vendored dependencies), it doesn’t make sense to have them vendored, since it doesn’t provide additional benefit (i.e. originally I did it to ensure compiler backwards compatibility, but that reason is gone now).

But I’m on vacation right now, not sure when I’ll come back to fix it. I’ll need to upstream all changes I made to azul-dependencies and then edit the Cargo.toml to unlock the dependencies again.

Thanks for clarifying. I know my opinion probably isn’t needed or wanted, but I’ll just state my experience here. When I see this kind of thing, I feel like the devs don’t want to work with the rust and cargo ecosystem, and come up with rube-goldberg contraptions to get around a fairly non existent (or, perhaps, smaller) problem. If this is a flaw of cargo, petition and talk with the cargo devs, or use one of the many cargo workarounds… but… don’t do /this/.

Communicable code is simple code.

This very thread is a great example of why the vendored git repo “solution” creates way way way more problems than it solves.

I actually contribbed to winnit and work on a few public rust projects relating to gui (among other things), and have been watching azul for a long time now considering helping out (have various reasons), but to be honest… I was scared off by this setup. It’s way too complicated and awkward. Of course, it’s your project and you have the right to run it any way you see fit - but I wonder how many other people came across this setup and turned away too.

Just my 2c. Good luck with azul 😃

Not to beat a dead horse… but I definitely agree. I tried to run the examples and they didn’t work, and I went in to fix it (since it’s already fixed in glutin), and I couldn’t figure out how to make it work - which then led me to this thread. Cargo may indeed have its issues, but the bigger problem here is that this project layout isn’t ergonomic and it’s hard to jump in and contribute. This situation makes me think of the golang proverb : Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. I’d love to start contributing to azul because as of right now its the most exciting project that I’ve come across in years, and if you want to attract more contributors it’ll help to reduce the barrier to entry.

I just experienced the same problem on Mac OS X 10.14.6:

An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: /Users/me/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/bf2933b/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61 in thread main

Error information:
not yet implemented

Backtrace:

azul::logging::set_up_panic_hooks::panic_fn @ logging.rs:86
core::ops::function::Fn::call @ function.rs:69
std::panicking::rust_panic_with_hook @ panicking.rs:481
std::panicking::begin_panic @ panicking.rs:411
glutin::platform::platform::Context::new @ mod.rs:61
glutin::combined::CombinedContext::new @ combined.rs:58
azul::window::create_gl_window @ window.rs:890
azul::window::Window<T>::new @ window.rs:483
azul::app::App<T>::create_window @ app.rs:211
my-azul-app::main @ main.rs:32
std::rt::lang_start::{{closure}} @ rt.rs:64
std::panicking::try::do_call @ panicking.rs:296
 @ lib.rs:80
std::rt::lang_start_internal @ rt.rs:48
std::rt::lang_start @ rt.rs:64

Thanks for clarifying. I know my opinion probably isn’t needed or wanted, but I’ll just state my experience here. When I see this kind of thing, I feel like the devs don’t want to work with the rust and cargo ecosystem, and come up with rube-goldberg contraptions to get around a fairly non existent (or, perhaps, smaller) problem. If this is a flaw of cargo, petition and talk with the cargo devs, or use one of the many cargo workarounds… but… don’t do /this/.

Communicable code is simple code.

This very thread is a great example of why the vendored git repo “solution” creates way way way more problems than it solves.

I actually contribbed to winnit and work on a few public rust projects relating to gui (among other things), and have been watching azul for a long time now considering helping out (have various reasons), but to be honest… I was scared off by this setup. It’s way too complicated and awkward. Of course, it’s your project and you have the right to run it any way you see fit - but I wonder how many other people came across this setup and turned away too.

Just my 2c. Good luck with azul 😃

TBH I kinda had other stuff to do so i didn’t come back to it also there was no immediate need for me. But as you seem to have a need, I guess I should re-focus at working on it.

I’ve sent them a PR at tomaka/glutin#1132

glium 0.25 is released now on crates.io: https://crates.io/crates/glium/0.25.0

Have a look at the https://github.com/maps4print/azul/tree/unvendor_dependencies branch. That branch is definitely where the party is at right now

So, does azul just not work on macos then? Is this going to get fixed?

Sure, this would be a one line addition in Cargo.toml as a new release fixes problems. If a crate starts breaking things without altering its minor version number, that’s not a flaw in cargo, that’s a flaw in both the library dev and your choice of packages to rely on.

Having vendored libs essentially bypasses cargo’s package management, blows up the size of the install directory like crazy (every time the version changes, it will now fetch the entire package vendored directory again - have you checked your cargo cache?), increases install/compile time (no re-use across packages, downloading packages on first install + updates), and the time taken for the contrib dev to update a package and update the frozen directory is completely unnecessary. Why do we even have cargo if we do this? You’re solving the wrong problem with a complex solution.

We aren’t using golang or something with a bad package manager, so why do this?

Anyway, again, this is all just my opinion, obviously the package owner has every right to develop how he likes. But I think as a rust developer who actually likes the rust and cargo ecosystem, I probably wouldn’t want to contrib to this even if I liked the project (which I do).

I’d also be willing to contribute to this, as I’m in need of a cross-platform UI, and this one fits the bill in every case except my development environment and one of my build targets. However, as stated by others, there’s an entry barrier here and I think the fork being merged in would be a great step towards removing that barrier.

Having same issue with macOS 10.15.1.

game of life is almost working

It is still pretty broken, but I have a refactored version that uses latest glium, glutin and winit and makes a window on MacOS. You can find my fork here: https://github.com/dignifiedquire/azul

(It drops azul-dependencies, and the code is reorganized into standard rust project layout)

glium = “0.25” depends on glutin = “0.21” and in there a couple of things like CombinedContext do not exist anymore. Especially on the migration guide there is nothing mentioned about this particular CombinedContext only that ContextTrait can be removed safely.

So after all I was also not able to cargo build

It might be worth considering some kind of cross platform CI, as… this is supposed to be a cross platform gui framework and having it break on a major platform for months at a time probably defeats the purpose 😛

Still keenly waiting for the changes, I could make a PR pointing to the new glium if you want? I took a look into the project though and it seems like a really super bizarre way of including dependencies, putting them into a pre-checked-out static repository on github, not sure if that’s a great way of doing it nor intuitive for contributors, why not allow cargo to work the way it way intended?

It’s because OpenGL context sharing isn’t implemented on macOS yet: https://github.com/tomaka/glutin/issues/899 - this needs to be fixed.

@Spleeding1 This issue is resolved, but not on the master branch. That’s why it’s still an open issue. The wip branch doesn’t have this problem, but it doesn’t compile (still working on it).

I am aware of rendering issues in multi-window apps and I’ll probably have to revert the system to use one WrRenderer per window, because otherwise, webrender has flickering problems. Then, shared OpenGL contexts won’t be needed anymore, but the app will consume a little bit more memory.

Same issue here on macOs Mojave 10.14.6. If the fork of @dignifiedquire seems good, can this be merged into the main Azul repo? Let’s provide a good experience for new users from macOs! 😄