Note: Through this document, the term 'function' is used to describe what in Fortran could be either a subroutine or a function. In most of the code, subroutines are used. Please excuse the lack of formality.
ForGE is a static library. To compile, include it in your library directory and add '-lforge' to the linker arguments. A preprocessor define is included to make code more readable, but it is unnecessary. To use it, add '-cpp' to the Fortran compiler arguments.
Theory of Design
ForGE was created to address a failing in the available GUI frameworks for the latest versions of Fortran. The existing frameworks are either expensive or complex. ForGE aims to be neither. To achieve these goals, the Fortran port |of GTK+, gtk-fortran, was used as a base for the GUI function calls. They were wrapped up and put into a form that even an inexperienced programmer could use.
The basic visual structure for any window in ForGE is a grid. Widgets are placed within sections of that grid and are designated by column and row values. Please see the diagram below.
Within the function calls of ForGE, the location and span of each widget is required. For instance, a call to create a label widget could be written as:
The first argument specifies the window object that the widget is placed in, the second specifies the name of the widget, and the final argument specifies the text to display for the label. The third, fourth, and fifth arguments are all location and span information. In every widget function call, they will be in the following order: column, row, and span. So, for the above function call, the label1 widget will be placed in Column 1, Row 2, and it will have a span of 1 (meaning it will only fill one grid spot).
The first argument in the above label example is the window object, which is the basic code structure for any window in ForGE. It is created with the following declaration:
type(window)::guiwindow
Once that object is declared, nothing can be done to the window until the create_window() function is called. This function is demonstrated below:
The guiwindow object is passed in as the first argument. The second argument is the name of the window, which is only used internally. The third and fourth arguments are the column and row size for the window's grid (see the earlier diagram for an example of a 3,3 grid). The fifth argument is the text displayed across the title of the window, and the sixth argument is the event (function) to call when the window is closed.
The create_window() function must be called before any widgets are assigned to the window, otherwise it simply won't work. Aside from that, the only other required function for the window to properly work is:
call show_window(guiwindow)
The argument is the window object itself, which was created earlier.
In any ForGE program, there are 3 main subroutines which must run for the whole thing to work. After the window object(s) is/are created, the following three functions must be called in order:
call init()
call setup()
call run()
The init() and run() functions are off-limits to the programmer (at least for now) and are contained within the ForGE library.. The setup() function is where all the ForGE function calls go and needs to be placed in the main program.
While it lacks event handling (for the event(event_destroy) argument), below is a very basic example of a program to run ForGE:
Thenameofmodulecanbewhatevertheprogrammerchooses,butitmustbecalledinthemainprogram(intheearlierprogramexample,alineof'use event_functions'rightabove'use forge'wouldmakeitwork).The'use iso_c_binding'and'use forge'arebothrequiredandcannotbeleftout.Theonlyprocedureinthismoduleisevent_destroy(),whichiscalledintheearliercreate_window()procedure.Foreveryevent,twovariablesarealwayspassedtothefunctionandshouldbeplacedthereevenifnotused.widget_ptrisatype(c_ptr)thatpointstothewidgetitself.data_ptrisapointertodatathatmaybepassedfromthewidget.Ifsuchdataispassed,anoteofitwillbemadewithinthewidgetcreationfunctiondefinitionintheseinstructions.Forthisexample,nodataispassed.Theonlyactualcodethatisbeingexecutedis'call gtk_main_quit()',whichisrequiredtoshutthewindowdown.The'bind(c)'thatcomesafterthe'event_destroy(widget_ptr, data_ptr)'isrequiredforalleventfunctions.Itwon't change, so just place it after the name of every function and forget about it.Onefinalnotethatshouldprobablyhavebeenmentionedearlier:Theevent()functionthatisusedinthecreate_window()functionaboveisactuallyjustapreprocessordefinitionthatreplacesc_funloc().Thefollowinglineisrequiredtobeplacedatthetopofthefiletousethis:
define event(x) c_funloc(x)
~~~~~~~~~~~~~~~~~~~~
And in the Fortran compiler arguments, -cpp must be added to enable the pre-processor. This will add a little bit of time to the compilation, but I think that it will make the code easier to read for someone not familiar with iso_c_binding functions. If you want to remove it, then all event(...) calls must be turned into c_funloc(...)
At the moment, there is a good amount of lower-level code exposed in the function calls for events. That may change in the future. For now, it isn't too much I hope.
Widgets
The following widgets are currently available in the ForGE framework:
Please note that the sub-menu widget is still in development and doesn't do anything
More will be added as time goes on.
Widget Function Arguments
window_object = the window object itself (guiwindow in the earlier examples)
widget_name = an internal text name (must be in single quotes) that must be unique for each widget (there isn't a check for this yet)
grid_x = the COLUMN that this widget will be in
grid_y = the ROW that this widget will be in
span = how many grid sections the widget will span
text = the text that will be displayed (must be in single quotes)
event_ptr = the event function that will be called when the widget is used (must be surrounded by event(...))
combo_options = a text array with each option in each spot (see example)
progress_bar_value = Decimal value between 0 and 1.0 for the progress bar to display
filters = a text array with each member being a filter for the files in the chooser (see example)
size_x = pixel size of the x dimension of the text view
size_y = pixel size of the y dimension of the text view
Last edit: John Shahbazian 2013-06-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Instructions (v0.3.x and up)
June 21st, 2013
Note: Through this document, the term 'function' is used to describe what in Fortran could be either a subroutine or a function. In most of the code, subroutines are used. Please excuse the lack of formality.
ForGE is a static library. To compile, include it in your library directory and add '-lforge' to the linker arguments. A preprocessor define is included to make code more readable, but it is unnecessary. To use it, add '-cpp' to the Fortran compiler arguments.
Theory of Design
ForGE was created to address a failing in the available GUI frameworks for the latest versions of Fortran. The existing frameworks are either expensive or complex. ForGE aims to be neither. To achieve these goals, the Fortran port |of GTK+, gtk-fortran, was used as a base for the GUI function calls. They were wrapped up and put into a form that even an inexperienced programmer could use.
The basic visual structure for any window in ForGE is a grid. Widgets are placed within sections of that grid and are designated by column and row values. Please see the diagram below.
Within the function calls of ForGE, the location and span of each widget is required. For instance, a call to create a label widget could be written as:
The first argument specifies the window object that the widget is placed in, the second specifies the name of the widget, and the final argument specifies the text to display for the label. The third, fourth, and fifth arguments are all location and span information. In every widget function call, they will be in the following order: column, row, and span. So, for the above function call, the label1 widget will be placed in Column 1, Row 2, and it will have a span of 1 (meaning it will only fill one grid spot).
The first argument in the above label example is the window object, which is the basic code structure for any window in ForGE. It is created with the following declaration:
Once that object is declared, nothing can be done to the window until the create_window() function is called. This function is demonstrated below:
The guiwindow object is passed in as the first argument. The second argument is the name of the window, which is only used internally. The third and fourth arguments are the column and row size for the window's grid (see the earlier diagram for an example of a 3,3 grid). The fifth argument is the text displayed across the title of the window, and the sixth argument is the event (function) to call when the window is closed.
The create_window() function must be called before any widgets are assigned to the window, otherwise it simply won't work. Aside from that, the only other required function for the window to properly work is:
The argument is the window object itself, which was created earlier.
In any ForGE program, there are 3 main subroutines which must run for the whole thing to work. After the window object(s) is/are created, the following three functions must be called in order:
call init()
call setup()
call run()
The init() and run() functions are off-limits to the programmer (at least for now) and are contained within the ForGE library.. The setup() function is where all the ForGE function calls go and needs to be placed in the main program.
While it lacks event handling (for the event(event_destroy) argument), below is a very basic example of a program to run ForGE:
module event_functions
use iso_c_binding
use forge
end module event_functions
define event(x) c_funloc(x)
~~~~~~~~~~~~~~~~~~~~
And in the Fortran compiler arguments, -cpp must be added to enable the pre-processor. This will add a little bit of time to the compilation, but I think that it will make the code easier to read for someone not familiar with iso_c_binding functions. If you want to remove it, then all event(...) calls must be turned into c_funloc(...)
At the moment, there is a good amount of lower-level code exposed in the function calls for events. That may change in the future. For now, it isn't too much I hope.
Widgets
The following widgets are currently available in the ForGE framework:
Please note that the sub-menu widget is still in development and doesn't do anything
More will be added as time goes on.
Widget Function Arguments
window_object = the window object itself (guiwindow in the earlier examples)
widget_name = an internal text name (must be in single quotes) that must be unique for each widget (there isn't a check for this yet)
grid_x = the COLUMN that this widget will be in
grid_y = the ROW that this widget will be in
span = how many grid sections the widget will span
text = the text that will be displayed (must be in single quotes)
event_ptr = the event function that will be called when the widget is used (must be surrounded by event(...))
combo_options = a text array with each option in each spot (see example)
progress_bar_value = Decimal value between 0 and 1.0 for the progress bar to display
filters = a text array with each member being a filter for the files in the chooser (see example)
size_x = pixel size of the x dimension of the text view
size_y = pixel size of the y dimension of the text view
Last edit: John Shahbazian 2013-06-25