Author: Graeme Geldenhuys (graemeg at gmail dot com)
Last updated: 2010-08-02

The latest release is: version 0.7
Downloadable from SourceForge

This website has moved to the SourceForge.net servers. That will now be the new official website for the fpGUI Toolkit project. Please update your bookmark links to point to: http://fpgui.sourceforge.net

The v0.7 release contains a lot of added features compared to the previous release. Below is just a small list of things that changed or was added (see the repository log for more details).

The pre-built HTML and INF class documentation will be made available during the next few days. This will include updated Class Documentation for fpGUI, FPC's RTL, FPC's FCL and a special version of FPC's Language Reference document in INF format. I will also include pre-built binaries of DocView (fpGUI's own help viewer) for Linux and Windows, plus intructions on how to integrate DocView with Lazarus IDE and MSEide so you can have context sensitive help from within each IDE's code editor.

For more information as to what is included in the v0.7 release, please see the change-log page.

At the beginning of June I started a total rewrite of fpGUI. Fixing design issues I found in the first attempt and basing the new code on a multi-handle design. Meaning every widget (component) has it's own window handle.

The old fpGUI code (single handle design) has been archived (tagged) in the repository under /tags/single_handle_fpgui The new code has replaced the old code completely and is now available in /trunk/src/

The reasons for the rewrite:
I tried to use fpGUI (old code) for a prototype application. To see what issues we might experience. eg: What is vital and still missing for real application use etc.. After all, that is what I want to use fpGUI for - real world commercial applications.

I found some major issues with the old fpGUI.

• Redrawing was very slow
• Scrolling canvas's gave issues and was slow
• Way to many events were flying around causing a lot of unnecessary redrawing!! Dragging a form over a busy fpGUI form, brought a 2.4Ghz P4 computer to it's knees.
• Window-in-a-window has always been bugging me. It's a feature I used a lot under Delphi and would like to use it again. How easy would it be to implement this using a single window handle per form widget set like fpGUI.

I started re-evaluating my thinking and design choices. I did a lot more research in other widget set implementations - especially cross-platform widgets sets. I also did a lot of reading about graphics libraries and widget set design. I can count on one hand how many widget sets decided to follow the one-handle-per-form route compared to the truck loads of widget sets that implement a handle-per-widget method. Surely there must be a good reason for their design choice?

As a result I thought I would take a step back, before I take another step forward. Questions need to be answered! Being a personal issue to me, I thought I would invest the time to answer these questions (at least for my own curiosity).

Where are we now?
As a result, I started implementing a new version of the fpGUI widget set based on the one-handle-per-widget design. Redesigned the whole event loop process, removing the TEventObj etc... After two weeks of working on a new prototype fpGUI, I came to the conclusion that the new design is much better! As such, I made the new prototype fpGUI the new default fpGUI codebase.

• Cross platform. It now supports Linux, FreeBSD (including DesktopBSD) and Windows. My goal was that fpGUI must work identical under all supported platforms.
• fpGUI now supports 32-bit and 64-bit systems.
• The applications must not depend on huge external libraries (like GTK and Qt). Provide its services independent of any operating system or graphics environment. All painting gets done by the Corelib package.
• The fpGUI package only contains the high-level classes - no native drawing routines.
• Fully object-oriented where it makes sense.
• Anti-Aliased font rendering on Linux and FreeBSD (using Xft).
• Themeing support. Themes can be applied per Application, Form or Component.
  • Correct theme (native look) will be auto selected on each platform, but can be overridden.
