Thank you Alex, Toshiya. I better got the goals after the message. Updated the demo app to use freetype lib with a bridge (still getting some errors).
Anyway, thank you for your all support and time. I still want to develop this, out of gsoc, in my free time. Best, Goksu goksu.in On Aug 26, 2024 at 06:58 +0300, suzuki toshiya <mpsuz...@hiroshima-u.ac.jp>, wrote: > Dear Ahmet, > Cc: Alex, > > > If I understood well, the existing apps (ftview, ftgamma etc) will work > > with these functions without an edit on them if they linked correctly. > > Of course, the intention of your project is "no modification in existing > apps, just rebuild is sufficient to use new Cocoa backend". But it is unsafe > to assume "graph.a is perfect" before rebuilding and testing the existing > apps. If your plan for extended 2-3 weeks is only what you call as > "integration", and, if the existing apps does not work well, it would be hard > for me to give high point to your achievement. I think it's a dangerous bet. > > Anyway, Alex seems to have more detailed goals for you, so I want him to > decide the extension of this project. > > Regards, > mpsuzuki > > On 2024/08/24 23:49, Ahmet Göksu wrote: > > My plan was > > -integrate a hello world on swift (to see it is working with the library) > > -develop the following functions one by one on 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 > > If I understood well, the existing apps (ftview, ftgamma etc) will work > > with these functions without an edit on them if they linked correctly. > > > > Best, > > Goksu > > goksu.in > > On Aug 24, 2024 at 17:35 +0300, suzuki toshiya > > <mpsuz...@hiroshima-u.ac.jp>, wrote: > > 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 > > <mpsuz...@hiroshima-u.ac.jp>, 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 <apodt...@gmail.com>, > > 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 > > <mpsuz...@hiroshima-u.ac.jp> 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 <ah...@goksu.in>, 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 <ht...@users.sourceforge.net>, > > 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 > > <mpsuz...@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 > > On Aug 5, 2024 at 17:23 +0300, Hin-Tak Leung > > <ht...@users.sourceforge.net<mailto: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<mailto: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<mailto:apodt...@gmail.com><mailto: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<mailto:ah...@goksu.in><mailto: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 > > > > > > > > > > > > > > -- > > Alexei A. Podtelezhnikov, PhD > > > > > > > > > >
