Re: Updates on Freetype Demos - Swift Support

So, your goal (of 2-3 weeks) is the building of the library, not the working demo?

Regards,
mpsuzuki

On 2024/08/24 23:14, Ahmet Göksu wrote:
> Hello,
> Yes, the demo I shared is not working with the backend.
> My purpose to develop it was to shape my understanding of Swift code I needed to develop for the project.
> 
> To test the code on development with the all library, I was trying to integrate a basic "hello word" script then develop it little by little (opening a window, logging the keys etc -which i did on the demo-).
> 
> Btw, my plan is to develop equals of these following functions in swift.
> gr_x11_surface_initgr_x11_surface_listen_eventgr_x11_surface_resizegr_x11_surface_set_icongr_x11_surface_set_titlegr_x11_surface_refresh_rectgr_x11_surface_done
> so the demos going the call and work.
> 
> Best,
> Goksu
> goksu.in
> On Aug 24, 2024 at 16:55 +0300, suzuki toshiya <[email protected]>, wrote:
> If my understanding is correct, yet you have not built a working
> ft-demos executable linked with your backend, so I feel the current
> status is not the integration phase. You will be able to make
> a working binary of ftview within 2-3 weeks, or you did it already?
> No need to write a makefile, write a special shell script to build it.
> 
> Regards,
> mpsuzuki
> 
> On 2024/08/24 22:17, Ahmet Göksu wrote:
> Hello again,
> In previous mails, I have shared a demo desktop app built by swift (also, in the link below) which was on GitHub.
> Right now, I am trying to figure out to connect swift and the entire build system. After that point I think it will be much more faster to develop as seen on the demo app that works on its own.
> 
> I am sorry for being late for two weeks than I proposed. I really want to work on this project for more 2-3 weeks to complete it.
> 
> https://github.com/goeksu/GraphDemo
> 
> Thank you for your consideration.
> 
> Best,
> Goksu
> goksu.in
> On Aug 24, 2024 at 15:10 +0300, Alexei Podtelezhnikov <[email protected]>, wrote:
> Hi Akhmet,
> 
> I am not interested in extending this project due to lack of progress.
> 
> Alexei
> 
> On Fri, Aug 23, 2024 at 7:46 PM suzuki toshiya
> <[email protected]> wrote:
> 
> Hi,
> 
> # Alex, Werner - Ahmet wants to extend the project
> 
> Please provide the updated practical schedule how long you want to extend,
> and the information about the current status in your original schedule.
> 
> Regards,
> mpsuzuki
> 
> On 2024/08/24 1:28, Ahmet Göksu wrote:
> Hello,
> As 26th is the deadline, is it possible to have extension to meet all the goals?
> 
> Best,
> Goksu
> goksu.in
> On Aug 20, 2024 at 17:21 +0300, Ahmet Göksu <[email protected]>, wrote:
> Hello,
> 
> Thank you for your help.
> 
> I have applied the diff you shared.
> 
> I have tested if it is linking correctly the header, dummy c and swift files by putting typos on them. All the typos caused error on the make process -so they are linked-. However, following print lines are not still working.
> on swift:
> /**TEST */print("hello")
> on dummy c:/**TEST */#include <stdio.h>int main(){ printf("Hello, World!\n");}
> 
> here is the output:
> goksu@air ~/Desktop/freetype-demos/bin % ./ftgamma
> cannot open X11 display
> FreeType Gamma Matcher - press ? for help
> so I guess still have some issue with linking.
> 
> 
> also added the else statement as hin-tak mentioned:
> else @echo "Cocoa is not supported on this platform." @exit 1endif
> 
> https://gitlab.freedesktop.org/freetype/freetype-demos/-/tree/gsoc-2024-ahmet
> 
> Best,
> Goksu
> goksu.in
> On Aug 8, 2024 at 16:16 +0300, Hin-Tak Leung <[email protected]>, wrote:
> By my earlier comment, I just meant trying not to insert code of the form
> 
> "if $(shell uname) = Darwin..."
> 
> It is the sort of things that would bite somebody later.
> 
> Or perhaps, a clearer suggestion from me would be that if you do decide to put such a clause in, make sure that you have a sensible "else" that goes with it, perhaps with some visibility e.g.:
> 
> else
> echo "not using cocoa"
> exit 1
> fi
> 
> This is to avoid things silently and surprisingly failing in the future, when somebody expects some generic non-platform-specific code to work, but not, it being skipped over by such a clause.
> 
> 
> 
> On Thursday 8 August 2024 at 13:25:17 BST, suzuki toshiya <[email protected]> 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
> On Aug 5, 2024 at 17:23 +0300, Hin-Tak Leung <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]><mailto:[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]<mailto:[email protected]><mailto:[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
> 
> 
> 
> 
> 
> 
> --
> Alexei A. Podtelezhnikov, PhD
> 
>