On Monday 5 August 2024 at 14:53:32 BST, suzuki toshiya <mpsuzuki@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.
>
>
>
> Best,
> Goksu
> goksu.in
> 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
>
>
>
> 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
>