Did you realise, Carlos, the user of CAIRO graphics and initiator of the Simply Fortran forum thread, CAIRO Calling, that your name, CA(rlos) HERRerA sounds a little bit like the Arabic 'القاهرة' ?

it means the name of probably the most most important Arabic city in history.

Pronounced something along the lines of, (Al) KAHheiRRa
We call it 'The [city of] Cairo'!
---
John

...for GUI creation you can use very nice program called Glade.
I believe that the Simply Fortran IDE itself is written in GTK

I looked at Glade a year or two ago and it certainly seemed like an excellent visual graphical way to construct GUIs, but I backed away from it at the time because I formed the impression that it resulted in object code that could not be linked with the Fortran .o files to create a single final executable but needed a separate component at runtime, in addition to the linked Fortran executable.  I would love to discover now that I was mistaken about that.  Was I?
—-
John

I believe that the Simply Fortran IDE itself is written in GTK.

Simply Fortran for GNU/Linux and macOS is indeed written using GTK+ for its user interface.  Simply Fortran for Windows uses the Windows API directly for its user interface and does not use any GTK+ code.

(1) Use Appgraphics!  Brilliant, and built into SF.

(2) Use the fantastic, free, DISLIN library.
     Full 'Windows' style facilities, text, vectors, bitmaps, GUIs.

Both of the above can be used completely withing Fortran source files.
No Java, or C.  Nothing but Fortran calls and functions.

AppGraphics doesn't expose any of the Windows API, so applying a cairo surface to an AppGraphics window would be a problem.  Specifically, the initwindow call returns an integer that corresponds to an internal library array that tracks the windows handle (the HWND value) internally only.  There isn't a supported way of retrieving this value.

The problem actually gets messier because, even if we did provide a way to get the handle, using a cairo surface probably still wouldn't work.  In order to effectively apply static display of drawn graphics in an AppGraphics window, the library dispatches a new thread to handle presenting the window and responding to Windows messages.  The actual drawing requested by the user is always performed on an internal bitmap which is then copied to the actual visual window whenever painting is requested.  If you tried to attach a cairo surface to an AppGraphics window, this automatic, threaded redrawing would actually overwrite the cairo surface over and over again. 

So while the window handle isn't exposed to the user at all (making calls to GetDC difficult), the actual architecture of AppGraphics would make this task fail anyway.

However, I do understand wanting to use cairo.  Creating and managing a window in Windows is difficult, though.  Let me see if I can think of a good way to do this instead of working through AppGraphics.  There's only a bit of C code to get a window open and attach cairo to the drawing context.