As we can see in #461, #463 and #465, the files inside fontforge/ are not well organized, you cannot easily figure out which part of fontforge (core or GUI) a single file belongs to.
I'd suggest to create separate folders and group all files inside fontforge/, and we need a way to prevent ourselves include GUI functions into the core library.
One possible solution is to add some binary target which relies only on the core library, such that if someone messes thing up, make will complain. I'd thought about a dummy target, but I just realized that the main binary of fontforge without X is what I need.
Here's my proposal, what do you think?
We always build libfontforge.so, the core lib contains all and only font-manipulating functions, no matter X/GUI is enabled of not. There should be no GUI features, or even any user-interactive features (command line prompts).
A new binary target fontforge-nox is introduced, and will be always built, as an instance of linking libfontforge.so. This target should be same as the current main binary when X is disabled (i.e. build with startnoui.c). This would make sure that the core library can be correctly linked with. When X is disabled, we may create a symbolic link from fontforge-nox to fontforge.
When X/GUI is enabled, we also build libfontforgeexe.so which includes all high-level GUI codes, such as different dialogs; and also a full GUI binary of fontforge which links with both .so and probably also libgdraw.so etc.
Maybe for the GUI version, we can name it as fontforge-gui or something, and fontforge will always be a symbolic link, or an alternative that can be handled by some Linux distros.
splinefont.h is really a monster, might need to be splitted.
Rather than thinking of it as "fontforge without X," I'd rather think of it as "the standalone script interpreter." It would be reasonable for the native-scripting and python script interpreters to be separate, too, not including code specific to each other. This kind of separation would be useful for people who run FontForge as a "compiler" for building font packages. I do that in Tsukurimashou, but so do the "efont" people, I think so do GUST (a group in Poland who make fonts for TeX in an automated way), and very likely others. If we followed Barry's suggestion of making fontlint a binary (which I'm not sure is a good idea, but that's a separate issue) then that is also something that would logically link with libfontforge.
and very likely others
and very likely others
Yep, my https://github.com/xen/bakery uses FF in this way :)
I think this sounds great, I definitely want the project's code more well organized to lower barriers to contribution. I suggest we get the next release out the door in the next 2 weeks and then do this for the next release :D
@mskala What python script should be interpreted by FF? FF is only a python module.
@mskala Oh I've just checked the code, indeed there are such interefaces, but they are nothing more than calling the Python interpreter directly.
Right now FontForge can be invoked as a GUI editor by typing "fontforge", as a native script interpreter by typing "fontforge -lang=ff", or as a Python script interpreter by typing "fontforge -lang=py". I never want to use Python, and I want to use the GUI editor and the native script interpreter in very different contexts. It would be better if those three things were three different binaries instead of one huge binary with different command-line options. Then my headless compile machines that run native scripts wouldn't need to have the GUI program installed. (They already don't, but only by means of recompiling a special version of the GUI program with the GUI code disabled, which is less than ideal.)
If typing "fontforge -lang=py" is really just the same thing as typing "python" (which seems unlikely, but I don't know Python, maybe that's true) then all the code for it in the "fontforge" binary should be removed and Python users should be encouraged to use the "python" binary to interpret their Python scripts. I thought the relationship of "fontforge -lang=py" and "python" was more like the relationship of expect and tcl: the fontforge binary contains an embedded copy of the Python interpreter plus a whole bunch of added support for font editing, which calls and is called back by the embedded Python interpreter and appears to scripts as additional library functions.
I agree with @chemoelectric that the parameter for interpreting python scripts does not make much sense. As a python module, it's supposed to be run by python, and actually it is so inside fontforge.
For native scripts, as documented, the sharp-bang line is fontforge, so we may not change the name of the binary for compatibility. But maybe we can show a transitional warning about the future change?
Also note that command line is not the only way to execute the scripts, they can be called within the GUI, it's like Macros in MS Office, or extentions in Photoshop/GIMP which would do automated tasks, while you still need to make some adjustment manually. So it might make sense if we have a separated interpreter, but it does not make sense if we remove the script interpreting code from the main binary.
You want a no-X script interpreter, and I want to make sure the lib can be correctly linked with. So as I've proposed, just enabled startnogui.c all the time, maybe with a new proper name. This file should not introduce extra maintenance cost, it has been in the codebase, and it plays somewhat the same role as pyhook/fontforgepyhook.c
The python within fontforge makes sense, but it's unfinished and as not yet complete.
Back in summer, there was talk about adding pulldown menus for running scripts - this is where it makes sense to have python (and native scripting) inside fontforge, but, right now, as the code stands, it needs some fixes before this can be accomplished (for pull-down menu functionality).
closed due to #880 and following works