MGL for macOS
PallHaraldsson opened this issue · 7 comments
https://github.com/openglonmetal/MGL
is LGPL2.1 is compatible with 3.0.
I'm confused about your language:
not an acceptable solution to pirate the OpenGL-to-Metal shared library, the source has to be legit and has to conform to the lGPL3-0 licensing mousetrap has.
FYI: Using MGL or other similar isn't "pirating", implying copyright infringement ("illegal"). Reuse is ok. Maybe someone needs to make a _jll for this. I'm not sure this is "the OpenGL-to-Metal shared library", is there a the or many? Any other GPL-compatible, e.g. MIT would be ok.
I'm just pointing out, macOS is not a priority for me. I don't use your package, nor macs. Your package just seems great, and I would really like a go-to-solution for all platforms. I think it may be already, and "OpenGL deprecated" overblown. I don't see how Apple will get away with dropping it. They likely will never, just provide MGL themselves if needed.
It's just a signal on their part that it will not be developed further, adding new features, later versions of OpenGL. I doubt there's a huge downside for them to keep it, only for dropping. To signal use Metal mean you will target our proprietary platform... good for them, and possibly a bit faster to not go though a compatibility layer, but of very little concern to you?
Thank you for bringing this up, I think I was being unclear. I wasn't referring to pirating the opengl-to-metal binding, but the opengl shared library/framework that comes with macOS itself (/System/Library/Frameworks/OpenGL.framework usually), which is not part of the binary builder sandbox and not publicly available. The only way to access this framework to my knowledge is to either own a mac, or to download macOS in part or in full, which is obviously not open source and to my knowledge not even publicly available anywhere.
Using the MGL library you posted in the binary builder sandbox environment I get an error, because it, too, needs to access the system-supplied opengl library
sandbox:${WORKSPACE}/srcdir/MGL # mkdir build; cd build
sandbox:${WORKSPACE}/srcdir/MGL/build # cmake ..
(...)
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
OPENGL_INCLUDE_DIR)
which I don't have access to.
Overall I don't think it's that much of an issue, 95% of mousetrap is still available on macOS, and most users don't need to do GPU-side programming to make their app.
I think my language was too strong because I asked on discourse and stackoverflow about this and was basically told to just write a metal back-end because OpenGL is deprecated, which is ironic because I am literally unable to develop this unless I buy an apple computer first, so I was frustrated. In the grand scheme of things I don't think it has much of an impact on the vast majority of my user base, so this is fine for now.
I've been busy with another project but I will respond in the PR thread soon. Thank you for taking the time to respond here.
I suppose MGL only works on macOS, i.e. an actual mac. Probably with or without the OpenGL.framework.
I realize (now) that you have a testing problem for macOS, but you seem to have that either way. I suppose some mac user would be willing to test and make MGL work. But again for little gain (yet) I think. Or donate a mac to you, if you need that, or access to a mac. What does JuliaLang do for CI? I suppose they would want to know your project just works.
95% seems ok to me, even a bit 2nd class, but MGL will not change that. Metal (or Vulkan) would.
If you were starting from scratch I would have suggested Vulkan (and it would support more or all of Metal), for all platforms, not just a Macs. I'm not sure how easy to migrate to, but you can have OpenGL-to-Vulkan bridge I believe in the meantime. I'm not sure if you can migrate slowly, use Vulkan and OpenGL for old parts.
I'm fine with no action (even for other platforms, i.e. OpenGL for now), except possibly clarifying doc on what you meant. I was just confused about what you meant.
I think I will clarify the language a bit so mac users don't assume that they can't use mousetrap, most of it already works just as well so it's worth it to make that clearer, thank you for pointing it out.
I just noticed dlangui project support same platforms you do, including macOS, plus Android, though not iOS. I'm not suggesting reusing it, maybe learn from it, I don't use D, dlang, currently, but know D experts.
Does your project support GUI builders? I understand there are available for GTK, but unclear to me if they work. I just like to know how best to support all (important) platforms (preferally including mobile, at least Android); and with GUI builders. People suggested .NET and calling Julia, and thought not possible, but that's one way. I pointed out projects that enable that, and also your new project.
I thought Qt was the way to go, maybe GTK4 is much improved, also for Windows, and on top you simplifying its use.
dlangui project support same platforms you do, including macOS, plus Android, though not iOS
Just to be clear, mousetrap works on macOS, it just as fast as on other operating systems, the only difference is that the RenderArea widget is missing. While that widget has an entire documentation chapter dedicated to it, that chapter is number 9 out of 10, and RenderArea makes up maybe 5% of the functionality of mousetrap.
I just like to know how best to support all (important) platforms (preferally including mobile, at least Android)
GTK can't target mobile and there's no way GNOME would even want to target mobile, but then again Julia will also most likely never run on mobile so it's not a huge issue for me specifically. For shipping for Windows 10, 11, any 64-bit linux, and macOS, GTK4 works well and I think has feature parity with QT.
I thought Qt was the way to go, maybe GTK4 is much improved, also for Windows, and on top you simplifying its use
In general, I think apps created in GTK4 are just as good as QT on any platform, and GTK4 has the huge advantage of being free, the big problem with GTK4 is that it's stupid hard to learn and their docs are terrible. It took me a few months to be able to get to a point where I can build whatever I want. That's a huge reason why I created mousetrap, I'm hoping mousetrap is easy to learn, has a streamlined design, and the docs are good and can be understood by anyone. The trade-off is that I omitted some GTK4 features. For example, pure GTK4 has 4 different types of windows, mousetrap just has one.
Does your project support GUI builders?
It doesn't, and I don't really want it to. I'd prefer mousetrap apps are build entirely through writing Julia code. If you want a GUI builder, gnome-builder has some features for GTK4, but then your app would have to be written in C or Vala (or maybe C++ with gtkmm, or rust). GTK4 has something called the builder interface, which allows you to define a GUI as xml, instead of C code. I intentionally didn't expose that interface though.
If you're thinking of using mousetrap in production, the only thing I would consider missing are an interactive debugger (which pure GTK4 has), and an app bundler for distribution, I still haven't started on working on an installer so you can actually send out your app as an executable, instead of a Julia package, but it is planned. I'm hoping PackageCompiler will work for that in the future.
Overall, pure GTK4 is nice and the end-product is as good as QT, but the development process is a lot more demanding. If you want to open a proper company that sells an app, I would recommend using QT unless you have the time to spend ~3months learning GTK4, or you find someone that knows Vala and GTK4 already, in that case that person can easily match the product quality of QT. Their wage might even be cheaper than the QT fees.
If you just want to create a GUI to more easily control some Julia-related package, I think mousetrap will be there soon, and it hopefully has a smooth learning curve, and has all the advantages Julia has over a language like C++ or Rust
I'm hoping mousetrap is easy to learn, has a streamlined design, and the docs are good and can be understood by anyone.
It great that you are doing this, well it seems done. Don't get me wrong, people have different priorities, and that's ok, I'm not saying yours are wrong, just clarifying for myself what there, and could be done, in these last off-topic comments if you don't mind.
Mine would be:
Linux (since I use that)
Windows
Android
macOS
iOS
You say RenderArea is missing, so I can use the rest on all platforms, and my program would be cross-platform. It's unclear I need it, but if, then to all but macOS, or is there a fallback to something slower for it? The problem with GUI toolkits is always do you want to support a lowest denominator. If RenderArea is valuable for other platforms (I guess it must be), then it's a trade-off, do I want to just not support macOS (or at least slower).
GTK4 has something called the builder interface, which allows you to define a GUI as xml, instead of C code. I intentionally didn't expose that interface though.
That's your call since it's your project. I just think some would want that or a GUI builder (I assume they would make that XML; XAML?).
there's no way GNOME would even want to target mobile, but then again Julia will also most likely never run on mobile
I think you're wrong on both counts.
https://discourse.gnome.org/t/gtk-4-and-android/2808
https://blogs.gnome.org/shell-dev/2022/09/09/gnome-shell-on-mobile-an-update/
I think pretty much everyone building (infrastructure, if not apps; at least GTK, Qt does already) wants to (or does) support mobile in some form.
My understanding of your project is that even though you build on GTK4, it's just an implementation detail, and you will not be able to use all their current or future features. That's ok (for now). I'm thinking if they have some widgets (or window types), can you bypass mousetrap and use everything it has? If not now, then at least in theory later? And e.g. later if they support Android.
Julia has been run in Ubuntu that runs in Android, so in that sense it has... I'm just saying it's possible, and I basically think the real reason Julia doesn't run on Android directly is that most would want a GUI, where your project might come in..., and while text-based only also useful, TUI isn't most usefulr or what people have in mind with Android support. I make no demands, just want to know if your project could be hypothetically extended to Android.
I has Glade or some other GUI builder in mind (I'm not sure it supports Android, but I thought most popular for GTK and desktops).
I'm an old-timer, I grew up with desktops (or earlier...), and GUI programming for was taught at Uni. I just know they no longer do that. The younger people only learn mobile and/or web (probably only mobile optional to learn at Uni), and they don't even have an interest in learning for desktops...
The concepts and design for mobile scales up (well just lots of empty space, probably non-ideal to not think of mobile and desktops/larger screens as separate designs), But a desktop design hardly scales down.
Just fyi, I updated the C++ components build system so it now works 100% on mac, everything is portable now. The change isn't merged yet but will be with v0.3.0, all platforms will be supported then so what I said earlier won't apply.
There's still no way mousetrap will be on mobile though.