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

[T J <jt...@ou...>]

Regarding your questions:

  1.  gdraw
  2.  Not really, no. Most of the time it’s just inspecting code to figure out what’s going on. But if you have some understanding of how gui toolkits work, it’s not too bad. The gist of it is:
gdraw exposes a public interface, which allows you to:
     *   Create toplevel and child windows
     *   Draw and render text to that window (usually using Pango and Cairo, unless you’ve somehow managed to disable that, in which case it uses straight X/Xlib calls)
     *   Receive events on that window (mouse/keyboard events, expose/render events, resize events etc)
There’s then some indirection, because behind that interface may be one of three implementations, an X backend (gxdraw), which works directly with Xlib, a GDK backend (ggdkdraw), which uses GDK to create/manage windows, and a Postscript backend (gpsdraw), which is mostly not functional.

>From there, there’s a somewhat functional, mostly broken toolkit of widgets (ggadget/gwidget), which you can use, so you don’t completely have to implement everything from scratch.

  1.  Painfully. But in brief, you set up some state and desired attributes, then either call GDrawCreateTopWindow (toplevel windows) or GDrawCreateSubWindow (child windows). You then probably use some of the widgets from gwidget/ggadget, which involves setting up a lot more state and some event handlers.
  2.  When a window is constructed, it passes in an event handler, in the source you’ll often find it called *_e_h, e.g. splash_e_h. This receives information about things like mouse click/key events, expose (paint) events etc. When you use premade widgets, you can sometimes pass in a callback to one of those as well, which just builds on that aforementioned event handler.

Jeremy


From: Thor Christopher<mailto:tca...@gm...>
Sent: Monday, 8 July 2019 10:45 PM
To: fon...@li...<mailto:fon...@li...>
Subject: [fontforge-devel] Some rookie questions about GUI

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.

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

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.

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

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?
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