The GTK+ version is not yet available for testing.  There are a few sticking points remaining (some menus are not behaving as expected, the outline system can lock up under certain circumstances).  Initially the GTK+ version will be available as a .deb package suitable for Debian Jessie or Ubuntu 14.04 or higher only.  We'll add an RPM package once released.  Unlike the Windows version, the GTK+ version of Simply Fortran will not include the Fortran compiler; it will rely on the distribution's compiler and GNU Debugger packages.  So yes, it will integrate completely with the system's packages.

I can look into some more keybindings.  It is unfortunate that Simply Fortran does not allow user-defined hotkeys, and that is unlikely to change soon.

Re Makefile, I completely understand, and it's simply enough to write a separate Makefile for the Linux cluster I use.

To add to the list of things to highlight, consider perhaps known dotted words like .true. .not., etc?

Is the GTK Linux version available for testing? Does it allow integrate with packages installed via the distributions package manager?

A final suggestion for this post, keybindings for navigating and folding code. For example, moving between subroutines with ctrl-down/up, and folding/unfolding with ctrl-minus/plus.

sorry.. I use Vim and am accustomed  to this kind of customization, but I quite like SF's debugger & profiler, hence my interest.

You should be able to add non-existent files via the "Add File(s)..." option in the Project menu.  After you navigate to the directory, you can just type in the name of the file and click Ok.  It doesn't have to exist, and it also isn't actually created until you open it in Simply Fortran (from the Project Outline), edit it, and save it.  It's not ideal, but Windows allows it.

I do like the idea of highlighting TODO statements in comments.  I'll see what can be done.

Unindenting end statements has been problematic in the past.  It probably won't ever work in fixed-format Fortran.  However, it does work in free-format Fortran (Fortran 90 and higher, generally) if you enable Syntactical Indentation in the Editor Settings window under the "Language Features" tab.

The abstract keyword should absolutely be highlighted.

I'll examine what's possible as far as pretty-printing the project files.  I'm not exactly sure what the library we're using supports.  It would make source control much nicer.

The makefile issue is more complicated.  Simply Fortran uses Open Watcom Make, or wmake, as opposed to GNU Make.  The decision to use wmake is as old as Simply Fortran, and it's based on plenty of issues encountered with GNU Make under Windows.  If you examine the Makefiles generated by Simply Fortran, you'll notice it uses an Open Watcom directive, ".SYMBOLIC," as an example of it not being a GNU Make makefile. 

Additionally, Simply Fortran uses makefiles out of convenience rather than providing portability.  Make systems are quite good at handling dependencies.  The files generated, though, were never meant to be used outside of Simply Fortran, honestly.  The hard-coding of compiler paths in the makefile is because only Simply Fortran itself is expected to use the makefiles. 

I do understand what you're suggesting, though, so I will look into handling them differently.  The hard-coding is ugly, but it developed as a working solution to a messy problem on Windows.

I'll look into eliminating links for the runtime functions in profile results.

Promoting Simply Fortran as working under WINE will be a moot point soon.  We're currently testing a Linux native version that should be shipped before the year's end.  We're trying to fix up some packaging issues that we're finding, but the application looks great.

The GNU/Linux version I mentioned above is a true GTK+ 3 application.  Simply Fortran for Windows is a normal Win32 application, written mostly in C and using the Windows API.  Because it uses this long-supported API, Simply Fortran actually works fine on Windows 2000 and Windows 10.  We don't promote Windows 2000 compatibility, though.

Thank you for all the questions, though!  I'll start looking into your suggestions next week.

From other IDEs (and make for that matter) I have found it useful for more than one target to be built, while SF seems to assume only one EXE is to be run, with one configuration (working dir + command line arguments). Is there some feature I'm missing? Isn't this a little limited? Or, should I create separate projects for each target?

A few small suggestions (uh, random thoughts)

- adding a file requires creating it, saving it and adding it to the project  (I'd have expecting just to say "add new file to project"?)
- highlighting TODO or XXX in comments
- unindenting end statements automatically
- highlight abstract keyword
- pretty printing the prj file (seems to be json) so that one item per line: this allows tools like Git & SVN to usefully track changes in their diffs
- no presets compiler paths in Makefile, pass as arguments (so that Makefile is reusable elsewhere?)

Lastly, when profiling, I would disable links for procedures which can't be opened (e.g. _mcount_private, __powidf2, __gcc_deregister_frame, ..), or even have option to hide profiling time spent in GFortran's runtime?

SF is quite impressive, I've nearly forgotten that it's a Windows application running under Wine. I would suggest making this more prominent on your website, as it's easy to overlook.

Out of curiosity, is SF implemented in GTK+?

*edited for clarity*