On Thursday 8 August 2024 at 13:25:17 BST, suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp> wrote:
Dear Ahmet,
On 2024/08/08 3:39, Ahmet Göksu wrote:
> 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 for clarification. Do you mean that the simple inclusion of current grcocoa.o into graph.a is insufficient to test the freetype-demos with Cocoa backend? Attached is an experiment to include grcocoa.o into graph.a.
The basic idea is following:
* current configuration (of freetype and freetype-demos) want to use GNU libtool to compile graph.a on Unix-like platforms, even if we are building a simple archive library for graph.a.
* therefore, grcocoa.lo is needed to complete graph.la.
* but GNU libtool does not provide nice support for Swift compiler. If we tell GNU libtool to use swiftc as yet-another C compiler, GNU libtool wants to add -fno-common and -fPIC options, which swiftc does not understand.
* thus, I wrote a dummy C source (grcocoa-dummy.c) to give GNU libtool to generate both of grcocoa.o and grcocoa.lo. The grcocoa.lo is needed for grcocoa.la, but its content has nothing to do with grcocoa.o. using "hello wolrd" C source to generate grcocoa.lo must be acceptable, but I wrote dummy functions to follow grcocoa.h.
* after grcocoa.lo is generated by GNU libtool, swiftc overwrites it by the output from grcocoa.swift.
* when GNU libtool pack all "lo" files into graph.la and all "o" files into graph.a, the overwritten grcocoa.o is used.
* in summary, attached patch includes a dummy C file (grcocoa-dummy.c) and a patch for graph/cocoa/rules.mk.
I don't think this is the best. There are other ideas like:
a) for macOS, do not use GNU libtool, compile "o" files directly and pack them by "ar" command directly.
b) after building graph.la (and graph.a) by GNU libtool, use "ar" command directly to append "grcocoa.o" into graph.a.
> 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.
Good decision! Please keep your priority to the work items in your schedule. I want to remind that the primal motivation of your project is "X11 backend is not the native graphic framework of macOS, so we want to add a native graphich backend to graph.a". If there is a platform whose native graphic framework is Cocoa, and its Swift interface is sufficiently compatible with macOS, expanding the target to such platform would make sense.
But, if there is a platform which is trying to build an emulation layer of Cocoa with Swift (or Objective-C) on X11, it should not be treated in the same way as macOS in your project. Because X11 is already available on the system, its stability & reliability is clearly better than the emulated Cocoa. You might be troubled by a situation "am I debugging my grcocoa? or am I debugging Cocoa emulation layer? or am I debugging Swift ported on this platform?".
Regards,
mpsuzuki
On 2024/08/08 3:39, Ahmet Göksu wrote:
> 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
> 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...
>
>
>
> 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.
>>
>>
>>
>> Best,
>> Goksu
>> goksu.in
>> On Jun 22, 2024 at 16:38 +0300, Alexei Podtelezhnikov <
apodtele@gmail.com<mailto:apodtele@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 <
ahmet@goksu.in<mailto:ahmet@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
>> 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
>>
>
>