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...
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
fpGUI v0.7 (final release) is out.
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.
This is a status update of what is happing with the fpGUI project, for those
that didn't follow all the newsgroup posts over the last month (June 2007).
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
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
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
- 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
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.
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
||Discuss development of fpGUI itself.
||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:
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:
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
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)
- 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)
- Forms (windows): Normal, Modal and Popup.
- 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
- Calendar control
- Calendar Combo Box
- Gauge (pie, needle, horizontal, vertical, text and dial)
- Color Wheel
- Value Bar (normally used with color wheel)
- TextEdit (something like SynEdit but still work-in-progress)
- 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)
- Label component needs to be enhanced to allow for keyboard shortcuts and underline the keyboard
- 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
- 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.
allows you to position controls at exact locations (as you normally do with
GUI designers like Lazarus), but still mantains the MinSize property
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