Hello, Unfortunately, grcocoa does not work at the moment; it is still in a draft state. I have developed the makefile, and while it works, all the applications are still built using X11.
I am planning to bridge the functions between a .h file and the Swift (Cocoa) implementation, but I am currently feeling a bit lost in the process. Thank you, Hin-Tak, for your suggestion. Once I successfully run the code on macOS, I agree that it would be beneficial for the API to work on other platforms as well. Best, Goksu goksu.in On Aug 5, 2024 at 17:23 +0300, Hin-Tak Leung <ht...@users.sourceforge.net>, wrote: > FWIW, I think I mentioned that swift is open source and in fact available > under Linux. I don't know if the Linux version of swift can bind to the > display system (x11/wayland, or indirectly via cairo/skia/opengl etc). This > is worth keeping in mind of the possibility/convenience that the swift code > is not necessarily mac only; and it might be possible for Linux person > sufficiently skilled/motivated to look into the libtool issue, for example. > > Swift is about the size of rust and full of static libraries etc, so I > haven't looked at the Linux version of swift at all. > > It is also best to avoid "if uname = darwin" sort of code, for that reason... > > On Monday 5 August 2024 at 14:53:32 BST, suzuki toshiya > <mpsuz...@hiroshima-u.ac.jp> wrote: > > > Dear Ahmet, > > Thanks, it's *really* far greater than I expected, please let me confirm the > current situation. > > (1) if I execute "make" on macOS, the demo programs, like ftview, are built > successfully. > (2) but the compile of grcocoa.o is done *after* linking the demos, like > ftview. > (3) therefore, the built demo programs are not calling the functions provided > by grcocoa.o, yet. > (4) as a result, if I execute ftview, it would not show any GUI window > (because it does not link grcocoa.o yet). > (5) the reason why grcocoa.o is not included in graph.a might be related with > GNU Libtool's insufficient support for Swift. > > This is my situation. Your situation is same? > > I think, my situation (2) is because GRAPH_OBJS is not updated in current > rules.mk > > But, even if grcocoa.o is added to GRAPH_OBJS, GNU libtool would refuse to > pick it for graph.la, because GNU libtool want to have grcocoa.lo. This is my > situation (5). > > Unfortunately, xxx.lo is GNU libtool specific file format (although it's just > a small sh script to setting a few shell variables) generated by GNU libtool. > But the lack of sufficient support for Swift makes it hard to generate > grcocoa.lo by normal way. We should have some dirty trick. > > Regards, > mpsuzuki > > On 2024/08/05 9:09, Ahmet Göksu wrote: > > Hello, > > You can find the progress on development of native api. > > With guidance of Alexei, > > *Created an entry point on grinit.c > > *Created a subfolder named "Cocoa" > > *Wrote the rules.mk and it controlls if $(shell uname) = Darwin > > *Wrote a draft swift code, it is being compiled but not works with ftgamma > > app. Trying to integrate it. > > > > > > https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/0905103b7e23fc791900aa63587ee6dace11dc53 > > > > Best, > > Goksu > > goksu.in > > On Jun 22, 2024 at 16:38 +0300, Alexei Podtelezhnikov <apodt...@gmail.com>, > > wrote: > > Hi Akhmet, > > > > Going in the opposite order: > > - grinit.c should have an entry for you new driver, which should > > reside in a subfolder, which should contain rules.mk, which should > > detect macOS. Once set up properly, you should have your driver > > compiled in. > > - grInitDevices() is the first call (see inside FTDemo_display_New). > > This does not open the window yet. This only prepares for it: > > RegisterClass in Windows, XOpenDisplay and get details of appropriate > > Visual in X11. > > - grNewSurface(...) actually opens the window of the requested size > > and the requested (or default) color depth. Or returns NULL and causes > > termination. The return surface object will be used for future > > communication with the open window. It also hosts the frame buffer > > that is projected in the windows > > - grRefreshSurface does just that: looks at the surface frame buffer > > and displays it > > - grListenSurface communicates the key presses and window resizes so > > that the main program modifies the frame buffer and back to > > grRefreshSurface, etc, etc, etc > > > > Alexei > > > > > > On Fri, Jun 21, 2024 at 8:21 AM Ahmet Göksu <ah...@goksu.in> wrote: > > > > Hello, > > I apologize for my recent silence due to exams. Thank you for your > > understanding. I am now able to be more active. > > > > Here's the updates so far with the Graph Demos Swift support: > > -studied the code in grx11.c > > -studied the code in ftgamma.c > > -studied how they built by makefiles > > -developed a demo using cocoa and swiftui > > https://github.com/goeksu/GraphDemo > > This demo opens a window, displays a test bitmap, and logs keyboard strikes. > > > > while the development process has been easy and basic so far, I am now > > facing the challenge of figuring out how to integrate this into the > > existing codebase. I would greatly appreciate any guidance or assistance > > you can provide in this matter.. > > > > Best, > > Goksu > > goksu.in > > > >
