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