X11 is the default windowing tool that Wine uses, because most other non-Windows operating systems use X11 as their main windowing system.
Xquartz And Wine Compile For Windows On Mac OS X DoesMac OS X does not, so a version has to be run on top that Wine can use.It makes Wine ran programs not integrate quite as well like a native app would.This can be useful for testing, or getting around bugs that may be fixedin XQuartz and not made it into WineskinX11 yet.Many features will not work right when running through XQuartz instead, but basic functionality will be there. And to use that you probably have to install the rest of Mono from source too, with the option --with-libgdiplussibling so that it finds the correct libgdiplus. Recently I referenced to XplatUICarbon and managed to make a Cocoa version of XplatUI, but I havent understand how it works, it would be better if anyone who can give me some thoughts. I have long assumed Carbon died with 32, so either my memory is faulty or Apple at some point reversed course and added 64 bit support to it. It should probably be a replica of the 32 bit one, with some bits shared where possible. I did a partial review last night and I got a good sense of what needs doing. I built a simple Carbon application in Xcode, it only worked when I switched the architecture to i386 other than x8664. To do this, I would dynamically load Xamarin.Mac, but it would be an external dependency and we would need to figure out how to distribute this. Do you already have a prototype of a Cocoa backend or are these 5000 lines of code you are talking about just an estimation. Qt for example took that direction in 2009 if I remember correctly. ![]() We had some design choices early on, such as using the System.Drawing implementation on top of Cocoa, that make it complicated to use it as drop-in binary replacement. It works somewhat as a source-level replacement where applications link to our System.Window.Forms and System.Drawing libraries. I have a pending patch to fix System.Drawing on 64-bit Cocoa, but it depends on patches to libgdiplus that were not merged yet. And the non-Cocoa changes to SWF were 90 back-ported to official Mono repository. I have done this locally as a proof of concept, so I know its possible, but my effort was largely unfinished. There was still some glue code missing to support creating Graphics objects for non-client and client parts of the controls, so the rendering of controls was not perfect. ![]() For anyone else wanting to try it, here are the steps I followed (I already had Mono compiled and installed as 64-bit). When running configure I needed to specify where it could find X11, which resulted in running CPPFLAGS-IoptX11include LDFLAGS-LoptX11lib.configure. I needed to specify the X11 library path too, so I ran it with LDLIBRARYPATHLDLIBRARYPATH:optX11lib MONOMWFMACFORCEX11true mono.exe. That said, since this was originally started, we did merge a lot of the work from filipnavara which should get us on a path to have a Cocoa backend, but I have not checked recently on how much was missing or was completed. Obviously, if XQuartz isnt running, it has to be started when starting the application in my experience that takes at least 5 10 seconds. Drawing in general seems pretty slow as well e.g. ListBox. And after installing XQuartz it requires a log out and back in before itll get used, which could make application installation more awkward.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2020
Categories |