Re: Updates on Freetype Demos - Swift Support

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 <[email protected]>, 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 <[email protected]> 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 <[email protected]>, 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 <[email protected]> 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
> >
>
>