Hello,
it would like to extend the duration 3 weeks.
I must be at between phase 3 (refinement-test) and phase 4 (documentation) but
right now i am still stuck on integration.
here i am leaving the current issue. still challenging to figure out what's
going on with this.
> 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
> gitlab.freedesktop.org/freetype/freetype-demos/-/tree/gsoc-2024-ahmet
Best,
Goksu
goksu.in
On Aug 24, 2024 at 02:46 +0300, 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
> > > >
> > >
> > >
>
