>> Please describe your setup carefully before jumping to quick
>> solutions.
>
> The problem occurred on an Arch GNU/Linux, and the '/bin/sh
> --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After
> checking the Git repository and noticing that my particular problem
> occurred th
I dare say your problem does not happen to thousands of Arch Linux users who
try to compile freetype.
One thing on the security aspect of sh and GNU Bash - you are aware that GNU
Bash itself behaves differently, depending on what you call the binary, right?
If you build GNU Bash yourself, then
>
> The main purpose of going through all this trouble is long-term
> reproducibility of our scientific publications/results.
Reproducibility is not equal to determinism.
Thanks Hin-Tak,
I will be updating the version of FreeType shortly, this was for an
older project.
The main purpose of going through all this trouble is long-term
reproducibility of our scientific publications/results. Unfortunately
that is something most operating system package managers ig
Hmm, why are you trying to compile an older version of freetype (2.11.x), when
arch linux ships 2.13.x ?
Anyway, here is how the Arch Linux people build freetype - they use meson
instead of autoconf (PKGBUILD itself is largely a shell script with, divided
into shell script routines):
https://g
> You mean former (instead of latter), ftinspect already depends on Qt?
Yes, sorry.
Werner
You mean former (instead of latter), ftinspect already depends on Qt?
I think you may be looking something in the "AppKit" namespace, whichever
language binding you use... for the widgets, windows and buttons.
On Thursday, 2 May 2024 at 16:17:02 BST, Werner LEMBERG
wrote:
> Again the
> Again the goal is to remove dependencies like XQuartz and make it
> work without it. Adding Qt or Py dependencies is not a solution. Or
> this a different project.
For the latter we already have `ftinspect`.
Werner
Quartz seems to have CGBitmapContextCreate/CGBitmapContextCreateImage ... just
reading random bits of Just's python code.
On Thursday, 2 May 2024 at 15:57:47 BST, Alexei Podtelezhnikov
wrote:
Xlib uses XPutImage.
Windows uses SetDIBitsToDevice.
What does macOS use?
Xlib uses XPutImage.
Windows uses SetDIBitsToDevice.
What does macOS use?
Swift is a language and a runtime; python is also a language and a runtime...
objective c is a compiled language, extended c. They all provide binding to the
platform's GUI toolkit. (cocoa/quartz). Swift on Linux doesn't bind to cocoa
(nor x11, I think - not familiar with it). If you are going
Forgot to mention window resize events…
Again the goal is to remove dependencies like XQuartz and make it work without
it. Adding Qt or Py dependencies is not a solution. Or this a different project.
> On May 2, 2024, at 10:37, Alexei Podtelezhnikov wrote:
>
>
>>
>> Am I missing some points
> Am I missing some points?
Me too. We are talking about an API which opens a window and shows an
uncompressed pixel buffer in whatever language.Then it passes on keystrokes,
receives an updated pixel buffer, and updates the window with it.
We are talking about really basic window programming
Thank you very much for good introduction of PyObjC. Your comment "(Swift) is quite
large" is about Swift on Linux? or both of macOS and Linux?
In my understanding, the basic idea of Ahmet's GSoC 2024 is a rewriting of
freetype-demos/graph/mac to catch up with the latest macOS, not an introduct
Dear Alexei, Werner and Hin-Tak,
Thank you for the comments; I appreciate the prompt replies :-).
There is this peculiar autogen.sh to be run initially... Still fails? How?
I had indeed read the README, but it had only instructed using
'autogen.sh' when "... building a git snapshot or checko
Besides what Werner said - name your system. Most of the world has converged
on GNU bash, but Ubuntu/Debian uses dash, some older Solaris used ksh. Some
really old unix system (tru64 came to mind) has genuine BSD sh. You wrote about
lacking the privilege to be root, so I guess you are not using
I think Swift runs on Linux also these days, but perhaps without any GUI
bindings. I considered installing it at some point but it is quite large (even
without GUI) binding. Size we are talking about similar to Rust and Java.
Open GL on Mac OS X is on the way out and quite buggy/behind mesa on L
Good to hear that you have your own preference!
I would prepare Swift environment in my side :-)
Regards,
mpsuzuki
P.S.
SVG Native Viewer has a small demo written in
Objective-C with Cocoa framework.
On 2024/05/02 17:59, Ahmet Göksu wrote:
Thank you for your guidance.
I agree with your assess
Thank you for your guidance.
I agree with your assessment and prefer to use Swift. It seems well-suited for
future-proofing our project.
Best,
Goksu
goksu.in
On May 2, 2024 at 11:17 +0300, suzuki toshiya ,
wrote:
> Dear Ahmet,
>
> The development of native GUI application for macOS have 3 choic
Dear Ahmet,
The development of native GUI application for macOS have 3 choices:
1) Use C and Carbon framework (now obsoleted)
2) Objective-C and Cocoa framework
3) Swift
I think 2) or 3) are (still) reasonable options, but 1) is not anymore.
I'm unfamiliar with a market trend for Apple products,
20 matches
Mail list logo