Re: [fontforge-devel] Some rookie questions about GUI

[Jose Da S. <di...@jo...>]

On July 8, 2019 05:44:59 AM Thor Christopher wrote:
> Hi, this might seem like some very basic stuff here, but I've been
> skimming through the code just to get an overview on how FontForge is
> built and some really basic stuff just seems difficult to discern from
> the code and documentation alone.

It is probably understandable to write code and not put much effort into 
documenting it if you are the sole creator and maintainer. If you look at 
FontForge (up to 20120731), you have one author, and a few contributors.


> I think this project could learn a lot from InkScape when it comes to
> documentation and code structure.

There are a number of factors at play here:

I think there will be a lot more developers interested in SVG graphics than 
there are developers interested in Fonts, so you should expect a bigger 
pool of talent looking at InkScape vs FontForge.

Lacking a larger pool of eyes looking at & fixing code, as a creator and 
maintainer, you may likely shy-away from external contributions if you 
don't think you can comfortably merge and maintain incoming stuff (and lack 
new eyes to come along and help). Suppose you imagine a drive-by 
contribution that is given, merged, and then you cannot maintain it.
There are a lot of ideas floating in the existing code.

There was a time shortly after 20120731 where pretty much anything 
contributed got merged in, some good, some bad, some so-so. You'll see 
different coding styles, different opinions on what goes, stays, etc.

FontForge was created at a time when 1GB harddrives were considered huge, 
and fonts were designed with size and speed in mind, now we're reading of 
some sfd files that run 500M or larger in size, harddrives are more like 2TB 
in size, solid state drives are becoming common, and RAM is more like 16GB.
The past fonts were mainly bitmap, and vector fonts were only beginning to 
be seen in the past, today, vector fonts are common, and bitmap rarer.

More could be said, but it is what it is
:-)
New help is appreciated.



> Anyway, the first thing I do when I try and understand code is to look
> for the GUI code so I can see how the UI fits with the functionality of
> the program. For FontForge this has been rather difficult, all I could
> find about the GUI from the docs is this part from the FAQ:
> 
> * "**Why doesn't it use the native MS Windows or Mac windowing system?*
> 
>    - *FontForge is not a commercial product and is not bound by the
>    constraints of the market.*
>    - *Doing that port doesn't interest me.*
>    - *I don't have time nor do I have the skill to take that task on.*
>    - *I'd like to encourage people to use Linux/unix*
> 
> *Of course, if I were to use either gtk or qt
> <https://fontforge.github.io/faq.html#widget-set> some of the
> difficulties of porting would vanish. But unfortunately I don't like
> either of those widget sets.*
> 
> *Now... if you would like to do the port, that would be wonderful. I
> encourage you to do so.*
> * Why is FontForge based on a non-standard widget set? ..."*

> None of this information explains what this widget set is or how it
> draws its GUI, the only hint I've found is that it uses Cairo,
> somewhere in the code it looks like it draws the GUI pixel by pixel,
> and there's a GDraw directory with some datatypes such as GWindow and
> GWidget that seem to be related to the UI, but trying to follow the
> function calls and see where it ends it's very difficult to get an idea
> on how the GUI code works. Since I'm still confused about this, I think
> this is probably something a lot of other people might have a problem
> understanding as well when they first start looking into the FontForge
> source code. I'd say it increases the learning curve and reduces the
> possibility of more developers contributing to this project.

Indeed.
My first guess is that the widget set is based on early versions of GDK and 
tries to avoid dependent libraries as much as possible so that FontForge 
could interact directly with X. Some clues here is probably looking at xpm 
xbm stuff in the gutils folder, which were more common in 200x and forgotten 
now.
2000...2012 you're probably looking at code that at some level talks to or 
through the Xwindow system. Targetting X would avoid the differences between 
Gnome and KDE. If you look at 2012 code, some of these GUI choices are 
optional, not required.


> Maybe you should have a more in depth overview on which libraries are
> used and how they work in the docs?

Smaller pool of developers.
Time & resources - where is time best used.
A lot has gone into fighting fires and improvements.


> Some of my questions are:
> 1. What is the name of this non-standard widget set? 2. Is there any
> documentation for how it works?

My first guess is, look at the early versions of the GDK toolkit.
Look at the output results, then parse output to reduce dependencies.


> 3. How is a window created using this widget set?
> 4. Where do I find the event listeners? Is it a signal/slot pattern, or
> something else?
> 
> Hope I'm not spamming with too basic stuff here, but I've been trying to
> get into the code without any luck several times now, and I'm starting
> to think this is something other people might want to know about as
> well. - Thor Arisland

Start with an early TAG point, less code to look at.
I mention 20120731 as latest GW code before we started supporting it, 
therefore different coding styles, ideas, etc. are mixed into later code.

Hope this helps.
Joe