freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updates on Freetype Demos - Swift Support


From: Ahmet Göksu
Subject: Re: Updates on Freetype Demos - Swift Support
Date: Sat, 24 Aug 2024 16:17:08 +0300

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 <apodtele@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
<mpsuzuki@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 <ahmet@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 <htl10@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 <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
On Aug 5, 2024 at 17:23 +0300, Hin-Tak Leung <htl10@users.sourceforge.net<mailto:htl10@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 <mpsuzuki@hiroshima-u.ac.jp<mailto: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.


https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/0905103b7e23fc791900aa63587ee6dace11dc53

Best,
Goksu
goksu.in
On Jun 22, 2024 at 16:38 +0300, Alexei Podtelezhnikov <apodtele@gmail.com<mailto: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><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
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]