• Really easy and developer friendly API to minimize the amount of code that needs to be typed. This will allow for easy creation of GUI applications without the need for a GUI Designer. (a lot more needs to be improved or abstracted though)
• Mouse wheel handling.
• I used a new prefix for all classes and methods. During my work with FPCanvas and FPImage I found our current prefix 'F' not being clear enough. A lot of FPC classes are named with a 'FP' prefix and our 'F' prefix was to close to that and made it difficult to distinguish between them. So it's now changed to the lowercase 'fpg'. fpg stands for fpGUI (Free Pascal GUI - the first letters of each word). It's now sufficiently different to FPC's names.
• OS based timers have been added.
• A blinking text cursor (caret) is now available.
• UTF-8 support has been added. UTF-8 text input doesn't work yet and only left-to-right languages are supported at this time.
• A new event queue was added. The old EventObj doesn't exist anymore. Instead I opted for the Object Pascal language features using messages, records and method pointers. Windows developers will feed right at home, though the implementation is different to how Windows messaging works. Developers can now send there own custom application messages as well. Very handy for component developers.
• This is a nice one. Thanks for the idea Lazarus! :) Internal standard images. See the /examples/gui/stdimages demo for the available images. They can be used in dialogs like ShowMessage, FileOpen and FileSave. Developers can also use the same global images list and add there application based images if required.
• Due to the new images, our buttons class (TfpgButton) now supports images as well. Most examples show this in action.
• The Canvas class also sports a new DrawImagePart() method which can take a image and paint on the canvas only a part (rectangle) of that image. So now we have the basis to build a new theme engine with composite images (something like WinAmp skins does).
• Text in edit and memo widgets can now be selected with the keyboard or mouse. Though clipboard support is still missing.
• Align and Anchor support has been added.
• Clipboard support (application wide). Global (OS based) is in the works.
• All painting is done via double buffering, so drawing flicker is a thing of the past.
• Better font support. We now have support for Font Aliases. We can define a font style (font name, size and attributes) and give it a text name. Whenever we want to use that font style, we can reference it by the text name.
• All colors are now defined in RGB order, no matter what platform we use.
• Modal form support (with some minor issues under Windows that should be fixed soon).
• Widgets and Forms now have a single consistent constructor due to the base window class that descends from TComponent.
• Delayed resource allocation. This is very handy under Linux where the X Server can be in a remote location (not on the same computer). This gives a performance bonus as we need to communicate less with the X Server which is inherently slow.
• Supports a Model-GUI-Mediator (MGM) implementation to work with the tiOPF Object Persistent Framework. Business Objects can now be saved in a OO fashion. The MGM implementation also makes the standard fpGUI components Object-Aware. No need for DB Components.
• fpGUI now has a Visual Form (GUI) Designer in the example/apps directory. Developers can now create forms visually at a much faster rate. The designer uses the same source file that contains your code - generating the ui code like you would have done manually. No external ui files like Lazarus (*.lfm) or Delphi (*.dfm). See the readme file in the project directory for more details.

Fig.1: Example of the Layout Managers at work. Click to enlarge.
This is a screenshot of the old fpGUI, but layout managers will soon be supported in the new code base. The second top red block shows a BoxLayout in a horizontal orientation. Group Box 1 shows a BoxLayout in vertical orientation and vertical fill mode. Group Box 2 shows a BoxLayout in vertical orientation, but this time a centre fill mode - spreading the buttons and centering them vertically.

Fig.2: Components autosized to fit new text. Click to enlarge.
A quick fake translation to demonstrate the autosize feature. Notice how the Label component increased in size and decreased the combo box next to it. Also notice how the right most button increased in width to allow for the larger caption. In the process the button to the left was moved horizontally to make space for the larger button, yet keeping the spacing between them constant.

Fig.3: Example of a very basic custom style. Click to enlarge.
A custom style has been applied to the form, changing the look of the Group Box components (single flat border line and underlined title) and a different Focus Rectangle. The rest of the components inherited the Windows Style.

Fig.4: Minimum Size of form Click to enlarge.
When resizing the form, the Layout Managers auto set the minimum size of the form, based on all it's child components and makes sure no clipping occurs.

Fig.5: fpGFX Bitmap Test. Click to enlarge.
This was done with direct manipulation of the bitmap pixel data.

Fig.6: fpGFX Hello World test.
Painting directly onto the window canvas.

Fig.7: fpIMG Blitting Mask test. Click to enlarge.

Fig.8: fpGFX running on a WinCE device. Click to enlarge.
The first screenshot of fpGFX running on a WinCE device. Here it shows the Hello World demo in action.

Fig.9: fpGUI UTF-8 test.
Paints correctly under Linux and any Windows 9x and up OS.

Fig.10: fpGUI Visual UI Designer. Click to enlarge.
You can now visually design your forms. The designer saves the user interface code into a normal *.pas unit as if you created the form via code. It can also handle multiple forms in a single *.pas unit.

Fig.11: fpGUI File Open dialog. Click to enlarge.
The standard File Open dialog. The File Save dialog looks similar.

Since 2009-04-04 the source code is stored in a Git repository on SourceForge. The old SubVersion repository will still be available for a week or two before it is disabled. You can get the latest code by executing the following command.

git clone git://fpgui.git.sourceforge.net/gitroot/fpgui/fpgui

The source can also be viewed online with your web browser. Use the following link: http://fpgui.git.sourceforge.net/git/gitweb.cgi?p=fpgui

Most of the documentation are skeleton docs at the moment, created by fpdoc. A few units have already been documented and I should be able to complete all the documentation over the next few weeks.

• Click here to view the fpGUI docs.

Due to SourceForge.net not being able to import my old message archives into the mailing list setup, and our company replacing a fault ADSL Router Modem, support is moved back to the News Server. I have tested the news server, and ask others to test it for me as well, and indeed it seems to have been the faulty ADSL Router that gave us all the timeout errors. Things are running smoothly again. Here follows the details for the News Server.

Server Name: opensoft.homeip.net
Port: 119

Available groups:

	fpgui.development	Discuss development of fpGUI itself.
	fpgui.support	Ask questions about using fpGUI.

For those behind a firewall, that can't access newsgroups. I have a web interface to the news sever at:
OpenSoft's WebNews

Bugs and Feature Requests can be submitted via the SourceForge Tracker. Please detail the steps to reproduce a software defect. If it's a painting issue, submit a small screenshot showing the affected area. Small example programs reproducing the problem can also help.
The tracker is located at the following address:
http://sourceforge.net/tracker/?group_id=182330

The widget set is under a Modified LGPL license (like Free Pascal's RTL). This means you can link dynamically or statically to fpGUI without releasing your code. Only the changes to fpGUI needs to be made public. This allows you to use fpGUI in commercial applications as well.

We still have some missing features that were available in the old fpGUI, but things are moving fast. We already have components not previously available. Missing components will be a short lived issue.

Available components (and growing):

• Button (with image and flat look and grouping support)
• Label
• Bevel
• Panel
• Group Box
• Radio Buttons
• Check Boxes
• Track Bar (aka Slider)
• Track Bar Extra (variation in look and function of standard track bar)
• Page Control (aka Tab Control)
• List Box
• Color List Box (with predefined color schemes)
• Scrollbars
• Memo
• Forms (windows): Normal, Modal and Popup.
• Dialogs
  • ShowMessage()
  • Font Selection dialog
  • File Open...
  • File Save As...
  • Directory Select
  • Color Select
  • About Dialog
  • Message Dialog (info, question, error, general)
  • Input/Prompt dialog
  • New Directory dialog
  • Database Login dialog
• Text Edit
• Currency Edit
• Integer Edit
• Float Edit
• Combo Box (aka Choice List)
• Edit Combo Box
• Grids (aka Tables)
  • Base Grid
  • Custom Grid
  • Draw Grid
  • String Grid
  • File Grid
• Progress Bar
• List View (partially implemented)
• Main Menu bar and Popup Menus
• Treeview
• Calendar control
• Calendar Combo Box
• Gauge (pie, needle, horizontal, vertical, text and dial)
• Splitter
• Color Wheel
• Value Bar (normally used with color wheel)
• TextEdit (something like SynEdit but still work-in-progress)
• Splitter
• Basic Theme/Style manager (Windows 2000 is currently the default style used)
• Animation control (something like animated gifs)
• HyperLink label
• MRU (most recently used files) Manager
• DBLabel (just as a demo that DB components can be created)
• Spin Edit
• Spin Edit Float
• Hint window (customizable including drop shaddow)

Outstanding features:

• Label component needs to be enhanced to allow for keyboard shortcuts and underline the keyboard shortcut letter.
• Toolbar component needs to be created. (already possible with embedded buttons, but must create a dedicated component)
• Complete all theme styles:
  • Windows 2000 (default style used)
  • Windows XP
  • Motif
  • ClearLook
  • OpenSoft
  • Bluecurve
  • image based
• Create a Style Factory to register all styles with. The factory will also create the styles.
• Implement '--style' parameter to override the default (auto detect) style.
• Implement '--display' parameter so any fpGUI/X11 application can override the defaults display used.
• Layout Managers (BoxLayout,GridLayout and FixedLayout). This is a very important feature. It completely removes the burden off the developer to position controls in correct locations or keep their size correct. It prevents text or controls being clipped, when the application gets translated or forms get resized. Components are also always aligned correctly, nothing needs to be done by the developer. The forms/dialogs automatically have their minimum size set so all controls will be visible.
  FixedLayout allows you to position controls at exact locations (as you normally do with GUI designers like Lazarus), but still mantains the MinSize property for you.
  I'm also busy porting the MigLayout layout manager which is a grid based layout manager, but is extremely flexible and doesn't require nested layout managers.